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.
Background
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.
Each visitor is selectively evaluated by the time of day they’re visiting the site, their source IP address, along with the versions of their browser and various plugins. If they match a specific profile, the Lander injects a single line of HTML or JavaScript code into the page. This line of code makes a call to the Exploit Kit Gate, which serves up a worthy exploit to take advantage of a vulnerability in an often outdated browser or plugin used by the visitor. We use the term ‘Gate’ to describe the attacker-controlled system which may serve the exploit itself or may be an intermediary step where the client is profiled a second time then sent to the exploit. With arbitrary execution achieved on the visitor’s system, the exploit kit has done its job. The shellcode of the exploit downloads a binary and executes the payload of the attacker’s choice which, in many cases, is ransomware.
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.
Avoiding Detection
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.
New Landers
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:
These iFrames include additional JavaScript to profile the user and ensure they are vulnerable:
With a confirmed wounded duck, the JavaScript posts back to the gate which returns a big nasty page with tons of obfuscated JavaScript. Parts of the JavaScript are encoded just right to make Fiddler hiccup when processing.
By saving the raw bytes using HexView we can see the resulting JavaScript.
A few breakpoints later, we reveal three levels of JavaScript obfuscation that result in the inclusion of a Flash object into the original landing page (geiserpharma[.]com).
This Flash object contains exploits a vulnerability which achieves code execution in the context of the browser.
The SWF is passed a few hex-encoded items via the FlashVars variable. This supports the modular nature of the exploit kit. Any exploit kit customer can provide a download URL which is passed from JavaScript, through Flash, arriving as an argument to payload which is eventually executed. We can see this by inspecting the ROP Chain that the exploit uses once it achieves control over the instruction pointer.
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.
