Overview

Drive-by Compromise (T1189) is an initial access technique where an attacker causes a victim to gain code execution on their system simply by visiting a malicious or compromised website during normal browsing. The attacker may inject exploit code into a legitimate site, serve malicious ads, abuse browser push notifications, or host purpose-built watering hole pages that fingerprint and exploit vulnerable browsers or plugins.

Every security team needs visibility into this technique because it requires zero deliberate action from the victim beyond clicking a link — it bypasses email gateway controls entirely and can target highly specific user populations through watering hole campaigns. A single successful drive-by can hand an attacker a fully interactive shell on an endpoint inside your perimeter with no phishing attachment or credential theft required.

Attacker Perspective

Attackers exploit the implicit trust users place in websites they visit regularly, turning the browser itself into the attack surface.

• Watering hole with browser exploit kit: An attacker compromises a trade-association website and injects a JavaScript fingerprinting stager that redirects vulnerable Chrome or Firefox versions to a RIG or Magnitude exploit kit landing page, delivering shellcode that executes directly in the renderer process.
• Malvertising via ad network: Attackers purchase ad slots through a legitimate ad broker and serve a malicious iframe that loads a hidden exploit chain; tools like BeEF (Browser Exploitation Framework) are used to hook browsers and pivot to payload delivery without any user download prompt.
• Fake Flash/browser update lure: A compromised or look-alike site serves a page that displays an “Update Required” banner, prompting users to download install_flash_player.exe or ChromeSetup.exe — a masqueraded loader — from an attacker-controlled domain.
• DNS rebinding attack: An attacker registers a domain with a very short TTL, initially resolving to their public server to deliver JavaScript, then rebinding the DNS record to an internal RFC-1918 address so the same-origin JavaScript can enumerate and attack internal services on the victim’s LAN.

This technique is attractive to attackers because it is highly scalable, the initial exploitation leaves minimal forensic traces on the web server itself, and it can be precisely targeted at specific organisations or individuals through strategic site selection or user-profiling scripts.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Alternatively, deploy Sysmon (Event ID 1) with a SwiftOnSecurity or Florian Roth Sysmon config for richer parent-child process telemetry including hashes and full command lines.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures decoded PowerShell content even when Base64-encoded at invocation — critical for catching post-exploitation stagers dropped by browser exploits.
• Windows — Network Connection (Sysmon Event ID 3): Configure Sysmon to log outbound TCP/UDP connections including Image, DestinationIp, DestinationPort, and User fields. This exposes browser child processes making unexpected outbound connections.
• Windows — File Creation (Sysmon Event ID 11): Log file creation events, especially in %TEMP%, %APPDATA%, Downloads, and browser cache directories — common drop locations for drive-by payloads.
• Windows — DNS Query Logging (Sysmon Event ID 22 or Windows DNS Client ETW): Captures per-process DNS queries including QueryName, QueryResults, and Image. Required for DNS rebinding detection and C2 domain identification.
• Proxy / Web Gateway Logs: HTTP/HTTPS inspection logs must include: cs-uri-stem, cs-uri-query, cs-host, cs-user-agent, sc-status, cs-method, c-ip, and referrer fields. SSL inspection should be enabled to see HTTPS traffic content. Tools: Zscaler, Bluecoat, Squid, Palo Alto URL Filtering.
• Web Server / Application Logs (if you own the site): Apache/Nginx/IIS access logs with full URI including query strings, referrer, and response body size. Enable mod_security or equivalent WAF logging.
• EDR Telemetry: CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne process tree data provides the richest browser-to-child-process lineage and is the most reliable source for detecting post-exploit execution.
• Linux: Enable auditd with rules targeting browser process execution: -a always,exit -F arch=b64 -S execve -F ppid=$(pgrep -f firefox|head -1) -k browser_child. Alternatively deploy Sysmon for Linux to get equivalent Event ID 1/3/11 coverage.
• macOS: Enable Unified Log collection and deploy an EDR agent. Use Endpoint Security Framework (ESF) or osquery to capture process creation with parent-child relationships. Enable Santa or Google’s OSQuery for file and process telemetry.

Key Indicators

