DET0189: Detection Strategy for Indicator Removal from Tools - Post-AV Evasion Modification
MITRE ATT&CK DET0189: Detection Strategy for Indicator Removal from Tools - Post-AV Evasion Modification Detection Strategy details, with detection guidance,…
Security context for executives and security teams
DET0189 is a detection-strategy object for spotting when adversaries alter tools after defensive products have detected or quarantined them. The business issue is not just malware detection; it is whether the organization can recognize the follow-on adaptation cycle where a previously blocked tool is changed to avoid the same indicator-based control. That matters for resilience because a single antivirus or signature hit may not end the incident if the attacker can quickly reintroduce a modified version.
Executive priority
Treat this as a validation point for incident response and SOC maturity: when security tools quarantine or block a file, leaders should ask whether the team can connect that event to later modified binaries, repeated delivery attempts, or changed indicators on Windows, Linux, and macOS assets. Priority should go to proving that endpoint telemetry, quarantine records, file metadata, and alert correlation are retained long enough to support investigation and evidence for audit or post-incident review. This is especially relevant when budgets are weighted heavily toward signature-based prevention without matching investment in investigation, correlation, and response workflows.
Technical view
The supplied ATT&CK relationship says this strategy detects T1027.005, Indicator Removal from Tools, under the stealth tactic, with related platforms Linux, macOS, and Windows. Because the official detection text for DET0189 is not provided, teams should validate coverage by testing their ability to correlate an initial detection or quarantine with later appearances of similar but not identical tools. Focus on endpoint and malware-analysis evidence that shows file changes, renamed or repacked artifacts, altered hashes, and recurring execution or delivery attempts after an initial AV/EDR action. SOC and IR workflows should avoid closing incidents solely on the first quarantine event without checking for subsequent modified artifacts.
Likely telemetry
- Endpoint protection, AV, or EDR detection and quarantine events
- File creation, modification, rename, and execution metadata
- Cryptographic file hashes and other file identity attributes over time
- Process execution records tied to newly introduced or modified files
- Alert history showing repeated detections or near-miss variants after an initial block
Detection direction
- Validate correlation between initial AV/EDR quarantine events and later modified files rather than treating each alert as unrelated.
- Look for repeated tool introduction or execution attempts where hashes or indicators change after a prior detection.
- Tune detections to reduce over-reliance on a single static file signature; include behavioral and temporal context where available.
- Check blind spots where quarantine logs, file metadata, or endpoint events are not retained, not centralized, or not searchable across operating systems.
- Account for false positives from legitimate software updates, recompilation, packaging changes, and administrative tooling that may alter file hashes without malicious intent.
Mitigation priorities
- Ensure endpoint protection quarantine and alert logs are centrally retained and available to SOC and IR teams.
- Prioritize investigation playbooks that require follow-up hunting after a malicious tool is blocked or quarantined.
- Strengthen endpoint visibility for file changes, process execution, and artifact recurrence across Windows, Linux, and macOS where those platforms are in scope.
- Use layered controls so prevention does not depend only on static indicators; pair signature-based alerts with behavioral review and response procedures.
- Document evidence retention and response steps for compliance readiness and post-incident review, especially when an incident begins with an AV quarantine event.
Additional notes and limits
The object itself has no official description, detection text, tactics, or platforms. The practical interpretation comes from its name and the supplied relationship showing it detects T1027.005, Indicator Removal from Tools, whose related platforms are Linux, macOS, and Windows and whose tactic is stealth. Local validation should be based on actual endpoint tooling, retention, and SOC workflow maturity.
This take does not assert active exploitation, attribution, guaranteed detection, or specific vendor capability. ATT&CK provides sparse DET0189 fields, so concrete analytics must be derived and tested in the local environment using available telemetry and approved detection engineering processes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detection Strategy for Indicator Removal from Tools - Post-AV Evasion Modification
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 | T1027.005 | Indicator Removal from ToolsSub-technique | This object detects Indicator Removal from Tools. |
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 | 897e9446d60b… |
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-attackDET0189Open source URL
- [2]mitre-attackDET0189Open source URL
- [3]mitre-attackDET0189Open 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.