DET0682: Detection of File and Directory Discovery
This detection strategy is intended to help identify mobile file and directory discovery behavior: activity where an adversary enumerates device storage to...
Analyst context for executives and security teams
This detection strategy is intended to help identify mobile file and directory discovery behavior: activity where an adversary enumerates device storage to find useful information or decide what to do next. For leaders, the value is not the specific detection logic—none is supplied here—but the reminder that mobile compromise often includes reconnaissance before data access, persistence, or further actions. Coverage should be assessed as part of mobile device visibility, incident readiness, and evidence collection for Android and iOS environments tied to the related ATT&CK technique T1420.
Executive priority
Prioritize this as a visibility and response-readiness question for managed mobile environments: can the organization see suspicious file-system enumeration on relevant Android and iOS devices, and can SOC/IR teams use that evidence during triage? Because the ATT&CK object provides no official detection text or platforms for the strategy itself, leaders should avoid assuming coverage and instead request proof of telemetry, alert logic, response playbooks, and audit-ready evidence for mobile discovery behavior.
Technical view
The supplied relationship states that this detection strategy detects T1420, File and Directory Discovery, in the mobile ATT&CK domain. SOC and detection teams should validate whether mobile telemetry can distinguish normal application file access from unusual enumeration or searching of files and directories. IR teams should ensure mobile collection procedures preserve file-access, application, device-management, and security-tool evidence where available. Because the detection strategy has no official detection field, local engineering must define the analytic criteria and test them against known-good mobile activity.
Likely telemetry
- Mobile device management or enterprise mobility management inventory and compliance data
- Mobile endpoint/security agent events, where deployed
- Application behavior logs or security telemetry showing file and directory access patterns
- Operating system audit or diagnostic logs available from Android or iOS devices
- Incident response mobile forensic collections when live telemetry is limited
Detection direction
- Confirm what mobile file-system visibility actually exists for Android and iOS; do not assume desktop-style endpoint telemetry is available.
- Tune for unusual enumeration patterns, repeated directory listing or search behavior, or access to sensitive device locations when such events are observable.
- Baseline legitimate mobile application behavior to reduce false positives from indexing, backup, synchronization, security scanning, or enterprise management activity.
- Correlate discovery-like file access with other mobile suspicious signals before escalation, since this object supplies no standalone detection logic.
- Document telemetry gaps explicitly, especially for unmanaged devices, privacy-constrained logging, or platforms where file-access events are not centrally collected.
Mitigation priorities
- Start with asset and mobile management coverage: know which Android and iOS devices are in scope and which are unmanaged or lightly monitored.
- Enforce least-privilege mobile application permissions and review access to sensitive storage locations where policy and platform controls allow.
- Use mobile security tooling and MDM/EMM controls to improve visibility, compliance posture, and response actions such as isolation or investigation workflows.
- Maintain IR procedures for mobile evidence acquisition when routine telemetry cannot confirm or refute file discovery behavior.
- Use detection validation results as compliance and risk evidence rather than treating ATT&CK mapping alone as proof of control effectiveness.
Analyst notes and limits
This is a detection-strategy object, not a technique description or a complete analytic. Its only substantive context is the relationship to T1420, File and Directory Discovery, in the mobile domain, with related platforms Android and iOS. The Glexia interpretation therefore focuses on coverage validation, telemetry readiness, and defensive decision-making rather than prescribing a specific rule.
The official description, official detection text, tactics, labels, aliases, and strategy platforms are not provided. The related technique description is partially truncated in the supplied source. Any concrete detection logic, thresholds, platform-specific logging claims, or control effectiveness conclusions require local telemetry and environment validation.
Detection of File and Directory 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 | T1420 | File and Directory Discovery | This object detects File and Directory 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 | f6818a73fb84… |
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 DET0682Open 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.