Mobile T1575 Native API: Detecting Native Code Abuse in Android Apps

Android malware moves its most sensitive logic into native C and C++ libraries because compiled machine code is much harder to analyse than the Java or Kotlin bytecode that most app vetting tools read well. MITRE ATT&CK for Mobile records this as T1575 Native API, a technique under both Defense Evasion and Execution. This guide explains what the technique covers, what ATT&CK's procedure examples show, which Android and iOS platform controls bear on it, and how to detect and contain it with app vetting, Android Enterprise policy and mobile threat defence (MTD) data. It is written for mobile security engineers, app vetting teams and SOC analysts who already know the basics in the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Native code is normal, so presence is not the signal. Many legitimate apps ship NDK libraries; the signal is an unapproved native library loading just before sensitive activity such as sensor access, file writes or network connections.
• ATT&CK lists Android only. T1575 in ATT&CK v20 Mobile is an Android technique; on iOS all app code is compiled native code and Apple requires every executable to be signed, so the evasion gap looks different.
• Detection happens mostly before deployment. The ATT&CK detection strategy relies on application vetting, dynamic analysis and EMM package inventory rather than a live device event feed.
• Prevention is about where apps come from. Blocking untrusted app installs and enforcing Google Play Protect verification on managed devices removes most of the delivery routes native-code malware relies on.
• Native code does not hide secrets. Moving API keys or tokens into a compiled library slows an analyst down but does not protect them; credentials shipped in an app should be treated as public.

What T1575 Native API covers

ATT&CK describes T1575 as adversaries using Android's Native Development Kit (NDK) to write native functions that execute binaries or functions at a lower level than normal Android SDK calls. The NDK compiles C or C++ directly to machine code, and the Java Native Interface (JNI) lets Java code in the app call functions in a native library. ATT&CK notes that adversaries may choose native functions because native actions are typically much more difficult to analyse than standard, non-native behaviour.

Android's NDK documentation describes the mechanics: the NDK builds shared libraries (.so files), the build packages them into the APK alongside the .dex files, and the NDK supports 32-bit ARM, AArch64, x86 and x86-64 ABIs. An app can even be written as a fully native activity using the NativeActivity helper class with android:hasCode="false" in the manifest. None of this is malicious in itself: games, media codecs, cryptography libraries and app shielding products all use it.

What the procedure examples show

ATT&CK's procedure examples fall into three patterns. They are summarised here as ATT&CK states them; the cited vendor reports carry the detail.

ATT&CK also lists API-level behaviour under this technique, for example Chameleon using the KeyguardManager and AlarmManager APIs and GodFather hooking getEnabledAccessibilityServiceList to hide active services. One example, the Operation Triangulation campaign's use of the Audio Queue API to record audio, is an iOS campaign, even though the technique's platform field lists Android only. Read these entries as "abuse of lower-level platform APIs" rather than strictly NDK use. For how these families spread and what they steal, see the Mobile Malware Guide and the Android Banking Trojans Guide.

Android and iOS: how the platforms differ

Android: Native libraries run inside the app's sandbox with the app's own permissions, so native code does not grant extra privilege by itself; its value to an attacker is concealment. Android 7.0 tightened what native code can reach: apps can no longer dynamically link against non-NDK platform libraries, and loading a private platform library returns an error from System.loadLibrary or dlopen. Native code should use only the public NDK APIs.

iOS: ATT&CK does not list iOS for T1575, and the Android framing does not transfer directly. Every iOS app is compiled native code. Apple's platform security guide states that iOS requires all executable code to be signed with an Apple-issued certificate, that third-party apps must be validated and signed, and that the system validates the code signature of all dynamic libraries a process links against at launch. App Review Guideline 2.5.1 limits apps to public APIs, and Guideline 2.5.2 says apps may not download, install or execute code which introduces or changes features or functionality; both are marked as applying to notarisation for alternative distribution too. On iOS, the defender's questions are therefore about signing, distribution channel and private API use, not about native versus managed code.

Detection and vetting

ATT&CK's detection strategy DET0717 is explicit that Android detection of Native API comes from management, network or vetting evidence, and that state queries are periodic observations rather than real-time events. Its analytic draws on four sources.