• Suspicious browser child processes: In Sysmon Event ID 1 or EDR process telemetry, look for ParentImage containing chrome.exe, firefox.exe, msedge.exe, iexplore.exe, or safari spawning child processes like cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, or certutil.exe. This is the single highest-confidence indicator.
• PowerShell download cradles launched from browser context: In Event ID 4104, look for script blocks containing patterns like IEX(New-Object Net.WebClient).DownloadString, Invoke-Expression, (New-Object Net.WebClient).DownloadFile, or Start-BitsTransfer where the parent process chain traces back to a browser.
• Suspicious file drops in browser-associated paths: Sysmon Event ID 11 with TargetFilename matching C:\Users\*\AppData\Local\Temp\*.exe, C:\Users\*\Downloads\*.exe, or C:\Users\*\AppData\Roaming\*.dll where Image is a browser process.
• XSS strings in web proxy or WAF logs: In proxy or web server logs, cs-uri-query or cs-uri-stem containing URL-encoded or raw XSS payloads: %3Cscript%3E, <iframe, javascript:alert, onerror=, document.cookie. Filter to non-404 responses to reduce scanner noise.
• Flash or software update from non-vendor domain: In proxy logs, c-uri ending with /install_flash_player.exe or containing /flash_install.php where cs-host does not end with .adobe.com — also generalise to fake Chrome/Firefox updaters not served from dl.google.com or download.mozilla.org.
• DNS rebinding indicator: In Sysmon Event ID 22 or DNS logs, the same QueryName resolving to both a public IP and an RFC-1918 address within a short timeframe (under 30 seconds) from the same host. Check QueryResults for internal prefixes 10., 192.168., 172.16-31..
• Outbound connection from browser to unusual port: Sysmon Event ID 3 where Image is a browser and DestinationPort is not 80, 443, or 8080 — especially raw TCP ports like 4444, 1337, 8443 to non-CDN IPs.
• certutil or bitsadmin used for download: In Event ID 4688/Sysmon Event ID 1, CommandLine containing certutil -urlcache -split -f http or bitsadmin /transfer where parent process traces to a browser — classic LOLBin abuse post-browser-exploit.

Detection Logic

Rule 1 (Broad — High Sensitivity): Browser Spawning Shell or Scripting Interpreter
IF EventID = 1 (Sysmon) OR EventID = 4688 (Security)
AND ParentImage CONTAINS ("chrome.exe" OR "firefox.exe" OR "msedge.exe" OR "iexplore.exe" OR "opera.exe" OR "brave.exe")
AND Image CONTAINS ("cmd.exe" OR "powershell.exe" OR "wscript.exe" OR "cscript.exe" OR "mshta.exe" OR "rundll32.exe" OR "regsvr32.exe" OR "certutil.exe" OR "bash.exe" OR "sh" OR "python.exe")
AND NOT CommandLine CONTAINS ("--type=renderer" OR "--type=gpu-process" OR "NativeMessagingHost")
THEN alert HIGH

This rule catches the most critical post-exploit pivot: a browser spawning a shell. It will generate moderate volume in environments that use browser-based native messaging or extensions that spawn helper processes — tune aggressively using the NativeMessaging exclusion and whitelisting known helper paths like C:\Program Files\Google\Chrome\Application\.

Rule 2 (Moderate — Suspicious Download via LOLBin from Browser Lineage):
IF EventID = 4104 (PowerShell Script Block) OR EventID = 1 (Sysmon)
AND (CommandLine CONTAINS ("DownloadString" OR "DownloadFile" OR "certutil -urlcache" OR "bitsadmin /transfer" OR "Invoke-Expression" OR "IEX"))
AND ParentProcessChain CONTAINS ("chrome.exe" OR "firefox.exe" OR "msedge.exe" OR "iexplore.exe")
THEN alert CRITICAL

This catches the download-cradle stage of a drive-by compromise where the browser exploit drops a stager that fetches a second-stage payload. Expected alert volume is low; most legitimate PowerShell download activity does not originate from a browser parent chain.

Rule 3 (Network — Suspicious Software Update from Non-Vendor Domain):
IF log_source = proxy
AND (c-uri ENDSWITH "/install_flash_player.exe" OR c-uri CONTAINS "/flash_install.php"
OR c-uri ENDSWITH "ChromeSetup.exe" OR c-uri ENDSWITH "FirefoxInstaller.exe")
AND NOT (cs-host ENDSWITH ".adobe.com" OR cs-host ENDSWITH ".google.com" OR cs-host ENDSWITH ".mozilla.org" OR cs-host ENDSWITH ".microsoft.com")
AND sc-status != 404
THEN alert HIGH

