TA0030: Defense Evasion
The adversary is trying to avoid being detected.
Defense evasion consists of techniques an adversary may use to evade detection or avoid other defenses. Sometimes these actions are the same as or variations of techniques in other categories that have the added benefit of subverting a particular defense or mitigation. Defense evasion may be considered a set of attributes the adversary applies to all other phases of the operation.
Analyst context for executives and security teams
Defense Evasion in the ATT&CK mobile domain is a high-level objective: the adversary is trying to avoid being detected or bypass defenses. For leaders, the practical issue is not one specific tool or platform, but whether mobile security controls, monitoring, and incident response processes can still produce usable evidence when an intrusion attempts to hide, suppress alerts, or blend into other activity.
Executive priority
Treat this as a resilience and assurance question: can the organization prove that mobile-related defenses remain observable and trusted during an incident? Because ATT&CK provides no specific detection guidance for this tactic, executives should ask for evidence of control health monitoring, mobile telemetry coverage, escalation paths when visibility is degraded, and audit-ready documentation showing how evasion attempts are investigated. This supports budget decisions around managed detection, mobile security operations, incident response readiness, and compliance evidence for monitoring effectiveness.
Technical view
SOC, detection engineering, and IR teams should use this tactic as a validation lens across mobile ATT&CK techniques rather than as a standalone detection. Confirm which mobile data sources can show attempted concealment, defense bypass, alert suppression, policy changes, suspicious app behavior, or loss of sensor visibility. Because no platforms, techniques, or relationships are supplied with this object, detection content should be mapped locally to the mobile estate, deployed controls, and the specific techniques in scope for the organization.
Likely telemetry
- Mobile device management or unified endpoint management policy, enrollment, compliance, and configuration records where deployed
- Mobile security or endpoint sensor health, alert, quarantine, and tamper-status events where deployed
- Application inventory, installation, permission, and configuration change records for mobile devices
- Authentication, access, and session logs associated with managed mobile access to enterprise resources
- Network, DNS, proxy, or secure access telemetry that can be associated with mobile devices
Detection direction
- Do not treat the tactic itself as a single alert; map it to the specific mobile techniques and controls relevant to the environment.
- Validate that loss of visibility, disabled controls, unexpected policy changes, or missing telemetry are investigated as potential security events, not only as operational noise.
- Tune detections to distinguish legitimate administration, device lifecycle changes, and user-driven configuration changes from suspicious defense degradation.
- Review whether managed detection workflows include mobile evidence sources and whether analysts can correlate mobile events with identity and network activity.
- Because ATT&CK provides no detection text for this object, require local test cases, control validation, and incident review evidence before claiming coverage.
Mitigation priorities
- Prioritize reliable mobile asset inventory and management coverage so defenders know which devices should produce telemetry.
- Monitor the health and enforcement state of mobile security controls, not only the alerts they generate.
- Define incident response playbooks for degraded or missing mobile visibility, including escalation and evidence preservation expectations.
- Use identity and access policy enforcement to reduce business exposure when a mobile device becomes untrusted or noncompliant.
- Maintain compliance evidence showing monitoring coverage, control health checks, and investigation procedures for mobile defense evasion scenarios.
Analyst notes and limits
This object is a tactic-level entry, not a technique. It explains adversary intent to avoid detection and notes that evasion can appear as an attribute across other phases of an operation. The supplied object includes no detection guidance, no platforms, and no relationship context, so the most useful analysis is to frame validation questions and telemetry requirements rather than describe specific evasion behaviors.
Assessment is limited to the supplied official ATT&CK fields for TA0030 in the mobile domain. No active exploitation, attribution, affected platform, specific technique relationship, or guaranteed detection coverage is supported by the provided data. Local environment architecture and control telemetry are required to determine actual risk and coverage.
Defense Evasion
The adversary is trying to avoid being detected.
Defense evasion consists of techniques an adversary may use to evade detection or avoid other defenses. Sometimes these actions are the same as or variations of techniques in other categories that have the added benefit of subverting a particular defense or mitigation. Defense evasion may be considered a set of attributes the adversary applies to all other phases of the operation.
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 | 554a5172ec23… |
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 TA0030Open 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.