Mobile T1406 Obfuscated Files or Information: Exposing Mobile Evasion With MDM, MTD and Forensics

Mobile T1406 Obfuscated Files or Information is malware hiding its code, configuration and command server details by encrypting, encoding, packing or splitting them so that store review, scanners and analysts miss them. MITRE ATT&CK for Mobile v20 lists it under Defense Evasion for Android and iOS, with two sub-techniques: T1406.001 Steganography (Android only in ATT&CK) and T1406.002 Software Packing (Android and iOS). It is one of the most common mobile behaviours in ATT&CK, recorded for banking trojans, stalkerware and state-linked spyware alike. Because legitimate apps also obfuscate to protect their code, the defender's job is not to ban obfuscation but to find the combinations that only malware uses. This guide is for app vetting teams, mobile security engineers and SOC analysts. For the matrix overview see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Obfuscation alone is not malicious. OWASP MASVS-RESILIENCE treats obfuscation and anti-tampering as legitimate defence in depth, and notes malware uses the same techniques to evade review and analysts.
• Look for the write, then load chain. ATT&CK's Android analytics flag an app writing binary or DEX content into its own data directory and then loading it with DexClassLoader or dlopen.
• Packing defeats signatures, not behaviour. Commercial packers recorded in ATT&CK (Jiagubao for CherryBlos, the Tencent packer for Android/SpyAgent, FTT for Gustuff) change the file hash but not what the app does at runtime.
• Store policy is a control. Apple App Review Guideline 2.5.19 makes hiding undocumented features through code obfuscation grounds for removal.
• ATT&CK lists no mitigations for T1406. Defence is app source control, dynamic vetting and network monitoring, not a single setting.

What T1406 covers

ATT&CK describes T1406 as making a payload or file difficult to discover or analyse by encrypting, encoding or otherwise obfuscating its contents on the device or in transit. Payloads may be compressed, archived or encrypted, strings encoded, or functionality split across seemingly benign files that only become malicious when reassembled. The Enterprise counterpart is the T1027 Obfuscated Files or Information Defensive Guide.

T1406.001 Steganography

ATT&CK lists T1406.001 for Android only. The recorded example is Agent Smith (S0440), whose core malware was disguised as a JPG file and encrypted with an XOR cipher. ATT&CK's Android analytic for this sub-technique looks for a download, write and load chain: a media file downloaded, a binary file created in the app's private directory shortly after, and DexClassLoader or dlopen loading it. ATT&CK does not list iOS for this sub-technique, so this guide does not describe an iOS variant.

T1406.002 Software Packing

ATT&CK describes packing as compressing or encrypting an executable so its signature changes, with the real code usually decompressed in memory. Recorded examples include Bread (several commercial packers), Gustuff (FTT packer), S.O.V.A., BRATA, Crocodilus (packed dropper and payload) and CherryBlos (Jiagubao). The sub-technique applies to Android and iOS. For Android, ATT&CK's analytic suggests flagging DEX entropy above a threshold at install time for apps outside the MDM approved catalogue, and DexClassLoader calls at launch for paths not in the original APK. For iOS, it relies on application vetting of entitlements and Info.plist usage keys, MDM configuration state and network flow data.

Many legitimate apps, particularly banking apps, use commercial app shielding. See the Mobile App Shielding and RASP Buyers Guide. A packer name in a vetting report is therefore context, and the deciding question is whether the app comes from a known publisher through an approved channel.

Prevention and app vetting

Detection with MDM, MTD and forensics

