How to Detect Unauthorized File Changes on a Hardened Appliance

When a vendor publishes indicators of compromise for an actively exploitedActively Exploited🛡️A vulnerability that attackers are currently using in real-world attacks, requiring immediate patching regardless of severity score. flaw, as Fortinet did for the FortiMail zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. CVE-2026-104286, the list almost always includes added or modified files. For that August advisory the artifacts were a dropped `liblog.so`, a tampered `ld.so.preloadld.so.preload🛡️A Linux file read by the dynamic linker that lists shared libraries to load into every dynamically linked process before any other library. Designed for legitimate interposition, it is a favored persistence mechanism: writing a path into it forces attacker code to load into processes system-wide, including root-owned ones.`, altered `httpd.conf` and `smit`, and new binaries under `/data/bin`. Checking a handful of named hashes is easy. The harder and more valuable question is: could you have detected those changes before the vendor told you what to look for? That is what file integrity monitoring answers, and on a locked-down appliance it takes a different approach than on a server you fully control.

Why appliances resist ordinary monitoring

A general-purpose server lets you install an agent, run `aide` or `tripwire`, and schedule integrity scans. A sealed appliance usually does not. You may have no shell beyond a restricted CLI, no package manager, and no way to run your own binary on the box. Vendors design them this way deliberately, which means your integrity monitoring has to work from the outside or from whatever limited facilities the appliance exposes. The goal is unchanged: establish what "known good" looks like, then detect any drift from it. The methods adapt to the constraints.

Establish a baseline first

Integrity monitoring is worthless without a trustworthy baseline, and the baseline must be captured when you have reason to believe the system is clean. The best moment is immediately after a fresh install or upgrade, before the appliance is exposed to traffic. Record what you can:

• **FirmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. or software version and build**, so you can compare against the vendor's published hashes for that release.
• **Hashes of any files you can read**, whether through a diagnostic CLI, a support bundle, or a configuration export.
• **The running configuration**, exported in full, including accounts, admin users, logging destinations, and any archive or forwarding rules.

The configuration matters as much as the files. In the FortiMail intrusions, one of the clearest signals was not a binary at all but an added archive account pointed at an external IP. A config you captured when the box was clean turns that into an obvious diff.

Watch the bridges, not everything

You cannot hash a filesystem you cannot reach, so focus on the locations where a written file turns into running code or changed behavior. These are the same bridges an attacker aims for: the dynamic linker's preload file, web roots and script directories, scheduler and startup files, and the configuration of privileged daemons. If the appliance gives you any way to read those specific paths, a periodic check of them is far higher signal than a broad scan. A change to `ld.so.preload` on a device that has not been upgraded is not ambiguous; it is an incident. This is the detection side of the mechanism explained in How an Arbitrary File WriteArbitrary File Write🛡️A vulnerability class in which an attacker controls both the contents and the destination path of a file written by a target system. On a general-purpose OS it is usually equivalent to code execution, because files written to certain locations are loaded or run automatically. Becomes Code Execution Through ld.so.preload.

Use the facilities the appliance does give you

Even sealed systems usually offer something you can turn into integrity signal:

• **Support or diagnostic bundles.** Many appliances can generate a bundle that includes file listings, hashes, or configuration dumps. Pull one on a schedule and diff successive bundles.
• **Centralized, off-box logging.** Ship logs to a collector the appliance cannot reach back into. The FortiMail IoCs included specific log lines, such as the creation of the `archive234` account and anomalous admin logouts. If those logs live only on the box, an attacker with root can edit them; off-box they become durable evidence.
• **Configuration backups.** Automate a config export to external storage and diff each new export against the last. Unexpected accounts, logging destinations, or forwarding rules surface immediately.
• **External behavioral signals.** Outbound connections from a management appliance to an unknown host, like the FortiMail exfiltration to a remote IP, are visible at your firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. or netflow even when the box itself is opaque.

Make the signal survive a compromise

The core design principle is that your integrity evidence must live somewhere the monitored system cannot silently alter. Anything stored only on the appliance is suspect the moment the appliance is suspect, because root can rewrite it. Off-box log collection, externally stored configuration backups, and network-level observation all satisfy this. Hashes you recorded on a separate system and compare by hand satisfy it too. The question to ask of every control is: if this box were fully owned right now, would this evidence still be trustworthy? If the answer is no, move the evidence off the box.

Turn detection into a decision

Detection is only useful if it drives action, so decide in advance what a positive finding means. For a management appliance, an unexplained change to a bridge file or an unknown account should trigger the same response as a confirmed breach: isolate the device, preserve evidence per the vendor's forensic guidance, and rebuild rather than clean. Trying to surgically remove an implant from an appliance you do not fully control is a losing game. This connects integrity monitoring to the broader containment playbook in How to Check an Email Security Gateway for Compromise After a Zero-Day, and to the planning that should happen before an incident, covered in Why Disabling a Feature to Dodge a Zero-Day Is a Business Decision. The appliances that caught the FortiMail intrusions early were the ones already watching their own bridges, not the ones that waited for a hash list to appear in an advisory.