Why a Clean Integrity Check Cannot Clear a Compromised Appliance

The question every appliance incident reaches

When a perimeter appliance has a known exploited zero-day, the first thing most teams want is a yes or no: were we hit? Vendors often provide an integrity checking tool for exactly that moment. It runs on the box, compares system files against a known-good manifest, and reports whether anything has changed. A clean result feels like an answer.

It is only an answer to a narrow question. The Ivanti Connect Secure zero-day CVE-2026-104935 shows why. Volexity reported that Ivanti's Integrity Checker Tool found no modifications on an appliance that was actively compromised. The attack chain patched a shared library in memory and restored the cached configuration it had abused, so nothing on disk differed from the manifest.

What file integrity checking actually proves

An integrity checker answers one question: do the files it knows about match the expected versions? That is valuable. It catches dropped web shells, replaced binaries and modified scripts, which is how many earlier appliance compromises persisted. It does not tell you:

• Whether code is running in memory that was never written to disk.
• Whether a legitimate binary was copied and renamed somewhere outside the manifest.
• Whether configuration data was modified and then changed back.
• Whether credentials stored on the appliance were read.
• Whether the box was used as a pivot into the internal network.

The last two are usually the most damaging, and no on-box file scan can see them. Reading a secret leaves no file change.

Attackers adapt to the check

Integrity checkers are published tools. Anyone who targets an appliance family repeatedly can download one and see exactly what it inspects. Over the past few years, appliance intrusions have moved toward techniques that sit outside that scope: in-memory implants, tools staged in temporary directories and removed after use, and log tampering. In the Ivanti case, Volexity also observed log tampering in the appliance's debug and audit logs, so the logs could not fill the gap either.

This is not a failure of one vendor's tool. Any check that only looks at the disk can be beaten by an attacker who avoids writing to it.

Absence of evidence on a closed system

Most appliances are closed systems. You cannot install your EDR agent, you have limited shell access, and the vendor controls what logging is exposed. That makes the integrity checker one of very few views into the box, which is exactly why it gets more trust than it deserves. A clean scan on a system you cannot otherwise inspect means you saw nothing. It does not mean nothing happened.

What gives you real evidence

To clear an appliance with confidence, combine views that do not depend on the attacker leaving files behind:

• Memory capture. Where the vendor supports it, capture memory before rebooting or patching. In-memory changes are lost the moment the box restarts. Our guide How to Preserve Forensic Evidence on a Network Appliance Before You Patch It covers the sequence.
• Network evidence. Traffic from the appliance to the internal network and to the internet is recorded by systems the attacker does not control. Unusual LDAP queries, Kerberos requests or outbound connections from the appliance's address are strong signals.
• Directory-side logs. If the appliance's service account ran searches it never normally runs, the domain controllers may have recorded it even if the appliance's own logs were wiped. What an Appliance's LDAP Service Account Can Read in Active Directory explains what to look for.
• Request patterns at the edge. A reverse proxy, load balancer or network sensor in front of the appliance can keep request logs that show exploitation attempts.
• Vendor and researcher indicators. Use them, but remember that early in an incident they are incomplete. Ivanti stated that no reliable indicators were available yet when it disclosed this flaw.

The decision you actually have to make

Often you cannot prove an appliance is clean. In that case, the decision is about risk, not evidence. If an internet-facing appliance was exposed during a known exploitation window and you cannot rule compromise out, the safer path is to treat it as compromised. Rebuild it from known-good media, apply the fix, and rotate everything it held or could read. How to Contain Active Directory Exposure After a VPN Appliance Is Compromised lays out that rotation in order.

This costs more effort than accepting a clean scan. It costs far less than finding out months later that the attacker who left no files behind also left with your LAPS passwords and BitLocker recovery keys.

Building it into your plan

Write this into your incident playbook now, before the next appliance zero-day. Decide in advance which evidence sources count, who decides when an appliance is cleared, and what exposure window triggers an automatic rebuild-and-rotate. When the next advisory lands, the team then works the plan instead of arguing over whether a green checkmark is enough.