• MDM: app inventory against an approved catalogue is the basic control. Flag apps from outside the catalogue that hold sensitive permissions such as accessibility, notification access or SMS.
• Android enterprise logs: on company-owned devices, SecurityLog TAG_APP_PROCESS_START records the SHA-256 of the base APK, which lets you match a running app to a vetting verdict, and network logging records DNS and connect events.
• Play Protect state: a Play Integrity playProtectVerdict of MEDIUM_RISK or HIGH_RISK means Play Protect found potentially harmful or dangerous apps; POSSIBLE_RISK means Play Protect is turned off.
• MTD: behavioural engines that observe runtime code loading and contacted hosts see through packing better than signature scanners.
• Network: hidden C2 addresses still have to be contacted. Per-app VPN or secure web gateway data catches new or rare destinations.
• Forensics: on iOS, where in-memory decryption leaves little fleet telemetry, use the Mobile Verification Toolkit against backups, filesystem dumps or sysdiagnose archives with current indicator sets. See the Mobile Forensics Guide.

How to implement

1. Inventory: export installed apps across the fleet and mark each as catalogue, store-but-unapproved or sideloaded.
2. Close side doors: block unknown sources on Android and restrict configuration profile installation on iOS, in report-only mode for two weeks to find business apps that depend on them.
3. Vet the gap: send non-catalogue apps with sensitive permissions to dynamic analysis. Record verdicts by package name, signing certificate and hash.
4. Collect telemetry: forward Android security and network logs on company-owned devices; enable MTD on high-risk groups first.
5. Enforce: remove or block apps that load code not present in their package or contact undeclared hosts. Rollback is moving the app to a monitored exception list while vetting completes.

Decision guidance

• Static or dynamic vetting: static scanning is cheap but blind to packed and encrypted payloads. Use dynamic analysis for anything outside your catalogue that asks for high-risk permissions.
• Block or allow obfuscated apps: do not block on obfuscation alone; you will block your own bank. Block on provenance plus behaviour.
• Small organisations: app source restriction and Play Protect enabled cover most commodity cases. Larger or targeted organisations add MTD and a forensic route.

Where identity fits

Malware encrypts its own credentials too: NGate's decrypted config held a shared token, and several families protect C2 keys. Your own apps face the reverse problem. Obfuscating an API key in an app binary does not protect it, because the key is still extractable at runtime. Keep secrets out of mobile binaries, use short-lived tokens and app attestation instead. See the Mobile App Attestation guide.

Detection and measurement

• Share of installed apps that are catalogue apps, per platform.
• Sideloaded apps on managed devices (target zero on company-owned).
• Devices with Play Protect off, from the Play Integrity verdict.
• Non-catalogue apps with sensitive permissions awaiting vetting, and median days to verdict.
• MTD detections of runtime code loading per thousand devices, with false positive rate.

Framework mapping

Common failure patterns

• Relying on hash-based detection: packing and per-sample encryption change the hash every build.
• Vetting the install, not the runtime: encrypted assets and later downloads only reveal themselves after launch.
• Blocking all obfuscated apps: creates exceptions that end up covering everything.
• Ignoring declared but unused permissions: manifest padding, as recorded for GodFather, hides the permissions that matter.
• Hiding your own secrets with obfuscation: keys in a binary are recoverable; see the iOS Apps Leaking Hard-Coded Secrets breach analysis.

Practitioner checklist

• Maintain an approved app catalogue and report drift.
• Block unknown sources and unmanaged profile installation.
• Keep Play Protect on and monitor the Play Protect verdict.
• Run dynamic analysis on non-catalogue apps with sensitive permissions.
• Correlate app hashes from SecurityLog with vetting verdicts.
• Monitor new and rare network destinations per app.
• Keep MVT indicator sets current for iOS investigations.
• Never rely on obfuscation to protect secrets in your own apps.

Standards and references

• MITRE ATT&CK: Obfuscated Files or Information (Mobile T1406)
• MITRE ATT&CK: Steganography (Mobile T1406.001)
• MITRE ATT&CK: Software Packing (Mobile T1406.002)
• OWASP: Mobile Application Security Verification Standard
• Apple: App Review Guidelines
• Google Play Console Help: Device and Network Abuse policy
• Google: Google Play Protect
• Android Developers: SecurityLog

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Mobile App Security Testing Guide · Android Banking Trojans Guide