Almost all mobile traffic is encrypted, so malware that adds its own encryption or pins its own certificates looks, on the wire, much like every banking app on the device. MITRE ATT&CK for Mobile tracks this as T1521 Encrypted Channel, a Command and Control technique listed for both Android and iOS, with three sub-techniques: Symmetric Cryptography, Asymmetric Cryptography and SSL Pinning. This guide explains each sub-technique, what real Android and iOS implants have done, why network inspection alone rarely finds it, and which device, app-vetting and network signals do. It is for mobile security engineers, network and SOC teams, and MDM administrators. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Both platforms are in scope. ATT&CK v20 lists T1521 and all three sub-techniques for Android and iOS; Operation Triangulation is an iOS example, SharkBot and FluBot are Android examples.
- Encryption is not the anomaly. TLS is normal; the signals are who the app talks to, when it talks, and whether it encrypts data itself before sending.
- Pinning cuts both ways. SSL pinning protects your own apps from interception and also stops your TLS inspection seeing malware traffic.
- Hardcoded keys are the weak point. ATT&CK notes these implementations can be reversed when keys sit in the sample or its configuration, which is how analysts recover C2 content.
- Prevention happens earlier. ATT&CK lists mitigations only for the pinning sub-technique (user guidance and enterprise policy on certificates); otherwise, stop the app reaching the device and detect it by behaviour.
What T1521 covers
ATT&CK defines Encrypted Channel as explicitly using a known encryption algorithm to conceal command and control traffic, rather than relying only on the protection a protocol provides. It notes that these implementations may be reversible if the keys are encoded or generated in the malware sample or configuration.
| Sub-technique | ATT&CK description | Platforms | Procedure examples in ATT&CK v20 |
|---|---|---|---|
| T1521.001 Symmetric Cryptography | Same key for encryption and decryption; ATT&CK names AES, Blowfish and RC4 as common algorithms | Android, iOS | EventBot (RC4 and Curve25519), SharkBot (RC4), Rotexy (AES), TriangleDB (3DES), Windshift (AES in CBC mode), C0033 StrongPity (AES), Operation Triangulation (3DES and AES) |
| T1521.002 Asymmetric Cryptography | Public and private keypairs; ATT&CK classifies SSL/TLS here because it uses asymmetric cryptography to establish keys | Android, iOS | FluBot (RSA-encrypted message bodies), SharkBot (RSA to protect the symmetric key), TriangleDB and Operation Triangulation (RSA), eSurv (public key encryption), CHEMISTGAMES and SilkBean (HTTPS), CarbonSteal (rudimentary certificate validation) |
| T1521.003 SSL Pinning | Client accepts only a pre-defined certificate or public key, protecting C2 traffic from interception and analysis | Android, iOS | eSurv's Android version used certificate pinning for C2 |
The parent technique also lists AhRat (HTTPS to its C2) and Twitoor (encrypted C2). Because ATT&CK puts ordinary TLS under T1521.002, a large share of mobile malware technically matches this technique. The defensive value is in the less common patterns: custom encryption inside TLS, pinning to attacker infrastructure, and encrypted blobs staged before upload.
Android and iOS: what differs
| Area | Android | iOS |
|---|---|---|
| Legitimate pinning mechanism | Network Security Configuration <pin-set> with SHA-256 digests of the certificate's SubjectPublicKeyInfo, optional expiration, and a recommended backup pin | App Transport Security NSPinnedDomains with NSPinnedCAIdentities or NSPinnedLeafIdentities using SPKI-SHA256-BASE64 values |
| Effect on enterprise TLS inspection | Inspection with a user or MDM-installed CA does not see most modern app traffic unless the app opts in | Pinned apps refuse intercepted connections |
| ATT&CK detection data | Package inventory, permission state, app-vetting runtime traces of crypto APIs, high-entropy staged files | Apple MDM InstalledApplicationList or ManagedApplicationList, code-signing entitlements and Info.plist review, proxy metadata |
| Hardening for targeted users | Android Advanced Protection | Lockdown Mode (iOS 16 and later), which Apple describes as protection for people who may be targeted by mercenary spyware |
Three Android platform facts help defenders. Apps targeting Android 7.0 (API 24) or higher do not trust user-added CAs unless they opt in with <certificates src="user"/>. Android disables cleartext traffic by default for apps targeting Android 9 (API 28) and later, so plain HTTP from an app is now itself unusual. Android 16 adds opt-in Certificate Transparency checking in the Network Security Configuration, on by default from Android 17, which raises the bar for C2 using misissued certificates in apps that rely on the system trust store.
Real cases
- Operation Triangulation (iOS): ATT&CK records the operators encrypting C2 communication and data with 3DES, AES and RSA, and its TriangleDB implant using 3DES and RSA. This is the clearest iOS illustration of the technique, and the reason Lockdown Mode and fast iOS updates matter for high-risk users. See the Commercial Spyware Guide for the wider context.
- SharkBot (Android): encrypted C2 payloads with RC4 and used RSA to encrypt the symmetric key, a hybrid scheme that hides commands even from analysts who can decrypt TLS.
- FluBot (Android): encrypted C2 message bodies with RSA and base64-encoded them.
- eSurv (Android): used both public key encryption and certificate pinning for C2, so interception with a trusted proxy certificate fails.
Detection
ATT&CK publishes a detection strategy for the parent and each sub-technique. Read together, they point to four evidence sources:
| Evidence source | What to look for | Sub-techniques |
|---|---|---|
| App vetting with dynamic analysis | Calls to javax.crypto.Cipher, Android KeyStore or RSA/ECC operations on collected data, followed by encode-then-transmit that does not match the app's declared function; custom TLS trust evaluation such as a custom TrustManager or OkHttp CertificatePinner in apps not expected to pin | .001, .002, .003 |
| Forensic or filesystem artefacts | High-entropy blobs written to a staging path immediately before outbound transmission | Parent, .001, .002 |
| Mobile EDR or MTD telemetry | Repeated symmetric encryption with reused or locally derived keys while the app is in the background or the device is locked | .001 |
| MDM inventory and network proxy | Unapproved apps (Android EMM inventory, Apple MDM application lists) combined with proxy or DNS metadata showing connections to destinations outside the app's normal set | .003 and all |
On the network side, destination reputation, newly seen domains, beacon timing and traffic while the device is idle are more useful than payload inspection. Where you run TLS inspection for managed devices, treat connection failures from an unknown app to a single destination as a possible pinning signal rather than noise. See the TLS Inspection Guide for the trade-offs.
Metrics:
- Percentage of managed devices sending DNS through a monitored resolver or secure web gateway.
- Count of managed apps contacting newly registered or uncategorised domains, per week.
- Share of unknown apps that pass through dynamic analysis before approval.
- Number of high-risk users on Lockdown Mode or Android Advanced Protection.
- Median iOS and Android patch latency for managed devices.
Prevention and response
ATT&CK lists mitigations only for T1521.003: M1011 User Guidance (do not trust or install self-signed certificates) and M1012 Enterprise Policy (prevent users adding certificates and apps installing their own). In the Android Management API, credentialsConfigDisabled stops users configuring credentials. Beyond that, prevention means keeping the implant off the device:
- App sources: block unknown sources on Android and enforce Play Protect verification; on iOS, restrict app installation through MDM to approved apps. See the Mobile Device Management Security Guide.
- Patching: enforce minimum OS versions in compliance policy; Apple advises updating to the latest software for the full Lockdown Mode protections.
- Targeted users: enable Lockdown Mode or Android Advanced Protection.
- Response: when C2 is suspected, isolate the device from corporate resources, revoke sessions and tokens, capture network and MDM evidence, and use the Mobile Verification Toolkit (MVT) for consensual forensic checks on Android and iOS. Follow the Mobile Spyware Infection Response Playbook.
Where identity fits
Your own apps use the same cryptography for the opposite purpose. Pin your API endpoints with backup pins and a recovery plan, as both Android and Apple guidance advise, so attacker-in-the-middle tools cannot read tokens in transit. Never embed long-lived API keys or symmetric keys in the app: ATT&CK's point about recoverable keys in malware applies equally to legitimate apps. See Secrets in mobile apps and Certificate Pinning.
Framework mapping
| Framework | Reference | Relevance to T1521 |
|---|---|---|
| ATT&CK Mobile mitigations | M1011; M1012 (for T1521.003) | Certificate trust guidance and policy |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring and SI-4(4) Inbound and Outbound Communications Traffic; SC-7 Boundary Protection; AC-19 Access Control for Mobile Devices; SC-8 Transmission Confidentiality and Integrity | Monitoring outbound traffic, boundary controls, device policy; SC-8 for protecting your own app traffic |
| NIST CSF 2.0 | DE.CM-01; DE.CM-09 | Network monitoring; device and runtime monitoring |
| OWASP MASVS | MASVS-NETWORK | Secure channels and pinning in your own apps |
Common failure patterns
- Expecting TLS inspection to see mobile C2: modern apps ignore user-added CAs by default and pinned implants refuse interception.
- Treating encryption as the alert: almost everything is encrypted; alert on destination, timing and app identity instead.
- No DNS visibility on mobile: devices that bypass the monitored resolver on cellular data leave no network trail.
- Letting users install certificates: the T1521.003 mitigation is a policy that many fleets never set.
- Pinning without a backup: your own app pins a single leaf key and breaks on rotation, pushing teams to switch pinning off.
Practitioner checklist
- Route managed device DNS through a monitored resolver or secure web gateway, including on cellular.
- Block user certificate installation through MDM policy.
- Restrict app sources on Android and iOS and require dynamic analysis for unknown apps.
- Enforce minimum OS versions and short patch windows.
- Enable Lockdown Mode or Android Advanced Protection for high-risk users.
- Alert on unapproved apps contacting new or uncategorised destinations while the device is idle.
- Pin your own API endpoints with backup pins, and keep keys out of app binaries.
Standards and references
- MITRE ATT&CK: Encrypted Channel (Mobile T1521)
- MITRE ATT&CK: SSL Pinning (Mobile T1521.003)
- Android Developers: Network security configuration
- Apple Developer: Identity Pinning in Info.plist
- Apple: About Lockdown Mode
- Google: Android Management API policies reference
- OWASP: Mobile Application Security Verification Standard
- Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Certificate Pinning · TLS Inspection Guide · Mobile Threat Defense Buyer's Guide