After Flash, what will exploit kits focus on next?

Published: 2015-07-16
Last Updated: 2015-07-16 03:30:37 UTC
by Brad Duncan (Version: 1)
7 comment(s)


Adobe has received some bad publicity regarding zero-day Flash player exploits due to the recent Hacking Team compromise [1,2].  This certainly isn't the first time Adobe has had such issues [3].  With HTML5 video as an alternative to Flash player, one might wonder how long Flash player will be relevant.  Google has announced the next stable version of Chrome will block auto-playing Flash elements [4], and Firefox started blocklisting Flash player plugins earlier this week [5].  With people like Facebook's chief security officer calling for Adobe to announce an end-of-life date for Flash [6], I've been wondering about the future of Flash player.

More specifically, I've been wondering what exploit kit (EK) authors will turn to, once Flash player is no longer relevant.

In recent months, most EK traffic I've generated used a Flash exploit to infect vulnerable Windows hosts.  The situation with Flash player today is much like the situation with the Java that I remember back in 2013 and most of 2014.  However, in the fall of 2014, most EKs dropped Java exploits from their arsenal and started relying on Flash player as a vehicle for their most up-to-date exploits.

A recent history Java exploits in EK traffic 

Java exploits were prevelant when I first started blogging about EK traffic in 2013 [7].  Back then, Blackhole EK was still a player, and I commonly saw Java exploits in EK traffic.

The threat landscape altered a bit when the EK's alleged creator "Paunch" was arrested.  Organizations that monitor EK traffic noticed a sharp reduction of Blackhole EK traffic in 2014 compared to the previous year [8].  During that same time, I started noticing more Flash exploits in EK traffic.  By September 2014 most of the remaining EKs stopped using Java.

My last documented dates for Java exploits in exploit kit traffic are below (read: exploit kit name - date Java exploit last seen).

  • Angler EK - 2014-09-16 [9]
  • FlashPack EK - 2014-08-30 [10]
  • Nuclear EK - 2014-09-08 [11]
  • Magnitude EK - 2014-08-15 [12]
  • Sweet Orange EK - 2014-09-25 [13]
  • Rig EK - 2014-09-06 [14]

Of note, FlashPack EK and Sweet Orange EK have disappeared, and they are not currently a concern.  Neutrino EK was dormant from April through October of 2014, and when it came back, I didn't see it using any Java exploits.

Fiesta EK still sends several different types of exploits depending on the vulnerable client, and it still has Java exploits in its arsenal.  Other lesser-seen EKs like KaiXin still use Java exploits.  However, the majority of EKs gave up on Java sometime last year.

What we're recently seeing with Flash exploits

Most exploit kits use the latest available Flash exploits.  Angler, Neutrino, Nuclear, Magnitude, and Rig EK are all using the latest Hacking Team Flash player exploit based on CVE-2015-5122 [15].  If you have Flash player on a Windows computer, you should be running the most recent Flash update (version as I'm writing this).

Earlier I generated Angler EK traffic to infect a Windows host running Flash player on IE 11.  Angler sent a Flash exploit based on CVE-2015-5122, and the EK sent CryptoWall 3.0 as the malware payload.

Shown above: An image of the Angler EK infection and post-infection CryptoWall 3.0 traffic in Wireshark.  Click on the image for a full-size view.

Shown above: Angler EK sending a Flash exploit, based on CVE-2015-5122, targeting Flash

The infected host's bitcoin address for ransom payment was 1LY58fiaAYFKgev67TN1UJtRveJh81D2dU.  The address is the same one seen on 2015-07-01 and also documented in my previous diary on CryptoWall 3.0 [16].

Shown above: Decrypt instructions from the infected host.

Final words

Today, the majority of EKs utilize Flash player exploits based on the most recently known vulnerabilities.  But this situation can't last forever.  If Flash is no longer relevant, what will EK authors turn to for their latest exploits?  Will they go back to Java?  Will they focus on browser vulnerabilities?  It will be interesting to see where things stand in the next year or so.

A pcap of the 2015-07-15 Angler EK infection traffic is available at:

A zip file of the associated malware is available at:

The zip file is password-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)


A big issue for people in IT will be their tools that use Flash. If the browser vendors do not leave a way for exclusions to be set manually, such as for an Intranet zone, this is going to have a significant impact. In addition we run internal business apps that were built using Adobe Flex a.k.a. Flash.

It's kind of like how Cisco still requires Java for some of their admin tools like the ASA ASDM GUI. Our database activity monitoring console is built heavily in Flash. I know because every time Flash crashes I see those "the plug-in has crashed" messages.

Maybe a new article asking people to list IT tools they use that require either Java or Flash? It would be interesting to see how this impacts IT. It's not like we can remove those plug-ins and still do our jobs.
I suspect that when Flash & Java vulnerabilities start getting harder to find and exploit, the next major source of client-side bugs will be the HTML5 support that's incorporated into most browsers now. The HTML5 spec is huge, and the attack surface it represents has barely been scratched.
John McCash
I've had more than one person ask me why I highlight CWS or ZWS as the first three letters in images where I show a Flash exploit being passed. These are identifiers for archive formats used for Flash files, and you'll see them in the TCP stream when viewing the traffic in Wireshark.

- CWS is seen for Flash files that use zlib compression.
- ZWS is seen for Flash files that use LZMA compression.

This is similar to seeing PK as the first two ASCII characters for a zip archive.
I would also like to see an article on how many management tools require flash. I know the Juniper SRX management web page uses flash for some aspects.
HTML5--rats. I was hoping (naively) that they wouldn't find anything new to attack.

Our McAfee/Nitro SIEM uses a flash console. It's bad news having flash on a computer that needs lots of access--zones for flash would be handy.
I think we're already seeing it except not as drive-bys. For weeks now companies have been getting inundated with .doc and .xls attachments in emails that contain macros to download malware. They seem to be using the pre-Office 2007 format because there's no way to reliably determine whether a document contains a macro in Office 2003 and earlier file formats using our normal tools.
[quote=comment#34589]HTML5--rats. I was hoping (naively) that they wouldn't find anything new to attack.

Our McAfee/Nitro SIEM uses a flash console. It's bad news having flash on a computer that needs lots of access--zones for flash would be handy.[/quote]

Having done some development in html5, I'd agree that it will be a future target. It's rich, and complex, which often takes us down the path of security woes.

Diary Archives