AN2049: Analytic 2049
Monitor for unexpected changes to project files, although if the malicious modification occurs in tandem with legitimate changes it will be difficult to isolate the unintended changes by analyzing only file systems modifications.
Analyst context for executives and security teams
This analytic matters because unexpected changes to ICS project files can be an early warning that engineering logic, configuration, or operational documentation has been altered outside normal change control. For leaders, the value is not simply file monitoring; it is proving that changes to sensitive operational project artifacts are visible, authorized, and reviewable before they create operational or safety risk.
Executive priority
Treat this as a change-control and resilience evidence question: can the organization show who changed critical ICS project files, when they changed, whether the change was approved, and whether responders can distinguish normal engineering work from suspicious modification? This supports incident decision-making, audit readiness, and cyber-physical risk governance, but the supplied ATT&CK object does not identify specific platforms, tactics, or threat actors.
Technical view
SOC, OT security, and incident response teams should validate monitoring for unexpected project-file changes and correlate file-system modification events with approved engineering change windows, user activity, and asset context. The key limitation in the official text is that file modification telemetry alone may not isolate malicious changes when they occur alongside legitimate updates, so detection should emphasize correlation and change validation rather than raw file-write alerts only.
Likely telemetry
- File creation, modification, deletion, and rename events for ICS project-file locations
- File integrity monitoring or version-control change history where available
- User/account activity associated with project-file access or modification
- Change-management records and approved maintenance windows
- Engineering workstation or server logs that can place file changes in operational context
Detection direction
- Validate that project-file paths and repositories are explicitly in monitoring scope; do not assume generic endpoint logging covers them.
- Tune alerts for changes outside approved maintenance or engineering workflows, while allowing for legitimate project updates.
- Correlate file modifications with authorized change tickets, user identity, source host, and timing to reduce false positives.
- Account for the documented blind spot: malicious edits made during legitimate changes may require content review, version comparison, or engineering validation, not just file-system timestamps.
- Use this analytic as a coverage test for OT change visibility rather than a standalone confirmation of compromise.
Mitigation priorities
- Define authoritative storage locations and ownership for ICS project files.
- Require documented approval and review for project-file changes.
- Maintain backups or version history sufficient to compare and restore project files.
- Restrict modification rights to appropriate engineering roles and review access periodically.
- Integrate project-file change evidence into incident response and compliance reporting workflows.
Analyst notes and limits
The ATT&CK object is a detection analytic in the ICS domain with a narrow official description focused on monitoring unexpected project-file changes. No tactics, platforms, relationships, aliases, or detailed detection logic were supplied, so this take emphasizes validation, correlation, and operational change-control evidence.
Coverage and priority depend on the local ICS architecture, where project files reside, how engineering changes are performed, and what file, identity, and change-management telemetry is actually collected. The supplied object does not support claims about specific adversaries, active exploitation, affected products, or guaranteed detection outcomes.
Analytic 2049
Monitor for unexpected changes to project files, although if the malicious modification occurs in tandem with legitimate changes it will be difficult to isolate the unintended changes by analyzing only file systems modifications.
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 | 1.0 | Current bundle | b1b2fc5e5121… |
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 AN2049Open 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.