FIM!
Setting up File Integrity Monitoring in Wazuh and learning how something small is actually big. It's knowing what normal looks like well enough to notice when it stops being normal.
My first detection was a brute-force. A loud and obvious attack that fires passwords quickly at a login. This one would be the opposite. It’s something a normal employee could accidentally trigger. This would be detecting changes to a file.
What FIM actually is
FIM stands for File Integrity Monitoring. You hand Wazuh a folder and get it to log anything that changes within it: a creation, edit, or deletion of a file. It sounds small, however, this is how you can catch someone tampering with a file, malware being created, or exfiltration.
Setting it up
I made a throwaway folder for the agent to watch:
sudo mkdir -p /opt/fim-testThen I added one line to the agent’s config (/var/ossec/etc/ossec.conf), inside the <syscheck> section (syscheck is Wazuh’s internal name for FIM):
<directories realtime="yes" check_all="yes" report_changes="yes">/opt/fim-test</directories>
The three settings each earn their place. realtime="yes" means it alerts the moment something happens instead of reporting it on a schedule. report_changes="yes" is the one I’m glad I turned on. Instead of saying only that a file changed, it shows what changed. Then I restarted the agent so it read the new setting.
Poking the folder
Three commands, three kinds of change:
echo "original secret!" | sudo tee /opt/fim-test/secret.txt # created
echo "tampered!" | sudo tee -a /opt/fim-test/secret.txt # modified
sudo rm /opt/fim-test/secret.txt # deletedWhat fired
Three alerts, one per change: 554 for the file being added, 550 for the modification, 553 for the deletion.
The modified alert was the one that stuck with me. Because I’d turned on report_changes, rule 550 showed me the actual line that got added, instead of only saying secret.txt had changed. The raw alert carries a diff field: 1a2\n> tampered!\n. Wazuh had hashed the file before and after (MD5, SHA1, SHA256, all three) and handed me the exact edit, down to the byte count going from 16 to 26.
The part that clicked
I’d been thinking about detection as “spot the attacker”, recognize the hydra, recognize the exploit. FIM doesn’t do that. It never looks at who or how. It watches state and reports change. And a lot of the worst things an attacker does are quiet edits left as a way back in: a new line in authorized_keys, or a modified binary. Small changes, but ones that could be detrimental if not spotted quickly.
Limits
FIM tells you something changed. It doesn’t tell you if the change was legitimate. If I edit that file myself, I get the exact same alert as an attacker editing it. On a real system, you’d tune it heavily, like ignoring the processes that legitimately edit those files all the time.