AN0247: Analytic 0247
Behavioral sequence where removable media is mounted, files are written/updated, and subsequently read/executed on a separate host, suggesting removable-media relay communication.
Analyst context for executives and security teams
AN0247 describes a Windows-focused detection analytic for a removable-media relay pattern: media is mounted on one host, files are written or updated, and those files are later read or executed on a different host. For leaders, the practical concern is not just USB usage; it is whether removable media can move data, tools, or operational instructions across systems without normal network controls seeing it.
Executive priority
Prioritize this where removable media is allowed for business operations, recovery workflows, transfers between segmented environments, or operational technology support. The key decision value is confirming whether the organization can produce defensible evidence of cross-host removable-media activity during an incident or audit, and whether policy exceptions are monitored rather than simply documented.
Technical view
SOC and IR teams should validate whether Windows telemetry can correlate removable media mount events, file write/update activity, and subsequent file read or execution on a separate host. Because the ATT&CK object provides no official detection logic or relationship context, local implementation should focus on sequence correlation, host identity, device identity, file path/hash/name, timestamps, and process context. Baseline legitimate removable-media workflows before treating the pattern as suspicious.
Likely telemetry
- Windows removable media mount or device connection events
- File creation, modification, read, and execution activity on removable media paths
- Process execution events with command line, parent process, user, and host context
- Device or volume identifiers that can link the same removable media across hosts
- File metadata such as name, path, size, hash, and timestamps
Detection direction
- Validate that telemetry survives across multiple hosts and can correlate the same removable media device or volume over time.
- Tune for behavioral sequences: mount, write or update, then read or execute on a different Windows host.
- Separate common administrative, backup, imaging, and business transfer workflows from unusual cross-host execution patterns.
- Review blind spots where endpoint logging is disabled, removable media identifiers are not collected, file reads are not visible, or execution from removable paths is not captured.
- Use the analytic as a detection-design prompt rather than a ready rule, since no official detection logic is supplied.
Mitigation priorities
- Inventory where removable media is permitted and document business owners, approved use cases, and exception handling.
- Restrict or govern removable media use where business justification is weak, especially for sensitive or segmented systems.
- Ensure endpoint controls and logging cover device mount, file activity, and execution from removable paths on Windows hosts.
- Use policy, user training, and operational procedures to reduce unmanaged transfers between hosts.
- Confirm incident response playbooks include removable-media collection, chain of custody, and cross-host timeline reconstruction.
Analyst notes and limits
The object is a detection analytic, not a technique entry. It has Windows as the only supplied platform, no tactics, no official detection text, and no supplied relationships. The strongest use is as a validation checklist for removable-media monitoring and incident reconstruction.
Assessment is limited to the supplied ATT&CK fields and external reference. No attribution, active exploitation, impact, or specific detection coverage is implied. Local device-control policy, endpoint logging, and normal removable-media workflows are required to judge risk and tune detections.
Analytic 0247
Behavioral sequence where removable media is mounted, files are written/updated, and subsequently read/executed on a separate host, suggesting removable-media relay communication.
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.0 | Current bundle | 058090b20707… |
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 AN0247Open 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.