Targets the fake update lure delivery vector. This is a low-volume, high-precision rule that should generate very few false positives once legitimate vendor domains are excluded.

Rule 4 (DNS — Possible DNS Rebinding):
IF log_source = dns
AND QueryStatus = 0
AND same QueryName resolves to BOTH (QueryResults STARTSWITH ("10." OR "192.168." OR "172.16." through "172.31." OR "127.")) AND (QueryResults NOT STARTSWITH any private range)
WITHIN timeframe = 30 seconds
AND count(QueryName) BY ComputerName > 3
THEN alert MEDIUM

Detects DNS rebinding by flagging domains that flip between public and private IP resolution in a short window. Expect false positives from split-horizon DNS configurations in your own environment — build an exclusion list of internal domains known to legitimately resolve to both ranges.

Tuning Guidance

• Browser native messaging helpers: Many legitimate browser extensions (password managers, security tools, PDF viewers) spawn helper executables as children of the browser. Exclude known paths such as Image STARTSWITH "C:\Program Files\*\NativeMessagingHosts\" and processes like 1password.exe, keepassxc-proxy.exe. Build this exclusion list by reviewing your browser child process baseline before enabling alerting.
• Internal vulnerability scanners: Scanners like Tenable Nessus, Qualys, or Rapid7 InsightVM will generate significant XSS string hits in web server logs. Exclude scanner source IPs: AND NOT c-ip IN [scanner_ip_list]. Coordinate with your vulnerability management team to maintain this list.
• Split-horizon DNS: If your organisation uses internal DNS views that return private IPs for the same hostnames that publicly resolve to public IPs, the DNS rebinding rule will fire constantly. Suppress alerts for QueryName ENDSWITH ".yourdomain.com" or any domain in your internal zone list.
• Software deployment tools: SCCM, Intune, and similar tools may download installers from CDN URLs that resemble fake update lures. Exclude source processes: AND NOT ParentImage CONTAINS ("ccmexec.exe" OR "svchost.exe" AND ServiceName = "wuauserv") and verify the download URL matches a known patch management endpoint.
• Developer and QA environments: Developers frequently run PowerShell scripts launched from browser-based IDE terminals (VS Code integrated terminal), which can appear as browser-spawned shells. Tag developer machine hostnames or OUs and apply a separate, stricter tuning profile, or suppress Rule 1 for those assets while keeping Rule 2 active.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event from your SIEM or EDR console and confirm the ParentImage, Image, and CommandLine fields match the detection logic — do not rely solely on the alert summary. Check whether the process hash is known-bad via VirusTotal or your threat intel platform before proceeding.
2. Identify the affected host and user: From the process creation event, extract ComputerName and SubjectUserName (Event ID 4688) or User (Sysmon). Check if the account holds elevated privileges, is a service account, or belongs to a sensitive team (IT admin, finance, executive) — this dictates escalation priority.
3. Reconstruct the full process tree: In your EDR (CrowdStrike Process Explorer, Defender for Endpoint Device Timeline, or Sysmon EventID 1 correlated by ProcessGuid and ParentProcessGuid), trace the complete chain from the browser process back to its launch and forward to all child and grandchild processes. Look for the specific browser tab or URL that triggered the chain by correlating timestamps with browser history or proxy logs.
4. Identify the malicious URL and retrieve proxy logs: Match the alert timestamp to proxy or web gateway logs filtered by the affected host’s IP. Pull the cs-host, cs-uri-stem, cs-uri-query, and cs-referrer fields for the suspicious request. Submit the domain to VirusTotal, URLScan.io, and your threat intel feed to determine if it is a known malicious or compromised site.
5. Check for files written to disk and outbound network connections: Search Sysmon Event ID 11 for file creations by the browser or its children in %TEMP%, %APPDATA%, and Downloads directories around the alert time. Correlate with Sysmon Event ID 3 to identify any outbound connections made by child processes — note destination IPs and ports and check against threat intel for known C2 infrastructure.
6. Hunt for lateral movement originating from this host: Query your SIEM for authentication events (Event ID 4624, 4648) from the affected host after the compromise time, especially logon types 3 (network) and 10 (remote interactive). Check for SMB, WMI, RDP, or PsExec activity in Sysmon Event ID 3 and Windows Security logs — any successful auth to other internal hosts should be treated as confirmed lateral movement.
7. Search for persistence mechanisms: Review Sysmon Event ID 13 (registry value set) for modifications to HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\...\Run, or scheduled task creation (Event ID 4698). Check for new services (Event ID 7045), new startup folder entries in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup, and any browser extension installations that post-date the compromise timestamp. Escalate to confirmed incident if any persistence is found.