• Static triage: list every lib/<abi>/*.so in the APK, record hashes per version, and flag libraries with high entropy, packed sections or names that do not match a known SDK. A native library that appears in a minor update deserves a closer look.
• Dynamic analysis: run the app in an instrumented environment and record library loads, JNI registrations and the first network, file and sensor events after each load. Payloads decrypted at runtime only show up here.
• Device-side signals: MTD agents and Google Play Protect scan installed apps; Play Protect checks apps at install and periodically, can send outside apps for a code-level evaluation, and can disable or remove harmful apps. Feed MTD verdicts into the SOC with the device and user identity attached.
• Forensics: where compromise is suspected on a specific device, preserve it and acquire app containers; see the Mobile Forensics Guide and the Mobile Verification Toolkit (MVT).

Prevention controls on managed devices

Because T1575 is about evading analysis, prevention is mostly about stopping unvetted apps from arriving at all. On Android Enterprise devices managed through the Android Management API, these advancedSecurityOverrides settings are the main levers:

Check that no policy overrides these defaults for convenience. On iOS, supervised devices and App Store or managed distribution keep apps inside Apple's signing and review model; for highly targeted users, Lockdown Mode (iOS 16 or later) reduces attack surface further, though it also prevents new MDM enrolment, so enrol first. See the Android Enterprise Security Guide, the iOS and iPadOS Enterprise Security Guide and APK sideloading.

Where identity fits

Developers sometimes move API keys, signing secrets or backend tokens into a native library on the assumption that compiled code keeps them safe. It does not: native code raises the cost of analysis but any value the app can read at runtime can be extracted. The Mobile Apps Hard-Coded AWS Keys 2022 research found AWS credentials embedded in 1,859 apps, many spread through shared SDKs. Issue short-lived, narrowly scoped tokens from a backend instead, and use attestation to bind them to a genuine app instance; see Mobile App Attestation. OWASP MASVS makes the same point in its MASVS-RESILIENCE category: anti-tampering and obfuscation must not substitute for sound security architecture.

Implementation steps

1. Confirm policy baselines: export current Android Enterprise policies and verify the three settings above on every policy, including kiosk and test policies.
2. Build an approved native library list: for each managed or in-house app, record the expected .so files and hashes per version. This becomes the $ApprovedNativeLibraries$ baseline the ATT&CK analytic refers to.
3. Add dynamic analysis to app vetting: require an instrumented run for any new app or any update that adds or changes a native library; pilot on a small app set first to tune noise from common SDKs.
4. Route MTD and Play Protect verdicts: send them to the SOC with device, user and package identifiers, and define a containment action (block corporate access via conditional access, then remove the app).
5. Review exceptions: any group allowed untrusted installs or developer settings should have a named owner and an expiry date. Roll back by reapplying the baseline policy.

Measuring it

• Policy coverage: percentage of managed Android devices on a policy with DISALLOW_INSTALL and VERIFY_APPS_ENFORCED (target 100% outside documented exceptions).
• Vetting depth: percentage of approved apps with native libraries that have had a dynamic analysis run on their current version.
• Baseline drift: number of app updates that introduced a new native library, and how many were reviewed before rollout.
• Response time: median time from an MTD or Play Protect harmful app verdict to removal or access block.

Common failure patterns

• Static-only vetting: scanning DEX bytecode and manifests but never executing the app, so payloads decrypted by native code are never seen.
• Treating native code as suspicious in itself: alerting on every .so creates noise from legitimate SDKs until the alert is ignored; alert on unapproved libraries and the activity that follows them.
• Silent policy exceptions: developer, QA or executive groups left with unknown sources or developer settings enabled long after the reason has passed.
• Secrets in native libraries: relying on compilation to protect long-lived keys, as described above.
• Ignoring the iOS equivalent: assuming iOS is out of scope because ATT&CK lists Android only, while allowing enterprise-signed or developer-signed apps outside managed distribution.

Framework mapping

Practitioner checklist

• Verify untrustedAppsPolicy, googlePlayProtectVerifyApps and developerSettings on every Android Enterprise policy.
• Keep an approved native library list with hashes for every managed and in-house app version.
• Require dynamic analysis for new apps and for updates that add or change native libraries.
• Correlate library loads with the sensor, file and network activity that follows, not library presence alone.
• Send MTD and Play Protect verdicts to the SOC with device and user identity, and define the containment action.
• Keep iOS apps inside App Store, managed or notarised distribution and review any enterprise-signed apps.
• Remove long-lived secrets from app binaries, native or not, and issue scoped tokens from a backend.
• Review policy exceptions quarterly with named owners and expiry dates.

Standards and references

• MITRE ATT&CK: Native API, Mobile technique T1575
• Android Developers: NDK concepts
• Android Developers: Android 7.0 behaviour changes (NDK apps linking to platform libraries)
• Apple Platform Security: App code signing process
• Apple Developer: App Review Guidelines
• Google: Android Management API policy reference
• Google: Use Google Play Protect to help keep your apps safe
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Mobile App Security Testing Guide · Mobile Threat Defense Buyer's Guide