DET0601: Detection of System Information Discovery
DET0601 is a mobile ATT&CK detection strategy for identifying System Information Discovery, where an app or adversary activity attempts to learn a device’s...
Analyst context for executives and security teams
DET0601 is a mobile ATT&CK detection strategy for identifying System Information Discovery, where an app or adversary activity attempts to learn a device’s operating system, hardware, version, patch, or architecture details. For leaders, the value is not just catching “device lookup” activity; it is understanding whether mobile telemetry can reveal early reconnaissance that may shape later actions against Android or iOS devices.
Executive priority
Prioritize this as a mobile security visibility and readiness question: can the organization prove which apps or activities are collecting sensitive device characteristics, and can the SOC distinguish normal compatibility checks from suspicious discovery? This supports mobile risk governance, incident triage, BYOD or managed-device policy decisions, and audit evidence around monitoring coverage. Because the ATT&CK object provides no official detection logic, investment should focus on validating telemetry and response workflow before assuming coverage.
Technical view
The supplied relationship states that this detection strategy detects T1426 System Information Discovery in the mobile domain, with related platforms Android and iOS. SOC and detection teams should validate whether available mobile telemetry can show applications or processes querying OS, hardware, version, patch, and architecture information, then correlate that behavior with app install time, first execution, unusual app behavior, or other discovery activity. Since no official detection field is provided for DET0601, detections should be locally engineered and tested against known-benign mobile apps that legitimately collect device metadata.
Likely telemetry
- Mobile device management or mobile endpoint inventory records showing OS version, patch level, model, and architecture
- Mobile threat defense, EDR, or app behavior telemetry that records app-level access to device/system properties
- Application logs or backend service logs that receive device metadata from mobile clients
- Mobile OS audit or diagnostic logs where available for Android or iOS environments
- App installation, update, signing, and permission context to help distinguish expected from unexpected collection
Detection direction
- Confirm that telemetry exists for Android and iOS separately; visibility and logging depth may differ by platform, management model, and app sandbox constraints.
- Baseline legitimate device-information collection by enterprise apps, security agents, support tools, and compatibility checks to reduce false positives.
- Tune for suspicious context rather than single events alone, such as unexpected apps collecting detailed system information, collection soon after installation, or collection combined with other discovery behaviors.
- Validate whether logs preserve the requesting app identity, timestamp, device identifier, OS/hardware fields accessed, and any network destination receiving that metadata.
- Use the relationship to T1426 as the analytic anchor; do not assume DET0601 provides a complete detection rule because the official detection text is not supplied.
Mitigation priorities
- Start with mobile asset and app inventory so responders know which Android and iOS devices and apps are expected to collect system details.
- Apply mobile app governance: approve trusted apps, review app behavior during onboarding, and investigate unexpected device-fingerprinting behavior.
- Ensure managed mobile devices have sufficient security telemetry, retention, and SOC access for incident review.
- Document acceptable device metadata collection for compliance and privacy review, especially where apps transmit OS, hardware, or patch information to external services.
- Prepare IR playbooks to triage suspicious mobile discovery by app, device, user, collection scope, and any related follow-on activity.
Analyst notes and limits
This take is based on the DET0601 detection strategy metadata and its relationship to T1426 System Information Discovery. The strongest supported analytic point is that adversaries may use OS and hardware details to shape follow-on behavior. Local validation is required to determine what is observable in a specific mobile fleet.
The ATT&CK object has no official description, no official detection text, no tactics, and no platforms directly specified for DET0601. Android and iOS are supported only through the related T1426 technique. No active exploitation, actor attribution, impact, or guaranteed detection coverage is implied.
Detection of System Information Discovery
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1426 | System Information Discovery | This object detects System Information Discovery. |
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.0 | Current bundle | 7c9eeee9a9ff… |
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]
mitre-attack DET0601Open 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.