Drive-by Compromise (T1189) is initial access with no click on anything obviously malicious: a user visits a legitimate but compromised site, or one boosted by SEO poisoning, and a script fingerprints the browser before serving an exploit or a fake update. The tell is what the browser process does seconds later: spawning a script host or fetching a payload it never should.
Practice detecting Drive-by Compromise on realistic SIEM, XDR alerts in SOCSimulator Operations.
“Drive-by Compromise is documented as technique T1189 in MITRE ATT&CK® v19.1 under the Initial Access tactic. Detection requires visibility into SIEM, XDR telemetry.”
The chain starts with a page the victim trusts: a legitimate site that got compromised, one boosted to the top of search results through SEO poisoning, or an ad slot serving malvertising. Injected JavaScript fingerprints the browser and OS, then either fires an exploit against a vulnerable plugin or renders a fake dialog, most commonly a browser update prompt styled to match the vendor. SocGholish, the campaign Red Canary and MITRE both document most thoroughly, favours the second path: it never needs a zero-day, it just needs the user to click 'update'.
Where drive-by compromise separates itself from simple social-engineering downloads is what happens next inside the process tree. A successful exploit hands the attacker code execution directly; a fake-update lure hands the JavaScript payload to the Windows Script Host, so the browser process becomes the direct parent of wscript.exe or cscript.exe running a .js file dropped to a temp directory. That parent-child relationship, browser to script host, is unusual enough on its own to anchor a detection, because browsers do not normally download a script and execute it themselves.
Once the script runs, the intrusion moves fast and mostly in memory. SocGholish's JavaScript performs system, software, and process discovery (whoami, listing installed AV, enumerating running processes), stages what it finds locally, and phones home over HTTP POST requests disguised as ordinary web traffic. The pivot into domain reconnaissance, nltest.exe with /domain_trusts or /all_trusts, is the signal that the infection is being handed off for further exploitation rather than left dormant.
Drive-by compromise sits at the very front of the kill chain, it is how the attacker gets a foothold without sending a single email. MITRE credits state-sponsored operators (APT28, APT32, Lazarus Group, Turla, Dragonfly) with running strategic web compromises and watering holes against specific industries or regions, while SocGholish, attributed to the group Mustard Tempest, runs the technique as a commodity service: infected browsers are sold on as initial access to other criminal groups, including ransomware affiliates and, per Proofpoint's research, has been linked to payloads associated with LockBit and Evil Corp operators.
What comes after the drive-by depends on the buyer. Red Canary's telemetry shows the wscript.exe stage frequently followed by domain-trust enumeration (nltest.exe) and, in a meaningful share of incidents, a second-stage payload such as NetSupport RAT or AsyncRAT, sometimes escalating to ransomware deployment. For a defender, that means the browser-spawns-script-host alert is not the end state to investigate, it is the earliest point to interrupt an intrusion chain that, left alone, ends in domain-wide encryption.
The following detection strategies help SOC analysts identify Drive-by Compromise activity. These methods apply across SIEM, XDR environments and can be implemented as detection rules, correlation queries, or behavioral analytics in your security platform.
index=* EventCode=1
(ParentImage="*\\chrome.exe" OR ParentImage="*\\msedge.exe" OR ParentImage="*\\firefox.exe")
(Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe")
| table _time, ComputerName, User, ParentImage, Image, CommandLineSysmon process-creation events where a browser is the direct parent of a script host. Mirrors the browser-to-wscript.exe chain Red Canary documents as SocGholish's signature initial-execution step.
EventID: 1
UtcTime: 2026-07-16 03:14:22.118
Image: C:\Windows\System32\wscript.exe
CommandLine: wscript.exe //B //Nologo C:\Users\jmartin\AppData\Local\Temp\update_verify.js
User: CORP\jmartin
ParentImage: C:\Program Files\Microsoft\Edge\Application\msedge.exe
ParentCommandLine: "msedge.exe" --single-argument https://update-chrome-verify[.]net/checkdetection:
selection_parent:
ParentImage|endswith:
- '\Google Chrome'
- '\firefox'
- '\Safari'
- '\Microsoft Edge'
- '\Opera'
selection_child:
Image|endswith:
- 'bash'
- 'sh'
- 'python'
- 'perl'
- 'php'
- 'osascript'
- 'pwsh'
- 'curl'
- 'wget'
condition: all of selection_*SigmaHQ's 'Suspicious Browser Child Process' rule (tagged attack.t1189), which fires when a browser process spawns a shell, scripting engine, or download utility, the process-tree pattern a successful drive-by exploit or fake-update lure produces.
// Browser spawns a script host that then reaches out to the network
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
and FileName in~ ("wscript.exe", "cscript.exe")
| join kind=inner (
DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("wscript.exe", "cscript.exe")
) on DeviceId, ProcessId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, RemoteUrl, RemoteIPReconstructs Red Canary's SocGholish detection: a browser-spawned script host that immediately makes an outbound connection. Follow up on any hit with nltest.exe /domain_trusts in the same session, the reconnaissance step that typically follows.
Timestamp: 2026-07-16T03:14:30.442Z
DeviceName: WS-ACCT-22.corp.local
FileName: nltest.exe
ProcessCommandLine: nltest.exe /domain_trusts /all_trusts
InitiatingProcessFileName: wscript.exe
AccountName: jmartinLegitimate browser update mechanisms genuinely spawn helper processes: Chrome and Edge run their own updater executables, macOS browsers invoke Apple's software-update framework, and enterprise deployment tools push browser patches through management agents that can look, at a glance, like a browser launching an installer. IT-approved extension installers and some browser-based automation or testing frameworks (headless Chrome driven by CI pipelines) will also spawn scripting engines as part of normal operation.
The fix is context, not blanket suppression. Exclude the specific vendor update paths and signed installer processes your fleet actually uses, and pay attention to the working directory: a script launched from a user's Temp or Downloads folder with a randomized filename is a different animal from an update binary running from Program Files. A browser-to-script-host event paired with an immediate outbound connection to a domain with no prior reputation in your environment is the combination worth escalating over one running from a known update channel.
These realistic alert examples show what Drive-by Compromise looks like in your security tools. Use them to tune detection rules and train analysts to recognize true positives versus false positives in live environments.
msedge.exe on WS-ACCT-22 launched wscript.exe against a .js file dropped from a compromised marketing site, and the script process opened an outbound connection within eight seconds. Browsers do not legitimately download and hand off execution to the Windows Script Host, this is the documented SocGholish fake-update chain.
nltest.exe /domain_trusts ran under the same user session two minutes after a browser-spawned wscript.exe process on FS-01.corp.local. This reconnaissance step is the pivot point where a drive-by infection typically hands off to a ransomware affiliate.
Proxy logs show six internal hosts hitting update-chrome-verify[.]net, a domain registered nine days earlier, each followed within a minute by a .js file download. The clustering across unrelated users and the domain's age both point to a watering-hole or SEO-poisoning campaign rather than isolated user error.
When this fires, start by identifying the source: which URL or domain the browser was pointed at, whether it matches a known-compromised or newly registered domain, and whether the resulting script or download came from a path consistent with legitimate software (Program Files, a signed vendor updater) or a temp directory with a generic filename. Check whether the script process made an outbound connection and to where, and whether any discovery commands (whoami, nltest, process enumeration) ran in the following minutes, that tells you whether this is a live infection or a blocked attempt.
If the script executed and reached out to the network, treat the host as compromised and move fast: isolate it before the reconnaissance phase completes and a second-stage payload lands, since SocGholish-style chains hand off to RATs and ransomware affiliates within the same session in a meaningful share of documented cases. Preserve the host for IR rather than reimaging immediately, capture the dropped script file and any staged data for analysis, and check other hosts that visited the same domain in the same window, watering-hole and SEO-poisoning campaigns rarely hit just one user.
Investigate Drive-by Compromise on realistic SIEM, XDR, and firewall consoles, free.
Investigate a high-stakes 2025 intrusion where a simple search engine result led to a full-scale Akira ransomware deployment. This scenario tracks the transition from initial access via Bumblebee to post-exploitation via AdaptixC2, culminating in domain-wide encryption. You will analyze the browser-to-endpoint execution chain, identify lateral movement via administrative tools, and uncover the specific techniques used by the Howling Scorpius group to evade modern EDR solutions.
In this advanced SOC simulation, you will investigate a multi-stage intrusion that began with a drive-by download of a trojanized Zoom installer. The attack progressed through several stages of loader execution, including d3f@ckloader and IDAT loader, eventually leading to the deployment of high-end C2 frameworks like Cobalt Strike and Brute Ratel. You must trace the attacker's path from the initial web-based compromise, through lateral movement via RDP tunneling and proxy tools, to the final mass-deployment of BlackSuit ransomware via enterprise management software. This scenario is based on real-world 2025 threat intelligence and requires deep analysis of SIEM, XDR, and Firewall telemetry to reconstruct the full kill chain.
Phishing is a social engineering attack delivered via email, SMS, voice calls, or other channels that deceives recipient…
Read more GlossaryAn organization's attack surface is the total set of points where an adversary could attempt unauthorized access: networ…
Read more GlossarySocial engineering is the psychological manipulation of individuals into performing actions or revealing information tha…
Read more GlossaryAn Indicator of Compromise (IOC) is an observable artifact, such as a file hash, IP address, domain name, URL, registry …
Read more Career PathTier 1 SOC Analysts are the front line. You monitor alert queues, triage incoming detections, classify them as true or f…
Read more Career PathTier 2 SOC Analysts handle the investigations that Tier 1 escalates. You dig into multi-stage attacks, coordinate contai…
Read more ToolThe SIEM console in SOCSimulator replicates the workflow of enterprise platforms like Splunk Enterprise Security, Micros…
Read more ToolThe XDR console in SOCSimulator replicates the investigation workflow of platforms like CrowdStrike Falcon, Microsoft De…
Read more ComparisonSOCSimulator wins on operational realism. You get multi-tool shift simulation with SLA pressure, noise injection, and al…
Read more GlossaryComplete glossary of Security Operations Center terminology for aspiring SOC analysts.
Read more FeaturePractice alert triage under realistic time pressure with SLA timers and noise injection.
Read more FeatureStructured CTF-style investigation operations covering real-world attack scenarios.
Read more