Initial Access – Drive-by Compromise (T1189)

Introduction

We will use MITRE ATT&CK Enterprise Matrix as our framework. Our idea is to explain in every post a technique of each tactic (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact).

An adversary (cybercriminal, competitor, hacktivist) reaches its final objectives (financial returns, commercial/political/military advantages or expression of political beliefs and ideologies) once it successfully chains different techniques. For this reason, it’s very important to know them. A defense-in-depth approach can help to detect and block these techniques but to be truly secure you have to test it against Red Team exercises and Breach and Attack Simulations (BAS). First, because you will know your actual exposure in front attacks against your company and second, because you will continuously improve your defenses (security products effectiveness and Blue Team detection and incident response).

In this post we are going to explain Drive-by Compromise technique that provides “Initial Access” or a foothold within a network.

This technique does not require any action from the user (victim), beyond simply visiting a compromised site that contains an exploit that silently compromises a vulnerable browser. Often, the compromised site is one visited by a specific group of users. This kind of targeted attack is known as “watering hole attack”. The steps of a Drive-by compromise are:

1. A user visits a compromised site and the browser executes a malicious JavaScript embedded in an iframe,
2. The script checks the user’s source IP address and the browser’s version or other vulnerable software in use (like plugins or complements),
3. If the conditions are met (target source IP address and vulnerable software), a malicious file (with exploit code and a payload) is delivered to the user’s browser to exploit it,
4. If the exploitation is successful and there aren’t other protections in place, the adversary gets remote access to the user’s computer.

Drive-by Compromise is a technique usually used by Exploit-Kits, targeting office applications and web browsers vulnerabilities, as we can see in the following table:

Exploit-Kit	CVE
Fallout	2018-15982, 2018-8174, 2018-4878
GrandSoft	2018-8174, 2016-0189, 2013-2423
GreenFlash Sundown	2018-8174, 2018-4878, 2016-4117, 2016-0189, 2015-7645, 2015-5119
Kaixin	2018-8174, 2016-7201, 2016-7200, 2016-4117, 2016-0189, 2015-2419, 2014-6322, 2014-0569, 2013-0422, 2012-4681, 2012-1723, 2011-3544
Magnitude	2018-8174, 2018-4878, 2016-4117, 2016-1019, 2016-0189, 2015-8651, 2015-7645, 2015-5122, 2015-5119, 2015-3133, 2015-3113, 2015-3105, 2015-3090, 2015-2426, 2015-2419, 2015-1701, 2015-1671, 2015-0359, 2015-0311, 2014-8439, 2013-2551, 2013-2471, 2013-2463, 2013-0634, 2012-0507
RIG	2018-8174, 2018-4878, 2016-7201, 2016-7200, 2016-4117, 2016-3298, 2016-1019, 2016-0189, 2016-0034, 2015-8651, 2015-7645, 2015-5122, 2015-5119, 2015-3113, 2015-3090, 2015-2419, 2015-0359, 2015-0311, 2014-6332, 2014-0569, 2014-0515, 2014-0497, 2014-0322, 2013-7331, 2013-3896, 2013-2551, 2013-2465, 2013-2423, 2013-1493, 2013-0634, 2013-0322, 2013-0074, 2012-1723, 2012-0507
Spelevo	2018-15982, 2018-8174
ThreadKit	2018-8174, 2018-4878, 2018-0802, 2017-8759, 2017-8570, 2017-11882, 2017-0199
Underminer	2018-15982, 2018-8174, 2018-4878, 2016-0189, 2015-5119

According to ENISA Threat Landscape Report 2018, web browser based (drive-by) Exploit-Kits trend is continuing due to the continued use of Internet Explorer and the increase in use of “pseudo exploit-kits” (copy and pasting from leaked or POC-type exploits).

Attack demonstration

We have prepared a “pseudo exploit-kit” using published POC code in GitHub that exploits CVE-2018-15982. For the sake of clarity and ease of comprehension, file names generated will be naive and obvious.

First, we generate an Empire stager to save it into stager.txt. Once executed in the user’s (victim) computer, it will contact the Empire Command and Control at c2-server.com to provide an agent (remote control session):

Then, we use a custom Python script named weaponize.py to generate all the needed files and an iframe tag to add to the compromised web page:

We add the iframe tag to index.html. Once the iframe is loaded it will request the page named landingpage.html from check-stager-server.com.

Here is a sequence diagram of the user interaction with the iframe which loads the JavaScript checker.

Landingpage.html contains html and the previously created JavaScript code that will check two conditions:

