In this post, I am going to go over a real world example of how a drive-by attack works to exploit a target user’s web browser over the normal course of browsing. If done correctly, the attack will not alert the target user that anything has been compromised, leaving them open to further exploitation.
The MITRE ATT&CK Framework describes the attack as follows:
A drive-by compromise is when an adversary gains access to a system through a user visiting a website over the normal course of browsing. With this technique, the user’s web browser is typically targeted for exploitation, but adversaries may also use compromised websites for non-exploitation behavior such as acquiring application access tokens.
To show how a drive-by attack works, I am going to create a scenario in which a target user is compromised during their normal course of browsing.
The attacker was given the task of compromising the engineering department of a medium sized company.
The OSINT (Open-Source Intelligence) team has reported that users within the engineering department have a few workstations that are still running Windows 7, and Windows 8.1. They also reported that the target company purchases their industrial parts from 2 different online vendors in which they have business accounts with. One of these vendors is vulnerable to a RCE (Remote-Code Execution) attack, allowing the attacker to embed the client-side exploit targeting Internet Explorer into the HTML. After the vendor’s web site has been compromised, there is nothing left to do but wait for your target to connect. The specific exploit I am using for this example can be found here; it was written to attack CVE-2014-6332.
Trend Micro describes CVE-2014-6332 as follows:
The bug is caused by improper handling resizing an array in the Internet Explorer VBScript engine. VBScript is the default scripting language in ASP (Active Server Pages). Other browsers like Google Chrome do not support VBScript, but Internet Explorer still supports it via a legacy engine to ensure backward compatibility.
If you want to know more about this exploit, the guys over at AHN Labs did a good write-up located here.
However, using this technique, the attacker does not know if the target user will be using Internet Explorer to access the vendor site or not, so it can become a bit of a waiting game when trying to exploit a specific browser. This does not deter the attacker.
From the perspective of target user, they shouldn’t notice anything. This is exactly why this type of attack is very dangerous and very stealth. In this scenario, the target user didn’t change any of their browsing or work related behavior, so it is very hard to determine why the user was compromised.