UNC3886G1048 ↗
Has replaced atomic indicators mentioned in threat intelligence publications, sometimes as quickly as under a week after release.1
tfMITRE ATT&CK sub-technique
Indicator Removal from Tools T1027.005
sub-technique of T1027 Obfuscated Files or Information
- Tactic
- Stealth
- Platforms
- Linux, macOS, Windows
- Version
- 2.0
- Created
- 19 March 2020
- Last modified
- 12 May 2026
Adversaries may remove indicators from tools if they believe their malicious tool was detected, quarantined, or otherwise curtailed. They can modify the tool by removing the indicator and using the updated version that is no longer detected by the target's defensive systems or subsequent targets that may use similar systems.
ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact
7
Threat groupsTop 23%
Threat groups77th percentile · 77% of ATT&CK techniques have this many threat groups attributed or fewer.2
CampaignsTop 17%
Campaigns83rd percentile · 83% of ATT&CK techniques have this many campaigns recorded or fewer.9
Tools & malware73rd pct
Tools & malware73rd percentile · 73% of ATT&CK techniques have this many tools implementing them or fewer.6
Detection rules67th pct
Detection rules67th percentile · 67% of ATT&CK techniques have this many detection rules written or fewer.Indicator Removal from Tools MITRE reference T1027.005
Top 23%of all ATT&CK techniques for number of groups
7 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
GALLIUMG0093 ↗
Ensured each payload had a unique hash, including by using different types of packers.1
OilRigG0049 ↗
Has tested malware samples to determine AV detection and subsequently modified the samples to ensure AV evasion.12
PatchworkG0040 ↗
Apparently altered NDiskMonitor samples by adding four bytes of random letters in a likely attempt to change the file hashes.1
APT3G0022 ↗
Has been known to remove indicators of compromise from tools.1
TurlaG0010 ↗
Based on comparison of Gazer versions, Turla made an effort to obfuscate strings in the malware that could be used as IoCs, including the mutex name and named pipe.1
All 7 groups for this technique · 6 newest in this preview
2 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
Operation WocaoC0014 ↗
During Operation Wocao, threat actors edited variable names within the Impacket suite to avoid automated detection.1
Triton Safety Instrumented System AttackC0030 ↗
In the Triton Safety Instrumented System Attack, TEMP.Veles modified files based on the open-source project cryptcat in an apparent attempt to decrease anti-virus detection rates.1
All 2 campaigns for this technique
9 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
QakBotS0650 ↗
Can make small changes to itself in order to change its checksum and hash value.12
PenquinS0587 ↗
Can remove strings from binaries.1
WaterbearS0579 ↗
Can scramble functions not to be executed again with random values.1
SUNBURSTS0559 ↗
Source code used generic variable names and pre-obfuscated strings, and was likely sanitized of developer comments before being added to SUNSPOT.1
GravityRATS0237 ↗
The author of GravityRAT submitted samples to VirusTotal for testing, showing that the author modified the code to try to hide the DDE object in a different part of the document.1
InvisiMoleS0260 ↗
Has undergone regular technical improvements in an attempt to evade detection.1
All 9 software entries for this technique · 6 newest in this preview
Offense vs defense T1027.005
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Range
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Campaigns · 2Sigma rules (cumulative) · 4Splunk ESCU (cumulative) · 2
first rule: 2017 Q2 · 2 of 2 campaigns plottedIndicator Removal from Tools detection strategy DET0189
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Indicator Removal from Tools - Post-AV Evasion Modification
3 platforms
AN0540 · Windows
Detection of known tools or malware flagged by antivirus, followed by a near-term drop of a similar binary with modified signature and resumed activity (execution, C2, or persistence).
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| Application Log ContentDC0038 | WinEventLog:Application | EventCode=1000 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AVAlertMessage | Vendor-specific signature string or detection message that can be correlated to threat intel context. |
| TimeWindow | The time between AV alert and similar file/process activity (e.g., 5–30 minutes) |
| FilenameSimilarityThreshold | String or hash similarity thresholds between original and modified binary. |
AN0541 · Linux
Detection of anti-malware quarantining or flagging a tool, followed by a new binary written to disk with a similar function or name and a resumed process chain.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process ModificationDC0020 | auditd:SYSCALL | open, rename |
| Process CreationDC0032 | auditd:SYSCALL | execve |
| Application Log ContentDC0038 | EDR:detection | ThreatDetected, QuarantineLog |
| File MetadataDC0059 | linux:osquery | file_events |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| PathWatchlist | Tunable list of directories often abused for dropped binaries (e.g., /tmp, ~/.cache, /opt/soft/). |
| ProcessAncestryDepth | Limit how far up the tree to trace tool modification behavior for detection. |
AN0542 · macOS
Detection of XProtect or AV quarantining a known tool, followed by modification (file size, hash, string) and subsequent re-execution by the same or related user.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Application Log ContentDC0038 | macos:unifiedlog | quarantine or AV-related subsystem |
| File MetadataDC0059 | macos:osquery | file_events |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| BinaryChangeThreshold | File hash delta or binary string diff score to tolerate renamed/mutated variants. |
| UserContext | User or group expected to use dev tools; reduce false positives from legitimate repacking. |