AN1216: Analytic 1216
Detects the relocation of malicious executables via copy/move actions across suspicious folders (e.g., from Downloads to System32), followed by deletion of the original source or renaming to blend into legitimate binaries.
Analyst context for executives and security teams
This analytic is about spotting a common preparation and concealment pattern on Windows: an executable is copied or moved from a user-controlled or suspicious location, such as Downloads, into a more trusted-looking folder, such as System32, and the original is then deleted or the file is renamed to resemble a legitimate binary. For leaders, the value is not the file movement itself; it is whether the organization can reconstruct suspicious file lineage quickly enough to support containment, eradication, and evidence-based incident decisions.
Executive priority
Prioritize this as a Windows endpoint visibility and incident readiness question. If SOC and IR teams cannot reliably see file copy, move, rename, and deletion activity across sensitive directories, they may miss attempts to stage or disguise malicious executables. Executives should ask whether endpoint telemetry supports timely investigation, whether retention is sufficient for post-incident reconstruction, and whether detections are tuned to distinguish routine software administration from suspicious relocation into trusted system paths.
Technical view
Validate coverage for Windows file-system activity involving executable relocation from user-writable or suspicious folders into sensitive or trusted-looking directories, followed by deletion of the source or renaming to blend into legitimate binaries. Because the official analytic provides a description but no detection logic, teams should define local path lists, executable extensions, trusted directory baselines, expected administrative workflows, and rename/delete correlation windows. Triage should preserve the source path, destination path, file name changes, timestamps, user context, process responsible for the copy or move, and any subsequent execution if available.
Likely telemetry
- Windows endpoint file creation, copy, move, rename, and deletion events
- Source and destination file paths, especially user download locations and system directories
- Process telemetry for the program performing the file operation
- User account and host context for the file operation
- File metadata such as name, extension, hash, signature status, and timestamps where collected
Detection direction
- Correlate executable file movement from suspicious or user-writable folders into sensitive Windows directories with deletion of the original source or renaming activity.
- Tune allowlists or baselines for legitimate software deployment, patching, administrative scripts, and installer behavior to reduce false positives.
- Give higher review priority to relocations into trusted-looking paths, suspicious name changes, unsigned or unusual binaries, and activity by non-administrative users where local policy makes that unexpected.
- Validate whether endpoint logging captures rename and deletion events; many environments collect process starts but lack complete file lineage.
- Use this analytic as an investigation trigger rather than a standalone verdict, since the supplied ATT&CK object does not include formal detection logic or relationship context.
Mitigation priorities
- Ensure Windows endpoint monitoring captures file creation, movement, rename, and deletion activity in relevant directories.
- Restrict unnecessary write access to sensitive system folders and review administrative pathways that legitimately place executables there.
- Maintain baselines for approved software installation and deployment behavior so suspicious relocation patterns stand out.
- Preserve sufficient endpoint telemetry retention for incident response reconstruction of source, destination, and rename history.
- Document this coverage for compliance and audit evidence where endpoint monitoring and incident response readiness are assessed.
Analyst notes and limits
This is a detection analytic object, not a technique object. ATT&CK lists Windows as the platform and describes suspicious executable relocation behavior, but it does not provide tactics, detection pseudocode, related techniques, or relationships. Local engineering is required to convert the description into production logic and tune it against normal administrative and software installation activity.
The supplied object contains no official detection implementation and no relationship context. This take cannot infer adversary groups, campaigns, active exploitation, impact, or guaranteed detection outcomes. Coverage depends on local Windows endpoint telemetry depth, logging configuration, retention, and path/process baselines.
Analytic 1216
Detects the relocation of malicious executables via copy/move actions across suspicious folders (e.g., from Downloads to System32), followed by deletion of the original source or renaming to blend into legitimate binaries.
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 | 2650bb5f0132… |
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 AN1216Open 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.