D3-SFA System File Analysis: Detecting Tampering With Operating System Files

Authentication databases, system configuration, logs and system executables decide how a host behaves below the user level, so an attacker who changes them gains persistence, credentials or cover without running anything obviously malicious. MITRE D3FEND names the countermeasure System File Analysis (D3-SFA) and defines it as "Monitoring system files such as authentication databases, configuration files, system logs, and system executables for modification or tampering." It is a Detect technique under Operating System Monitoring, its digital artefact is the Operating System File, and its child technique is Service Binary Verification (D3-SBV). This card explains what D3-SFA watches, which ATT&CK techniques D3FEND relates it to, the Windows and Linux signals that implement it, how to verify it and where it falls short. It is for detection engineers and host owners; general tool selection for file integrity monitoring is in the File Integrity Monitoring Guide.

Key takeaways

• Scope is the operating system's own files. D3-SFA covers files that are part of, or store information about, the operating system: authentication stores, configuration, logs and system binaries, not business data.
• Baseline first. D3FEND's considerations call for a baseline or snapshot of file checksums for later comparison, and warn that false positives and log volume need planning.
• Wide ATT&CK reach, inferred. D3FEND relates D3-SFA through the Operating System File artefact to techniques from Proc Filesystem (T1003.007) and Proc Memory (T1055.009) to PAM changes, systemd services, dynamic linker hijacking and log clearing.
• Three MITRE CAR analytics show the shape. D3FEND cites analytics for log clearing (events 1100, 1102, 1104 and 104), permission changes (event 4670 and chmod) and autorun differences.
• Change control decides the noise. Patching rewrites system files every month; without a link between alerts and approved changes, D3-SFA drowns in expected modifications.

D3-SFA at a glance

How it works

D3FEND's article is brief: the technique ensures the integrity of system-owned file resources, because system files can change behaviour below the user level. In practice D3-SFA combines three methods.

• Baseline comparison: hash and record attributes of system files, then compare on a schedule or on change. Differences that do not match an approved change are investigated.
• Real-time change events: operating system auditing or an agent records writes, deletes, permission and ownership changes on watched paths as they happen, with the process and account responsible.
• Content analysis: for files whose meaning matters more than their hash, such as PAM configuration, sudoers, autorun locations or service definitions, parse the content and alert on specific risky entries.

ATT&CK techniques D3FEND relates to D3-SFA

Relationship type: inferred only. D3FEND lists these relations as "inferred and experimental", derived because each technique accesses or modifies an Operating System File or one of its sub-artefacts such as configuration, log or executable files (D3FEND 1.6.0, checked November 2026). The ontology records three direct relations: Proc Filesystem accesses, Proc Memory accesses and may modify, and Device Driver Discovery may access Operating System File. D3FEND still lists Clear Linux or Mac System Logs under an ID that ATT&CK v20 has revoked; the successor T1685.006 is shown. Each ID was checked against ATT&CK v20.

Not every row is equally detectable with file monitoring. Changes to PAM, sudoers, unit files, /etc/ld.so.preload and logs are classic D3-SFA wins. Reads of /proc for credential or memory access are poorly served by file watches and are better caught at the system call layer with D3-SCA System Call Analysis. Technique detail: T1003 OS Credential Dumping, T1055 Process Injection Defensive Guide and T1652 Device Driver Discovery.

What to watch

Platforms are listed alphabetically. The paths are common examples, not a complete list; adapt them to your builds.

Microsoft's own monitoring recommendation for event 1102 is simple: you should not normally see it, so investigate every occurrence. For Linux implementation detail, see the Linux File Integrity Monitoring Guide and the Linux Logging and auditd for Defenders Guide.

Where identity fits

Many of the files in scope are identity stores and identity configuration: /etc/shadow, sudoers, PAM stacks, SSH daemon settings and authorised key locations. A change there creates or widens access for a human or a service account. Alerts should name the account and process that made the change, and changes made by configuration management service accounts should be matched to an approved run rather than trusted by default.

Implementation steps

