AN1802: Analytic 1802
Defender correlates a causal chain where a device transitions into USB debugging or file transfer mode after a physical connection event, followed by application installation, file replication, or execution originating from the USB interface rather than the application store ecosystem.
Analyst context for executives and security teams
This analytic is about spotting a risky Android device sequence: a physical USB connection is followed by USB debugging or file-transfer mode, then app installation, file replication, or execution from the USB path rather than the normal app-store ecosystem. For leaders, the value is not just mobile malware detection; it is validating whether the organization can see and investigate hands-on device access, sideloading-style activity, and data movement paths that bypass managed distribution controls.
Executive priority
Prioritize this where Android devices are used for sensitive work, field operations, regulated data handling, or operational environments where physical access to devices is plausible. The business decision is whether mobile security, endpoint management, and incident response teams have evidence to distinguish authorized USB servicing from suspicious post-connection activity. This supports resilience, compliance evidence for mobile control enforcement, and incident triage when a device may have been physically accessed or manipulated.
Technical view
For Android, validate whether telemetry can correlate the causal chain described by ATT&CK: physical USB connection event, transition into USB debugging or file transfer mode, and subsequent application installation, file replication, or execution originating from the USB interface rather than the application store ecosystem. Because no official detection logic is supplied, detection engineering should focus on correlation quality, event timing, source attribution for installs or file operations, and clear separation between approved administrative workflows and unexpected USB-originated activity.
Likely telemetry
- Android device management or mobile security events showing USB connection state
- Events indicating USB debugging enabled or device entering file transfer mode
- Application installation records, including source/origin where available
- File replication or file transfer records tied to USB/MTP access where available
- Execution or app launch telemetry that can be temporally linked to USB-originated installation or files
Detection direction
- Build or validate a correlation that requires sequence, not isolated events: USB physical connection followed by debugging/file-transfer mode, then install, replication, or execution from USB-originated content.
- Tune for approved workflows such as IT provisioning, repair, developer testing, kiosk maintenance, or authorized data transfer to reduce false positives.
- Confirm whether the telemetry can identify origin: USB interface versus application store ecosystem. If origin is unavailable, treat detections as lower confidence triage leads.
- Review alert windows and device context, including ownership, user role, management status, and whether USB debugging is expected for that device population.
- Document blind spots where unmanaged Android devices, limited mobile telemetry, or privacy constraints prevent collection of USB mode, install source, or file movement evidence.
Mitigation priorities
- Establish policy expectations for Android USB debugging and file transfer use, especially on managed or sensitive devices.
- Use mobile device management controls where available to restrict or monitor USB debugging, sideloading-related behavior, and unauthorized app installation paths.
- Define approved exceptions for developer, support, and maintenance workflows so detection tuning has authoritative allow-list context.
- Ensure incident response playbooks include triage for suspected physical access to Android devices, including user interview, device custody context, and review of recent installs and file transfers.
- Maintain compliance-ready evidence showing mobile configuration policy, exception handling, and monitoring coverage for USB-related device activity.
Analyst notes and limits
ATT&CK provides this as a mobile detection analytic for Android with a clear behavioral chain but no official detection query, no tactics listed, and no relationship context. The strongest use is as a coverage validation pattern: can the organization correlate physical connection, USB mode change, and USB-originated install/file/execution activity?
The supplied object does not include active exploitation details, adversary attribution, related techniques, mitigations, or a concrete detection implementation. Local Android management capabilities, logging depth, privacy constraints, and approved operational workflows will determine practical detectability and confidence.
Analytic 1802
Defender correlates a causal chain where a device transitions into USB debugging or file transfer mode after a physical connection event, followed by application installation, file replication, or execution originating from the USB interface rather than the application store ecosystem.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | 40e994a5c321… |
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 AN1802Open 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.