Introduction
For years, I had dutifully read through my personal web server's log files. I had seen something with a User-agent of "ZmEu" get 404 codes hundreds of times. I had seen IP addresses try to log in to non-existent WordPress blogs thousands of times. I decided to try my luck at capturing some of what the folks trying to log in to WordPress had to offer.
Between May, 2013 and September, 2013 I ran a WordPress honey pot. This documents the malware that people downloaded to that honey pot. I'm writing it down to ensure that I have a clear picture of what went on while I ran the honey pot.
Previous to the more complete honey pot, I had written a PHP tarpit to observe HTTP requests from the "ZmEu" phpMyAdmin vulnerability scanner. I also had a WordPress login page that just caught login attempts. After that, I did a WordPress 3.5 lookalike. Although it got scanned for log ins many times, nothing got downloaded. I moved to a honey pot that closely resembled WordPress 2.9.2. It looked just enough like real WordPress to fool some entities into interacting with it. The honey pot showed a few posts, it appeared to register users, it appeared to allow any username/password combination in as the administrative user. It appeared to allow theme and plugin upload, which it always said succeeded. It appeared to allow new posts.
I logged HTTP requests, ran a p0f passive OS detector, and had my emulated code log a large amount of detail. I organized all this data in a relational database. Because of the database, I can match downloads to IP addresses and methods of download. I can see what called a downloaded program, when, and with what HTTP parameters. Further, I captured PHP code that otherwise doesn't reside in the filesystem at all.
I hope to include enough detail about the honey pot to be believeable, yet not rehashing code analyses done better elsewhere. I do include my own analyses of pieces of code that I can't find analyzed or reported elsewhere, or to make a point about how the WordPress malware world seems to work.
Running an Effective WordPress Honey Pot
I have evidence or experience to back up the following assertions or advice on honey pot niceities. But your mileage may vary. Let me know if you have good or bad experiences with the following tips.
All of your emulated WordPress pages should save the contents of PHP globals $_SERVER, $_REQUEST, $_COOKIE and $_FILES. The latter global allows your code to save any uploaded files, and all emulated WordPress pages should save uploaded files. You should handle HTTP cookies exactly as WordPress does, generating cookies on "successful" login. If you can track these WordPress-login-cookies, you can see what IP address performed the first login versus what address used that login cookie.
My honey pot allowed any user ID/password to login as the WordPress admin user. I've not decided if this was a good idea or not. Perhaps only allowing logins after a small number of consecutive attempts, or randomly allowing a small percentage of log in guesses in would allow a honey pot to capture more malware.
Allow registration of mere users. Allow theme editing and plugin uploads, always claim success. Include new post uploading in your WordPress emulation. It will entertain.
Install a WSO ("FilesMan") web shell emulation. A lot of entities use WSO as an uploader. It may be worth your while to make the WSO emulator the default for any ".php" URL under ./wp-content/. That is, invoke the WSO PHP instead of just giving out an HTTP 404 code. The WSO emulation needs to be able to look like remote users log in, accepting any password. Your WSO emulation should probably show recently uploaded files in the "File Manager", as some uploaders apparently invoke WSO's "FilesMan" action in a second invocation after an upload to check that the file arrived correctly.
It will probably pay off to save any files that a remote user tries to upload to URLs ending in 7c334.php or 7c34.php. These are common names for a generalized backdoor that doesn't save anything to the filesystem. You'll also have to watch for name changes to keep up with this thing.
It's possible that emulating theme editing adequately would trick attackers into downloading more malware. My honey pot did not emulate theme editing at all well, but attackers tried to edit themes anyway.
Observations
- Guessing passwords is important enough to create password-guessing distributed computations.
- Code makes multiple attempts at error-prone or tricky operations before treating that operation as failed.
- Code accomodates execution on multiple versions of PHP, and usually Windows and Linux.
- Crippling bugs and non-working order of operations abound.
- Some attackers do not want their code to appear in files.
- Knowledge of working user IDs and passwords, and successfully installed malware is passed around or sold.
Summary
Access to WordPress is obtained not by hacking or exploits, but rather by guessing the admin user's password. Single machine and apparently coordinated multi-machine guessing attacks happen. Some password guessing programs appear to be poorly written and buggy, others exist that try an exploit immediately upon logging in. My WordPress login emulation allowed in any user ID/password combination as an admin user, which may have discouraged the use of exploits.
Registered users do all new post spam. All spam is about some given topic, but the keywords and hyperlinks are not related. A variety of hyperlinks appear in spams.
The WSO web shell gets installed various ways, and then used to upload more pieces of malware. WSO web shells don't usually get used interactively, but rather by programs. Many versions of WSO are in current service. Folks try to obscure or camoflage WSO in many different ways.
People upload email spam tools, file retrieval gateways, generalized back doors and reconnaissance tools. On occasion, the IP address that guessed the password does not install any of the malware. Invocation of the malware can come months after install.
The generalized backdoor gets used to run email spamming tools slightly customized to just do SMTP function checking, a specialized use of general tools to do reconnaissance. I didn't rapidy analyze and emulate downloaded malware, so any SMTP testing failed. It's possible that additional spamming did not take place because the tests failed.
Most WordPress malware appears to be Linux-specific, or at least always chooses Linux-specific alternatives when OS-independent PHP APIs fail to work. Sometimes malware includes its own version of functions that are now part of PHP itself. Malware often tries several alternatives for functions like sending email. These appear to be coding for robustness in the face of many different versions of PHP in the wild.
Either the malware or the hosts it runs on aren't very reliable. Risky operations often get tried at least twice without the malware code treating API failures or HTTP 404 errors as real exceptional conditions. Attackers appear to use code without understanding it, which can lead to situations where attackers perform actions that will never succeed, or tasks get performed in a repetitious, inobvious and inefficient manner.