T1426: System Information Discovery
Adversaries may attempt to get detailed information about a device’s operating system and hardware, including versions, patches, and architecture. Adversaries may use the information from System Information Discovery during automated discovery to shape follow-on behaviors, including whether or not to fully infects the target and/or attempts specific actions.
On Android, much of this information is programmatically accessible to applications through the `android.os.Build` class. [1] iOS is much more restrictive with what information is visible to applications. Typically, applications will only be able to query the device model and which version of iOS it is running.
Analyst context for executives and security teams
System Information Discovery on mobile devices matters because it helps a malicious app or implant decide what it is running on before taking next actions. On Android, device OS and hardware details are broadly available through android.os.Build; on iOS, applications are more restricted but can typically learn device model and iOS version. For leaders, this is less about the discovery call itself and more about whether the mobile security program can see untrusted apps profiling high-value devices, patch levels, and hardware before follow-on behavior.
Executive priority
Prioritize this as a mobile fleet visibility and readiness issue. The business question is whether security teams can prove which Android and iOS versions, models, and patch states exist across managed devices, and whether risky or unknown applications are allowed to run on sensitive users’ phones. This technique is associated in ATT&CK with multiple mobile malware families and campaigns, so it should inform mobile threat modeling, executive-device protection, incident triage, and audit evidence around mobile inventory and patch governance.
Technical view
Validate coverage across Android and iOS separately. For Android, review whether app analysis, mobile security tooling, or runtime telemetry can identify applications querying android.os.Build or collecting OS, hardware, version, patch, and architecture details, especially when paired with suspicious permissions, recent sideloading, or network transmission of device metadata. For iOS, expect less application-visible detail, but validate monitoring around device model and OS-version collection where telemetry exists. ATT&CK provides no official detection text for T1426, but a related detection strategy object, DET0601, exists; teams should map that strategy to local mobile telemetry before claiming coverage.
Likely telemetry
- MDM/EMM inventory for device model, OS version, patch level, and platform
- Mobile threat defense or mobile EDR events, if deployed
- Application vetting/static analysis results for Android use of android.os.Build and related device-fingerprinting logic
- Runtime app behavior telemetry where available
- Network telemetry showing apps transmitting device model, OS version, patch, architecture, or similar metadata
Detection direction
- Treat standalone system-information collection as low-fidelity because legitimate mobile apps often collect device model and OS version for compatibility, support, and analytics.
- Increase confidence by correlating discovery with suspicious app provenance, excessive permissions, obfuscation, unusual outbound communication, or other mobile ATT&CK behaviors.
- Separate Android and iOS logic: Android exposes more system details programmatically, while iOS restricts most app-visible system information to model and OS version.
- Use ATT&CK relationship context to prioritize tests against mobile malware behaviors that use this technique, but do not infer local exposure without matching telemetry.
- Account for the revoked Device Type Discovery technique T1419 being consolidated into T1426 when maintaining older detection content or reporting mappings.
Mitigation priorities
- Maintain accurate mobile asset inventory, including OS version, device model, and patch posture for Android and iOS fleets.
- Prioritize mobile OS and security patch governance, especially for users and functions where mobile compromise would affect business continuity or sensitive access.
- Reduce exposure to untrusted applications through managed app distribution, application vetting, and controls on sideloading where organizational policy and platform capability allow.
- Use mobile security monitoring for high-risk users and devices, with response playbooks for suspicious apps collecting and transmitting device metadata.
- Align incident response procedures so responders can quickly determine device model, OS version, installed applications, and management status during mobile investigations.
Analyst notes and limits
The relationship set is broad: campaigns, groups, and many mobile malware/software entries are linked as using this behavior, including Android and iOS examples. That makes T1426 useful for coverage validation and threat-informed mobile testing, but the behavior is common enough that detection must be correlation-driven. The Android-specific android.os.Build reference is a key technical anchor. iOS visibility should be scoped conservatively because the ATT&CK description states that iOS is more restrictive.
ATT&CK does not provide official detection guidance or tactics for this object in the supplied fields. The relationship data supports that the behavior is used by multiple mobile threats, but it does not establish current activity, customer exposure, or guaranteed detectability. Local conclusions require mobile management coverage, app inventory, device telemetry, and network evidence from the environment.
System Information Discovery
Adversaries may attempt to get detailed information about a device’s operating system and hardware, including versions, patches, and architecture. Adversaries may use the information from System Information Discovery during automated discovery to shape follow-on behaviors, including whether or not to fully infects the target and/or attempts specific actions.
On Android, much of this information is programmatically accessible to applications through the `android.os.Build` class. [1] iOS is much more restrictive with what information is visible to applications. Typically, applications will only be able to query the device model and which version of iOS it is running.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1419 | Device Type Discovery | Device Type Discovery revoked by this object. |
Groups, software, and campaigns
G0112: Windshift
S0318: XLoader for Android
XLoader for Android is a malicious Android app first observed targeting Japan, Korea, China, Taiwan, and Hong Kong in 2018. It has more recently been observed targeting South Korean users as a pornography application.[1][2] It is tracked separately from the XLoader for iOS.
S0288: KeyRaider
S1083: Chameleon
Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]
S0535: Golden Cup
Golden Cup is Android spyware that has been used to target World Cup fans.[1]
S0463: INSOMNIA
S0555: CHEMISTGAMES
CHEMISTGAMES is a modular backdoor that has been deployed by Sandworm Team.[1]
S0525: Android/AdDisplay.Ashas
Android/AdDisplay.Ashas is a variant of adware that has been distributed through multiple apps in the Google Play Store. [1]
S9005: DocSwap
DocSwap is an Android malware first identified in 2025, and attributed to Kimsuky. DocSwap’s name is a combination of its Korean name “문서열람 인증 앱” (Document Viewing Authentication App) and a phishing page masquerading as CoinSwap at the C2 address. Based on DocSwap’s name and Korean-language strings, DocSwap potentially targets mobile device users in South Korea. Several variants of DocSwap exist; one of the latest samples indicates that the adversary added a native decryption function that decrypts an internal APK.[1][2]
S0418: ViceLeaker
ViceLeaker is a spyware framework, capable of extensive surveillance and data exfiltration operations, primarily targeting devices belonging to Israeli citizens.[1][2]
S0490: XLoader for iOS
XLoader for iOS is a malicious iOS application that is capable of gathering system information.[1] It is tracked separately from the XLoader for Android.
S0540: Asacub
S1056: TianySpy
C0033: C0033
C0033 was a PROMETHIUM campaign during which they used StrongPity to target Android users. C0033 was the first publicly documented mobile campaign for PROMETHIUM, who previously used Windows-based techniques.[1]
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | aae030f3c199… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Android-Build
Android. (n.d.). Build. Retrieved December 21, 2016.
Open source URL -
[2]
NIST Mobile Threat Catalogue APP-12Open source URL
-
[3]
mitre-attack T1426Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.