Attackers persist by changing files that the system trusts, and file integrity monitoring is the control that notices when those files stop matching a known good state. MITRE D3FEND names this countermeasure File Integrity Monitoring (D3-FIM) and defines it as "Detecting any suspicious changes to files in a computer system." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM), alongside Application Performance Monitoring, Firmware Behavior Analysis, Firmware Embedded Monitoring Code, Firmware Verification, Operating Mode Monitoring, Operating System Monitoring, Operational Process Monitoring and Platform Uptime Monitoring. This card covers what D3FEND says about D3-FIM, the ATT&CK techniques it relates to, how FIM is implemented across tool classes, how to verify it and where it fails. The broader programme view, including compliance drivers, is in the File Integrity Monitoring Guide; this page stays at the countermeasure level.
Key takeaways
- Baseline, compare, alert. D3FEND describes FIM tools as comparing current artefacts with a previous snapshot and alerting when files have been created, modified or removed.
- Scope decides success. D3FEND's own consideration is that FIM "works best when pointed at a narrow scope of critical files", because systems change constantly and broad scopes drown analysts.
- Very wide ATT&CK reach. Because almost every persistence and stealth technique touches a file, D3FEND infers relations from D3-FIM to well over a hundred ATT&CK techniques and sub-techniques, led by persistence, privilege escalation and stealth.
- Who changed it matters as much as what changed. Modern implementations record the account and initiating process with each change, which turns a hash mismatch into an investigation lead.
- A change log is only useful if change is controlled. FIM alerts need to be reconciled with approved changes, otherwise every patch day becomes an incident.
D3-FIM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FIM (d3f:FileIntegrityMonitoring) |
| Tactic | Detect |
| Parent technique | Platform Monitoring (D3-PM) |
| Digital artefact | File (D3FEND relation: analyzes File) |
| D3FEND references | Microsoft Learn: File Integrity Monitoring in Microsoft Defender for Cloud; the tripwire manual page |
| Detection methods | Scheduled scan against a stored baseline; real-time event-driven monitoring; agentless scans of disk snapshots |
| Effort | Low to deploy; medium to keep tuned against change management |
| Main limitation | Detects changes after they happen; noisy on wide scopes; blind to attacks that never touch watched files |
How it works
D3FEND's article gives the two classic patterns. On Unix, tripwire first initialises a database as the basis for comparison, then scans the file system against that baseline; users define policies that specify potential violations. On Windows and in cloud estates, D3FEND points to Microsoft Defender for Cloud FIM, which tracks creation, removal and modification of specific files and registry keys. Implementations differ in three ways.
- Scheduled baseline comparison: a scan computes hashes and attributes and compares them with a stored database. AIDE, a GPL-2.0 file and directory integrity checker, builds its database from regular expression rules in its configuration and then uses it to flag inconsistencies; its project page lists md5, sha1, rmd160, tiger, crc32, sha256, sha512 and whirlpool among supported hashes. Simple and tamper-evident if the database is stored off-host, but changes made and reverted between scans are missed.
- Real-time monitoring: kernel notification mechanisms report changes as they happen. osquery's file_events table uses inotify on Linux and FSEvents on macOS, and ntfs_journal_events on Windows; it calculates MD5, SHA1 and SHA256 on change events where possible.
- Agent or agentless collection with attribution: Microsoft Defender for Cloud FIM now uses the Defender for Endpoint agent and agentless scanning. Its documentation says agent events stream to a Log Analytics workspace in near real time, agentless events arrive on a 24-hour cadence, and each change record includes the account and initiating process.
What to watch is the second design decision. As one documented example, Defender for Cloud recommends items you can choose to monitor, including Linux paths such as /bin, /boot, /etc/*.conf, the cron directories, /etc/crontab, /etc/init.d, /sbin, /usr/bin and /usr/sbin, and Windows registry keys including the Run and RunOnce keys, AppInit_DLLs values and SECURITY\POLICY\SECRETS. Those lists map closely to the persistence techniques below.
ATT&CK techniques D3FEND relates to D3-FIM
Relationship type: inferred only. D3FEND 1.6.0 lists no direct ATT&CK mapping for D3-FIM; every row below is inferred because the ATT&CK technique creates, modifies, deletes or reads a File, the artefact D3-FIM analyses (checked November 2026). The full list is long, so it is grouped by tactic with representative IDs. Where D3FEND still lists an ID that ATT&CK v20 has revoked, the v20 successor is shown with a note. IDs verified against ATT&CK v20.
| Tactic (v20) | Representative techniques D3FEND relates to D3-FIM | File change FIM can see |
|---|---|---|
| Persistence and Privilege Escalation | T1546 Event Triggered Execution (.002 Screensaver, .004 Unix Shell Configuration Modification, .008 Accessibility Features, .010 AppInit DLLs, .013 PowerShell Profile, .015 Component Object Model Hijacking); T1547 Boot or Logon Autostart Execution (.001 Registry Run Keys / Startup Folder, .006 Kernel Modules and Extensions, .008 LSASS Driver, .009 Shortcut Modification); T1543 Create or Modify System Process (.001 Launch Agent, .002 Systemd Service, .004 Launch Daemon); T1037 Boot or Logon Initialization Scripts (.001, .002, .004); T1505.003 Web Shell; T1137.001 Office Template Macros | New or changed autostart entries, unit files, shell profiles, web root scripts and templates |
| Credential Access and Defense Impairment | T1556 Modify Authentication Process (.002 Password Filter DLL, .003 Pluggable Authentication Modules); T1552.001 Credentials In Files; T1003.008 /etc/passwd and /etc/shadow | Changes to PAM modules, authentication DLLs and credential stores |
| Stealth and Execution | T1574 Hijack Execution Flow (.001 DLL, .007 Path Interception by PATH Environment Variable, .008 Path Interception by Search Order Hijacking, .009 Path Interception by Unquoted Path); T1036 Masquerading (.003 Rename Legitimate Utilities, .005 Match Legitimate Resource Name or Location, .006 Space after Filename); T1070.004 File Deletion; T1027 Obfuscated Files or Information (.002 Software Packing, .004 Compile After Delivery); T1204.002 Malicious File | New binaries in search paths, renamed system utilities, deleted logs and tools |
| Collection and Impact | T1074.001 Local Data Staging; T1560 Archive Collected Data (.001, .002, .003); T1114.001 Local Email Collection; T1565 Data Manipulation (.001 Stored Data Manipulation, .003 Runtime Data Manipulation) | Archives appearing in staging folders; tampering with stored data |
| Revoked IDs still listed by D3FEND | DLL Side-Loading (now T1574.001 DLL); Clear Linux or Mac System Logs (now T1685.006); Impair Command History Logging (now T1690 Prevent Command History Logging) | D3FEND 1.6.0 shows the pre-v20 IDs; use the v20 successors in detection content |
D3FEND's inferred set also includes Software Deployment Tools (T1072), File and Directory Discovery (T1083), Automated Collection (T1119) and Data from Local System (T1005); for those, FIM sees only side effects such as files written or read, not the discovery itself. Treat the table as a guide to which paths to watch, not as coverage. Technique detail is in the T1547 Boot or Logon Autostart Execution Defensive Guide, T1546 Event Triggered Execution Defensive Guide, T1505 Server Software Component Defensive Guide, T1036 Masquerading Defensive Guide and T1070 Indicator Removal Defensive Guide.
Where it is implemented
Tool classes are listed with documented examples in alphabetical order; examples are illustrative, not recommendations.
| Class | Documented examples | Method | Fits when |
|---|---|---|---|
| Host-based integrity checkers | AIDE; tripwire (cited by D3FEND) | Scheduled scan against a stored database of hashes and attributes | Linux and Unix servers with stable file sets; regulated systems needing a simple, auditable baseline |
| Cloud security platform FIM | Microsoft Defender for Cloud FIM (cited by D3FEND) | Agent (near real time) and agentless (24-hour cadence) collection of file and registry changes | Cloud and hybrid server estates already managed by the platform |
| Endpoint query and telemetry agents | osquery file_events and ntfs_journal_events; Sysmon file events on Windows | Real-time OS notifications, queried or forwarded to a SIEM | Teams that want FIM data in the same pipeline as other endpoint telemetry |
| Linux kernel audit | auditd path and directory rules with write and attribute permissions | Syscall auditing on watched paths, with user and process attribution | Linux hosts where who changed a file is the key question |
Availability: Microsoft documents Defender for Cloud FIM as requiring Defender for Servers Plan 2, with legacy Windows machines needing the Defender for Endpoint client version 10.8799 or later; FIM is not enabled by default and custom rules are limited to 500. AIDE and osquery are open source. Linux specifics are in the Linux File Integrity Monitoring Guide.
Implementation steps
- Define the critical file set. Start with the persistence and authentication locations in the table above for each operating system, plus your own application binaries, web roots and configuration. Write it down per server role.
- Build the baseline from a known good state. Take it immediately after a clean build or a verified patch cycle. Store host-based databases off the host or read-only, so an attacker cannot rewrite the baseline.
- Choose method per role. Real-time where speed matters (internet-facing servers, domain controllers), scheduled scans where change is rare and simplicity matters.
- Connect to change management. Tag approved change windows and deployment identities so expected changes are reconciled automatically, and the remainder alert.
- Pilot in report-only mode. Run on one role for a patch cycle, record every alert, and remove noisy paths (logs, caches, temp files) from scope rather than muting rules.
- Roll out and keep rollback. Deploy configuration through your management tooling with the previous version kept. If CPU or I/O impact is seen, narrow scope or switch that role to scheduled scans.
How to verify it works
- Canary change test: on a schedule, modify a harmless test file placed inside each watched directory, and create and delete another. Confirm an alert with the account and process for each.
- Baseline integrity: check that the baseline database itself has not changed outside a recorded update, and that the update procedure requires approval.
- Coverage report: compare the configured paths on each host with the approved list per role; drift here is common after OS upgrades.
- Downloaded code checks: the same compare-to-known-good idea applies to scripts and tools pulled into pipelines. The Codecov Breach 2021 was found when a customer compared the published checksum of the Bash Uploader with the script actually fetched, and they did not match.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Canary changes detected | 100%, with account and process attributed | Proves collection, comparison and alerting end to end |
| Alerts reconciled to approved change | Most alerts auto-reconciled after tuning | Analysts focus on unexplained change |
| Servers with FIM on the approved file set | Every server in scope, tracked per role | Unmonitored hosts are where persistence hides |
| Median time from unexplained change to triage | Tracked and falling | FIM value decays with delay |
Limits, bypasses and failure patterns
- Scope too wide: D3FEND's own warning. Watching whole volumes generates constant churn, and the real change is lost.
- Baseline on the host: an attacker with root or SYSTEM can update the local database or the agent configuration. Keep baselines off-host and alert on agent configuration changes.
- Scan gaps: scheduled scans miss changes that are made and reverted between scans, and agentless scans on a 24-hour cadence are slow by design.
- Kernel-level hiding: a rootkit can present clean file content to user-mode tools. Pair FIM with boot integrity techniques such as D3-SFV System Firmware Verification and off-host comparison.
- Notifier limits: osquery documents that very large directory counts can exhaust inotify handles and stop all events, that some platforms cannot watch a path until it exists, and that hard link changes may be missed.
- Alert without change control: where nobody can say whether a change was approved, alerts are closed by habit.
Where identity fits
Most legitimate changes to watched files come from non-human identities: configuration management agents, deployment pipelines and patch services. Recording the account on each change, and reconciling against an allow list of those service identities, makes FIM sharper. It also means a stolen pipeline credential produces "approved-looking" change, so watch for changes by deployment identities outside their release windows. Related monitoring of new files is in D3-FCA File Creation Analysis.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity; SI-7(1) Integrity Checks | Integrity verification tools and the checks they run |
| NIST SP 800-53 Rev 5 | CM-3 Configuration Change Control; CM-6 Configuration Settings | Reconciling detected change with approved change |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Feeding FIM alerts into monitoring |
| NIST CSF 2.0 | DE.CM-09, PR.PS-01 | Monitoring software and runtime environments; configuration management practices |
| MITRE D3FEND | D3-PM, D3-FIM | Parent and technique |
Practitioner checklist
- Write a critical file set per server role, starting from persistence and authentication paths.
- Baseline from a known good build and store the baseline off-host.
- Use real-time monitoring on internet-facing servers and identity infrastructure.
- Record account and process with every change.
- Reconcile alerts against approved change and deployment identities.
- Run a canary change test per watched directory on a schedule.
- Alert on changes to the FIM agent configuration and baseline.
- Map detection content to ATT&CK v20 IDs, not the revoked IDs D3FEND still lists.
Standards and references
- MITRE D3FEND: File Integrity Monitoring (D3-FIM)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7)
- Microsoft Learn: File Integrity Monitoring in Microsoft Defender for Cloud
- Microsoft Learn: Sysmon
- AIDE: Advanced Intrusion Detection Environment
- osquery: File Integrity Monitoring
- Linux man-pages: auditctl(8)
Related NHI Mgmt Group resources: File Integrity Monitoring Guide · Linux File Integrity Monitoring Guide · D3-FCA File Creation Analysis · MITRE D3FEND Guide