Email Spam Tools
Attackers uploaded PHP source code that seems specifically designed to send spam email. Upon upload, the spam tools immediately get called with what looks like well-known addresses to test them.
qq.php
qq.php arrived as a file uploaded to WSO from 188.165.215.67, four different times: 2013-06-26T10:33:35-06, 2013-06-26T11:36:41-06, 2013-07-02T09:02:19-06, 2013-07-02T10:22:07-06.
Invoked 21 diffent times after upload, by 188.165.215.67 and 88.198.1.37, 4 times on 2013-07-02, 15 times on 2013-09-13T and two times on 2013-09-25. The first 4 invocations by 188.165.215.67, the rest by 88.198.1.37.
p0f identifies 188.165.215.67 as "Windows Vista SP0/SP2, 7 SP0+, 2008 SP0". p0f identifies 88.198.1.37 as "Linux 2.6 (newer, 3) or Mac OSX 10.3.1 (possibly FC 6, CentOS 5.x)". I don't know what to make of the nearly 2-month gap between uploading qq.php. and 88.198.1.37 invoking it.
I had ended my honey pot experiment by September 13, so I don't have any data on what got sent to qq.php by 88.198.1.37. The four attempts at invoking qq.php by 188.165.215.67 were all clearly intended as tests of my honey pot host's SMTP system. The four invocations of "qq.php" had two each using "stratigery.com" and "www.stratigery.com" as the host name part of the URL. The POST parameters passed to qq.php involved a parameter named "body", with values like this:
<html><head></head><body>TEST http://www.stratigery.com/wp-content/uploads/2013/06/qq.php<br/> </body></html>
and
<html><head></head><body>TEST http://stratigery.com/wp-content/uploads/2013/06/qq.php<br/> </body></html>
That constitutes an SMTP test. It seems to me that using gmail.com as an SMTP server and email reader would prevent you from seeing some or all of the relevant SMTP headers. Perhaps it isn't worth the risk of running your own SMTP server to see them. Apparently, "davidberns60@gmail.com" is interested in the contents of these emails.
The qq.php. source code is just a wrapper around code from the open source PHPMailer project. Values of $Version in the code indicates PHPMailer version 5.2.2, and it has no comments - they've all been stripped from the code.
accountTu39
A fairly versatile spamming tool, accountTu39.php allows the user to send batches of SMTP emails to a list of (firstname, lastname, email address) tuples, specify a subject and message body, and customize the subject line and message body by macro substitution of the victim's first name and last name in both. Extra HTTP parameters allow the user to send base64-encoded HTTP parameters to accountTu39.php, and get debugging output from spamming sessions.
The original upload has a weird attempts at obfuscation - all functions and variables got renamed mechanically, all comments stripped out, all indentations and end-of-line characters removed. Seems like a corporate-style obfuscation, since it doesn't involve eval() or preg_replace() executing base64-encoded PHP.
This code has self-contained SMTP implementation, complete with multiple fall-back alternatives to create a socket. It probably runs on many PHP versions, and isn't Windows or Linux specific. The code also allows the names in HTTP POST request name/value pairs to take on arbitraray values: only the first character in a name matters. This is probably an attempt to avoid intrusion detection systems when invoking a freshly installed accountTu39.php.
This code arrived 2013-06-24T09:51:03-06, via WSO "uploadFile". By 2013-07-01T13:35:38-06, the same IP address was uploading an evolved version. Because the obfuscation makes development almost impossible, it would seem that the attackers have the original, unobfuscated code, develop that, and re-obfuscate.
The attachers invoked accountTu39.php 3 times in the next 4 seconds after upload. These invocations were pretty clearly a test run, sending The string "Do you remember me?" to robotsk@stat-run.info. The nominal sender of the test email is one "John Smith", infozz@stat-run.info. Once again, we note multiple attempts at failure-prone operations.
823491.php
Just for variety, someone from 91.213.8.225 uploaded (only a single time, via WSO shell) an interactive bulk email web page. The other email spamming tools don't even pretend to offer a human-user-interface, but this PHP generates a plain, but serviceable, human interface. It might be possible to use it programmatically, as people certainly use the WSO web shell as a file uploading service. I have no record of it any invocation.
The upload of 823491.php. seems automatic: 91.213.8.225 made 4 HTTP requests in 3 seconds. The sequence went like this:
- GET mod_menu.php, the WSO web shell file name.
- POST pass=FDY17c to mod_menu.php: send it a password. WSO, and my emulation, set a cookie based on the MD5 hash of the hostname, and the MD5-hashed password.
- Upload 823491.php file to WSO, using the "uploadFile" action of WSO. Send the cookie from step 2 along in HTTP headers.
- Re-invoke mod_menu.php, sending the cookie from step 2 along in HTTP headers.
Steps (1) and (2) can actually be circumvented by sending an extra HTTP parameter, something like pass=45000045, in the step (3) call to "uploadFile" action. WSO doesn't check if a user retrieves a login page first (step (1)) or if the login cookie gets set with an extra parameter while requesting an "uploadFile". Other code does this exact circumvention.
The "default action" of WSO web shells is "FilesMan", which ends up displaying a listing of WSO's working directory. This is also the directory that the file named "823491.php" should appear. Unfortunately, my emulation code would only show "823491.php" in the files listing in the HTML returned to 91.213.8.225 after step 3. The extra invocation of mod_menu.php in step 4 wouldn't show "823491.php" in the directory listing. I suspect this caused the program at 91.213.8.225 to assume an error or a trap, and just move on. Very clever, Mister Bond!
This interactive spamming tool has some interest in that it was not installed via WSO "uploadFile" action, but rather arrived along with a WSO file, and an SMTP recon program in the attacker's favorite "Tumblr Importer" plugin. Attackers invoked the SMTP recon program immediately after upload. That got a WSO login page, as I did not emulate the SMTP recon program. PostMan Full 3.5 was never invoked.
Googling for "PostMan Full 3.5" yeilds some interesting things. The copy downloaded to my honey pot claims that it's "by Ghostx", and other copies do too, but some claim they're by "<<<AZ>>>", or "unknown" or "Januardy" or "r3v3ng4ns".
That matches up with the internals - the code is clearly hacked on by many. The actual SMTP email is done by a very early (circa 2003) version of the PHPMailer. The PHPMailer code is clearly supposed to be password-encrypted, but someone along the way has changed whatever password encryption previously existed into a simple, password-less, character-replacement scheme. There's a cryptic comment (in English and Portugese) at the start of the code about how "YOUR PASSWORD IS ONLY YOURS!" and you're not supposed to share it. So much for showing respect to fellow spammers or "bulkers" or whatever self-serving euphemism they use now.
After leaving the HTML for a defanged "PostMan Full 3.5" available for a few days, I note that HTML gets hits by referral from Google. It appears that people google for some identifiable phrase in the HTML, visit the URLs provided, and send spam emails via "PostMan Full v3.5" as installed by some other miscreant. It may be worth including an emulated "PostMan Full v3.5-insec" PHP program in future honey pots, just to draw spammers and see what they send out.
Some folks test PostMan Full 3.5, trying to get it to send a test email to an address multiple times. Others appear to just use the form indiscriminately.