DET0600: Detection of Software Discovery
DET0600 is a mobile ATT&CK detection strategy for Software Discovery: attempts to list applications installed on Android or iOS devices. For leaders, the b...
Analyst context for executives and security teams
DET0600 is a mobile ATT&CK detection strategy for Software Discovery: attempts to list applications installed on Android or iOS devices. For leaders, the business significance is not the app list itself; it is that this discovery can help an adversary decide what to do next, such as identifying security tools or selecting follow-on actions. This makes mobile visibility, managed device controls, and incident triage evidence important for resilience.
Executive priority
Prioritize this as a validation question for mobile security governance: can the organization tell when apps or processes are enumerating installed software on managed Android and iOS devices, and can responders use that evidence during an investigation? The object has no official detection text, so the executive decision is to confirm whether mobile telemetry, MDM/UEM policy, and incident response playbooks actually support this behavior rather than assuming ATT&CK coverage exists.
Technical view
This detection strategy detects T1418 Software Discovery in the mobile domain. SOC and IR teams should validate whether Android and iOS telemetry can show attempts to obtain installed-application listings, especially when performed by apps, services, or profiles that do not have an expected business reason. Because the official detection field is not provided, teams should build local logic around available mobile management, mobile threat defense, endpoint, and device inventory evidence, and then test it against known benign administrative and security tooling to reduce false positives.
Likely telemetry
- Managed mobile device inventory and installed-application records
- Mobile security or mobile EDR/MTD alerts related to application enumeration, where deployed
- Android and iOS device management logs that show application inventory collection or permission-relevant activity, where available
- Application installation, removal, and inventory-change history from MDM/UEM systems
- Incident response device acquisition or triage artifacts that can confirm which apps were present and which software queried them
Detection direction
- Validate whether telemetry exists for Android and iOS devices, since the related technique lists those platforms while the detection-strategy object itself does not specify platforms.
- Look for unusual or unnecessary attempts to obtain installed-application listings, especially by non-administrative or unexpected applications.
- Tune carefully for expected MDM/UEM, security, compliance, and support tooling, which may legitimately collect software inventory.
- Correlate software discovery signals with preceding installation events and follow-on suspicious mobile activity rather than treating enumeration alone as proof of compromise.
- Document blind spots for unmanaged devices, BYOD devices, privacy-restricted telemetry, and platforms where OS controls limit visibility.
Mitigation priorities
- Start with asset and device management: know which Android and iOS devices are managed and what app-inventory telemetry is collected.
- Restrict mobile app permissions and management profiles according to least privilege where policy and platform controls allow.
- Use approved app stores, application allow/deny policies, and mobile device compliance rules to reduce untrusted apps that could perform discovery.
- Ensure incident response procedures preserve mobile inventory and relevant management logs before devices are wiped or retired.
- Use the gap analysis as compliance evidence: show where mobile software discovery is monitored, where it is not technically available, and what compensating controls exist.
Analyst notes and limits
ATT&CK provides the detection-strategy identifier DET0600 and its relationship to T1418 Software Discovery. The related technique describes adversaries attempting to list installed applications and using that information to shape later behavior, including identifying security measures or deciding follow-on actions. No official description, detection logic, tactics, or platforms are specified on the detection-strategy object itself; platform context comes from the related T1418 technique, which lists Android and iOS.
This take is constrained by sparse official fields. It does not assert active exploitation, attribution, impact, or guaranteed detectability. Local mobile OS version, management model, privacy controls, MDM/UEM configuration, and security tooling determine whether the suggested telemetry is available and usable.
Detection of Software 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 | T1418 | Software Discovery | This object detects Software 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 | 1663697ccf21… |
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 DET0600Open 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.