Increase in CryptoWall 3.0 from malicious spam and Angler exploit kit

Published: 2015-06-11
Last Updated: 2015-06-12 02:33:38 UTC
by Brad Duncan (Version: 1)
7 comment(s)


Since Monday 2015-05-25 (a bit more than 2 weeks ago), we've seen a significant amount of CryptoWall 3.0 ransomware from malicious spam (malspam) and the Angler exploit kit (EK).

A malspam campaign pushing CryptoWall 3.0 started as early as Monday 2015-05-25, but it has increased significantly since Monday 2015-06-08.  The CryptoWall 3.0 push from Angler EK appears to have started around the same time.  Both campaigns (malspam and Angler EK) were active as recently as Wednesday 2015-06-10.  

The timing of these campaigns indicates they might be related and possibly initiated by the same actor.

Below is a flow chart show the paths to infection from each of these campaigns:

Shown above: Path 1 shows the infection chain from the malspam - Path 2 shows the infection chain from Angler EK.

CryptoWall 3.0 from malspam

This campaign has been using Yahoo email addresses to send the malspam.  So far, all the attachments have been named  The first week of this campaign, material extracted from the zip attachments were all HTML files named my_resume.svg.  At that time, the CryptoWall 3.0 ransomware was downloaded from a compromised server.  This week, the extracted HTML file names use random numbers, with names like resume4210.html or resume9647.html.  Furthermore, the CryptoWall is now hosted on various URLs.

Shown above: some of the emails seen starting on 2015-05-25 through 2015-06-08.

Shown above: examples of the malicious spam.

Opening the attachment and extracting the malicious file gives you an HTML document.  An example is shown below:

Shown above: an example of the HTML file inside the zip attachments from the malspam.

Here are some of the URLs from the unzip-ed HTML files on Wednesday 2015-06-10:

  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=288
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=296
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=490
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=609
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=161
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=191
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=579
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=177
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=317
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=586
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=623
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=861
  • - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=873

If you open one of these HTML files, your browser will generate traffic to a compromised server:

Shown above: Traffic from an HTTP GET request to one of the compromised servers.

The return traffic is gzip compressed, so you won't see it in the TCP stream from Wireshark.  Exporting the text from Wireshark shows HTML that points to a shared document from a Google server:

Shown above: HTML returned after the GET request pointing to

Here are some of URLs we saw from the traffic on Wednesday 2015-06-10:

  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztV2ZrMGZTWFRnLU0
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztUmFCOGlteHdncWs
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztTnEzNnFfZktRZUk
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztdVU2RXZSeUlla00
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztczFQSWo4TWFtVnc
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztcklyU2dKdXRJdlE
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztcDEyZEg0QkZuYms
  • (https) - GET /uc?export=download&id=0BzNnVzs5RTztaTNtOTJyd1hCejg
  • (https) - GET /uc?export=download&id=0B-HWsX8wPhPFZDk2dms3c2plZk0
  • (https) - GET /uc?export=download&id=0B-HWsX8wPhPFVTNpNTJneHJKazQ
  • (https) - GET /uc?export=download&id=0B-HWsX8wPhPFQzJsSmYtdERrZ1k

Examining the traffic in Wireshark, you'll find see a chain of events leading from the compromised server to

Shown above: Wireshark display one of the GET requests to a compromised server.

Run the downloaded malware on a Windows host, and you'll find traffic that's typical for CryptoWall 3.0.

Shown above: Wireshark display on some of the CrytpoWall 3.0 traffic.

The bitcoin address for ransom payment by this malware sample is 16REtGSobiQZoprFnXZBR2mSWvRyUSJ3ag.  It's the same bitcoin address from a previous sample found on Thursday 2015-06-04, when we were first notified of this particular malspam [1].  We also saw the same bitcoin address used on Tuesday 2015-06-09 [2] associated with another wave of malspam the following week.

Shown above: Decrypt instructions from the CryptoWall 3.0 sample.

CryptoWall 3.0 from Angler EK

We first noticed Angler EK pushing CryptoWall 3.0 on Tuesday 2015-05-26 [3].  I posted a diary about it on Thursday 2015-05-28 [4].  This was the first time I'd seen version 3.0 of CryptoWall sent by Angler.  I seen previous versions of CryptoWall from Angler, but not 3.0 until this campaign.

My last documented instance of Angler EK sending CryptoWall 3.0 happened on Tuesday 2015-06-09 [5].  We're still seeing examples where CryptoWall 3.0 came from Angler as recently as Wednesday, 2015-06-10.

In each case I've documented, the bitcoin address for the ransom payment was 16Z6sidfLrfNoxJNu4qM5zhRttJEUD3XoB.

