Mobile T1426 System Information Discovery: Detecting Device Fingerprinting by Mobile Malware

Before a mobile implant decides whether to fully infect a phone, it reads the model, manufacturer, OS version and patch level, because those values tell it which exploits will work and whether the target is worth the risk. MITRE ATT&CK for Mobile tracks this as T1426 System Information Discovery, a Discovery (TA0032) technique on Android and iOS. Unlike most discovery techniques, much of the data is legitimately available: ATT&CK notes that on Android it is programmatically accessible through the android.os.Build class, while iOS typically lets apps query only the device model and iOS version. Analytics and anti-fraud SDKs read the same fields every day, so the work is separating ordinary fingerprinting from the reconnaissance step of an intrusion. This guide is for mobile security engineers, app vetting teams and SOC analysts. It extends our MITRE ATT&CK for Mobile Guide; the host version is T1082 System Information Discovery.

Key takeaways

• You cannot block it, so make the answer boring. ATT&CK v20 maps no mitigation to T1426; the practical defence is a fleet on current OS and patch levels, so a version check gives the attacker nothing to exploit.
• The platforms differ sharply. Android exposes build details through android.os.Build; iOS typically exposes only model and version to apps, and ATT&CK's richer iOS cases are implants with elevated access.
• Volume and timing are the signal. ATT&CK's DET0601 looks for an app outside an allow-list reading many Build fields in a short window at launch or in the background.
• Hardware identifiers are already locked down. Android restricts IMEI and serial number to privileged callers from Android 10 and MAC addresses to system apps from Android 6.0.
• Discovery precedes the real damage. The same families that fingerprint the device go on to collect messages, location and credentials; respond to the device, not just the alert.

What the technique covers

ATT&CK v20 describes adversaries getting detailed information about a device's operating system and hardware, including versions, patches and architecture, to shape follow-on behaviour, including whether to fully infect the target. There are no sub-techniques. The closely related questions of network identifiers, running apps and sandbox detection have their own ATT&CK entries: T1422 System Network Configuration Discovery, T1424 Process Discovery and T1633 Virtualization/Sandbox Evasion.

How adversaries use it: real cases

ATT&CK v20 records more than 50 software, group and campaign entries for T1426. A selection shows the range.

• iOS exploit-chain implants: ATT&CK records INSOMNIA (S0463) collecting device name, serial number, iOS version and disk space, citing Google Project Zero's implant teardown, and Operation Triangulation (C0054) collecting device and user information, citing Kaspersky. Pegasus for iOS (S0289) monitors device status, citing Lookout. LightSpy (S1185) collects phone number, IMEI, CPU, screen and memory details.
• Android surveillanceware from state-linked groups: ATT&CK records Hornbill (S1077) and Sunbird (S1082) collecting device ID, model, manufacturer and Android version, citing Lookout; Windshift (G0112) including system information enumeration in apps from Operation BULL and Operation ROCK, citing BlackBerry; and PROMETHIUM (G0056) using StrongPity during campaign C0033 to collect device information, citing ESET. BOULDSPY (S1079) collects Android version and device identifiers.
• Banking trojans: GodFather (S1231) gathers device data such as battery level, sound settings and brightness alongside remote control capability. See the Android Banking Trojans Guide.

The Commercial Spyware Guide puts the iOS cases in context.

What to detect and where

Android network logging limits: Android's documentation says network logging is available to the device owner from Android 8.0 and to a work profile's profile owner from Android 12 (work profile traffic only), does not record UDP, can be bypassed by apps that connect directly, and deletes batches that are not retrieved. Collect it promptly and pair it with VPN gateway logs.

Making the answer useless

1. Enforce current OS and patch levels. If every managed device is current, version fingerprinting points to no known exploit. On Android Enterprise, set minimumApiLevel in policy; Google's API reports OS_NOT_PERMITTED for devices below it. Apply the equivalent MDM compliance rule on iOS.
2. Control app sources. Keep Google Play Protect on (daily scans, install-time checks for apps from outside Google Play, automatic removal of the most harmful apps) and block unknown sources on managed devices. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.
3. Protect high-risk users from exploit chains. Every iOS case above began with an exploit. Apple documents Lockdown Mode on iOS 16 or later, blocking most message attachment types, complex web technologies and configuration profile installation. See the Apple Lockdown Mode Guide and Android Advanced Protection.
4. Collect less in your own apps. Android's guidance is to avoid hardware identifiers and use resettable or app-scoped identifiers instead. An app that does not collect device fingerprints cannot leak them through a compromised SDK.

Where identity fits

Device fingerprints are widely used as identity signals in fraud and session risk scoring. That is reasonable as one input, but a fingerprint built from model, version and build values is readable by any Android app and can be replayed. Do not let it stand in for device authentication. Bind sessions and API tokens to platform attestation and hardware-backed keys instead. See the Mobile App Attestation Guide and the Mobile Access Credentials Guide.

Measuring whether it works

• Patch currency: percentage of managed devices on a security patch level within your target window.
• Unknown apps: number of managed devices carrying apps outside the approved catalogue; trend to zero.
• Vetting depth: percentage of approved apps with dynamic analysis covering device information reads and first network contact.
• Allow-list hygiene: SDKs on the fingerprinting allow-list reviewed in the last 12 months.

Common failure patterns

• Alerting on every device information read: without an SDK allow-list the signal drowns in analytics libraries and gets switched off.
• Using device fingerprints as authentication: treating a matching model and build as a trusted device.
• Allowing a long tail of old builds: exceptions for executives' older phones leave exactly the versions an implant is checking for.
• Ignoring iOS because apps see little: the iOS cases come from exploit chains, which is an argument for updates and Lockdown Mode, not for less monitoring.

Framework mapping

Practitioner checklist

• Set minimum OS and patch levels in EMM policy and block access below them.
• Block unknown app sources and keep Play Protect enabled on managed Android.
• Build an allow-list of analytics and anti-fraud SDKs that read device information, keyed by package and signer.
• Add burst reads of device information and first-contact network traffic to app vetting reports.
• Collect Android Enterprise network logs or per-app VPN flow data and alert on unknown packages beaconing.
• Offer Lockdown Mode and Android Advanced Protection to high-risk staff.
• Remove device fingerprints as a standalone trust signal in your own authentication flows.

Standards and references

• MITRE ATT&CK: T1426 System Information Discovery (Mobile)
• Android Developers: Best practices for unique identifiers
• Android Developers: Network activity logging
• Google: Android Management API policies reference
• Google: Google Play Protect client protections
• Apple: About Lockdown Mode
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · T1082 System Information Discovery · Mobile Device Management Security Guide · Mobile Threat Defense Buyer's Guide