Response Playbook

Containment

• Isolate the host immediately but leave it powered on: Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or SentinelOne Disconnect from Network) to cut the host from all network access while preserving volatile memory for forensics. Do not reimage until memory and disk acquisition is complete.
• Acquire volatile evidence before any other action: Run a memory dump using WinPMEM, AVML (Linux), or your EDR’s live memory collection capability. Capture the running process list, open network connections (netstat -anob), and active sessions. This evidence is destroyed on reboot.
• Disable the affected user account: In Active Directory, disable the account via Disable-ADAccount -Identity username or through the Azure AD / Entra ID portal. Revoke all active SSO sessions and OAuth tokens — in Azure AD use Revoke-AzureADUserAllRefreshToken; in Okta, clear all active sessions from the admin console.
• Block identified C2 domains and IPs at the perimeter: Add the malicious domain and IP addresses to your firewall deny list, proxy URL filter blocklist, and DNS RPZ (Response Policy Zone) or Cisco Umbrella block list. Verify the blocks are applied to all egress points including VPN breakout locations.
• Kill malicious processes if containment is not yet applied: If live on the system, terminate malicious child processes using EDR remote kill or Stop-Process -Id [PID] -Force via a privileged remote session. Document the PID, name, and parent before killing.

Eradication

• Remove identified persistence mechanisms: Delete any malicious registry run keys found during investigation using reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v [ValueName] /f. Remove malicious scheduled tasks with schtasks /delete /tn "[TaskName]" /f. Unregister any malicious services with sc delete [ServiceName].
• Delete dropped payloads and tooling: Remove all files identified during the investigation from temp directories, AppData, and Downloads. Run a full AV/EDR scan and cross-reference with the file hashes identified to ensure nothing was copied elsewhere on the system.
• Reset credentials for all accounts active on the compromised host: Force a password reset for the victim user and any other accounts that authenticated to the host during or after the compromise window. If a service account was present in memory, rotate that credential immediately and audit where it is used.
• Audit lateral movement targets: For every host the victim host connected to after the compromise time, run the same persistence-hunting checks (scheduled tasks, registry run keys, new services, unexpected accounts). Treat any finding on a second host as a new incident requiring the same containment process.
• Rotate secrets and API keys exposed in the browser: If the user was authenticated to cloud services, SaaS apps, or internal applications during the session, rotate those application credentials and OAuth tokens. Check browser-saved passwords — advise the user to change all passwords stored in the compromised browser profile.
• Identify and notify the compromised website owner (if applicable): If investigation reveals a legitimate website was the vector (watering hole), notify the site owner via their security contact or through CISA/national CERT. This helps protect other organisations.

Recovery

• Re-image the host if confidence in cleanliness is not absolute: If any persistence was found, or if the attacker had more than a few minutes of dwell time, re-image from a known-good golden image rather than attempting manual cleanup. Restore only user data files (not executables) from backup after scanning them.
• Re-enable the user account only after confirming no persistence remains: Before unlocking the account, verify through EDR and SIEM that no attacker-controlled processes, services, or scheduled tasks exist on any host the user account touched. Brief the user on the incident and require a password reset on next login.
• Monitor the affected host and user account for 72 hours post-remediation: Create a temporary, high-sensitivity watch list in your SIEM for the affected ComputerName and UserName. Alert on any new process spawning from browser context, any outbound connection to the previously identified C2 infrastructure, and any new persistence mechanism creation.
• Push browser and plugin patches to all endpoints: Identify the browser version that was exploited and verify the current patch status across the fleet using your vulnerability management tool. Prioritise patching or browser update enforcement via GPO (Update → AutoUpdateCheckPeriodMinutes) for Chrome, or equivalent managed update policy for Firefox and Edge.
• Document, review, and improve: Write a full timeline from first suspicious DNS/proxy event to containment. Identify any detection gaps — specifically whether the alert fired before or after payload execution. Add any new IOCs (domains, IPs, file hashes, registry keys) to your threat intel platform and update your detection rules. Schedule a lessons-learned review within five business days.