When the Patch Hasn't Landed Yet: A Defender's Playbook for Edge Appliance Compromises

Guest contribution by Naseem Khan, Technical Editor at UnpanicTech. Edited for clarity and checked against the cited sources by BlueRadius editorial.

Incident responders keep running into the same scenario: an organization discovers its FortiGate or Ivanti appliance was compromised weeks after the fact, and the logs that would have shown when and how the attacker got in have already rotated off. The appliance is patched. The vendor advisory is closed. But the attacker's service-account credentials are still valid in Active Directory, and a rogue workstation enrolled months earlier is still quietly sitting on the domain.

That is the scenario this piece is about: not the moment of the patch, but the days and weeks before it arrives, and the response posture that limits damage when you are operating without the safety net of a released fix.

It draws on documented incident patterns from FortiGate and Ivanti intrusions in 2024 through 2026, and it is written for teams with real work to do, not for a 40-person SOC. The assumptions: you have some centralized logging, a small team, and a vendor advisory in your inbox that has not been accompanied by a patch yet.

1. The fog of disclosure: what "exploitation" means right now

When a vendor publishes an advisory for a critical edge appliance flaw, the language around exploitation status blurs fast. The advisory says "we are aware of reports of exploitation." A news article says "actively exploited in the wild." A Mastodon post says a proof of concept is already circulating. By the time your team reads the advisory, you may have no idea which of those is true, and the distinction matters for how urgently you need to act.

These terms are not interchangeable, and it is worth pinning them down before you make triage decisions:

• Vulnerability disclosed: a flaw has been described publicly. No exploitation implied.
• Proof of concept exists: someone has demonstrated the vulnerability works, usually a researcher. Not a deployed attack.
• Public exploit: working exploit code is available, on GitHub, ExploitDB or a forum. This changes your timeline materially, because opportunistic actors can now use it without much skill.
• Exploitation observed: a credible organization (an MSSP, a threat intelligence firm, an IR team) has seen it used against real targets. This is the line where "possible" becomes "happening."
• Active exploitation, CISA KEV listing: the evidence is sufficient for CISA to add it to the Known Exploited Vulnerabilities catalog, or a major authoritative source is documenting ongoing campaigns.

The practical problem is that vendors rarely say which of these they mean, and they have obvious incentives not to alarm customers before a patch is ready. Embargo leaks, where a researcher quietly tells a few IR firms about a flaw before the vendor is ready to disclose, mean some exploitation is already under way while the public advisory is still in draft. That happened with several Ivanti vulnerabilities in 2024 and again with FortiGate in 2025 and 2026, as SentinelOne's March 2026 intrusion report documents (SentinelOne).

Speculative chatter is a separate problem. When a major vendor drops an advisory for a critical pre-auth flaw, social media fills with "this is being mass-exploited" claims, sometimes before any credible evidence exists. Some of that chatter turns out to be right, but reacting to every post burns team capacity on false alarms.

A workable heuristic for lean teams: treat "proof of concept exists and no patch" as a credible threat that requires active pre-patch detection work, regardless of whether exploitation has been confirmed. The gap between proof of concept and active exploitation on edge devices has compressed sharply over the past two years (Trend Micro). Waiting for a confirmed KEV listing before acting is waiting too long.

The more disciplined question is which exploitation-status source you trust, and whether you have read the primary source rather than a headline summary. CISA advisories, vendor PSIRTs, and IR firms that publish detailed findings (SentinelOne, Mandiant, Volexity, Wiz Research) are the anchors. News aggregators and security social media are leads, not evidence.

2. High-priority telemetry: what to pull before it disappears

One finding that comes up repeatedly in published FortiGate incident reports is blunt: insufficient log retention on the appliance meant investigators could not determine the initial access vector (SentinelOne). Edge devices, firewalls, VPN concentrators and SSL gateways have limited onboard storage. When logs fill up, older entries disappear. In a real intrusion, the most forensically valuable events (the initial login, the configuration export, the first admin account creation) are exactly the ones most likely to be gone by the time anyone looks.

The table maps what to collect immediately and why each source matters. The FortiGate log IDs and the Windows event IDs are the ones cited in SentinelOne's report.

Log source	What to pull	Why it matters
Appliance admin and auth logs	Admin login events (FortiGate log ID 0100032001), failed logins, account creation events (log ID 0100044547), password changes	Reveals unauthorized admin logins, rogue account creation and SSO abuse. These are the first artifacts investigators look for, and the first to rotate off.
Configuration export logs	FortiGate log ID 0100032095 (config file downloaded). Any CLI audit showing show full-configuration or backup exports outside maintenance windows.	In documented FortiGate intrusions, attackers extract the config file to obtain encrypted LDAP and AD service-account credentials. The timestamp of this event anchors the whole compromise timeline.
VPN session logs	SSL VPN tunnel establishment (FortiGate log ID 0101039424), tunnel teardown, source IPs (the remip field), assigned internal VPN addresses, session durations	Lets you correlate the attacker's external source IP with their internal VPN-assigned IP, which is how you link appliance access to the authentication events that follow on the domain controllers.
Domain controller authentication logs	Windows event IDs 4624 (logon), 4625 (failed logon), 4741 (computer account created), 4728 and 4732 (group membership changes). Specifically, logons originating from the VPN IP range.	In the first SentinelOne incident the attacker used stolen LDAP credentials to join rogue workstations to the domain (event 4741). Correlating the subject security ID on those events to the FortiGate service account confirms the chain.
Firewall policy change audit logs	Rule additions, zone-to-zone policy changes (source all, destination all is a red flag), changes to management access lists	Attackers in documented intrusions created permissive firewall policies right after gaining access, before pivoting internally, to keep their access. These changes are almost always anomalous.
DNS registration logs	DNS Server audit log event 515 (record create), the Microsoft-Windows-DNSServer analytical log (client IP and query name)	Rogue domain-joined workstations register DNS records. The analytical log captures the internal VPN IP of the client that registered the record, connecting appliance access to the domain join.

