Detecting and Mitigating Drive-by Compromise (T1189)

Drive-by compromise (MITRE ATT&CK T1189) is initial access through a web browser. Nobody has to open an attachment or run an installer. A person visits a website in the ordinary course of work, and code on that site tries to run on their machine. MITRE files it under the Initial Access tactic and lists Identity Provider, Linux, Windows and macOS as platforms.

It matters because the entry point is a place your users already trust. Blocking a phishing email does nothing if the site your finance team reads every morning is serving the exploit.

How attackers use it

MITRE describes several ways exploit code ends up in front of a browser:

• A legitimate website is compromised and the attacker injects malicious code.
• Script files that a legitimate site loads from a publicly writeable cloud storage bucket are modified.
• Malicious ads are bought and served through legitimate ad providers, often called malvertising.
• Web application features that accept user content are abused to insert scripts or iframes, for example through cross-site scripting.
• Browser push notifications are abused. When a user clicks "allow", they may be giving a site permission to run JavaScript in their browser.

Attackers often pick a site that one community visits, such as a government, an industry or a region. That pattern is called a strategic web compromise or watering hole attack. The goal is to reach a specific set of users through a shared interest.

MITRE outlines the typical process. The user visits the site. Scripts run automatically and look at browser and plugin versions for something vulnerable. The user may be asked to enable scripting or notifications, or to click through warnings. If a vulnerable version is found, exploit code is delivered. If that works, the attacker gets code execution on the endpoint. Sometimes a second visit is needed before the exploit is served.

One distinction from MITRE is worth keeping in mind. Unlike exploiting a public-facing application, the target here is software on a client endpoint. That usually puts the attacker on the internal network rather than on a server in a DMZ.

How to detect it

MITRE's detection strategy for this technique is behavior based and correlates several weak signals into one story. The pieces, from the detection text:

1. Unusual fetches. Network requests from the browser to domains you have not seen before, or to resources that look suspicious. Proxy, firewall and HTTP logs (Zeek, for example) are the sources.
2. Odd children of the browser. The browser process spawning an interpreter or script engine it normally does not start. On Linux and macOS the page names python, ruby and sh. On Windows, watch for unusual child processes and unsigned modules loaded into the browser.
3. Files and registry changes right after. New files in temp directories (/tmp, /var/folders) or registry changes shortly after those requests.
4. Outbound connections that break baseline. Command and control style traffic from the same host in the same short window.
5. Identity signs after the fact. For identity providers, MITRE points to token reuse from new or unfamiliar IP addresses and unusual sign-in patterns following a compromise.

No single item proves anything. A browser crash alone is noise. A browser crash, a new file in a temp folder and a first-seen outbound connection within a minute is a case worth opening.

If you have process creation logging (Sysmon event ID 1 or Windows Security event 4688 with command lines), a simple hunt is parent process equals the browser and child process is a shell or script host.

How to reduce the risk

MITRE lists these mitigations. In plain steps:

• Isolate the browser. Sandboxes limit the impact of an exploit, though MITRE notes sandbox escapes can exist. Other virtualization and microsegmentation can help too.
• Turn on exploit protection. Tools that watch for exploitation behavior, such as Windows Defender Exploit Guard, and control flow integrity checking can stop some attempts. Compatibility depends on the application.
• Restrict web content. Ad blockers can stop malicious ad code from running. Script blocking extensions help against JavaScript. Consider disabling browser push notifications for applications and browsers that do not need them.
• Patch browsers and plugins. Keep them current and use modern browsers with security features switched on.
• Train users. Teach people to spot manipulation attempts, including prompts to enable notifications or ignore warnings.

Check your own environment

Use this as a short review:

• Do you know the browser versions running across your fleet, and how quickly updates land?
• Is browser push notification permission allowed everywhere by default?
• Do your proxy or DNS logs flag newly seen domains, and does anyone look at them?
• Can your endpoint tooling alert when a browser starts a shell, script host or interpreter?
• Do any of your own websites load scripts from a storage bucket that anyone can write to? If so, an attacker who can modify those files can serve code to your visitors.
• Do you have an inventory of third-party scripts on your own sites?

Quick check

Sources

• MITRE ATT&CK T1189: Drive-by Compromise