Baseline a system and catch a tampered binary
Task
Build an AIDE baseline, store it where an attacker cannot reach it, then modify a binary and confirm the tool catches it. Then see the flaw in keeping the baseline on the machine it protects.
Steps
- Understand what the baseline captured:
aide --config-checkand a look at/etc/aide.conffor which paths and attributes are watched. - Copy the database off the machine -- to the collector VM, or read-only media. State why this matters before continuing.
- Modify a configuration file and a binary. For the binary, append a byte:
printf '\0' >> /usr/bin/sleepon a copy, or use a non-critical binary. - Run
aide --checkand read the report. Confirm both changes are listed, and note the difference in how a config change and a binary change are flagged. - Now demonstrate the flaw: as root, modify a binary AND run
aide --updateto fold the change into the baseline. Runaide --checkagain and confirm it now reports nothing -- the attacker updated the baseline too. - Restore the off-machine database, run
--checkagainst it, and confirm the tampering reappears. - Cross-check with the package manager:
rpm -Vafinds changed package files independently, and a changed binary there is a strong compromise indicator where a changed config file is not.
Verify
aide --check 2>&1 | grep -Ei 'changed|added|removed' | head
rpm -Va | grep '^..5' | head # files whose checksum differs
# after restoring the off-machine db over the tampered one:
aide --check 2>&1 | grep -qi 'changed' && echo "off-machine baseline caught it"
Step 5 is the lesson: an integrity tool whose database lives on the machine it watches can be defeated by the same root that defeats everything else. The off-machine copy in step 6 is what makes it evidence rather than reassurance.
Notes
Take the baseline before the machine is exposed, not after. A baseline built on an already-compromised host records the compromise as normal, after which the tool reports clean forever -- the most comforting possible false negative.