Baseline a system and catch a tampered binary

short · 30 min · Objective 3.6

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

  1. Understand what the baseline captured: aide --config-check and a look at /etc/aide.conf for which paths and attributes are watched.
  2. Copy the database off the machine -- to the collector VM, or read-only media. State why this matters before continuing.
  3. Modify a configuration file and a binary. For the binary, append one byte to something nothing critical depends on -- printf '\0' >> /usr/bin/sleep leaves it runnable, since an ELF file ignores trailing data, but changes its hash.
  4. Run aide --check and read the report. Confirm both changes are listed, and note the difference in how a config change and a binary change are flagged.
  5. Now demonstrate the flaw: as root, modify a binary AND fold the change into the baseline the way an attacker would. aide --update writes the new baseline to /var/lib/aide/aide.db.new.gz and leaves the one --check reads untouched, so on its own it hides nothing -- the attacker also runs mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz, exactly as you did after --init. Run aide --check again and confirm it now reports nothing: the attacker updated the baseline too.
  6. Copy the off-machine database back over /var/lib/aide/aide.db.gz, run --check against it, and confirm the tampering reappears -- both binaries, and the configuration file from step 3.
  7. Cross-check with the package manager: rpm -Va finds 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.

This is an independent study companion for CompTIA Linux+ and is not produced by or endorsed by CompTIA.