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.
| ID | Name | Description |
|---|---|---|
| S0422 | Anubis |
Anubis can use its ransomware module to encrypt device data and hold it for ransom.[1] |
| S1062 | S.O.V.A. | |
| S0298 | Xbot |
Xbot can encrypt the victim's files in external storage (e.g., SD card) and then request a PayPal cash card as ransom.[3] |
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0678 | Detection of Data Encrypted for Impact | AN1781 |
For Android, detect Data Encrypted for Impact by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; OS API Execution via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: ContentResolver, DocumentProvider, StorageAccessFramework, or bulk stream I/O invocations exceed $FileModificationRateThreshold$ operations per minute across distinct file paths — API-level operation rate distinguishes ransomware from norma]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |