Patched is not the same as clean.

Collect before you change anything

Patching often means a reboot. On an appliance, a reboot can clear in-memory state and rotate local logs. Before the change window, take what you will want later:

• A configuration export, with a timestamp.
• The device or server logs for the whole window below, copied off the box.
• The list of local accounts, API tokens and SSH keys.
• A file listing of the web root, plugin and upload directories with modification times, for server applications.
• Whatever the vendor's support bundle or diagnostic export contains, if the product has one.

If you find something later, these are what tell you how long it was there.

Which window to search

The date a CVE was added to KEV is the date CISA had evidence and a fix to point at. Exploitation usually started earlier. Pick the start of your window in this order:

1. The earliest exploitation date in the vendor advisory or the CISA alert, if either gives one.
2. The date the vulnerable build went onto an exposed device.
3. If neither is known, several weeks before the KEV date. Widen it as soon as you find anything.

What to look for

These are categories, not signatures. They hold across vendors because they are what an intruder needs to stay.

Area	Question
Accounts	Any admin, local user, API token or SSH key created or changed in the window that you cannot tie to a ticket?
Configuration	New VPN profile, new authentication source, changed SAML settings, a new forwarding or NAT rule?
Files	New or changed script files in web-served directories, written by the service account?
Persistence	New scheduled tasks, cron entries, services, startup items or plugins?
Network	Outbound connections from the device or server to addresses it has never talked to?
Credentials	The device's service accounts logging in somewhere else, from an address that is not the device?

For server applications, the process-tree check in A web server should not start a shell covers the moment a foothold gets used.

Vendor integrity tools are evidence, not proof

Some vendors publish a checker for their appliances. Ivanti, for example, ships an Integrity Checker Tool for Connect Secure. Use the vendor's tool, not a script from a forum, and run it before and after the patch.

Then treat a clean result as one input. In early 2024, CISA reported that integrity checks on running Ivanti gateways did not always detect compromise. A tool running on a box the attacker controls has limits.

Rebuild or clean

Rebuild from a vendor image, then restore a configuration you have reviewed line by line, when any of these is true:

• The row has the triage flag, the device was exposed during the window, and you found anything at all.
• You cannot get trustworthy logs for the window.
• The vendor's own guidance says to reset.

Whichever you choose, rotate what the box held: service account passwords, directory bind credentials, certificates and private keys, local admin passwords, and the session secrets that sign user cookies. Rotation is cheap compared with finding out later that the old key still works.

Write it down

Five lines are enough, and they save the next person a week:

• Build before and after, and the date of each.
• Window searched, and why that start date.
• Sources read: which logs, which tool, which version of the tool.
• Findings, including "nothing found in X".
• What was rotated, and what was not.

Sources

• CISA Known Exploited Vulnerabilities catalog
• CISA advisory AA24-060B on Ivanti Connect Secure and Policy Secure
• Heldnote · Thirteen of thirty-eight rows are boxes at the edge