The single highest-leverage action is forwarding appliance logs to a SIEM or syslog aggregator in real time, before a suspected incident. Once an attacker has access they may clear local logs, but they cannot reach what has already been forwarded off the device (Moxfive). SentinelOne's DFIR team puts the floor at 14 days of retention on next-generation firewall appliances, with 60 to 90 days materially better for an investigation.

If you are reading this after a suspected compromise and have not forwarded logs, pull what is still on the device now. Do not reboot, do not patch, do not factory reset until you have exported what is there. A preservation-first approach, a configuration backup with a hash, a session log export and chain-of-custody notes before any remediation step, is the difference between a complete IR picture and a permanent blind spot.

3. Pre-patch anomaly checks: what a lean team can look for right now

You do not need a 24-hour threat hunting team to run useful detection checks before a patch lands. You need a small set of targeted questions, an understanding of what normal looks like on your specific appliance, and a few hours of focused attention.

The checks below are drawn from documented post-exploitation patterns in Ivanti Connect Secure and FortiGate intrusions: the artifacts investigators found most reliably across multiple incidents.

Web shells in CGI and API paths

Web shells planted in appliance CGI paths are a consistent post-exploitation technique. The attackers' approach is usually to modify a legitimate file the web server already executes, rather than drop an obviously named new file. On Ivanti Connect Secure, CISA's advisory documents LIGHTWIRE and CHAINLINE, both of which lived in modified copies of compcheckresult.cgi, and BUSHWALK, another web shell embedded in a legitimate appliance component (CISA AA24-060B).

What this means practically: your integrity check should focus on recently modified files in web server directories, not just new files. The modification timestamp on a legitimate-looking file, combined with unexpected Perl imports or encoded execution stubs, is the tell. The RESURGE implant found on appliances compromised through CVE-2025-0282 went further and tampered with the appliance's integrity manifest, so the vendor's built-in integrity checker returned a clean result on a compromised device (Picus Security). External integrity verification matters more than the appliance's self-check.

On FortiGate, the equivalent check is the admin account list: look for accounts outside your authorized set, particularly generic names like ssl-admin, support and cloud-init, all of which appeared in documented intrusions. Then review firewall policies for any rule with source all and destination all that your team did not create.

Atypical outbound traffic

One of the harder detection problems is that some implants are designed to avoid generating outbound traffic. RESURGE does not beacon; it embeds in the appliance's native web process and activates only when it receives specially crafted inbound TLS traffic. Network monitoring that looks for beaconing will not catch it.

Post-exploitation activity usually does generate outbound traffic eventually. In the second FortiGate incident SentinelOne describes, the attacker downloaded remote management tools (Pulseway, MeshAgent) from cloud storage URLs, used PowerShell to pull additional payloads, then established command and control on port 443 to a Cloudflare address.

The checks worth running now:

• Outbound connections from appliance management IPs or VPN-assigned IPs to storage services (S3 hostnames, storage.googleapis.com) that are not part of your normal vendor update traffic.
• Internal hosts downloading executables with PowerShell Invoke-WebRequest from cloud hosting URLs. This was the download vector in the documented case.
• Remote management tools (Pulseway, MeshAgent, AnyDesk, ScreenConnect) that do not correspond to your own IT tooling. The SystemComponent=1 registry value, which hides an application from Programs and Features, is a specific indicator from the SentinelOne report.
• C:\ProgramData\USOShared used as a staging location. It was used for attacker tools in the documented FortiGate intrusions.

Suspicious CLI execution on the appliance

Audit logs that capture CLI commands, specifically show full-configuration, bulk configuration exports or backup downloads outside normal maintenance windows, are a significant red flag. On FortiGate, log ID 0100032095 captures configuration file download events. If it appears in your logs and does not correspond to a known admin action, treat it as a confirmed credential-extraction event, not a suspicious one. The timeline in SentinelOne's second incident was stark: within ten minutes of creating a local account on the FortiGate, the attacker had authenticated to multiple servers with domain administrator credentials.

4. Containment and verification

The mistake teams make most often is treating remediation as a linear checklist: patch the appliance, reset the VPN accounts, done. The incidents documented in 2025 and 2026 break that assumption. Attackers used the appliance not just as a foothold but as a key to Active Directory, and credential artifacts from a compromised appliance persist long after the appliance itself is remediated.

