DC0059: File Metadata
contextual information about a file, including attributes such as the file's name, size, type, content (e.g., signatures, headers, media), user/owner, permissions, timestamps, and other related properties. File metadata provides insights into a file's characteristics and can be used to detect malicious activity, unauthorized modifications, or other anomalies. Examples:
- File Ownership and Permissions: Checking the owner and permissions of a critical configuration file like /etc/passwd on Linux or C:\Windows\System32\config\SAM on Windows. - Timestamps: Analyzing the creation, modification, and access timestamps of a file. - File Content and Signatures: Extracting the headers of an executable file to verify its signature or detect packing/obfuscation. - File Attributes: Analyzing attributes like hidden, system, or read-only flags in Windows. - File Hashes: Generating MD5, SHA-1, or SHA-256 hashes of files to compare against threat intelligence feeds. - File Location: Monitoring files located in unusual directories or paths, such as temporary or user folders.
Analyst context for executives and security teams
File Metadata is a foundational evidence source for understanding whether files are expected, trusted, modified, misplaced, or suspicious. For leaders, its value is not in any single hash or timestamp; it is in whether security teams can prove what changed, who owns it, where it resides, and whether its attributes match policy during an investigation or audit.
Executive priority
Prioritize File Metadata coverage because it supports incident triage, integrity monitoring, threat intelligence comparison, and compliance evidence around critical files. Executives should ask whether SOC and IR teams can reliably answer: what file changed, when it changed, who owns it, what permissions it has, whether it is signed or packed, and whether it appears in an unusual location. Weak metadata collection can slow containment decisions and make unauthorized modification harder to prove.
Technical view
ATT&CK provides this as an enterprise data component, not a technique, and supplies no specific tactics, platforms, or detection logic. Defenders should validate that file name, size, type, content indicators such as signatures or headers, owner/user, permissions, timestamps, attributes, hashes, and location are captured where operationally important. Detection engineering should focus on baselining critical files, identifying unauthorized ownership or permission changes, comparing hashes against approved or intelligence-driven references, and flagging unusual locations or attributes while accounting for legitimate software updates and administrative activity.
Likely telemetry
- File name, path, size, and type
- File owner or user context
- File permissions and access control properties
- Creation, modification, and access timestamps
- File attributes such as hidden, system, or read-only flags where applicable
Detection direction
- Confirm metadata is collected for files that matter to business operations, security tooling, identity stores, configuration, and regulated evidence—not only for malware alerts.
- Tune detections for unauthorized permission or ownership changes, unexpected timestamp changes, unsigned or suspiciously structured files, hash mismatches, and files appearing in unusual paths.
- Build allowlists or maintenance-window logic for legitimate software installation, patching, backup, and administrative workflows to reduce false positives.
- Validate whether metadata is retained long enough to support incident response timelines and audit reconstruction.
- Because no ATT&CK detection text or relationship context is supplied, map this data component locally to the techniques, assets, and platforms in scope before claiming coverage.
Mitigation priorities
- Define which critical files and directories require integrity and metadata monitoring.
- Standardize file ownership, permission, location, and signing expectations for high-value systems and applications.
- Ensure hash generation and metadata retention are available to SOC, incident response, and compliance teams.
- Review access controls and change-management processes for files whose metadata changes would create operational or security risk.
- Use metadata baselines to support investigations, but do not rely on metadata alone without corroborating process, user, network, or endpoint context.
Analyst notes and limits
This object is a data component, so the decision value is coverage validation: whether the organization collects and can use file metadata as evidence. The official description provides examples including ownership, permissions, timestamps, headers, signatures, attributes, hashes, and location. No ATT&CK relationships were supplied, so no technique-specific conclusions are made.
Platforms, tactics, official detection guidance, and relationship context are not specified. Local operating systems, logging tools, retention periods, asset criticality, and change-management practices are required to turn this into concrete detection coverage.
File Metadata
contextual information about a file, including attributes such as the file's name, size, type, content (e.g., signatures, headers, media), user/owner, permissions, timestamps, and other related properties. File metadata provides insights into a file's characteristics and can be used to detect malicious activity, unauthorized modifications, or other anomalies. Examples:
- File Ownership and Permissions: Checking the owner and permissions of a critical configuration file like /etc/passwd on Linux or C:\Windows\System32\config\SAM on Windows. - Timestamps: Analyzing the creation, modification, and access timestamps of a file. - File Content and Signatures: Extracting the headers of an executable file to verify its signature or detect packing/obfuscation. - File Attributes: Analyzing attributes like hidden, system, or read-only flags in Windows. - File Hashes: Generating MD5, SHA-1, or SHA-256 hashes of files to compare against threat intelligence feeds. - File Location: Monitoring files located in unusual directories or paths, such as temporary or user folders.
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 | 2.1 | Current bundle | 961387609de1… |
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 DC0059Open 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.