The paths that actually matter
Watching the whole filesystem produces noise proportional to how busy the server is. A useful configuration concentrates on the places where compromise has to leave a mark.
- Authentication and accounts: /etc/passwd, /etc/shadow, /etc/group and /etc/gshadow, where a new user or a changed privilege shows up.
- SSH: /etc/ssh/sshd_config and its drop-in directory, plus authorized_keys files, where persistent access is granted.
- Scheduled execution: /etc/crontab, /etc/cron.d and per-user crontabs, plus systemd units and timers.
- Privilege: the sudoers configuration, setuid binaries, and preload files such as ld.so.preload.
- Name resolution: /etc/hosts and /etc/nsswitch.conf, which are quietly effective redirection targets.
- Web content: served directories, where webshells and injected scripts land, including WordPress core, plugins and themes.
Expected change versus suspicious change
This is the entire problem. A routine apt upgrade rewrites a large number of files in a burst, all of them legitimate. A configuration management run does the same. If every one of those is an alert, the signal is buried within a week and the system is switched off shortly after.
Useful discrimination comes from context rather than from the change itself: whether the change coincided with a package operation, whether the file is one that legitimately changes, whether it arrived alongside other suspicious activity such as a new process or an SSH login from an unusual address.
This is where SecAI leans on correlation. A modified sshd_config on its own is worth knowing about. A modified sshd_config twenty seconds after a successful login from an address that had been failing repeatedly is an incident.
What FIM catches that nothing else does
Its particular value is persistence. An attacker who gains access wants to keep it, and keeping it almost always means writing something: a key, a cron entry, a unit file, a modified binary.
That is also why it is the piece that makes cleanup succeed. Removing a webshell without finding the cron entry that restores it produces a server that is compromised again in days, and file monitoring across the persistence paths is how the second half gets found.
What a finding carries
A change is reported with the path and the hash before and after. For the persistence files, the cron entries, sudoers and its drop-ins, an authorized_keys file, a systemd service or timer, the text before and after the change travels with it, within a small size limit and never for a binary file, so the new cron line or the new key is read in the alert rather than guessed at. A restart is not a change: the first time the agent sees a file it records the hash and reports nothing.
A package update is not an intrusion
The classic failure of file integrity monitoring is reporting a routine update as a compromise. SecAI checks the two places where an update most resembles an attack against the package manager's own record: a privileged binary, one with setuid, setgid or a capability, that changed is cleared when dpkg -V or rpm -V vouches for the new file, and an account created by a package is rated low when the package that declared it still verifies, and medium again if that account has a login shell, a home directory or a key. Changes to the watched configuration files are reported with the context around them: the interactive session they happened inside, if any, and what else happened on the server at the time.
SecAI's own changes are not intrusions either. A hardening fix it applies keeps a copy of every file it touches on the server and is recorded as SecAI's change with its own Undo, so the monitor never reports SecAI as the intruder. The agent watches its own service unit for tampering and reports the text before and after any edit to it, which is also why its survival settings live in a separate drop-in rather than in the unit.
Quarantine, restore, never delete
When a file in a web root matches a web-shell rule, it is flagged with a 200-byte excerpt and screened automatically, and the proposed action is quarantine: the file is made unreadable in place, owned by root, never deleted and never moved. Quarantine always waits for a person, even when a person asked for it, because an excerpt is enough to recognise something and not enough to prove it. Restore never needs approval and refuses only if the file changed after quarantine, because a later edit is somebody's work. SecAI never rewrites or cleans application files.
WordPress and web content
On a server hosting websites, the web root is where compromise usually becomes visible first. SecAI covers WordPress core, plugin and theme files specifically, which matters because those have a knowable expected state: core files should match the released version, and a modified core file is unambiguous in a way that a modified application file is not.
Automated WordPress file integrity monitoring is included on the Pro plan and above.
The audit trail
Because changes are recorded with what changed and when, the history is usable as evidence: a timeline of modifications to sensitive files, rather than an assertion that monitoring exists. That history feeds the compliance reports, which support an audit programme without claiming to constitute compliance by themselves.