DC0055: File Access
To events where a file is opened or accessed, making its contents available to the requester. This includes reading, executing, or interacting with files by authorized or unauthorized entities. Examples include logging file access events (e.g., Windows Event ID 4663), monitoring file reads, and detecting unusual file access patterns. Examples:
- File Read Operations: A user opens a sensitive document (e.g., financial_report.xlsx) on a shared drive. - File Execution: A script or executable file is accessed and executed (e.g., malware.exe is run from a temporary directory). - Unauthorized File Access: An unauthorized user attempts to access a protected configuration file (e.g., `/etc/passwd` on Linux or `System32` files on Windows). - File Access Patterns: Bulk access to multiple files in a short time (e.g., mass access to documents on a file server). - File Access via Network: Files on a network share are accessed remotely (e.g., logs of SMB file access).
Analyst context for executives and security teams
File Access is a foundational evidence source for understanding who or what opened, read, executed, or interacted with files. For leaders, its value is less about one alert and more about proving whether the organization can see sensitive data use, unusual bulk access, access to protected configuration files, execution from suspicious locations, and remote access to shared files.
Executive priority
Prioritize File Access visibility where file activity affects business continuity, regulated data, privileged configuration, or incident scoping. Executives should ask whether teams can produce audit-ready evidence of access to sensitive documents, shared drives, critical system files, and network-accessed files during an investigation. Because ATT&CK provides no specific tactic mapping or detection logic for this data component, investment decisions should focus on telemetry completeness, retention, and the ability to correlate file access with identity and process context.
Technical view
SOC, detection, and IR teams should validate that file open/read/execute/access events are collected and searchable for high-value locations and sensitive file classes. The official examples include Windows Event ID 4663, file read operations, execution of scripts or executables, access attempts against protected files such as /etc/passwd or Windows System32 files, bulk file access in short time windows, and remote access to files on network shares such as SMB. Since no ATT&CK detection guidance or relationship context is supplied, local engineering should define baselines, sensitive paths, authorized access patterns, and correlation requirements.
Likely telemetry
- File open/access/read events
- File execution access records
- Access attempts to protected or sensitive files
- Bulk file access patterns over short time windows
- Network share file access logs, including SMB where applicable
Detection direction
- Confirm whether file access auditing is enabled for sensitive repositories, shared drives, protected configuration files, and critical system locations.
- Tune for unusual access patterns such as mass reads, access outside normal user or service behavior, and execution from temporary or unexpected directories.
- Correlate file access with user identity, requester/process context, and network share source where available.
- Separate legitimate administrative, backup, indexing, security scanning, and business workflow activity from suspicious bulk or unauthorized access patterns.
- Validate retention and search performance for incident response, because file access evidence often becomes important after the initial alert.
Mitigation priorities
- Classify and prioritize monitoring for files and repositories that matter most to business operations, regulated data, credentials, configuration, and incident response.
- Enable appropriate file access auditing on critical systems and network shares, balancing visibility with event volume and privacy requirements.
- Apply least-privilege access controls to reduce unnecessary exposure of sensitive files and protected locations.
- Maintain retention and audit evidence sufficient for investigations and compliance needs.
- Use baselining and allowlisting for known administrative, backup, and service activity before escalating unusual access patterns.
Analyst notes and limits
This is a data component, not a technique. Its defensive value is as an evidence class that supports detection, investigation, compliance evidence, and access governance. The supplied ATT&CK object has no tactics, platforms, relationships, or official detection text, so coverage decisions must be driven by the organization’s file repositories, identity model, audit policy, and operational risk.
No relationship context, platform list, tactic mapping, or official detection analytics were supplied. The examples mention specific event types and file locations, but they do not guarantee applicability in every environment. Local logging configuration is required before any coverage claim can be made.
File Access
To events where a file is opened or accessed, making its contents available to the requester. This includes reading, executing, or interacting with files by authorized or unauthorized entities. Examples include logging file access events (e.g., Windows Event ID 4663), monitoring file reads, and detecting unusual file access patterns. Examples:
- File Read Operations: A user opens a sensitive document (e.g., financial_report.xlsx) on a shared drive. - File Execution: A script or executable file is accessed and executed (e.g., malware.exe is run from a temporary directory). - Unauthorized File Access: An unauthorized user attempts to access a protected configuration file (e.g., `/etc/passwd` on Linux or `System32` files on Windows). - File Access Patterns: Bulk access to multiple files in a short time (e.g., mass access to documents on a file server). - File Access via Network: Files on a network share are accessed remotely (e.g., logs of SMB file access).
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 3.0 | Current bundle | d09b341b80f3… |
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 DC0055Open 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.