Systemd Path Activation - Poor Man's File Integrity

What it is

A DFIR.ch walkthrough for using systemd path units as lightweight file-integrity monitoring on Linux hosts where EDR isn't an option. The worked example watches ~/.ssh/authorized_keys and fires a canary-token DNS lookup when the file is written and closed.

How it works

Two paired unit files in /etc/systemd/system/, sharing a base name so systemd auto-links them. canary.path watches the target; canary.service runs the script:

# canary.path
[Path]
PathChanged=/home/malmoeb/.ssh/authorized_keys
Unit=canary.service
[Install]
WantedBy=multi-user.target

# canary.service
[Service]
Type=simple
ExecStart=/home/malmoeb/canary.sh

The script is a single DNS lookup against a canarytokens.com subdomain, which triggers an out-of-band email alert:

#!/bin/bash
host me0nurs7zu15y[..].canarytokens.com 8.8.8.8

PathChanged= triggers on write-and-close. The post also names other directives worth knowing for different detection shapes:

• PathExists= / PathExistsGlob= — file/glob appearing
• PathModified= — fires on writes without waiting for close
• DirectoryNotEmpty=

What to do

Enable and start both units (enabling the .path, not the .service):

$ sudo systemctl enable canary.{path,service}
$ sudo systemctl start canary.path

Test by writing to the monitored file and confirming the service ran and the alert fired:

$ echo "dfir.ch" >> /home/malmoeb/.ssh/authorized_keys
# systemctl -l status canary.service

Adapt PathChanged= to any critical file or directory. Choose PathModified= over PathChanged= if you need to catch writes that never cleanly close.

Caveats

This is detection, not prevention — it alerts after the change, it does not block it. As written, the response action is a canary-token DNS lookup, so it depends on outbound DNS reaching the internet and on the token infrastructure being reachable; an attacker who blocks egress or removes the units first defeats it. The units themselves live in a predictable location and offer no tamper protection.