DET0782: Detection of Drive-by Compromise
DET0782 is an ATT&CK for ICS detection strategy for identifying Drive-by Compromise behavior. The business significance is that a normal browsing session c...
Analyst context for executives and security teams
DET0782 is an ATT&CK for ICS detection strategy for identifying Drive-by Compromise behavior. The business significance is that a normal browsing session can become an initial access path, including through websites associated with trusted suppliers or industry communities. For leaders, this is less about a single alert and more about whether the organization can prove it has visibility into web-originated compromise paths that may reach operational environments or personnel supporting them.
Executive priority
Treat this as a resilience and assurance question: can the organization show that browsing-related compromise risk is governed, monitored, and investigated before it affects systems that support operations? Because the ATT&CK object does not specify platforms, tactics, or detection logic, executives should ask for evidence of coverage across business users, supplier-facing workflows, and any pathways between enterprise browsing activity and ICS-relevant assets. This supports incident readiness, third-party risk discussions, and audit evidence around preventive and detective controls.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T0817 Drive-by Compromise in the ICS domain. SOC and IR teams should validate visibility for browser and web-session activity, suspicious redirects or downloads, endpoint execution following web browsing, and network connections initiated after visits to potentially compromised or industry-relevant sites. Detection engineering should avoid assuming platform-specific coverage because the object lists no platforms and provides no official detection text. Use the relationship to T0817 as the analytic anchor: normal user browsing followed by signs of exploitation, payload retrieval, or unusual post-visit activity.
Likely telemetry
- Web proxy, secure web gateway, or DNS logs showing visited domains, redirects, and download activity
- Endpoint telemetry linking browser processes to child processes, file writes, script execution, or unexpected network connections
- Network security logs for outbound connections following browsing activity
- Email, collaboration, or ticket context when users are directed to industry, supplier, or third-party websites
- Asset and identity context to determine whether affected users or hosts have access to ICS-relevant environments
Detection direction
- Validate that web activity can be correlated with endpoint process and file activity; drive-by compromise often requires sequence-based analysis rather than a single indicator.
- Tune for post-browsing behavior that is unusual for the user, host, or business process, while accounting for legitimate software downloads and browser update activity.
- Prioritize correlation for users, jump paths, or workstations with access to operational technology or ICS-supporting systems.
- Review blind spots where browsing occurs outside managed endpoints, through unmanaged networks, or without web/DNS logging.
- Because no official detection logic is supplied, document local analytic assumptions, required data sources, and known false-positive patterns.
Mitigation priorities
- Confirm baseline preventive controls for safe browsing, browser hardening, patching, and restriction of unnecessary web access from systems supporting operational environments.
- Reduce exposure by separating routine internet browsing from ICS-supporting assets and privileged operational workflows where feasible.
- Strengthen identity and access boundaries so compromise of a browsing user does not automatically provide access to sensitive operational systems.
- Maintain incident response playbooks for suspected web-originated compromise, including user triage, endpoint isolation, and review of downstream access.
- Use detection validation exercises to prove that web, endpoint, network, asset, and identity telemetry can be joined during an investigation.
Analyst notes and limits
This take is based on the supplied ATT&CK detection strategy DET0782 and its relationship to T0817 Drive-by Compromise. The most useful local validation is whether browsing telemetry can be connected to endpoint and identity context, especially for users or systems with ICS relevance. The ATT&CK object itself provides no official description or detection procedure, so implementation should be driven by local architecture and risk.
The supplied object has no official description, no official detection text, no tactics, and no specified platforms. The related T0817 description is partial and should not be treated as complete technique documentation. This summary does not assert active exploitation, attribution, customer exposure, or guaranteed detection coverage.
Detection of Drive-by Compromise
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0817 | Drive-by Compromise | This object detects Drive-by Compromise. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | d4428d137fc3… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0782Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.