Pulling the Brake on the Magnitude EK Train

Clock Icon 5 min read

This blog goes into detail on recent work that Unit 42 has done to identify malicious sites associated with the Magnitude Exploit Kit (EK). It details the investigation process involved in identifying the algorithm used to generate domains used by the Magnitude EK. Defenders can use the provided data to identify possible domains that may be associated with the Magnitude EK before they're used and block them pre-emptively and so block Magnitude EK attacks before they happen.

Initial Assessment

While hunting for new malware in Palo Alto Networks AutoFocus, I stumbled across some Adobe Flash files being used in what appeared to be an active exploit kit to which some users were being redirected. As I started to collect the URLs from these sites, a pattern began to emerge with which I was not immediately familiar. Below is a sample of the URLs.

The third-level domains are a mix of alphanumeric characters, followed by a second-level domain made up of two combined English language words, followed by unusual, legitimate top level domains (TLDs), and then finally a path made up of alphanumeric characters. Within a few minutes of refining my search criteria, I was seeing pages of session data covering this type of activity indicating this was an active threat so I decided to dive in further.

I was able to use AutoFocus in conjunction with YARA to accurately identified the container files as being dropped from Magnitude EK. Additionally, I found multiple blog posts such as this one on Malware Traffic Analysis which confirmed this pattern was in fact Magnitude.


Great, now that I know what I’m dealing with, I can get down to the business at hand and further enumerate Magnitude EK URLs.

Pulling the Brake

In research, we typically start the process of enumeration by identifying a pattern and then using that pattern to further target and collect information. Then we take that information and repeat the process. In this case, I extracted around 100,000 sessions that contained Adobe Flash files from URLs that matched a handful of the TLD’s I observed, including things like “stream”, “space”, “review”, “webcam”, “trade”, “date”, “party”. This provided a solid body of data that I could use to try and create a pattern from by using the previously discussed rules with alphanumeric characters and the like.

Below is a Pearl Compatible Regular Expression (PCRE) that I crafted to identify the initial landing pages for Magnitude EK.

Using this PCRE, I successfully identified 1113 unique landing pages across 1056 unique domains (856 unique second level domains). These are included in “magek_landing.txt” on the Unit 42 GitHub IOC repository. This file also contains the PCREs described in this blog.

While creating the PCRE I noticed there was another URL pattern that frequently showed up on these domains. After additional research, I identified that this secondary URL pattern is the actual exploit Magnitude delivers once the landing page has profiled the browser/version(s) of Adobe Flash.

The following URLs are examples of this second pattern.

Building on the previous PCRE, the PCRE below will identify the exploit part being delivered by this kit.

I didn’t identify any new domains with this new PCRE. Nevertheless, it provides another opportunity for defender blue teams to identify and catch this activity at their proxy or URL filtering devices.

Clearing the Track

At this point, we have good coverage from the PCREs of the Magnitude EK infrastructure but I wanted to see if the coverage could be extended even further. So far, everything I’ve identified has been actively seen in an attack but, as every blue teamer knows, it’s better if you can stop a threat before they are able to carry out an attack. To do this, I need to shift focus from known attack domains to unknown attack domains.

Taking the previously mentioned 1056 domains, I started reviewing the registration information for them and noticed several interesting characteristics as I collated the data from PassiveTotal.

1. There were 110 registrants that registered 26 domains, which was roughly the average number of domains per registrant. On the low end, 16 registrants registered exactly 52 domains. In Table 1 you can see the top ten registrant addresses and the number of times they were used.

 404  Klarkson avenue 25
 343  32 Glendale Crescent
 318  Densell st. 199
 298  Henbamo 33
 286  1299 Still Street
 212  Nolenpark 88
 183  Haringo 399
 172  1043 Mattson Street
 160  Idorkalben 1928
 159  hotberry road 38

Table 1 Top 10 registrant addresses used.

2. There was heavy re-use of addresses and telephone numbers, with one phone number being used for 1411 domains while another phone number is tied to 2421 registrations.   

3. There was a lot of information that is just plain wrong in the registration details, which I feel would be worth its own research effort. For example, Table 2 shows entries wherein the city doesn’t exist in the listed state.

Domain         Email                   Country       State   City antonvarvutov@yandex[.]ru united states florida moscow adamdalnet@gmail[.]com united states kansas tolens benfansyl@gmail[.]com united states ohio colorado city bovengals@gmail[.]com united states indiana florida briangarret@gmail[.]com united states delaware gasanter

Table 2 Example domain registrants with cities listed for states in which they do no exist

Given this, I took 223 identified unique e-mails from our domains observed being used in attacks and used that to enumerate a list of 6089 second level domains for Magnitude EK that match our known pattern. These domains can also be found in “magek_domains.txt” on the Unit 42 GitHub IOC repository.

By leveraging this data, defenders can now proactively block domains that could be used for Magnitude EK before they are used for attacks. In addition, defenders can use the provided PCRE’s to block future domains. For Palo Alto Networks customers, all domains are properly identified as malicious and the below tag was created in AutoFocus for those who wish to explore the activity further.


Happy hunting! Choo chooo!

Acknowledgements: A big “thank you” to Juan Figuera for tightening up these PCRE’s and testing them, along with Nathan Fowler, who both helped make sure these are false-positive adverse for the greater good of the community.


Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.


Enlarged Image