DET0439: Detection of Malware Relocation via Suspicious File Movement
DET0439 is a detection strategy for spotting suspicious file movement associated with malware relocation. The business significance is that relocated malwa...
Analyst context for executives and security teams
DET0439 is a detection strategy for spotting suspicious file movement associated with malware relocation. The business significance is that relocated malware can undermine incident containment and create false confidence that cleanup is complete, especially when older artifacts are deleted or renamed to blend into the environment.
Executive priority
Treat this as an incident response and resilience validation item: can the organization prove where suspicious binaries moved, whether copies remain, and whether cleanup removed all related artifacts? Because the linked ATT&CK technique is categorized under stealth and applies to Linux, macOS, network devices, and Windows, leaders should ask whether endpoint, server, and network-device logging is sufficient to reconstruct file movement during an investigation.
Technical view
The supplied detection strategy has no official detection logic, platforms, or tactic fields, so SOC teams should anchor validation to the related technique, T1070.010 Relocate Malware. Detection engineering should focus on evidence of suspicious copying, renaming, or movement of payload-like files, especially when followed by deletion of earlier artifacts or relocation into paths that help the file blend into the local environment. IR teams should validate whether file movement timelines can be correlated with process execution, file deletion, and endpoint inventory evidence.
Likely telemetry
- File creation, copy, rename, move, and deletion events where available
- Endpoint process execution telemetry associated with file operations
- File path, filename, hash, signer, and ownership metadata
- EDR or host audit logs from Windows, Linux, and macOS systems where collected
- Network-device file system or administrative activity logs where supported
Detection direction
- Validate that detections can correlate the same or similar file appearing in a new location after delivery or execution.
- Look for relocation paired with cleanup behavior, such as deletion of the original artifact, because the related technique notes this may be combined with File Deletion.
- Tune for local baseline context: legitimate software updates, installers, administrative scripts, and security tools may also copy or rename files.
- Prioritize suspicious file movement into locations that appear intended to blend into the local environment, while avoiding assumptions not supported by local evidence.
- Confirm coverage across the platforms named by the related technique: Linux, macOS, network devices, and Windows; the detection strategy itself does not specify platform coverage.
Mitigation priorities
- Ensure endpoint and relevant device logging can preserve file movement and deletion evidence long enough for investigation.
- Standardize IR procedures to search for renamed or copied payloads, not only the originally observed file path.
- Use file integrity, application control, and least-privilege controls where appropriate to reduce unauthorized movement or execution of suspicious files.
- Maintain asset and software baselines so defenders can distinguish expected file relocation from suspicious blending behavior.
- Include file relocation evidence requirements in incident response, audit, and compliance readiness exercises.
Analyst notes and limits
This take is based on DET0439 and its relationship to T1070.010 Relocate Malware. The detection strategy record provides a name and external reference but no official description or detection text, so the practical guidance is derived conservatively from the related technique description and platform/tactic context.
No official detection logic, data sources, platforms, or tactics are specified for DET0439 itself. Local telemetry availability, retention, endpoint coverage, and normal software behavior will determine whether this strategy can be implemented reliably.
Detection of Malware Relocation via Suspicious File Movement
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 |
|---|---|---|---|
| Enterprise | T1070.010 | Relocate Malware Sub-technique | This object detects Relocate Malware. |
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 | 83fee094a77c… |
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 DET0439Open 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.