Mobile spyware and banking malware rarely send stolen data as it is collected: they compress it, encrypt it, or both, so the upload is smaller, faster and harder to read in transit. MITRE ATT&CK for Mobile records this as T1532 Archive Collected Data, a Collection technique listed for both Android and iOS. ATT&CK maps no mitigations to it, because compression and encryption are normal app behaviour, so the defensive work moves to the steps around it: what the app could collect, where it stages the result, and where it sends it. This guide explains the technique with the procedure examples ATT&CK records, the telemetry that can and cannot see it on each platform, and the controls that limit what ends up in the archive. It is for mobile security engineers, SOC analysts working with MDM and mobile threat defence (MTD) data, and incident responders handling suspected spyware.
Key takeaways
- It is a staging step, not an end goal. T1532 sits between collection techniques such as T1533 Data from Local System and exfiltration techniques such as T1646 Exfiltration Over C2 Channel; detect the chain, not the archive alone.
- No mitigations are mapped. ATT&CK states the technique is hard to address with preventive controls because it abuses system features, so prevention means limiting what an app can read in the first place.
- Both platforms appear in real reporting. ATT&CK records Android families such as FrozenCell and BRATA and the iOS-capable LightSpy compressing or encrypting data before upload.
- The best signal is a sequence. ATT&CK's detection strategy DET0670 describes a read-then-archive pattern: broad background data access followed by a large, high-entropy file written to app-private storage.
- Most evidence comes from vetting and forensics. Neither Android nor iOS gives a live SOC feed of file writes inside an app sandbox; dynamic app analysis, MTD and consensual forensic acquisition fill the gap.
What T1532 covers on mobile
ATT&CK describes the technique as compressing and/or encrypting collected data before exfiltration. Compression reduces network use and hides content; encryption hides what is leaving from inspection. Either can be done with a standard utility, a programming library or a custom algorithm. As of ATT&CK v20.1 the technique (version 2.0, last modified 24 October 2025) is listed for Android and iOS, has no sub-techniques and no mapped mitigations. It mirrors the Enterprise technique T1560; see the T1560 and T1074 Archive and Stage Collected Data Defensive Guide for the desktop and server view. For where the technique sits in the wider mobile matrix, see the MITRE ATT&CK for Mobile Guide.
On a phone the archive normally lives inside the malicious app's own sandbox: on Android the app-private directories under its data folder or cache, on iOS the app's randomly assigned home directory. Neither location is visible to other apps or, without forensic acquisition, to the device owner. That is why the technique is hard to see directly and why the surrounding steps matter more.
Procedure examples from ATT&CK
The table summarises procedure examples recorded by ATT&CK for T1532, as ATT&CK states them. Attribution and detail come from the cited ATT&CK software and campaign pages.
| Software or campaign | What ATT&CK records | Method |
|---|---|---|
| BRATA (S1094) | Compressed data with the zlib library before exfiltration | Compression library |
| LightSpy (S1185) | Collects and compresses data to be exfiltrated using SSZipArchive | Compression library |
| FrozenCell (S0577) | Compressed and encrypted data in password protected .7z archives | Archive with password |
| DCHSpy (S1243) | Compressed and encrypted collected data with a password from the C2 server | Archive, server-supplied password |
| Sunbird (S1082) | Can exfiltrate collected data as a ZIP file | ZIP |
| Golden Cup (S0535) | Encrypted exfiltrated data using AES in ECB mode | Symmetric encryption |
| Anubis (S0422) | Exfiltrates data encrypted with RC4 by its ransomware module | Symmetric encryption |
| Exodus (S0405), GolfSpy (S0421) | Encrypt data with XOR before exfiltration | Simple custom encoding |
| C0033 (PROMETHIUM, StrongPity) | Exfiltrated encrypted data to the C2 server | Encryption before upload |
Two patterns stand out. First, most families use ordinary libraries (zlib, ZIP, 7z, AES), so the code itself is not a reliable indicator. Second, families with server-supplied passwords, such as DCHSpy as ATT&CK records it, mean a forensic examiner may recover an archive but not its contents without the key from network evidence.
Android and iOS: what differs
| Aspect | Android | iOS |
|---|---|---|
| Where staged data sits | App-specific internal storage (getFilesDir(), getCacheDir()) or app-specific external storage; both are removed on uninstall | The app's sandboxed home directory, randomly assigned at install; other apps cannot read it |
| What limits the input | Runtime permissions and scoped storage (Android 10 and later); broad file access needs MANAGE_EXTERNAL_STORAGE (Android 11 and later) | App sandbox and signed entitlements; access to other data only through system services |
| Management visibility | Android Enterprise managed package inventory, permission grant state via DevicePolicyManager.getPermissionGrantState(), network logging | Apple MDM installed application list; no per-file telemetry |
| Forensic route | Consensual acquisition and MVT (Android backups, intrusion logs) | MVT on iOS backups, filesystem dumps and sysdiagnose files |
| Hardening for high-risk users | Restrict sideloading, keep Play Protect on, Android Enterprise work profile | Lockdown Mode (iOS 16 and later) |
Prevention: limit what can be archived
Because the archiving step itself cannot be blocked, prevention means reducing what a malicious or over-privileged app can collect and making sure the archive has nowhere useful to go.
- Control app sources. On managed Android devices restrict installs to managed Google Play and keep Play Protect enabled; Google states Play Protect checks apps installed from outside Play at install time against known harmful samples and on-device models. On iOS, distribute through the App Store or MDM-managed apps only.
- Reduce data scope. Deny or audit broad storage permissions. On Android, flag any app holding
MANAGE_EXTERNAL_STORAGE, which the Android documentation says most apps do not need. Prefer the system photo and document pickers so apps receive only what the user selects. - Separate work data. Use an Android Enterprise work profile or iOS managed apps so corporate data sits in managed containers that personal apps cannot read. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.
- Keep the OS current. Several families in the table rely on older permission models. ATT&CK mitigations M1001 Security Updates and M1006 Use Recent OS Version apply to the collection steps that feed T1532.
- Protect high-risk users. Offer Lockdown Mode on iOS to staff at risk of targeted spyware; Apple documents that it blocks most message attachment types, some web technologies and wired connections to a locked device.
Detection and measurement
ATT&CK's detection strategy DET0670 Detection of Archive Collected Data describes the same logic for both platforms: correlate the app's permissions, the managed app state and file creation evidence, then alert on a sequence inconsistent with the app's baseline. The Android analytic describes an app reading files across multiple directories or databases in the background, then writing an archive-like container, high-entropy blob or .zip or .gz output to app-private or cache storage. The iOS analytic describes a large container, temporary package or high-entropy blob written to container-local storage after clustered data access. ATT&CK also warns not to infer file activity or payload content from management state alone.
- App vetting: in dynamic analysis, watch for read-then-archive sequences and for compression or crypto libraries invoked on user data while the app is not in use. Flag apps that bundle 7z or password-protected ZIP handling with no user-facing feature that needs it.
- Network evidence: on Android, network logging (device owner from Android 8.0, work profile owner from Android 12) records DNS lookups and TCP connections per package. A burst of outbound volume from an app with no sync feature, following quiet collection, is the downstream view of T1532.
- MTD: mobile threat defence agents combine app reputation with on-device behaviour. See the Mobile Threat Defense Buyer's Guide for evaluation criteria.
- Forensics: in a spyware investigation, list unexpected archives and high-entropy files in app containers and correlate their timestamps with network records. See the Mobile Verification Toolkit (MVT) guide.
Metrics:
- Percentage of managed devices with sideloading restricted and Play Protect on (Android) or MDM-managed app distribution (iOS).
- Number of managed apps holding broad storage permissions, and the trend over time.
- Percentage of new apps passing dynamic analysis that includes a background data access check.
- Mean time from an MTD high-risk app alert to device quarantine or app removal.
- Percentage of devices on a supported, current OS version.
Where identity fits
An archive built on a phone often contains more than photos and messages. ATT&CK's examples for the collection techniques that feed T1532 include authentication tokens, account data and Wi-Fi passwords. If a mobile app stores OAuth refresh tokens, API keys or MDM enrolment credentials in readable app storage, they leave with the archive. Keep tokens in the Android Keystore or iOS Keychain, bind them to the device where possible, and plan revocation as part of response. See OAuth for Native and Mobile Apps Guide.
Common failure patterns
- Hunting for the archive format. Families use standard ZIP, zlib, 7z and AES, so signature checks on archive formats produce noise. Hunt for the read-then-archive-then-upload sequence instead.
- Assuming encryption in transit is enough to inspect. TLS inspection does not reveal content that was encrypted before upload with a key the attacker controls.
- Treating MDM inventory as detection. An installed application list tells you what is present, not what it is doing. ATT&CK's own guidance warns against inferring file activity from management state.
- Leaving broad storage permission unreviewed. Apps granted all-files access years ago keep it; review grants after OS upgrades and at app updates.
- Wiping before acquisition. Resetting a suspected device destroys the staged archives and timestamps that show what was taken. Acquire first, then remediate; see the Mobile Spyware Infection Response Playbook.
Framework mapping
| Framework | Reference | Why it applies |
|---|---|---|
| ATT&CK for Mobile | T1532 Archive Collected Data; detection DET0670 | The technique and its detection strategy |
| ATT&CK for Mobile | T1533, T1646 (adjacent steps); M1001, M1006 | Collection feeding the archive, exfiltration following it, mitigations on the feeder steps |
| NIST SP 800-53 Rev 5 | AC-19 Access Control for Mobile Devices; CM-11 User-installed Software; SI-4 System Monitoring; SC-28 Protection of Information at Rest | Mobile device policy, app source control, monitoring and protecting staged data sources |
| NIST CSF 2.0 | PR.PS-05; DE.CM-09; DE.CM-01 | Prevent unauthorised software; monitor devices and network for adverse events |
| OWASP MASVS | MASVS-STORAGE; MASVS-PRIVACY | How your own apps store sensitive data and limit collection, so less is exposed to other apps |
Practitioner checklist
- Restrict app sources on managed devices and confirm Play Protect is on for Android fleets.
- Report and review every managed app holding broad storage permission.
- Put corporate data in work profiles or managed apps only.
- Enable Android Enterprise network logging where you own the device or work profile, and feed it to the SIEM.
- Add a background read-then-archive check to dynamic app vetting.
- Offer Lockdown Mode to iOS users at high risk of targeted spyware.
- Store tokens in Keystore or Keychain, never in plain app files, and document how to revoke them.
- Acquire suspected devices forensically before wiping, and keep network records for key recovery.
Standards and references
- MITRE ATT&CK: T1532 Archive Collected Data (Mobile)
- MITRE ATT&CK: T1560 Archive Collected Data (Enterprise)
- Android Developers: Data and file storage overview
- Android Developers: Network activity logging
- Apple Platform Security: Security of runtime process in iOS, iPadOS and visionOS
- Apple Support: About Lockdown Mode
- Google: Play Protect client protections
- Amnesty International Security Lab: Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · ATT&CK Collection Tactic Guide · Commercial Spyware Guide · Mobile Forensics Guide · Data Exfiltration Guide