DET0614: Detection of Drive-By Compromise
DET0614 is a MITRE mobile detection strategy for identifying Drive-By Compromise behavior, where a user’s normal web browsing can become the entry point fo...
Analyst context for executives and security teams
DET0614 is a MITRE mobile detection strategy for identifying Drive-By Compromise behavior, where a user’s normal web browsing can become the entry point for browser exploitation or token acquisition. The business value is in validating whether mobile browsing, identity token activity, and device security signals are visible enough for responders to distinguish routine web activity from a potential compromise path.
Executive priority
Treat this as a mobile and identity readiness question: if Android or iOS users can be compromised through ordinary browsing, leaders should ask whether the organization has evidence to investigate affected users, devices, visited sites, browser/app behavior, and any related application access token activity. This supports incident decision-making, mobile security investment, and compliance evidence around monitoring and response capability.
Technical view
The ATT&CK object has no official detection text and no tactics or platforms specified for the detection strategy itself. Its relationship indicates it detects T1456 Drive-By Compromise in the mobile domain, with the related technique covering Android and iOS. SOC and IR teams should therefore validate telemetry around mobile web access, browser/application anomalies, device posture, and identity token use rather than assuming a single alert will identify the behavior.
Likely telemetry
- Mobile web browsing and web proxy or secure web gateway logs, where collected
- DNS and HTTP/S metadata associated with mobile devices, subject to privacy and architecture limits
- Mobile device management or unified endpoint management inventory, compliance, and device posture records
- Mobile threat defense or endpoint security alerts for browser/app exploitation indicators
- Browser or application crash, update, and abnormal behavior telemetry where available
Detection direction
- Map available mobile telemetry to the Drive-By Compromise scenario instead of relying on the sparse DET0614 object for analytic logic.
- Validate whether mobile web activity can be tied to a user, device, browser/app, timestamp, and subsequent identity activity.
- Tune for suspicious sequences such as risky web access followed by abnormal device behavior or unusual application access token activity, while accounting for benign browsing noise.
- Review blind spots caused by unmanaged mobile devices, encrypted traffic visibility limits, privacy controls, lack of mobile browser telemetry, and incomplete identity log retention.
- Use the relationship to T1456 as context: coverage should be tested against Android and iOS environments if they are in scope.
Mitigation priorities
- Prioritize mobile device inventory and management so responders know which Android and iOS devices are in scope.
- Ensure mobile web security, device posture, and identity token logs are retained and correlated for investigations.
- Harden mobile browser and application update practices through managed configuration where applicable.
- Review identity controls around application access tokens, including visibility into issuance, refresh, and anomalous use.
- Document detection and response procedures for suspected mobile drive-by compromise, including device isolation, token review, and user impact assessment.
Analyst notes and limits
This take is based on DET0614 and its stated relationship to T1456 Drive-By Compromise. Because the detection strategy lacks official description and detection fields, the practical guidance focuses on validation questions and evidence classes implied by the related technique’s mobile browser and application access token context.
ATT&CK provides no official detection logic, tactics, labels, aliases, or platforms for DET0614 itself. Local architecture determines whether the listed telemetry exists, whether it can be correlated to users and devices, and whether privacy or BYOD constraints limit collection.
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 |
|---|---|---|---|
| Mobile | T1456 | 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 | 3200b4e6e29e… |
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 DET0614Open 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.