Systemd Path Activation - Poor Man's File Integrity

Table of Contents

This blog post outlines a method for monitoring changes to files and directories in Linux using path units. Administrators and defenders can be notified of modifications by creating a new path unit, which watches for changes to files and directories and links it to a service unit that executes a script when changes are detected. This setup might be particularly useful for detecting unauthorized access in environments where installing EDR solutions is not feasible.

Introduction

As written on the RedHat website, with path units, you can monitor files and directories for events and use them to execute service units. Further: With path units, you can monitor files and directories for certain events. If a specified event occurs, a service unit is executed, and it usually carries the same name as the path unit.

For demonstration purposes, we built a little detection script that triggers when the content of the SSH authorized_keys file within a specified user’s home folder is modified. But in theory, this could be a file or directory deemed critical and must be observed for modifications.

The path unit: canary.path

We create a new path file and place it in the directory /etc/systemd/system/. We named the file canary.path with the following content:

[Unit]
Description=Monitors the authorized_key file for changes

[Path]
PathChanged=/home/malmoeb/.ssh/authorized_keys
Unit=canary.service

[Install]
WantedBy=multi-user.target

In the [Path] section, PathChanged= specifies the absolute path to the file to be monitored, while Unit= indicates which service unit to execute if the file changes. Source: RedHat

The service unit: canary.service

Following the corresponding service unit named canary.service, which also we placed inside the folder /etc/systemd/system/. If the file authorized_keys (in my user home) changes (written AND closed), the following service unit will be called to execute the specified script (in our case, /home/malmoeb/canary.sh):

[Unit]
Description=Executes the canary script when the authorized_key changes

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

[Install]
WantedBy=multi-user.target

In this example, the file canary.sh contains only one line, a simple lookup for a canary token subdomain:

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

I’ve written a comprehensive blog post about canary tokens and will not go into details here. Please read the corresponding blog post here for further insights.

Testing

We must enable (and activate) our newly created path and service files to keep the file monitoring alive.

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

We write some content into the authorized_keys file, but in practice, this would be, of course, the public key of the attacker to gain SSH access to the compromised server:

$ echo "dfir.ch" >> /home/malmoeb/.ssh/authorized_keys

According to the logs, the canary path service was executed, and indeed, we received an email shortly notifying us that the authorized_keys file had changed (truncated output).

# systemctl -l status canary.service
systemd[1]: Started canary.service - Executes the canary script when the authorized_key changes.
canary.sh[139235]: Using domain server:
canary.sh[139235]: Name: 8.8.8.8
canary.sh[139235]: Address: 8.8.8.8#53
canary.sh[139235]: Aliases:
canary.sh[139235]: me0nurs7zu15y[..].canarytokens.com has address 52.18.X.X

canary token

Figure 1: Canary Token Alert

Despite PathChanged, according to the man page, there would be more options for monitoring files, like:

  • PathExists=
  • PathExistsGlob=
  • PathModified=
  • DirectoryNotEmpty=

This technique might help build a monitoring system for critical files and folders if the installation of an EDR is not possible for whatever reason. Another way to catch an attacker :)