T1471: Data Encrypted for Impact
An adversary may encrypt files stored on a mobile device to prevent the user from accessing them. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware) or to render data permanently inaccessible in cases where the key is not saved or transmitted.
Analyst context for executives and security teams
This Android mobile technique matters because encrypted device files can quickly turn a user’s phone or tablet into an unavailable business asset and can block access to locally stored data. In practical terms, it is a mobile ransomware-style impact behavior: the attacker may seek payment for decryption, or may make the data permanently inaccessible if no usable key exists. For organizations with mobile-dependent workflows, the key decision is whether Android devices are backed up, monitored, and recoverable enough that file encryption becomes an incident to contain rather than a business disruption.
Executive priority
Prioritize this as a mobile resilience and incident response readiness issue. Leaders should ask whether Android devices used for business have enforceable backup, recovery, mobile security monitoring, and response processes. The ATT&CK relationships show this behavior is associated with Android malware families including Xbot, Anubis, and S.O.V.A.; that does not prove current exposure, but it supports treating mobile malware impact as a realistic planning scenario. This technique can also affect compliance evidence if business records, messages, or app data on mobile devices become unavailable without recoverable copies.
Technical view
For SOC, detection engineering, and IR teams, validate coverage for Android devices where business data may be stored locally. ATT&CK provides no official detection text for T1471, but a related detection strategy, DET0678 Detection of Data Encrypted for Impact, is linked. Teams should review that strategy where available and test whether existing mobile telemetry can show suspicious file encryption, rapid file modification, ransom-note-like artifacts, abnormal app behavior, or user reports of inaccessible files. Because the object has no specified ATT&CK tactic and no official detection guidance, local device management, mobile threat defense, backup, and incident workflow evidence will determine real coverage.
Likely telemetry
- Android mobile device management or enterprise mobility management inventory and compliance state
- Mobile threat defense or endpoint security alerts for Android applications
- File system or app-level evidence of rapid file changes, inaccessible files, or unusual storage activity where available
- Application installation and permission history for Android devices
- User reports of ransom prompts, inaccessible files, or unexpected device behavior
Detection direction
- Confirm whether DET0678 or an equivalent mobile detection strategy is implemented for Android environments.
- Validate that monitoring covers business-managed Android devices, not only traditional endpoints.
- Tune for combinations of signals rather than a single indicator: sudden file inaccessibility, suspicious app behavior, ransom messaging, unusual storage modification, and related mobile malware alerts.
- Account for false positives from legitimate encryption, secure container behavior, backup tools, or application updates that modify many files.
- Use relationship context to inform threat hunting for Android malware families known in ATT&CK to use this behavior: Xbot, Anubis, and S.O.V.A., without assuming those families are present.
Mitigation priorities
- Start with recoverability: ensure business data accessed or stored on Android devices is backed up or synchronized to recoverable services where appropriate.
- Enforce mobile device management controls for business Android devices, including application governance and visibility into device compliance.
- Limit unnecessary local storage of sensitive or operationally critical data on mobile devices when recovery cannot be assured.
- Maintain incident response playbooks for mobile ransomware-like events, including isolation, evidence preservation, device wipe or restore decisions, and user communications.
- Use mobile security monitoring and threat intelligence reviews to assess exposure to Android malware behaviors associated with this technique.
Analyst notes and limits
This take is based on the supplied ATT&CK object for T1471 Data Encrypted for Impact in the mobile domain, platform Android, with external references to MITRE ATT&CK and the NIST Mobile Threat Catalogue APP-28. The relationship context links one detection strategy, DET0678, and three software objects that use the technique: Xbot, Anubis, and S.O.V.A. The defensive value is primarily in validating mobile telemetry, recoverability, and response readiness rather than relying on a MITRE-provided detection description.
ATT&CK does not provide official detection text, tactics are not specified, and the supplied fields do not include mitigations or procedure-level details beyond the related software descriptions. This assessment does not claim active exploitation, attribution, customer exposure, or guaranteed detection coverage. Local Android fleet composition, management status, mobile security tooling, and backup architecture are required to determine actual risk and control effectiveness.
Data Encrypted for Impact
An adversary may encrypt files stored on a mobile device to prevent the user from accessing them. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware) or to render data permanently inaccessible in cases where the key is not saved or transmitted.
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.
Groups, software, and campaigns
S0298: Xbot
S0422: Anubis
S1062: S.O.V.A.
S.O.V.A. is an Android banking trojan that was first identified in August 2021 and has subsequently been found in a variety of applications, including banking, cryptocurrency wallet/exchange, and shopping apps. S.O.V.A., which is Russian for "owl", contains features not commonly found in Android malware, such as session cookie theft.[1][2]
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 | 3.2 | Current bundle | a342ff4236a2… |
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]
NIST Mobile Threat Catalogue APP-28Open source URL
-
[2]
mitre-attack T1471Open 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.