DC0061: File Modification
Changes made to a file, including updates to its contents, metadata, access permissions, or attributes. These modifications may indicate legitimate activity (e.g., software updates) or unauthorized changes (e.g., tampering, ransomware, or adversarial modifications). Examples:
- Content Modifications: Changes to the content of a configuration file, such as modifying `/etc/ssh/sshd_config` on Linux or `C:\Windows\System32\drivers\etc\hosts` on Windows. - Permission Changes: Altering file permissions to allow broader access, such as changing a file from `644` to `777` on Linux or modifying NTFS permissions on Windows. - Attribute Modifications: Changing a file's attributes to hidden, read-only, or system on Windows. - Timestamp Manipulation: Adjusting a file's creation or modification timestamp using tools like `touch` in Linux or timestomping tools on Windows. - Software or System File Changes: Modifying system files such as `boot.ini`, kernel modules, or application binaries.
Analyst context for executives and security teams
File Modification is a foundational evidence type for understanding whether important files were changed, permissions were loosened, attributes were hidden, or timestamps were manipulated. For leaders, its value is not that every file change is suspicious; it is that many high-consequence events—tampering, ransomware-like changes, unauthorized configuration edits, and system or application alteration—leave this kind of evidence behind.
Executive priority
Treat file-modification visibility as a control and evidence question: can the organization prove when critical configuration, system, application, or access-control files changed, who or what changed them, and whether the change was authorized? This matters for incident response scoping, audit evidence, operational resilience, and prioritizing monitoring around files that could affect availability, security posture, or recovery confidence.
Technical view
SOC and IR teams should validate that monitoring can capture changes to file contents, metadata, permissions, attributes, and timestamps. The ATT&CK description includes examples such as configuration files, hosts files, permissions changes, hidden/read-only/system attributes, timestamp manipulation, and system or application file changes. Because no ATT&CK detection guidance, tactics, platforms, or relationships are supplied, teams must define local critical-file lists and baselines based on their environment rather than relying on this object alone.
Likely telemetry
- File integrity monitoring or endpoint file-change events
- Operating system audit logs for file writes, permission changes, attribute changes, and metadata updates
- Security tool telemetry showing changes to protected system, application, or configuration files
- Change-management records to distinguish approved from unexpected modifications
- Backup, recovery, or version-control records that can confirm file content or timestamp differences
Detection direction
- Prioritize monitoring for high-value configuration, system, application, and access-control files rather than alerting equally on all file writes.
- Correlate file changes with approved change windows, software updates, administrative activity, and deployment tooling to reduce false positives.
- Validate whether telemetry captures more than content writes, including permission changes, hidden/read-only/system attributes, and timestamp changes.
- Identify blind spots where file changes occur but the responsible user, process, host, or approval context is not retained.
- Because ATT&CK provides no detection text for this data component, detection engineering should be driven by local asset criticality and known operational baselines.
Mitigation priorities
- Define and maintain an inventory of critical files whose unauthorized modification would affect security, availability, or recovery.
- Apply least-privilege access controls so only authorized users, services, or deployment processes can modify sensitive files.
- Use change management and integrity monitoring to create evidence of authorized versus unexpected changes.
- Protect and retain file-change telemetry so responders can reconstruct what changed during an incident.
- Test recovery procedures to ensure critical files can be restored to a trusted state after unauthorized modification.
Analyst notes and limits
This is a data component, not a technique. Its main value is as telemetry and evidence that can support many investigations. The supplied object has no ATT&CK tactics, platforms, detection text, or relationship context, so the strongest use is to guide validation of file-change collection and governance around critical files.
The source fields do not specify platforms, related techniques, mitigations, or official detection logic. Linux and Windows examples appear in the official description, but environment-specific coverage, alerting quality, and business impact must be confirmed locally.
File Modification
Changes made to a file, including updates to its contents, metadata, access permissions, or attributes. These modifications may indicate legitimate activity (e.g., software updates) or unauthorized changes (e.g., tampering, ransomware, or adversarial modifications). Examples:
- Content Modifications: Changes to the content of a configuration file, such as modifying `/etc/ssh/sshd_config` on Linux or `C:\Windows\System32\drivers\etc\hosts` on Windows. - Permission Changes: Altering file permissions to allow broader access, such as changing a file from `644` to `777` on Linux or modifying NTFS permissions on Windows. - Attribute Modifications: Changing a file's attributes to hidden, read-only, or system on Windows. - Timestamp Manipulation: Adjusting a file's creation or modification timestamp using tools like `touch` in Linux or timestomping tools on Windows. - Software or System File Changes: Modifying system files such as `boot.ini`, kernel modules, or application binaries.
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 | 8f60f4d1f39d… |
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 DC0061Open 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.