1. Define the watch list. Start with authentication and privilege configuration, logs, service definitions and system binaries on your most valuable hosts. Keep it short enough to review.
2. Take the baseline. Hash watched files on a known-good build and store the baseline off the host, as D3FEND's considerations recommend.
3. Enable change events. On Windows, enable Audit File System and set SACLs on the watched paths; on Linux, load keyed audit rules. Forward events off-host immediately.
4. Link to change management. Tag patch windows and configuration management runs so expected changes are labelled rather than suppressed.
5. Write targeted content rules. Alert on new entries in /etc/ld.so.preload, new NOPASSWD lines in sudoers, new PAM modules and new services, regardless of change window.
6. Pilot and tune. Run for two to four weeks on a server group, review every alert, then extend. D3FEND notes log volume and false positives as known concerns.
7. Roll back safely. If rules overload hosts or the SIEM, remove the noisiest path rule rather than disabling the set, and re-baseline after major upgrades.

How to verify it works

• Replay the CAR tests in a lab: grant full control on a test file with icacls on Windows and run chmod 777 on a test file on Linux; confirm the 4670 and process events reach the SIEM.
• Edit a watched file: append a comment to a watched configuration file on a test host and confirm the audit key or 4663 event and the baseline difference both appear.
• Clear a test log: clear the Security log on a test host and confirm event 1102 alerts, from the forwarded copy.
• Audit the coverage: confirm every host in scope has the audit rules or SACLs loaded and a recent baseline.

Limits, bypasses and failure patterns

• Baselines taken after compromise: a baseline of an already altered host records the attacker's changes as normal. Baseline from a known-good build.
• Root or SYSTEM can blind the monitor: an attacker with full privileges can stop auditing or the agent before changing files; pair with D3-SDM System Daemon Monitoring and off-host forwarding.
• In-memory changes: techniques that modify a running process or load code without writing a watched file leave nothing for D3-SFA to compare.
• Too many paths: watching whole system directories in real time creates volume that teams stop reviewing; CAR notes that cron jobs running chmod and folder permission changes per file both inflate counts.
• Patch noise treated as permanent exception: suppressing the binary directories entirely to stop patch noise removes coverage of replaced system binaries, which D3-SBV is meant to catch.
• Local-only logs: log clearing is only visible if events left the host before the clear.

Framework mapping

See M1022 Restrict File and Directory Permissions for the preventive side.

Related countermeasures

• File Integrity Monitoring: the general file integrity technique; D3-SFA focuses it on operating system files. See D3-FIM File Integrity Monitoring.
• Service Binary Verification: the D3-SFA child that checks service executables.
• System Init Config Analysis: covers autorun and init configuration that CAR-2013-01-002 compares. See D3-SICA System Init Config Analysis.
• Local File Permissions: the hardening counterpart to permission change detection. See D3-LFP Local File Permissions.

Practitioner checklist

• Keep a short, reviewed watch list of system files per platform.
• Baseline watched files from a known-good build and store it off-host.
• Enable Audit File System with SACLs on Windows and keyed audit rules on Linux.
• Alert on every event 1102 and on Linux log file truncation or deletion.
• Write content rules for sudoers, PAM, /etc/ld.so.preload and new services.
• Link file change alerts to change management records.
• Forward events off-host in real time.
• Re-baseline after every major upgrade and record why.
• Test rules quarterly with the CAR lab cases.

Standards and references

• MITRE D3FEND: System File Analysis (D3-SFA)
• MITRE CAR: CAR-2016-04-002 User Activity from Clearing Event Logs
• MITRE CAR: CAR-2019-07-001 Access Permission Modification
• MITRE CAR: CAR-2013-01-002 Autorun Differences
• Microsoft Learn: Event 4663, an attempt was made to access an object
• Microsoft Learn: Event 1102, the audit log was cleared
• Linux man-pages: audit.rules(7)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: File Integrity Monitoring Guide · Linux File Integrity Monitoring Guide · D3-FIM File Integrity Monitoring · MITRE D3FEND Guide