Yesterday we came into a spam malvertisement of login credential stealer (Trojan Win32/Fareit) which looks like sent from an infected PC in a local network of US's Department of Defense, and also looks relayed via their email sever. Below is the snapshot of the email:
And this is the written header for relaying this malvertisement:
You can see is a common spam of malware campaign, inside of the ZIP file there is an executable PE file which actually a Trojan Win32/Fareit, an FTP, FileZilla, Browser, Remote Directory, Email and Faceook's login credential stealer.
The distributed Trojan: Win32/Fareit
Well to be brief, the trojan itself runs as per the below video and downloading two Zeus variant malware files from remote host, send the grabbed our login data to a remote credential panel (we call it gates) URL, and in the end to make our PC becoming a part of Zeus botnet.
Below is some evidence I grabbed, the panel sent with credentials:
h00p://nursenextdoor.com:443/ponyb/gate.php h00p://dreamonseniorswish.org:443/ponyb/gate.php h00p://prospexleads.com:8080/ponyb/gate.php h00p://phonebillssuck.com:8080/ponyb/gate.phpThe POST method use to send the credential:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/5.0) POST %s HTTP/1.0 Host: %s Accept: */* Accept-Encoding: identity, *;q=0 Accept-Language: en-US Content-Length: %lu Content-Type: application/octet-stream Connection: close Content-Encoding: binary User-Agent: %s Content-Length: Location:The encoded posted traffic contains credentials:
The downloaded another files malware (ZeuS/Zbot) URL:
h00p://www.lavetrinadeidesideri.it/Twe.exe h00p://ftp.aquasarnami.com/zKo.exeAnd the HTTP method it used to download them:
GET %s HTTP/1.0 Host: %s Accept-Language: en-US Accept: */* Accept-Encoding: identity, *;q=0 Connection: close User-Agent: %sPoC of the downloaded Zeus:
And with be saved in here by the Win32/Fareit:
↑These are Zeus malware alright. Confused a bit with the spambot and FakeAV but thank's to Xylit0l & other friend who remind me to recheck.
The overall samples and its detection ration in VT (click the MD5) is here:
2013/07/17 18:44 158,720 c7e5b822101343c1a4d8a2297a1a7d40 CommBank_Docs_18072013.exe 2013/07/18 19:18 205,824 1427015ba8d9736e6329ea0444bb300c Twe.exe 2013/07/18 20:01 315,392 0ac084b9fa597c74ea1260ed054b126e zKo.exe
Wrote a deeper analysis of the malware attached and can be viewed here-->>[KernelMode]
How far can they spoof?
Excluding the rogue contents used in the email. It is a common practice of these scammer to spoof: (1) Sender's email address, (2) Email's message ID, (3) The mail client information or even (4) The fake MIME version used in the header (these are marked red color numbers in the below picture).
With noted: They can fake "almost" everything even like the character set used (see the blue color part), see the following explanation for this details.
If we see the email routing header used in this spam, seems like the email was relayed two times before it came to my honeypot address. Let's see the routing information clearly which I marked in the above picture in purple color highlight. The first relay (which is the lower part) looks like a client in a local network with the IP mask 192.168.8.0/24 sent this email to a reached network's MTA, in this case is: 143.214.203.103 to relay this spam to another remote MTA in 69.199.182.82 then it was relayed to my honeypot mail server to my address.
So what happen after a an unix admin or engineer after seeing this? Oh, it looks like some malware infected a client in 143.214.203.103, which after checking further is the IP 143.214.203.103 is at the US DoD's network:
OK, this was a shock and a fact that hard to believe myself, so I tweeted this as per below:
And got no response to deny this, UNTIL...Pls tell me "why?" US DOD's IP address can be used to relay email #malware? https://t.co/czcRPoIxYt #MalwareMustDie! pic.twitter.com/UY7x1faMva
— MalwareMustDie, NPO (@MalwareMustDie) July 18, 2013
A fellow researcher (thank's to @snixerxero) contacted me for the possibility of spoofing for those email routing header. After looked back to the header again and the way it's written, I replied "No way, looks real to me, you must be wrong!", and he came with the related template of the Cutwail (Reference of Cutwail is here -->>[LINK])spambot as a PoC (with many thanks) as per I pasted below:
Received: from [{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}
{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}
{NUMBER[0-5]}] (port={NUMBER[1-9]}{DIGIT[1]}{DIGIT[1]}{DIGIT[1]}{DIGIT[1]}
helo=[192.168.{DIGIT[1]}.{DIGIT[1]}{DIGIT[1]}]) by {BOT_IP} with asmtp id
1rqLaL-000{SYMBOL[1]}{SYMBOL[1]}-00 for {MAILTO_USERNAME}@{MAILTO_DOMAIN}; {DATE}
Surprisingly THIS template match well to the values of the DoD header routing's data below:
Received: from [143.214.203.103] (port=30877 helo=[192.168.8.11]) by 69.199.182.82 with asmtp id 1rqLaL-0002D-00 for xxx@xxx; Wed, 17 Jul 2013 15:26:40 -0500This information is also breaking the ice of the template code as per below details:
1. The IP addresss spoofed template:
{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}.{NUMBER[1-2]}{NUMBER[0-5]}{NUMBER[0-5]}
please see the REGEX-like values used.
2. The port number template(format):
{NUMBER[1-9]}{DIGIT[1]}{DIGIT[1]}{DIGIT[1]}{DIGIT[1]
as per IP template, noted the digit per digit used to plot this number, a good hint in reversing.
3. We came into most important part, the way this spambot fakes the email relay log ID with the below template:
by {BOT_IP} with asmtp id 1rqLaL-000{SYMBOL[1]}{SYMBOL[1]}-00 for
This will print the fake relay log ID below:
by 69.199.182.82 with asmtp id 1rqLaL-0002D-00 for xxx@xxx; Wed, 17 Jul 2013 15:26:40 -0500Which explains us that 69.199.182.82 is the ACTUAL SpamBot IP of the Cutwail and there are never bee any relay of these malvertisement in 143.214.203.103 at all.
Mitigation
By understanding the template used by the spambots, we can do many things for blocking these spambot's malvertisement in the SMTP layer. Sadly, like happen to this case, mostly are in the crypted or encoded XML and can not be seen right away. we should pay more research attention and spread to all filtration industry the discovered spam template. for another example of ANOTHER spambot template.
Recently, we had a case where we popped and exposed one of the template while we nailed a Kuluoz network in this case here -->>[PASTEBIN].
In that case we decrypted (yes.. that one was not encoded but encrypted, so we did not decoding it) the spambot template and showing the below spoof email header as per below:
↑In this case we see the spoofing of the Outlook Express email client (MUA) used. Please noted the fake character set used.
Back to our original case, in the template at the relay log ID parts, we can see the below "static" strings used:
with asmtp id 1rqLaL-000and we know this is the unique string of template that I received (which was explained as Cutwail spambot's) template, so let's see "how many" and "what kind of spam" they altready sent us by using this template. I just grep that static strings into my spam database (is a mailbox collection I made of those botnet sent garbage to my honeypot) as per picture below:
These are the snapshots of recent ones (click to enlarge the picture) :
See the one with my name printed in the zip file?
One of the spambot template is implemented in he attachment filename, to be precise, like this one:
The above additional three samples are attached with Fareit, Fareit and Fareit.
So we know each other now (smile), and we know also WHO's crime group moronz is using WHAT and spreading WHICH malware mess now. We're getting closer to nail these scums for good. To these moronz, go and send me more of your spams! :-)
Sample
We share this information to common people and security researcher for raising the understanding & detection ratio in the SMTP methodology filtration for these threat.
I attached the samples I gain for the research purpose only by security experts in here-->>[MediaFire]
#MalwareMustDie!
Additional:
I credit the wonderful support from all fellow researchers who help this analysis and MalwareMustDie project in general, we won't make it this far without all of you.
I dedicated this writing to the incoming event of DEF CON and BlackHat 2013, I am still struggling to figure how to attend it, hopefully I can make it, God knows how much I wanted to go and meet many good friends in there (believe me), is just my health and my tight day work schedule is an obstacle to overcome.. But if I can't make it I will surely go to DerbyCon this year.