Angler EK is still being used by other groups to send different malware payloads.  However, the appearance of CryptoWall 3.0 in Angler since 2015-06-26 using the same bitcoin address indicates this is a separate campaign by a specific actor.

This week, compromised websites that redirected to Angler had code injected into their web pages, much like the example below:

Shown above: Malicious code injected into a page from a compromised web server (points to Angler EK).

A fellow security professional notified me this is a common injection technique used on WordPress sites that have been redirecting traffic to Angler EK.

The image below shows the 2015-06-09 Angler EK traffic and CryptoWall 3.0 post-infection activity as seen in Wireshark:

Shown above: Wireshark display on Angler EK and the post-infection traffic by CryptoWall 3.0.

Final Words

The timing of these two campaigns, along with their consistent use of the same bitcoin addresses for the ransom payment, suggest they are related.  They may have been initiated by the same actor.  This is a significant trend in our current threat landscape.  We will continue to monitor this activity and report any significant changes in the situation.

Update - Thursday 2015-06-11 at 01:13 UTC

I generated more Angler EK traffic on 2015-06-11 at 00:09 UTC.  This time, I got a sample using a different bitcoin address than I'd seen from previous Angler-based CryptoWall 3.0 payloads.  This bitcoin address, 12LE1yNak3ZuNTLa95KYR2CQSKb6rZnELb, began transactions during the same timeframe as other samples associated with this campaign.

At this point, I'm not 100 percent certain it's the same actor behind all this CryptoWall 3.0 we've been seeing lately.  However, my gut feeling tells me this activity is all related to the same actor or group.  The timing is too much of a coincidence.

Traffic and the associated malware can be found at:

The zip file is protected with the standard password.  If you don't know it, email and ask.

Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



7 comment(s)


We received a sample of what appears to be same attachment. Made it past our cloud antispam provider but desktop AV caught it (of course user clicked on it). I uploaded the sample here:
Thanks! I haven't noticed any malspam yet that's associated with this campaign today (2015-06-11). We're keeping an eye out for it, though.
Someone emailed the handlers list about an oversight in my flow chart. For the malicious spam (Path 1), after the user downloads the zip file containing CryptoWall 3.0, the user must execute the malware before the computer is infected. The user has to double-click on the extracted file. User action is required in this case.

In Path 2, the exploit kit will automatically execute the downloaded payload behind the scenes. No user action is required. At least, no user action is required after viewing the compromised website that starts the infection chain.
The exploit kit can but only run the payload if one of it's exploits works.
On a fully patched system it will fail.
It will also fail if your benelovent dict^Wadministrator or you has/have set the NTFS ACE "(D;OIIO;WP;;;WD)" on all/your user profile(s), or has activated SAFER/AppLocker.

Go figure!
The cryptowall trafffic seems to have change. It was img[\d]\.php\?[\w]\=[\w]{6,} POST traffic without any referrer for about 6 months

This is the first time your post is showing a different traffic g[\d]\.php\?[\w]\=[\w]{6,}. They have change the img to g.

New angler traffic seems even more difficult to detect than before. It seems to look so much like a legitimate traffic that any alerting attempt will generate a good amount of false positive; how are u guys detecting angler landing page?

EDIT: any idea whats the [[[[ redacted ]]]] referrer in the angler pcap about?

Any redacted sections are parts I had to remove (to "redact") because I don't have permission to share that information.


True, on a fully-patched system, the exploit will fail, and the computer won't be infected. Your comments also describe a properly-run enterprise environment. However, a significant amount--probably the majority of Windows computers--are run by home users, who are prone to using vulnerable applications, not updating their systems, and running as administrative users. This is an environment ripe for exploitation by exploit kits such as Angler. That is also why exploit kits continue to be an issue.

I've updated the flowchart to show the user action required for Path 1 and a vulnerable host required for Path 2.
What's the typical attack vector of the exploit kits?
Right, they use the web browser to leverage their attack.

What are the vulnerable applications that are typically attacked by exploit kits?
The Web browser itself and installed plugins/active-x controls like Flash player, Adobe reader, Java, etc.

I see FAR more computers where these applications are NOT kept up-to-date in "professional" or business/enterprise environments than in SOHO or home-use environments: all major browsers and the above named applications have (automatic) updaters which are typically NOT turned off by SOHO and home users.
Enterprises/businesses have (automatic) updates but typically turned off and perform their own patch management, which typically lags QUITE a bit.

And I know FAR more crappy "business" applications that need administrative privileges to run than the typical home-use applications.

And last, but not least: the "parental protection" is a VERY easy way to turn on SAFER fot those who wont try to follow <> or use the ready-to-run scripts available from <>

Diary Archives