1. If the source IP address belongs to the target user, and
2. If the user uses a vulnerable flash player version for CVE-2018-15982 If both are met, a flash movie (exploit.swf) is embedded into the web page.

Exploit.swf is a well-defined flash movie that contains:

• The exploit code, to take execution control once the flash movie is rendered
• The first stage, also obfuscated (encoded), that will be the first malicious code (in Powershell) executed on the user’s computer and will request the secondstage.ps1 from check-stager-server.com

Secondstage.ps1 contains the data in stager.txt but xored with a pre-shared key and obfuscated (encoded) again:

When the second stage is executed it initiates an Empire Agent that communicates with the Command and Control (c2-server.com).

Now that we have described the different pieces that play together to obtain remote code execution, we will see a video where the user (victim) is compromised once it lands to its favorite web page.

Finally, we can see the same result but from the adversary’s perspective (logging web requests and obtaining an Empire agent):

Detection

Once we’ve seen a successful live attack using the drive-by technique described before, it is easier to understand how harmful this technique can be as user interaction isn’t needed at all.Here are different ways to detect this technique from a network or an endpoint perspective.

Network

From the network point of view, based on the attack demo explained before, there are plenty of requests towards the different pages that can be intercepted or detected if there’s a proxy or a firewall in place. Those requests are needed to get a connection with the Command and Control from the user’s (victim) computer, from the JavaScript checker to the final stager. In a similarly way, a network IPS can be used to inspect the requests and responses against the malicious server and analyse them for known or obfuscated malicious scripts.

The proxy or the firewall can analyze the domains the end user is connecting to and check them against a threat intelligence source in order to decide whether a connection is suspicious or not. Collecting DNS’s logs can be a great source to detect traffic against known malicious domains as well.

Endpoint

Analyzing the behaviour of a computer is another source for detecting the exploit execution. From the previous demo, it is important to log and detect the script executions on the host where the parent process is a browser. Browsers have process names which can be easily identified, for Internet Explorer it usually is C:Program Files (x86)Internet Exploreriexplore.exe. The execution of powershell.exe where the parent process is iexplore.exe is a suspicious behavior and should be alerted. In a similar way, encoded powershell commands are commonly used among the attackers to hide their execution.

Mitigation

Although it’s important, detecting is not enough and we recommend the following mitigations to prevent the successful execution of this technique:

• Keep your software updated: Web browsers (also components and plugins), office and media applications.
• Protect your computer with an antivirus or an EDR (Endpoint Detection and Response). If it’s based on signatures, always keep it updated.
• Block and alert the network traffic classified as malicious by threat intelligence sources.

Block and alert the network traffic classified as malicious by threat intelligence sources.

Defense demonstration

Based on the previous detections and mitigations, we retried the demo but previously we installed on the user’s (victim) computer two tools:

• The Sysmon Sysinternal tool by Mark Russinovich and Thomas Garnier.
• Cylance Optics, an EDR which has the ability to detect and block. For Sysmon, a configuration file is needed to define what you wish to detect. Nevertheless, we used a popular configuration file from SwiftOnSecurity which includes plenty of detections.

Following the detection indications, it is interesting to look for the Sysmon Logs which has the event ID 1 (process creation) and 3 (network connection).

After the installation the demo is executed and the attacker successfully gets remote access to the computer, we can observe two detections from the sysmon logs where malicious activity is easy to see.

The first one is a detection from a connection towards the hostname attacker.com. We can observe that the process that made the connection is powershell.exe.

The second detection has some key details which were introduced in the detection section. We can see that the process powershell.exe whose parent is iexplore.exe (Internet Explorer) executed an encoded command:

Sysmon is used to detect and log but it doesn’t block. That’s why we had installed the Cylance’s EDR (Optics) on the user’s (victim) computer as well, although it was on alert mode. From the first execution, we saw two detections using the medium and high rated default rules:

Looking into those detections, we can see the configuration of each rule in the details:

• Powershell Encoded Command

• Internet Explorer to Scripting Engine Pivot

In both cases, we can observe the same powershell encoded command we detected using the Sysmon from the detection details:

Based on the previous detections and mitigations, we retried the demo with the same vulnerability but modifying the action of the Cylance’s EDR (Optics) to terminate the process that triggers the detection for the rule named Internet Explorer to Scripting Engine Pivot, as we can see on the following image:

On the following video you can see the final demo where the attack is successfully blocked and the attacker never gets the remote access to the computer.

As the configuration for that rule is set to terminate the process, the attacker will see the incoming requests but won’t be able to communicate with the empire agent, because Cylance will block its execution.

Photo by attack.mitre.org on Google Images.