How drive-by compromise gets a foothold without a phishing click
T1189 Drive-by compromise is the ATT&CK technique in which an adversary gains a foothold when a user simply visits a web page, with no email lure and no download the user chose to run. It sits under the Initial Access tactic (TA0001), whose ATT&CK definition is that the adversary is trying to get into your network. For a SOC lead, the uncomfortable point is that the entry point is ordinary browsing: the browser, a browser plugin, or a component the page loads is what gets abused. This page targets Enterprise ATT&CK version 20.0, and every detection mapping should be checked against that version because releases can rename or deprecate techniques.
The general pattern is short. A user reaches a site that has been compromised, or that serves content from a compromised third party, and the page delivers code that exploits or abuses the client software. The user may see nothing unusual. What the defender sees is a browser or helper process doing something it does not normally do shortly after a web request, which is why the detection work in the rest of this page leans on network and process telemetry rather than on the user's report. T1189 is one of several techniques in the broader MITRE ATT&CK tactic for Initial Access pillar, and it competes for attention with phishing and public-facing application exploitation, so it needs its own coverage.
The decision to make first is scope: which browsers, plugins and managed endpoints are in the estate, and whether web traffic from servers and privileged administrative workstations is visible to the SOC at all. Confirm with your endpoint team which browser versions and update channels are deployed, and confirm that web proxy or DNS logs can be correlated to endpoint process events for the same host. If either link is missing, drive-by activity will be detected late or not at all, regardless of which rules are written.
Which data sources reveal drive-by compromise
This table maps each ATT&CK data component relevant to T1189 Drive-by compromise to the signal it exposes and the open-source collector that captures it. Read it as a coverage checklist: no single source sees the whole chain from a visited page to a host-level action, so the rows are meant to be combined. Data component IDs are taken from ATT&CK v20.0 and should be re-checked against each new release before mappings are relied on.
| Data source | Signal to look for | Open-source collector |
|---|---|---|
| Network Connection Creation (DC0082) | Browser or endpoint process opening outbound connections to an unfamiliar domain shortly after a user visit to a web page, especially to newly registered or rarely seen hosts | Wazuh endpoint agent and Security Onion host logs |
| Process Creation (DC0032) | Browser process spawning a child interpreter, script host or shell, or an unexpected executable launched from a user profile directory after a page load | Wazuh (Sysmon event ingestion on Windows, auditd on Linux and macOS where configured) |
| Network Traffic Content (DC0085) | Suspicious HTTP responses carrying script or binary content from third-party hosts, unusual content types, or obfuscated payloads delivered during a browsing session | Zeek HTTP and file analyzers, and Suricata rules with content matching |
| Application Log Content (DC0038) | Identity provider sign-in records showing a successful login from a new device, browser fingerprint or location shortly after the user reached an external site | Wazuh ingestion of identity provider audit logs through its log collection and decoders |
| Network Traffic Flow (DC0078) | Sudden change in outbound volume or destination diversity from a workstation that normally browses a narrow set of sites | Zeek connection logs and Security Onion dashboards |
| File Creation (DC0039) | Files written to temporary or user download locations by a browser process, followed by execution of that file from the same path | Wazuh file integrity monitoring and Velociraptor artifact collection on demand |
Detection logic for drive-by compromise in words
Drive-by compromise starts with a user visiting a page that delivers malicious content without a deliberate download. The four ideas below look at the same event from different vantage points: the endpoint, the network, the identity provider and the web traffic itself. Tune each one against your own baseline, because the most common false positives come from software that behaves like an attacker's tooling by design.
Browser spawning unexpected children
Alert when a browser process creates a child process that is not on an approved list, such as a shell, a script host, or an installer launched from a temporary directory. Process creation telemetry (ATT&CK data component Process Creation, DC0032) is the source. Thresholds are best set as a rule that fires on any match in a small allowlist sense, then tuned by parent-child pair rather than by volume. Common false positives include browser-managed helper processes, PDF viewers opened from the browser, and enterprise extensions that call local management agents. Confirm each allowed pair with the browser vendor's enterprise documentation before suppressing it.
Unfamiliar domains from browsers
Flag outbound connections from browser processes to domains that the organization has not seen before, especially when the first contact is followed by a binary download or a redirect chain. Network Connection Creation (DC0082) provides the process and destination pair. Tune the newly observed window to your own traffic history, and suppress domains that are trusted by policy rather than by reputation. Common false positives include software updaters that fetch from content delivery networks, cloud-hosted SaaS tenants with rotating subdomains, and enterprise browser extensions that check in with vendor services. Keep an exception list reviewed by the team that owns endpoint management.
Sign-ins after browsing sessions
Correlate a web session on an endpoint with a later identity provider sign-in from the same device or user within a short window, and look for a new device, new location or unusual application. The signal comes from Application Log Content on the identity provider and from endpoint logs for the browsing session. Set the correlation window from your own sign-in patterns, and treat sign-ins from unmanaged devices as the higher-risk subset. Common false positives include users who open sign-in pages from links in email, password manager prompts, and sign-ins that follow a normal browser update. Confirm which identity provider events record the device and client, since not every log includes both.
Content anomalies in web traffic
Inspect web traffic for responses where the declared content type does not match the body, where scripts are delivered with an unexpected encoding, or where a page loads a large executable payload from a non-standard path. Network Traffic Content (DC0085) from a sensor such as Zeek or Suricata is the source. Thresholds should start with narrow rules on file types that have no business reason to arrive from a web page, then widen only after review. Common false positives include legitimate software installers from vendor portals, obfuscated JavaScript used by commercial web frameworks, and compressed assets served by content delivery networks. Validate sensor coverage on encrypted traffic before relying on content inspection, because many sessions will not expose the body to the sensor.
How to validate the detection in a lab before production
This sequence proves that the T1189 Drive-by compromise detections fire on a benign, agreed emulation in a private range before any rule reaches production, and it records how quickly and how accurately they fire. It gives the security team evidence it can review, rather than an assumption that the rule works.
Confirm the ATT&CK version and detection scope
The detection owner records the ATT&CK version the rules target, the platforms in scope (Identity Provider, Linux, macOS and Windows) and the data components the detections depend on, including Network Connection Creation, Process Creation and Network Traffic Content. Confirm the version against the MITRE ATT&CK updates page, because releases can rename or deprecate content. The step is done when the scope is written into the validation record with the version named.
Define the expected telemetry for each platform
For each platform in scope, the team lists the events and fields it expects to see if the behavior occurs, such as which network connection and process records should be generated and which web content fields should be captured. It also notes which telemetry is missing today. Confirm each field exists in the Wazuh or Security Onion pipeline before testing, since a rule cannot fire on data it never receives. The step is done when an expected-telemetry table is signed off by the detection engineer and the platform owner.
Agree the emulation plan with the team
The detection engineer, the SOC lead and the range operator agree in writing on a benign emulation that produces the same telemetry shape as the behavior, without real malicious payloads or live exploitation. The plan names the range systems involved, the accounts used, the time window, the people who must be told, and the stop conditions. Document who approves changes to the plan. The step is done when all named roles have accepted the plan.
Run the benign emulation in the private range
The range operator runs the agreed emulation only inside the isolated cyber range, with network egress restricted to what the plan permits. The operator logs the start and end time of each action so that alert timestamps can be compared with the activity. Any deviation from the plan is recorded and the emulation is halted if an unexpected system is affected. The step is done when the run log matches the approved plan.
Check that alerts fire in Wazuh or Security Onion
The SOC analyst checks whether each expected detection produced an alert in the chosen platform, whether Wazuh or Security Onion, and compares the alert against the expected-telemetry table from step two. Missing alerts are investigated against the pipeline first: ingestion, parsing, field mapping and rule syntax. The step is done when every expected detection has either an alert or a documented reason for its absence.
Record detection latency and alert fidelity
The team measures the gap between each emulated action and the matching alert timestamp, which gives detection latency. It also classifies each alert as a true positive for the emulated behavior, a benign match, or noise, which gives alert fidelity. Record these results per rule and per platform so that a later tuning change can be compared with the baseline. The step is done when the results table holds a latency and fidelity value for every rule tested.
Capture analyst notes and tune the rule
Analysts record what they saw, which fields helped them triage, what context was missing, and what they would need to escalate. The detection engineer uses these notes to adjust thresholds, exclusions or field mappings, then reruns the same emulation to confirm the change did not break the detection. Keep the before and after results together. The step is done when the rerun results are attached to the validation record and the rule owner has approved promotion or a further round.
Promote only validated detections to production
The team promotes a rule to production only after the range results meet the criteria agreed in step three, and it documents any known gaps, such as platforms with missing telemetry, as open risks with owners. Production deployment is staged, and the first weeks are monitored for false positives that the range could not reproduce. Confirm that the validation record is stored where auditors and the security governance group can review it. The step is done when the production change ticket links to the signed validation record.
Which ATT&CK mitigations reduce drive-by exposure
Drive-by compromise succeeds when a user's browser or a service's web content processes hostile code without the defender having reduced the exposure first. The mitigations below act on different links in that chain: patching the software that gets exploited, limiting what web content can reach, and containing what runs after a foothold. Each one needs an owner and a check in your own environment.
Update software (M1051)
This mitigation covers keeping browsers, browser engines, plugins, operating systems and web-facing libraries on supported, patched versions. For T1189, the question is not whether patching exists but how quickly internet-facing user endpoints receive browser updates after a vendor fix. Confirm the patch window for browsers and extensions on managed Windows, macOS and Linux endpoints, and confirm who approves emergency browser updates outside the normal cycle. The operational owner is usually endpoint or desktop engineering, with security setting the target.
Restrict web-based content (M1021)
This mitigation limits which websites, scripts, plugins and web resources a user or system can load, often through a proxy, secure web gateway, DNS filtering or browser policy. It matters most for T1189 because the hostile content usually arrives over ordinary HTTP or HTTPS from a site the user chose to visit. Confirm which categories of uncategorized, newly registered or unknown sites are blocked or isolated, and whether script execution policies differ by user group. The operational owner is typically the network or web security team, working with the identity team on policy exceptions.
Application isolation and sandboxing (M1048)
Isolation confines a browser process, renderer or document viewer so that code which escapes a page cannot easily reach the host or other data. Ask whether browser sites run in separate processes, whether high-risk browsing happens in a disposable or virtualized session, and whether administrators avoid browsing from privileged accounts. Testing should confirm that a sandbox escape in a test page does not grant access to user files or credentials. The operational owner is usually endpoint engineering, with the platform team supporting any virtual browsing service.
Exploit protection (M1050)
Exploit protection refers to operating system and endpoint features that make memory corruption harder to use, such as memory protections, control-flow hardening and exploit mitigations configured at the platform level. These controls raise the cost of turning a browser bug into code execution, but their availability and settings differ by operating system and product. Confirm which protections are enforced on managed endpoints, which are in audit mode only, and what exceptions exist for legacy applications. The operational owner is typically endpoint security, validated through the same test pages used for isolation checks.
What the SOC does in the first hour after a drive-by alert
The first hour after a drive-by alert is about containing the browser session and establishing what the user's identity touched, before anyone decides the event is a false positive. Start by confirming the browser, the user, the host and the time of the page load that triggered the alert. If the endpoint shows a browser process spawning unexpected child processes, or outbound connections to a domain that the page loaded from, isolate the host from the network through your EDR or Wazuh active response tooling, provided your change process allows it. Isolation is a decision for the on-call lead, and it should be recorded with the reason and the time. Before isolating, confirm that your isolation method does not destroy volatile state you still need.
Preserve browser artifacts and process history while the host is still in a known state. Velociraptor can collect browser history, download records, cache entries and process listings from Linux, macOS and Windows endpoints, but the exact artifacts available depend on the browser, the profile and the Velociraptor artifact version in your deployment, so confirm coverage in a test endpoint before relying on it during an incident. Also check Wazuh or your EDR for the Network Connection Creation and Process Creation records covering the same window. Next, search your identity provider logs for sign-ins, token issuance and MFA prompts for the affected user after the page load, since a drive-by compromise often matters most when it leads to session or credential theft. Ask your identity provider vendor which log fields and retention periods apply to your tenant.
Review neighboring hosts that visited the same sites in the same period, using proxy, DNS or Zeek HTTP records to build the list. Then decide on credential resets: reset passwords and revoke sessions for the user when identity logs show anomalous sign-ins or when the browser shows credential prompts or stored-password access, and widen the scope only when the evidence supports it. Record every decision, its owner and its time, because these notes will shape the post-incident review and any compliance evidence you later present.
Rehearsing drive-by compromise detection in a private cyber range
Detection engineers own the question of whether the telemetry exists and whether the rules fire on the right evidence. In a private range, the team builds an isolated environment with Linux, macOS and Windows endpoints, an identity provider and a Wazuh manager with Security Onion sensors collecting network metadata. The goal is to confirm that Network Connection Creation, Process Creation and Network Traffic Content are reaching the platform for every endpoint class before any rule is judged. Injects are scripted at the level of expected evidence, such as an unexpected browser child process or an outbound connection to a new domain, so that the team can test rule logic without publishing exploit steps.
- Telemetry coverage map: Record which data components are present per platform and per sensor, and mark any gap before the exercise starts.
- Rule tuning against baselines: Replay benign browsing and software update traffic to measure false positives before accepting a rule.
- Version-pinned mapping: Tie each detection to the ATT&CK version it targets, since releases can rename or deprecate content.
- Sensor health checks: Confirm that clock sync, parsing and log forwarding are working so a silent sensor does not look like a clean result.
- Documented rule changes: Keep a change log so the exercise shows which tuning decisions were made and why.
Before closing the exercise, confirm with your own environment owners which telemetry sources are licensed and retained at the volume the rules require.
SOC analysts test whether an alert becomes a correct decision within the time the team has set for its own queue. In the range, analysts receive alerts from the injects without knowing their full context, then must decide whether the activity is benign, suspicious or confirmed. The exercise measures how quickly they pivot from an endpoint alert to the related network record, the identity provider sign-in log and the host's process tree. Analysts should also practice writing a triage note that another analyst could act on without rereading the raw events.
- Alert-to-pivot path: Walk from the endpoint alert to network metadata, identity events and file records using the same fields every time.
- Benign versus suspicious decisions: Compare analyst calls with the inject answer key to find where the runbook is unclear.
- Escalation criteria: Test whether analysts know when to hand off to the incident lead, based on scope, user impact or repeat hosts.
- Triage notes: Require a short structured note with the timeline, affected hosts and open questions.
- Shift handover: Run one inject across a shift boundary to check that context survives the handover.
After the exercise, check that the runbook names the owners, queue thresholds and escalation contacts your organization has actually agreed to.
Incident leads test decisions that affect systems and people: whether to isolate an endpoint, reset a session, block a domain or pause a business process. In the range, the lead works from the same evidence the SOC has and must choose containment steps that match the scope the team can confirm. The exercise also covers communications, including who is told what, in which order, and which internal and external parties need formal notice under the organization's own obligations. Leads should record decisions with their reasons so the after-action review can check them.
- Containment options: Compare endpoint isolation, session revocation and domain blocking, and note the business impact of each.
- Scope decisions: Practice deciding when a single endpoint becomes a multi-host incident.
- Communications plan: Test the order of notifications to executives, system owners, legal and, where relevant, regulators.
- Decision log: Require timestamped decisions with the evidence behind them.
- Recovery checkpoints: Agree the criteria for returning hosts and accounts to service before the exercise.
After the exercise, confirm the notification thresholds and regulatory obligations with your legal and compliance owners, since these depend on your sector and jurisdiction.
Questions SOC leads ask about detecting drive-by compromise
How do you tell drive-by activity apart from normal browsing?
Drive-by activity is identified by a sequence, not a single event: a user visits a web page, the browser or one of its plugins spawns an unexpected child process, and that process then makes outbound connections or writes files. Normal browsing produces web requests and renders content, but it rarely launches shells, scripting hosts or unsigned binaries from the browser. Build your baseline from a sample of real browser behavior on your managed images, then alert on deviations such as browser parent processes launching command interpreters or downloading executables from newly registered domains. Use Process Creation and Network Connection Creation telemetry together, and confirm which browser builds and extensions your fleet actually runs before you tune thresholds.
How should we handle ATT&CK version changes in our detection library?
Record the ATT&CK version every detection maps to, and review mappings when MITRE publishes a release. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics, and it updated data components, so a mapping written against older content may point to a retired identifier. Recent releases are v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026). Pull the STIX bundle for your target version from the attack-stix-data repository, diff technique and data component IDs, and update your coverage matrix in one controlled change. Store the version in the rule metadata so auditors can see which content your detections were built against.
Which telemetry should we prioritize on macOS versus Windows?
Start with process lineage on both platforms, because a browser spawning an unexpected child process is the strongest early signal. On Windows, prioritize Process Creation with parent and child relationships, plus Network Connection Creation for the same processes, and confirm that your sensor records command-line arguments and signer data. On macOS, prioritize Process Creation and network telemetry from the endpoint agent, and check whether your agent exposes code signature and notarization status, since unsigned or ad hoc signed helpers are a common review point. Validate coverage on a sample host from each image before assuming parity, because collection depth differs by agent and OS version.
How do we reduce false positives from software updaters?
Allowlist updaters by specific signed binary, publisher and expected destination rather than by process name alone, because names are easy to reuse. Browser and plugin updaters legitimately spawn child processes and fetch executables, so a rule that fires on any download by a browser child will flood the queue. Build the exception list from your own environment: record which updater binaries run, which vendor domains they contact, and which versions are approved. Review the list whenever you change browser or plugin standards, and keep exceptions in version control so each change has an owner and a reason. Apply the Update Software mitigation at the same time, since a patched fleet produces fewer legitimate exceptions to maintain.
How can we test drive-by detections without using live payloads?
Test the detection logic with benign, pre-approved stand-ins that produce the same telemetry shape: a harmless test binary launched from a browser child process, or a controlled outbound request to a lab-owned domain. The goal is to confirm that the alert fires, carries the right fields and reaches the right queue, not to reproduce an exploit. Run these tests in a private cyber range, log each test with its expected and observed result, and replay recorded telemetry through your rule engine when you change logic. Never introduce working exploit code or real malware into production networks to validate a rule. Ask any testing partner to describe how they keep exercises inside an agreed scope and how they clean up test artifacts afterward.
How do we measure detection coverage for drive-by compromise over time?
Track coverage as a matrix that maps each detection to its ATT&CK technique, data components, and the ATT&CK version it targets, then record the result of each test run against that matrix. Useful measures include whether each mapped detection has a passing test in the last review period, how many hosts and browser populations produce the required telemetry, and how many alerts are closed as benign for each rule. Review these figures after each ATT&CK release and after major browser or OS changes, since both can silently break a rule. Keep the matrix under version control, and confirm with your SOC and auditors what evidence format they expect before you report it.
How DeployOpen builds drive-by compromise detections and range scenarios
DeployOpen scopes a drive-by compromise detection engagement as a fixed-scope piece of work, with the scope agreed in writing before any collector is installed. In practice that means listing the in-scope identity provider, the Linux, macOS and Windows endpoint groups, the web gateway or proxy that sees outbound browsing, and the log sources each one can export. The scope also records which browsers and browser-based applications are managed, which hosts are allowed to reach the internet directly, and which ATT&CK version the mapping will target. Ask the provider to confirm, in writing, what is and is not covered for each platform, and who owns the rule tuning after handover.
Implementation happens in the client's own environment, using open-source collectors and rules that the client can inspect and keep. Network Connection Creation and Process Creation events come from endpoint telemetry, while Network Traffic Content depends on whether the client's sensors can inspect web content at all, which is often limited by TLS. DeployOpen maps each detection to the relevant data components and to the Update Software and Restrict Web-Based Content mitigations, then tests whether the required fields actually arrive in the SIEM. Rules are written as Sigma where possible and converted for the client's backend, so the logic remains readable without the tooling.
Purple team exercises run in a private cyber range that mirrors the client's endpoint and web gateway configuration. The team plays the browser-side compromise scenario, the blue team checks alert quality, and both sides record which events were missing, noisy or late. Results are handed over as documented detections, each tied to a specific ATT&CK version and a test record. DeployOpen prepares this documentation as evidence for internal reviewers and for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies make those determinations.
