T1070.010: Relocate Malware
Once a payload is delivered, adversaries may reproduce copies of the same malware on the victim system to remove evidence of their presence and/or avoid defenses. Copying malware payloads to new locations may also be combined with File Deletion to cleanup older artifacts.
Relocating malware may be a part of many actions intended to evade defenses. For example, adversaries may copy and rename payloads to better blend into the local environment (i.e., Match Legitimate Resource Name or Location).[1] Payloads may also be repositioned to target File/Path Exclusions as well as specific locations associated with establishing Persistence.[2]
Relocating malicious payloads may also hinder defensive analysis, especially to separate these payloads from earlier events (such as User Execution and Phishing) that may have generated alerts or otherwise drawn attention from defenders. Moving payloads into target directories does not alter the Creation timestamp, thereby evading detection logic reliant on modifications to this artifact (i.e., Timestomp).
Analyst context for executives and security teams
Relocate Malware is a stealth behavior where an adversary copies or moves an already delivered payload to a new location to reduce evidence, blend in, avoid defenses, or support persistence. For leaders, the practical issue is not just the file move itself; it is whether the SOC can keep the investigation chain intact when malware is renamed, moved into a trusted-looking path, or separated from the original phishing or user-execution alert.
Executive priority
Prioritize this as a resilience and evidence-quality issue. If endpoint, server, macOS/Linux, Windows, or network-device file activity is not retained and correlated, incident responders may lose the timeline between initial delivery, later malware movement, deletion of older artifacts, and persistence setup. Security leaders should ask whether file/path exclusions are governed, whether persistence-sensitive directories are monitored, and whether audit evidence can show suspicious file movement was reviewed rather than hidden by exclusions or timestamp assumptions.
Technical view
ATT&CK provides no official detection text for this sub-technique, but the relationship context includes DET0439, Detection of Malware Relocation via Suspicious File Movement. SOC and detection teams should validate analytics that connect file copy, move, rename, and deletion activity with prior alerts such as phishing or user execution, suspicious process lineage, movement into excluded paths, legitimate-looking names or locations, and directories associated with persistence. Do not rely only on creation-time changes: the ATT&CK description notes that moving payloads into target directories does not alter the Creation timestamp, which can weaken timestamp-based logic.
Likely telemetry
- File creation, copy, rename, move, and deletion events on Windows, Linux, macOS, and supported network devices
- Process execution and parent-child process context around file movement
- Endpoint or host security alerts tied to earlier user execution or phishing events
- File metadata including path, filename, creation time, modification time, and ownership where available
- Records of file/path exclusions and locations excluded from defensive scanning
Detection direction
- Correlate suspicious file movement with earlier delivery or execution alerts instead of treating the relocated file as an isolated event.
- Tune for copy/rename/move into legitimate-looking names or locations, excluded paths, and persistence-associated directories.
- Review file deletion activity near malware relocation, because ATT&CK notes this behavior may be combined with File Deletion to clean up older artifacts.
- Avoid overdependence on Creation timestamp changes; movement may preserve creation time and evade timestamp-only logic.
- Establish false-positive handling for legitimate software installers, administrative scripts, patching tools, and security tooling that move binaries or stage files.
Mitigation priorities
- Govern and periodically review file/path exclusions so they do not become blind spots for relocated payloads.
- Limit write access to sensitive and persistence-relevant directories according to role and operational need.
- Ensure endpoint and server logging captures file movement and process context with sufficient retention for incident reconstruction.
- Strengthen IR playbooks to preserve both original and relocated paths, related deletion events, and metadata timestamps.
- Require detection validation across the supported platforms in scope: Linux, macOS, Network Devices, and Windows.
Analyst notes and limits
This object is a sub-technique of T1070 Indicator Removal and is categorized under stealth. The official description links the behavior to File Deletion, Match Legitimate Resource Name or Location, File/Path Exclusions, Persistence, User Execution, Phishing, and Timestomp as relevant context. A software relationship states that BRICKSTORM uses this object, which is useful for threat-informed validation but should not be treated as evidence of activity in any specific environment.
ATT&CK does not provide official detection guidance for this object. Conclusions about coverage require local validation of endpoint, server, macOS/Linux/Windows, and network-device telemetry, exclusion policies, and retention. The supplied fields do not support claims of active exploitation, customer exposure, or guaranteed detection.
Relocate Malware
Once a payload is delivered, adversaries may reproduce copies of the same malware on the victim system to remove evidence of their presence and/or avoid defenses. Copying malware payloads to new locations may also be combined with File Deletion to cleanup older artifacts.
Relocating malware may be a part of many actions intended to evade defenses. For example, adversaries may copy and rename payloads to better blend into the local environment (i.e., Match Legitimate Resource Name or Location).[1] Payloads may also be repositioned to target File/Path Exclusions as well as specific locations associated with establishing Persistence.[2]
Relocating malicious payloads may also hinder defensive analysis, especially to separate these payloads from earlier events (such as User Execution and Phishing) that may have generated alerts or otherwise drawn attention from defenders. Moving payloads into target directories does not alter the Creation timestamp, thereby evading detection logic reliant on modifications to this artifact (i.e., Timestomp).
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.
Related techniques
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 | Indicator Removal | This object subtechnique of Indicator Removal. |
Groups, software, and campaigns
S9015: BRICKSTORM
BRICKSTORM is a cross-platform backdoor with variants written in Go and Rust that facilitates command and control, the ingress transfer of other malware, and the exfiltration of data.[1][2][3][4] BRICKSTORM has also been created from a .NET application using ahead-of-time (AOT) compilation to blend in within victim environments.[1] BRICKSTORM was first observed in April 2024.[5] BRICKSTORM has previously been leveraged by People's Republic of China (PRC) state-nexus actors identified as UNC6201, UNC5221, WARP PANDA, PunyToad, and SYLVANITE.[6][7][1][8][9][10][3][4]
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 | 2.0 | Current bundle | 65dc63cfa8fb… |
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]
DFIR Report Trickbot June 2023
The DFIR Report. (2023, June 12). A Truly Graceful Wipe Out. Retrieved May 31, 2024.
Open source URL -
[2]
Latrodectus APR 2024
Proofpoint Threat Research and Team Cymru S2 Threat Research. (2024, April 4). Latrodectus: This Spider Bytes Like Ice . Retrieved May 31, 2024.
Open source URL -
[3]
mitre-attack T1070.010Open 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.