Plant a honeyfile and prove the alert fires

short · 35 min · Objective 1.2

Task

Place a decoy file on your own lab VM, wire an audit rule to it, and prove that touching it produces a high-confidence alert — then confirm that ordinary work elsewhere on the machine produces none.

Steps

  1. Create the decoy where an intruder would look and a colleague would not: sudo mkdir -p /srv/finance && printf 'acct,sortcode\n00000000,00-00-00\n' | sudo tee /srv/finance/payroll_2026.csv >/dev/null.
  2. Add an audit rule watching reads and writes: sudo auditctl -w /srv/finance/payroll_2026.csv -p rwa -k honeyfile.
  3. Generate the event: sudo cat /srv/finance/payroll_2026.csv >/dev/null.
  4. Read a normal file for comparison — cat /etc/hostname >/dev/null — so you can show the rule is specific rather than noisy.
  5. Search the audit log for the key: sudo ausearch -k honeyfile.
  6. Write one sentence in /tmp/honeyfile.md stating what control TYPE this is and why its false positive rate is near zero.

Verify

sudo auditctl -l | grep -c honeyfile
sudo ausearch -k honeyfile 2>/dev/null | grep -c 'type=SYSCALL'
sudo ausearch -k honeyfile 2>/dev/null | grep -c 'etc/hostname'
grep -icE "detective" /tmp/honeyfile.md

The first must be at least 1 — the rule is loaded. The second must be at least 1 — the access was recorded. The third must be 0: the unrelated read did not match, which is what makes this signal worth alerting on. The fourth must be non-zero; a honeyfile is a detective control and calling it preventive is the error the lesson warns about.

Notes

auditctl rules do not survive a reboot. Putting it in /etc/audit/rules.d/ makes it persistent, and that difference — a control that is present now versus a control that is enforced — is the configuration enforcement point from Domain 2 in miniature.

This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.