Adrian Hada
ATI Security Researcher

Drive-by Downloads – Deconstructing the Crash and Burn

May 9, 2017 by Adrian Hada

Security incident investigations are never easy – getting users to admit all their Internet activities (which they might sometimes want to keep secret) is difficult and walking through logs and histories can be cumbersome. But sometimes the user doesn’t have anything to hide – they were simply browsing the web when their files were encrypted. They didn’t open any suspicious e-mails or install anything on their computer.

“Drive-by download” is the technical term for malware delivery without the user’s consent or knowledge. The story goes as follows:

  • User accesses a website
  • The website delivers an exploit for the user’s browser
  • The exploit executes code on the user’s machine and downloads a complete payload
  • Profit!

The exact mechanism by which this occurs is a bit more complicated – after all, the user must be of interest to the malware creator (there’s not much point in targeting PCs in Romania if you want to steal money from Italians), the correct exploits need to be delivered for the given browser and software versions, and the exploits need to execute correctly. This has created a multi-part delivery system. Factor in that the malicious actors must also bypass security devices and the entire chain becomes more complex.

The Gates of Exploitation

The first step of the infection chain that a user’s browser will be directed to is called a gate. Victims reach gates by accessing a compromised website, a fake website setup by the malicious party (such as in a watering hole attack) or by accessing a website that unknowingly serves malicious advertisements (instead of the user accessing the compromised website directly, a website loads ads from a legitimate service; the malicious party uses this service to redirect to their own infrastructure).

Gates perform fingerprinting by checking browser properties such as installed plugins and browser version. Sometimes they inspect the visitor’s IP address to understand its geographical origin. They sometimes reject requests from addresses belonging to known security vendors (blacklisting). Once they consider the visitor a legitimate target, gates respond with HTML or Javascript code that redirects the victim’s browser towards the next step in the exploit chain. Enough talk, time for some examples:


Above is an example of the so-called “Good Man” gate documented here, redirecting towards the Rig Exploit Kit (more on that later). Quick explanation if you’re not fluent in HTML:

  • The “div” tag moves the iframe content beyond the top left of your screen so that you never see the rendered content
  • The “iframe” tag loads the website from the given URL on page access and shows it in the accessed web page

The end result is that the user is unaware that a frame has been loaded containing the malicious web page, leading to an infected browser.

Another practical example of gating in action, this time of a traffic distribution system (normally, a legitimate service) being used to redirect via HTTP 3XX redirection messages:


When the first page gets loaded, the browser is redirected to the destination specified in the “Location” header seen in the blue text.

A final example, this time of the EITest gate using Javascript:


This is similar to the first technique, where malicious iframes are used to redirect the browser, but the iframe doesn’t exist in the HTML response. It’s dynamically generated by the browser after interpreting the Javascript snippet that redirects the victim to another RIG URI as seen above.

The overall concept is that gates silently redirect interesting targets towards the next step in the exploitation chain. Sometimes there might be more of these redirections in-between but, in the end, you reach the next step of the chain, the exploit kit.

EK’s Landing

Exploit kits are – as the name implies – specialized services used to exploit targets. The first page of the exploit kit, called a landing page, can fingerprint the visiting machine and identify vulnerable applications (as well as installed security products). Based on this new information, the exploit kit might decide to avoid the machine if it seems too well guarded, appears to be a trap by a security researcher, or if the kit does not contain the necessary exploits for the detected software. Other times, it delivers exploits instantly. Here’s an example:


The image above is an excerpt from Rig EK’s landing page. There’s a good amount of obfuscation used to bypass security devices. After a couple of levels of deobfuscation, we get three different payloads. The first part decodes to VBScript code similar to this:


This code builds an exploit for CVE-2016-0198. Similarly, the other two payloads are a Flash-based payload and an exploit for CVE-2015-2419. The Flash payload checks for the Flash version before downloading the final exploit. The two VBS payloads do not fingerprint in any way, probably relying on the checks done at the gate.

Another example comes from the so-called Terror exploit kit.


The exploit kit uses some obfuscated Javascript code to send data back towards the server. Judging from the strings, this appears to be an attempt of fingerprinting the browser and installed components on the system. After deobfuscation, the code proves to be the expected fingerprinting routine:


After fingerprinting is complete, the landing page triggers download of the necessary exploits. Here’s the Terror exploit kit responding with some VBScript code that exploits the same CVE-2016-0189 as Rig EK, a remote code execution vulnerability in Internet Explorer (note that the code is adapted from an this open-source PoC)


This exploit kit doesn’t use too much obfuscation for these exploits. In fact, the malicious deed is done very much in the open, with the exact CVE number being specified:




After the exploit has succeeded, the exploit kit will fetch a malicious payload from a remote server. The Rig EK infection from above spawns cmd.exe and later calls wscript.exe on obfuscated code:


This code first writes some obfuscated JS code into a file and then executes it while also passing three parameters: a string, a URL, and a user agent string. What the deobfuscated code does is:

  • Downloads malware from the given URL
  • Decrypts the RC4-encrypted binary using the key given as a parameter
  • Adds the correct extension to the file (.exe or .dll)
  • Executes the file

This is the point where malware is executed. As you’ve probably noticed, there was no user interaction whatsoever except for the initial website access. The user who claims that he didn’t visit anything shady might actually be telling the truth – such attacks have even targeted visitors to large websites such as MSN, Yahoo, and others.

Understanding the way exploit kits work is extremely important for defending networks. As you have seen, their level of complexity is great and keeps increasing. The good news is that this complicated exploit chain leaves a lot of different places where you can neutralize the attack. Threat intelligence, endpoint protection solutions, IDS, internal policies – any of these can block an exploit kit from delivering its payload. Hopefully, by carefully monitoring and analyzing these exploit kits, we will have less of a threat to worry about.