You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/generic-methodologies-and-resources/basic-forensic-methodology/file-integrity-monitoring.md
+100-9Lines changed: 100 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,23 +9,114 @@ A baseline consists of taking a snapshot of certain parts of a system to **compa
9
9
For example, you can calculate and store the hash of each file of the filesystem to be able to find out which files were modified.\
10
10
This can also be done with the user accounts created, processes running, services running and any other thing that shouldn't change much, or at all.
11
11
12
+
A **useful baseline** usually stores more than just a digest: permissions, owner, group, timestamps, inode, symlink target, ACLs, and selected extended attributes are also worth tracking. From an attacker-hunting perspective, this helps detect **permission-only tampering**, **atomic file replacement**, and **persistence via modified service/unit files** even when the content hash is not the first thing that changes.
13
+
12
14
### File Integrity Monitoring
13
15
14
-
File Integrity Monitoring (FIM) is a critical security technique that protects IT environments and data by tracking changes in files. It involves two key steps:
16
+
File Integrity Monitoring (FIM) is a critical security technique that protects IT environments and data by tracking changes in files. It usually combines:
15
17
16
-
1.**Baseline Comparison:** Establish a baseline using file attributes or cryptographic checksums (like MD5 or SHA-2) for future comparisons to detect modifications.
17
-
2.**Real-Time Change Notification:** Get instant alerts when files are accessed or altered, typically through OS kernel extensions.
18
+
1.**Baseline comparison:** Store metadata and cryptographic checksums (prefer `SHA-256` or better) for future comparisons.
19
+
2.**Real-time notifications:** Subscribe to OS-native file events to know **which file changed, when, and ideally which process/user touched it**.
20
+
3.**Periodic re-scan:** Rebuild confidence after reboots, dropped events, agent outages, or deliberate anti-forensic activity.
18
21
19
-
### Tools
22
+
For threat hunting, FIM is usually more useful when focused on **high-value paths** such as:
-**`inotify` / `fsnotify`**: easy and common, but watch limits can be exhausted and some edge cases are missed.
36
+
-**`auditd` / audit framework**: better when you need **who changed the file** (`auid`, process, pid, executable).
37
+
-**`eBPF` / `kprobes`**: newer options used by modern FIM stacks to enrich events and reduce some of the operational pain of plain `inotify` deployments.
38
+
39
+
Some practical gotchas:
40
+
41
+
- If a program **replaces** a file with `write temp -> rename`, watching the file itself may stop being useful. **Watch the parent directory**, not only the file.
42
+
-`inotify`-based collectors can miss or degrade on **huge directory trees**, **hard-link activity**, or after a **watched file is deleted**.
43
+
- Very large recursive watch sets can silently fail if `fs.inotify.max_user_watches`, `max_user_instances`, or `max_queued_events` are too low.
44
+
- Network filesystems are usually bad FIM targets for low-noise monitoring.
If you need **process attribution** instead of only path-level changes, prefer audit-backed telemetry such as `osquery``process_file_events` or Wazuh `whodata` mode.
74
+
75
+
### Windows
76
+
77
+
On Windows, FIM is stronger when you combine **change journals** with **high-signal process/file telemetry**:
29
78
79
+
-**NTFS USN Journal** gives a persistent per-volume log of file changes.
80
+
-**Sysmon Event ID 11** is useful for file creation/overwrite.
81
+
-**Sysmon Event ID 2** helps detect **timestomping**.
82
+
-**Sysmon Event ID 15** is useful for **named alternate data streams (ADS)** such as `Zone.Identifier` or hidden payload streams.
30
83
84
+
Quick USN triage examples:
31
85
86
+
```cmd
87
+
fsutil usn queryjournal C:
88
+
fsutil usn readjournal C:
89
+
fsutil usn readdata C:\Windows\Temp\sample.bin
90
+
```
91
+
92
+
For deeper anti-forensic ideas around **timestamp manipulation**, **ADS abuse**, and **USN tampering**, check [Anti-Forensic Techniques](anti-forensic-techniques.md).
93
+
94
+
### Containers
95
+
96
+
Container FIM frequently misses the real write path. With Docker `overlay2`, changes are committed into the container's **writable upper layer** (`upperdir`/`diff`), not the read-only image layers. Therefore:
97
+
98
+
- Monitoring only paths from **inside** a short-lived container may miss changes after the container is recreated.
99
+
- Monitoring the **host path** that backs the writable layer or the relevant bind-mounted volume is often more useful.
100
+
- FIM on image layers is different from FIM on the running container filesystem.
101
+
102
+
## Attacker-Oriented Hunting Notes
103
+
104
+
- Track **service definitions** and **task schedulers** as carefully as binaries. Attackers often get persistence by modifying a unit file, cron entry, or task XML rather than patching `/bin/sshd`.
105
+
- A content hash alone is insufficient. Many compromises first show up as **owner/mode/xattr/ACL drift**.
106
+
- If you suspect a mature intrusion, do both: **real-time FIM** for fresh activity and a **cold baseline comparison** from trusted media.
107
+
- If the attacker has root or kernel execution, assume the FIM agent, its database, and even the event source can be tampered with. Store logs and baselines remotely or on read-only media whenever possible.
108
+
109
+
## Tools
110
+
111
+
-[AIDE](https://aide.github.io/)
112
+
-[osquery](https://osquery.io/)
113
+
-[Wazuh FIM / Syscheck](https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html)
0 commit comments