Exploit Kits play an integral role in many of the attacks we see on a daily basis. In this blog post we show how we use our data in a novel way to uncover new components of the attack infrastructure and protect our customers earlier.
A race unfolds each time a new WordPress, Joomla, or similar web application vulnerability is disclosed. Actors are looking to quickly craft an exploit and search the internet for vulnerable instances. Once compromised, these personal and business websites are turned against their users to become Exploit Kit Landers.
So Many Callbacks
The infection chain is littered with internet callbacks between the attacker and the victim. The victim first goes to the infected Lander, then is redirected to the Gate, then downloads the payload, and then calls back to ransomware command and control (C2) to negotiate keys. We can detect this communication at the network layer and ultimately prevent an infection from succeeding by blocking communication to the hosts involved in any of these callbacks. While we have developed systems to uncover each of these callbacks, one group which is particularly interesting to us are the Landers.
Actors take special care to protect their landers from discovery. These websites can be popular blogs or businesses that may have sizable followings and rank high in search results. If a high traffic lander is uncovered, it could mean a sizable opportunity loss. To avoid detection, actors will only expose functionality for specific hours of the day, exclude certain IP addresses, and refuse to infect a visitor more than a set number of times.
Block Page Referrers
Every time one of our users attempts to visit a malicious website, we notify them by redirecting their browser to our block page.
This is helpful to our users, but is also valuable to our researchers as another data source to perform analytics on. We store the full HTTP request every time a user ends up at one of these pages so good news for us: we can also see how they got there.
Hackathon Project: Find New EKs!
As a project during our annual hackathon at the beginning of last month, we decided to use our block page logs to identify new landers. Our end result was a module for our Avalanche System which allows us to stream in new data at near real time and protect our customers right away.
Block Page Logs
The logs from our block pages are just raw HTTP logs. By looking at the Referer HTTP Header data, we can identify how users end up at a Gate. We first parse them into a dictionary that looks like this:
We have a couple things working for us: We already know that this user is doing something risky since they’ve arrived at our blocked page and are in our logs. We’re also streaming in exploit kit gates, so we already know that headers.host is a gate that we’ve uncovered with our other classifiers. The thing we might not have prior knowledge about is the referrer, geiserpharma[.]com.
Attackers may set up their imposter websites or they may compromise legitimate websites, so it can be tricky to determine if a referring site is actually malicious. One way to root out false positives is to ensure the referrer is not an extremely popular site. We can use the top 5000 domains in the Cisco Umbrella 1m as a filter and check the popularity within Investigate.
Our suspected lander geiserpharma[.]com has very low popularity. On a scale on 0-100, where 100 is very popular, geiserpharma[.]com is a zero.
Line of Fire
Let’s visit geiserpharma[.]com just to test. The other nice thing we get from the block page logs is the User-Agent. This is useful since many Exploit Kits will profile the user and only launch an exploit if it appears to be vulnerable. By using the User-Agent in the logs, we’re one step closer to having the exploit kit show itself.
Surprise, surprise: Internet Explorer Crashes and we get a very concerning Windows Script Host error! All-in-all there were four major steps to this infection, here they are as Fiddler sessions:
If we dig into the HTML source of the page, we see a suspicious iFrame buried in the middle of it:
Now, these landers will very often cycle through a few different gates as you render the page. So if we wait a little time, then request the page again, we get:
This Flash object contains exploits a vulnerability which achieves code execution in the context of the browser.
The payload itself is simply a one liner to create a Windows Script Host temporary file that downloads, deobfuscates, and executes Cerber Ransomware via a DLL using regsvr32.exe.
But wheres the Arduino?
It can’t be a hackathon project without having something controlled by a small microprocessor, so we bolted on an API to our feed of fresh new landers and set up a Raspberry Pi to query it. Every time a new lander was identified, the Raspberry Pi triggered a PowerSwitch Tail which flipped on the electricity to my Christmas Tree and sent the train below racing around its track.