DET0640: Detection of Hide Artifacts
DET0640 is a mobile ATT&CK detection strategy for identifying attempts to hide artifacts, tied to the Android technique Hide Artifacts (T1628). The busines...
Analyst context for executives and security teams
DET0640 is a mobile ATT&CK detection strategy for identifying attempts to hide artifacts, tied to the Android technique Hide Artifacts (T1628). The business issue is visibility: if an app can hide user-facing indicators such as its launcher icon, users, help desks, and mobile security workflows may miss signs that an unwanted or malicious app is present. For leaders, this matters less as a standalone alert and more as a validation question: can the organization still inventory, investigate, and respond to mobile apps that are intentionally less visible to users?
Executive priority
Prioritize this where Android devices are used for sensitive business processes, regulated data access, privileged communications, or operational workflows. The key decision value is confirming that mobile device management, mobile threat defense, SOC procedures, and incident response playbooks do not depend only on what users can see in the app drawer. This detection strategy should support compliance evidence for asset/application visibility and incident readiness, but the supplied ATT&CK object does not provide specific detection logic or coverage claims.
Technical view
The official detection strategy object has no description, detection text, tactics, or platform field of its own. Its relationship context says it detects T1628 Hide Artifacts in the mobile domain, with Android as the related technique platform. SOC and mobile security teams should therefore validate visibility into installed Android applications and application metadata even when user-facing artifacts are hidden. Detection engineering should focus on comparing authoritative app inventory and device management records against user-visible app presence, launcher component state, and security tooling observations, while treating legitimate apps that hide icons for usability reasons as expected false-positive candidates.
Likely telemetry
- Android application inventory from managed devices
- Mobile device management or enterprise mobility management app inventory records
- Mobile threat defense findings and app reputation/context where deployed
- Application metadata and package/component state relevant to user-visible launcher presence
- Device compliance and configuration posture records
Detection direction
- Validate that mobile inventory does not rely solely on launcher icons or user-visible app lists.
- Correlate hidden or non-user-visible app artifacts with authoritative installed-package inventory and business-approved application baselines.
- Tune for legitimate applications that hide icons because they have no usable interface or to reduce application drawer clutter, as noted in the related ATT&CK technique context.
- Prioritize review when hidden artifacts appear on devices with sensitive access, unusual app provenance, policy violations, or other suspicious mobile security events.
- Document gaps caused by unmanaged devices, limited mobile telemetry, privacy constraints, or platforms outside the supplied Android relationship context.
Mitigation priorities
- Maintain authoritative mobile application inventory for managed Android devices.
- Use allowlisting, managed app deployment, and device compliance policies where appropriate for the organization’s mobile risk model.
- Ensure SOC and IR playbooks include checks for installed apps and app metadata, not just user-visible icons.
- Educate support and response teams that absence from the app drawer is not proof an app is absent.
- Use mobile security tooling and management controls to preserve evidence needed for investigation and audit readiness.
Analyst notes and limits
This take is based on the DET0640 detection strategy metadata and its relationship to T1628 Hide Artifacts. The useful defensive framing comes from the related technique description: mobile APIs can legitimately hide artifacts such as launcher icons, and adversaries may abuse that behavior to evade user detection. Because the official detection field is not provided, teams should treat this as a coverage-validation prompt rather than a ready-made analytic.
The supplied detection strategy has no official description, detection text, tactics, or platform list. Android is supported only through the relationship to T1628. No active exploitation, attribution, impact level, or guaranteed detection coverage is stated in the supplied ATT&CK fields. Local device management architecture, telemetry retention, privacy rules, and mobile ownership model are required to determine practical coverage.
Detection of Hide Artifacts
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 | T1628 | Hide Artifacts | This object detects Hide Artifacts. |
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 | 1b200cfe10a5… |
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 DET0640Open 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.