Posted November 6, 2015
Fake Abuse Policy CryptoWall 3.0 Campaign: Domain “Suspension Notice”
By Steven Weinstein
The LookingGlass Cyber Threat Intelligence Group (CTIG) observed new and unexpected behavior with a CryptoWall 3.0 malspam campaign. In this exploit, we see CW 3.0 attempting to convince users they received a suspension notice of a specific domain registered on Enom. The email contained a purported link to download a copy of the complaints received about abuse policy violations but actually downloads an Anti-Virus executable instead.
Here are some of the details from the email header:
Received: from smtpo66.poczta.onet[.]pl (141.105.16[.]16)
While this campaign isn’t “targeted” in the sense that only a few certain users received it, it is targeted in the sense that recipients of these convincing emails actually own (or are affiliated with) the domain mentioned in the email – it wasn’t just random data. The CTIG believes that attackers have scraped Whois records to identify domains not registered with privacy protection, along with their contact addresses. As such, the domain and registrant name has been redacted from the above image to protect the victim’s privacy.
As we expected, the link to the copy of complaints (hxxp://kakabrinquedos[.]com/abuse_report.php?REDACTEDDOMAIN.COM) does not actually download complaints – instead it downloads a file via “[DOMAIN]_copy_of_complaints.pdf.scr” which uses the terribly low quality PDF icon (I would have expected a better icon given the convincing nature of the email campaign):
The file is actually a PE (portable executable) file that happens to be CryptoWall 3.0. Looking at the file details on VirusTotal (SHA256: 968b4196632e91164a05c4a40d317f6145ea3c0e20cbde0860d56b3ec91dacb6), we can see many other submissions of this same file with different filenames from different victims:
Upon execution, CryptoWall acts as we expect:
- It adds itself into a new folder on the C drive, at C:\5eba06f2\5eba06f2.exe,
- It adds itself into the Application Data folder at C:\Documents and Settings\Administrator\Application Data\5eba06f2.exe
- It adds itself into the Startup folder at C:\Documents and Settings\Administrator\Start Menu\Programs\Startup\5eba06f2.exe for persistence on reboot
- It disables shadow copies:
- It injects itself into running processes like svchost.exe and explorer.exe
- It communicates with ip-addr.es to obtain the externally facing IP address of the victim machine
- Makes HTTP POST requests to predetermined C&C servers trying to obtain the public key needed for encrypting files
By creating a memory dump of the running svchost.exe process, we can identify numerous domains (most are compromised WordPress sites used for C&C) that we observed DNS requests made to. This list mirrors those found by Conrad Longmore: http://blog.dynamoo.com/2015/10/malware-spam-domain-domain-suspension.html
Also in the process memory are anticipated POST requests (although only a few POST requests were actually made – example in more detail shortly):
This pattern of POST request is indicative of CrytpoWall’s initial check-in or “Hello” to the C&C server. RC4 encrypted data is sent to the C&C with the key passed as the parameter at the end of the URI.
POST /wp-admin/js/5d8gMe.php?l=mfrnuqe88zk HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET4.0E; InfoPath.2)
In the above example POST request, the body is RC4 encrypted and can be decrypted to reveal the following:
This shows us the command ID, the campaign ID, a unique MD5 calculated from the victim’s host characteristics, some additional information about the victim machine, and the victim’s external IP address.
At this point, what we’d expect back is an acknowledgement from the attackers, and then our infected machine would make another request, this time for the encryption key. However, this did not happen for us, and things took an interesting turn.
Instead of receiving the standard acknowledgement back, we curiously received an executable.
Initially we had thought that the CryptoWall gang may have changed their TTPs to download additional malware, but when we took a closer look at the returned executable (SHA256: ae1987b17b81d3f285b9ddc4e3e1cbd148b80337b9dcae807679d83bd2c09628), we started to understand what was happening. This legitimate (and signed) executable is the Avira Launcher, which installs Avira’s Anti-Virus program.
Checking this hash on VirusTotal revealed that it had indeed been the content retrieved from numerous other domains we found in our traffic capture and in memory from the dumped svchost.exe process. We can even see that it actually is the legitimate executable delivered directly from the Avira website as well.
Looking back at our traffic capture, we can also see POST requests to these domains that resulted in 302 redirections directly to the Avira download location:
While it initially appeared that that Avira is involved in a takedown effort against these CryptoWall attacks by blocking the malware from encrypting victim machines by distributing their AV software, our friends at Avira have confirmed no involvement in the matter.
The content of an example PHP file from an infected server returning a 200 response code with the body containing the launcher executable is below:
This rules out any suspicion of IP blacklisting or geo-IP specific payloads because the PHP script did not contain anything other than a command to retrieve the Avira launcher, regardless of what machine communicates with the C&C. This leads us to believe that other security researchers (or the hosting provider – HostGator) may be attempting to take down the botnet by sending the AV launcher to victim machines in order to remove the infections.
Although these C&Cs are serving legitimate Avira executables which are harmless, the LookingGlass CTIG still recommends blocking all of the above listed domains on your corporate networks, as well as the IP addresses they resolve to:
LookingGlass ScoutVision had identified all 24 of the above IP addresses as C&C servers as early as October 22, 2015.