TA0103: Evasion
The adversary is trying to avoid security defenses.
Evasion consists of techniques that adversaries use to avoid technical defenses throughout their campaign. Techniques used for evasion include removal of indicators of compromise, spoofing communications, and exploiting software vulnerabilities. Adversaries may also leverage and abuse trusted devices and processes to hide their activity, possibly by masquerading as master devices or native software. Methods of defense evasion for this purpose are often more passive in nature.
Analyst context for executives and security teams
Evasion in the ICS ATT&CK context is the adversary objective of staying hidden from security defenses while conducting a campaign. For leaders, the key issue is not one specific tool or platform, but whether the organization can still see suspicious activity when an adversary removes indicators, spoofs communications, abuses trusted devices or processes, masquerades as legitimate control activity, or exploits software vulnerabilities to bypass controls.
Executive priority
Treat this as a resilience and assurance question: can the business prove that critical operational environments have enough independent visibility, logging, and response process maturity to detect activity that is designed to look trusted or normal? This matters for incident decision-making, compliance evidence, vulnerability prioritization, and cyber-physical risk because passive or disguised activity in ICS environments may not trigger obvious alarms until later stages of an incident.
Technical view
ATT&CK provides this object as an ICS tactic, not a technique, and no official detection guidance or platform scope is supplied. SOC, detection engineering, and IR teams should use it as a coverage-mapping category: identify which ICS-relevant techniques under Evasion are in scope locally, then validate whether telemetry can reveal indicator removal, communication spoofing, abuse of trusted devices/processes, masquerading as master devices or native software, and vulnerability-enabled bypass of defenses. Because no relationships were supplied, this take should not infer specific techniques, assets, vendors, or procedures.
Likely telemetry
- Security control alerts and audit logs showing blocked, bypassed, disabled, or missing detections
- Network communications metadata that can help distinguish expected control traffic from spoofed or masqueraded activity
- Device, application, and process logs from trusted systems where adversaries may hide activity
- Change records and configuration evidence for control systems, security tools, and monitored assets
- Vulnerability and patch management evidence for software flaws that could be used to evade defenses
Detection direction
- Map Evasion as a tactic-level coverage objective rather than a single detection rule.
- Validate whether monitoring depends too heavily on indicators that an adversary could remove or alter.
- Review whether trusted devices, trusted processes, native software, and master-device-like communications are baselined and monitored for abnormal use.
- Confirm that spoofed communications and masquerading scenarios are considered in detection logic where local architecture supports such analysis.
- Tune detections carefully to avoid treating all legitimate trusted-device or native-software activity as suspicious; environment-specific baselines are required.
Mitigation priorities
- Prioritize visibility and auditability across critical ICS assets and trusted communication paths before relying on alert outcomes alone.
- Maintain vulnerability management discipline for software that could be exploited to bypass technical defenses.
- Harden and monitor trusted devices, native software, and processes that could be abused for concealment.
- Preserve logs and response evidence in ways that make indicator removal or tampering easier to identify.
- Exercise IR playbooks against scenarios where activity appears legitimate, passive, or masked by trusted infrastructure.
Analyst notes and limits
This is a tactic-level ATT&CK object for ICS Evasion, so its main value is as a planning and coverage category. It should drive questions about independent telemetry, trusted-path monitoring, vulnerability exposure, and response readiness rather than a single analytic.
The supplied ATT&CK fields include no official detection text, no platforms, and no relationship context. Specific detections, affected technologies, adversary procedures, and control recommendations require local architecture details and related ATT&CK technique mappings not provided here.
Evasion
The adversary is trying to avoid security defenses.
Evasion consists of techniques that adversaries use to avoid technical defenses throughout their campaign. Techniques used for evasion include removal of indicators of compromise, spoofing communications, and exploiting software vulnerabilities. Adversaries may also leverage and abuse trusted devices and processes to hide their activity, possibly by masquerading as master devices or native software. Methods of defense evasion for this purpose are often more passive in nature.
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 | 406c648c25e0… |
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 TA0103Open 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.