The FortiBleed exploitation wave of June 2026 is the clearest recent example: the Cloud Security Alliance's research note on it describes attackers harvesting credentials from compromised Fortinet environments at scale, and CISA's emergency guidance ordering session termination, credential rotation, MFA enforcement and the removal of management interfaces from the public internet (Cloud Security Alliance). Rotating only VPN credentials misses the scope of what has potentially been exposed.

Containment steps

Restrict management access immediately. If a patch is not available, the first containment action is limiting exposure of the management interface. Remove FortiGate management and SSL VPN from public internet access wherever operationally feasible. For Ivanti, Palo Alto GlobalProtect and similar appliances the principle is the same: the management plane should not be reachable from untrusted networks.

Terminate active sessions. Force termination of all active VPN and administrative sessions. Stolen credentials could be in use right now.

Credential cycling, wider than you think

The scope of credential rotation after an edge appliance compromise is broader than most teams first consider. At minimum:

• Rotate all local appliance administrative accounts.
• Rotate all VPN user credentials.
• Rotate the LDAP or AD service account the appliance uses (the fortidcagent account on FortiGate, or its equivalent). It is stored in the device configuration, it can be decrypted from a stolen config file, and it is one of the primary targets in documented intrusions.
• Rotate any other service account whose credentials appear in the appliance configuration: RADIUS, LDAP, NTP authentication, syslog credentials.
• If packet capture or credential harvesting is suspected or confirmed, treat all Active Directory accounts as potentially exposed. That means domain administrator accounts, the Kerberos ticket-granting ticket (krbtgt) keys, and potentially every user password, depending on the scope of what was observed. This is a large operation and needs to be coordinated, not rushed, or you lock out your own workforce.

Check the CISA advisory for the specific flaw. For Ivanti Connect Secure, CISA noted that base64-encoded plaintext AD passwords and NTLM hashes for active and recently active sessions can be harvested from backup databases on the appliance (CISA AA24-060B). That is a qualitatively different exposure from VPN credentials alone.

Persistence verification

Post-patch, and before returning the appliance to normal service, run through these specifically:

• Audit all local admin accounts on the appliance against your authorized list and remove any account not on it. Watch for the generic names (support, ssl-admin, cloud-init) used in documented intrusions.
• Audit firewall policies for rules with source all and destination all that your team did not create.
• Search Active Directory for rogue computer objects using the mS-DS-CreatorSID attribute. If several rogue computers share the creator SID of the LDAP service account, that is a confirmed indicator. By default a standard account can join up to ten machines to the domain (ms-DS-MachineAccountQuota), so look for computer objects missing expected service principal names and created outside known provisioning windows.
• Audit for remote management tools not in your asset inventory, and check Windows scheduled tasks for unfamiliar names. A tool hidden with SystemComponent=1 will not appear in a standard software audit.
• Check for web shells in CGI directories on the appliance. On Ivanti, focus on recently modified .cgi and .py files in the web server document root, and do not rely on the vendor's built-in integrity checker when the documented implant for your CVE is known to tamper with it.

Removing the accounts the attacker created is not the end of it. If other persistence mechanisms were established, the environment is still compromised, and finding them is a search, not a checkbox.

What this adds up to

The structural problem with edge appliances is that they sit at the most exposed position on the network, they usually cannot run EDR, they often ship with weak log retention, and they hold credentials to exactly the systems attackers want to reach. That combination makes them a category-one target, and the exploitation patterns from 2024 through 2026 reflect it.

None of these four sections requires a large team or advanced tooling. They require acting early: before logs rotate, before speculative chatter hardens into confirmed exploitation, and before a patch is treated as the end of the response rather than the start of verification. The organizations that got ahead of this were mostly the ones where someone asked "what if we are already compromised?" instead of "when do we have to patch by?"

Keep the primary sources close. Vendor PSIRTs, CISA advisories and detailed IR reports from firms that publish their findings are worth reading properly, not just the headline.

If your team wants to rehearse this before it happens, our guide to incident response tabletop exercises covers how to run a drill around exactly this scenario, and our managed security services page describes the log forwarding and detection coverage BlueRadius runs for clients.

Sources

1. SentinelOne, FortiGate Edge Intrusions: Stolen Service Accounts Lead to Rogue Workstations and Deep AD Compromise, March 2026.
2. CISA and ACSC, Advisory AA24-060B: Threat Actors Exploit Multiple Vulnerabilities in Ivanti Connect Secure and Policy Secure Gateways, 2024.
3. Picus Security, RESURGE Malware Exploits Ivanti Connect Secure CVE-2025-0282, 2025.
4. Cloud Security Alliance, FortiBleed: Default Credential Exploitation and Mass Fortinet Compromise, June 2026.
5. Trend Micro, Edge Under Siege: How State-Sponsored Actors Exploit Your Perimeter, 2026.
6. Moxfive, Logging to Enable Forensics, 2026.

Naseem Khan is Technical Editor at UnpanicTech, which publishes vulnerability triage and defensive containment notes. Views are the author's own.