Threat Intelligence

12/22/2017
12:15 PM
Curtis Jordan
Curtis Jordan
Commentary
100%
0%

Block Threats Faster: Pattern Recognition in Exploit Kits

When analysts investigate an indicator of compromise, our primary goal is to determine if it is malicious as quickly as possible. Identifying attack patterns helps you mitigate quicker.

Vetting threats is a necessary task for security analysts, but it’s also agonizingly tedious. You want to quickly determine if something is good or bad, block it, and move on. The problem is, sometimes you can’t see the forest through the trees. There is so much noise you need a means of quickly distilling what in that data actually matters. That’s where pattern recognition comes in. Identifying patterns in TTPs (tactics, tool, and procedures) can tip you off to correlations, which is the fastest path to mitigation because you can categorically identify and block significantly more directly related indicators in a shorter amount of time.

Let’s apply this pattern recognition concept to the evolution of exploit kits.

Pattern #1: Exploit Kits Don’t Die, They Evolve 

Exploit kits are cheap and easy to purchase on the Dark Web. The most successful EKs quickly gain popularity, thus generating the greatest activity in the threatscape. When the vulnerabilities targeted by EKs are finally identified and patched, a new vulnerability gets added to the EK, and the cycle starts again. This is a good example of why you’ll see an exploit kit like Magnitude rise and fall in popularity over time.

Pattern #2: When One Tool Falls, Another Takes It's Place

So not only are there patterns in the rise and fall in popularity of an exploit kit, but there are also migratory patterns in how and when bad guys move from one exploit kit to the next. Sometimes it is merely a matter of an exploit kit no longer being effective enough. On rare occasions, however, an exploit kit may fall off the map completely due to the developer(s) behind it being taken down, as what happened when the Angler EK vanished after the Lurk criminal gang was taken down back in 2016.

It took a little while until hackers found an acceptable replacement. They experimented with a few different exploit kits like Sundown and Nuclear until finally they found RIG. Using our graph visualization tool, we tracked the migration from Angler to RIG and saw how this exploit kit beat out others.

This video (1:23) shows different EKs gaining in popularity, then dwindling, then being replaced by something new. Click here  to see the original on YouTube.

It’s not just EKs that behave this way. Noting what malware tools are used to deliver different payloads can tip an analyst off to what else to look for when they see one but not the other. For example finding Pony and, based on data spanning multiple sectors, knowing to look for Chancitor or Hancitor TTPs can help you mass identify and block indicators of compromise (IOCs), since they are often used to download that payload.

In sum, pattern recognition allows analysts to stop playing whack-a-mole by making every single indicator worth three. Keep these three tips in mind on your next investigation.

1. Keep your eye on dormant EKs. Don't discount the research you’ve done about an EK that is not active right now. TruSTAR platform data indicates new EKs use similar IOCs from old EKs (e.g. payloads).

2.  Look within historical data.  Find a way to manage your historical incident data and closed tickets to make historical data/patterns easily accessible. Graph visualization tools are useful tools in this scenario.

3. Exchange threat intelligence.  Participating in threat intelligence exchange networks can provide a more holistic view of the threat landscape, helping you identify valid patterns within a larger ecosystem and be better prepared to block threats.

This research was provided by the TruSTAR Data Science Unit. Click here to download a CSV of trending EKs and their most common IOCs.

 

Curtis Jordan is TruSTAR's lead security engineer where he manages engagement with the TruSTAR network of security operators from Fortune 100 companies and leads security research and intelligence analysis. Prior to working with TruSTAR, Jordan worked at CyberPoint ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
'Hidden Tunnels' Help Hackers Launch Financial Services Attacks
Kelly Sheridan, Staff Editor, Dark Reading,  6/20/2018
Inside a SamSam Ransomware Attack
Ajit Sancheti, CEO and Co-Founder, Preempt,  6/20/2018
Tesla Employee Steals, Sabotages Company Data
Jai Vijayan, Freelance writer,  6/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12697
PUBLISHED: 2018-06-23
A NULL pointer dereference (aka SEGV on unknown address 0x000000000000) was discovered in work_stuff_copy_to_from in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30. This can occur during execution of objdump.
CVE-2018-12698
PUBLISHED: 2018-06-23
demangle_template in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30, allows attackers to trigger excessive memory consumption (aka OOM) during the "Create an array for saving the template argument values" XNEWVEC call. This can occur during execution of objdump.
CVE-2018-12699
PUBLISHED: 2018-06-23
finish_stab in stabs.c in GNU Binutils 2.30 allows attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact, as demonstrated by an out-of-bounds write of 8 bytes. This can occur during execution of objdump.
CVE-2018-12700
PUBLISHED: 2018-06-23
A Stack Exhaustion issue was discovered in debug_write_type in debug.c in GNU Binutils 2.30 because of DEBUG_KIND_INDIRECT infinite recursion.
CVE-2018-11560
PUBLISHED: 2018-06-23
The webService binary on Insteon HD IP Camera White 2864-222 devices has a stack-based Buffer Overflow leading to Control-Flow Hijacking via a crafted usr key, as demonstrated by a long remoteIp parameter to cgi-bin/CGIProxy.fcgi on port 34100.