Linux File Integrity Monitoring with Auditd

A hands-on security investigation where I configured the Linux Audit daemon to monitor a protected directory, then used log analysis to identify which attack scripts modified which files -- simulating real SOC file integrity monitoring work.

---

Overview

File integrity monitoring is a core concept in security operations. The idea is simple: you tell the system to watch certain files or directories, and any time something writes to them, the system logs it. If something unauthorized modifies a sensitive file, you'll have a record of exactly what happened, when, and what process caused it.

In this project I:

• Configured auditd watch rules to monitor 10 files in a protected directory
• Ran three simulated attack scripts that secretly modified files in that directory
• Investigated the audit logs using ausearch to identify which attack was responsible for each change

Tools used: auditd, auditctl, ausearch, tee, Linux CLI (Ubuntu)

---

The Protected Directory

The directory being monitored contained 10 files:

car_sales.csv
cloudia.txt
dolly.txt
earthquakes.csv
loggy.txt
oakley.txt
precipitation.csv
squeaky.txt
tosty.txt
website.js

The goal was to watch all of them and catch which ones got tampered with.

---

Step 1: Download and Set Up the Project

# Download the project repo
wget https://github.com/codepath/project2/archive/main.zip

# Unzip it
unzip main.zip

# Navigate into the project folder
cd project2-main

# Make the attack scripts executable
chmod u+x attack-a attack-b attack-c

---

Step 2: Write the Audit Rule

auditd is the Linux Audit daemon -- a built-in service that can log system events based on rules you define. To monitor the protected directory, I needed to write a rule telling it what to watch and what events to log.

I used tee to write the rule directly into the audit rules file (avoiding vim entirely, which I'd recommend):

sudo tee /etc/audit/rules.d/audit.rules << 'EOF'
## First rule - delete all
-D
## Increase the buffers to survive stress events.
-b 8192
## This determine how long to wait in burst of events
--backlog_wait_time 0
## Set failure mode to syslog
-f 1
-w /home/codepath/project2-main/protected_files -p w -k protected_watch
EOF

Breaking down the watch rule at the bottom:

Flag	What it does
-w	Watch -- sets the path to monitor
/home/codepath/project2-main/protected_files	The directory being monitored
-p w	Trigger on write events (file modifications)
-k protected_watch	A filter key used to search logs for this specific rule later

The filter key is important. Without it, you'd have to dig through every single audit event on the system to find the ones you care about. With it, you can run ausearch -k protected_watch and pull only the events tied to your rule.

After writing the rule, restart auditd so the changes take effect:

sudo systemctl restart auditd

Then verify the rule loaded correctly:

sudo auditctl -l

Expected output:

-w /home/codepath/project2-main/protected_files -p w -k protected_watch

If you see No rules, the most common cause is a path error in the rules file or a syntax problem. Double check the path matches where your files actually live (echo $HOME is useful here).

---

Step 3: Run the Attack Scripts

With monitoring active, I ran the three attack scripts:

./attack-a
./attack-b
./attack-c

Each script printed a message confirming it had modified a file:

attack-a: Modifying a protected file at .../protected_files! ... hehe
attack-b: Modifying a protected file at .../protected_files! ... hehe
attack-b: Modifying a protected file at .../protected_files! ... hehe
attack-c: Modifying a protected file at .../protected_files! ... hehe

Note that attack-b printed twice, meaning it modified two separate files.

---

Step 4: Investigate the Logs

With the attacks complete, I used ausearch to pull all events tied to the protected_watch key:

sudo ausearch -k protected_watch

The output contained one log entry per file write event. Each entry includes:

• comm= -- the process (attack script) that caused the event
• name= -- the full path of the file that was modified
• time= -- exactly when it happened

Here's what the relevant entries looked like (condensed for readability):

time->Sun Jun 14 20:38:07 2026
type=PROCTITLE ... proctitle="./attack-a"
type=PATH ... name="/home/codepath/project2-main/protected_files/cloudia.txt"
comm="attack-a" exe=".../attack-a" key="protected_watch"

time->Sun Jun 14 20:38:07 2026
type=PROCTITLE ... proctitle="./attack-b"
type=PATH ... name="/home/codepath/project2-main/protected_files/oakley.txt"
comm="attack-b" exe=".../attack-b" key="protected_watch"

time->Sun Jun 14 20:38:07 2026
type=PROCTITLE ... proctitle="./attack-b"
type=PATH ... name="/home/codepath/project2-main/protected_files/squeaky.txt"
comm="attack-b" exe=".../attack-b" key="protected_watch"

time->Sun Jun 14 20:38:11 2026
type=PROCTITLE ... proctitle="./attack-c"
type=PATH ... name="/home/codepath/project2-main/protected_files/precipitation.csv"
comm="attack-c" exe=".../attack-c" key="protected_watch"

---

Findings

Out of 10 files in the protected directory, 4 were modified:

File	Attack Responsible
cloudia.txt	attack-a
oakley.txt	attack-b
squeaky.txt	attack-b
precipitation.csv	attack-c

The other 6 files (car_sales.csv, dolly.txt, earthquakes.csv, loggy.txt, tosty.txt, website.js) were untouched and did not appear in the audit logs.

---

Key Takeaways

The filter key is everything. When you have hundreds of audit events on a busy system, being able to run ausearch -k your_key and immediately narrow down to exactly the events you care about is what makes investigation practical. Unique keys per rule also mean you won't accidentally mix up events from different monitoring rules.

The path in your rule has to be exact. One of the trickier parts of this project was discovering that /root/project2-main/... and /home/codepath/project2-main/... are completely different paths. Auditd silently loads no rules if the file has an error, so always verify with auditctl -l after restarting the service.

This is real SOC work. File integrity monitoring is how security teams detect unauthorized changes to sensitive files -- config files, credential stores, log files -- in production environments. The investigation workflow here (configure watch rule → trigger event → filter logs → identify process and file) is the same pattern used in real incident response.

---

Real-World Connections

• SIEM integration: In production, audit logs feed into SIEM platforms (Splunk, Elastic) where analysts run queries similar to ausearch but at much larger scale
• File Integrity Monitoring (FIM): Tools like AIDE, Tripwire, and Wazuh build on the same concept, alerting on unauthorized file changes automatically
• Security+ relevance: File integrity monitoring appears in the Security+ exam under monitoring and detection controls
• Compliance: FIM is a requirement in frameworks like PCI-DSS and HIPAA for protecting sensitive data files

---

Related Projects

• Network Forensics: BEC Phishing Investigation -- packet capture analysis using Wireshark and tshark to identify a business email compromise campaign