How to Check If Your Firewall Was Compromised Before You Patched It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
When CISA adds a firewall CVE to the Known Exploited Vulnerabilities catalog, the guidance is always 'patch immediately.' What comes after patching is rarely explained: you need to determine whether the vulnerability was exploited against your device before you closed it.
Patching closes the door. It does not evict anyone already inside. Mandiant's post-incident analysis of Ivanti CVE-2024-21887 found that 30% of organizations that patched still had active webshells: installed before the patch, surviving through it. The same pattern applies to Fortinet, Check Point, and PAN-OS incidents.
This checklist covers the four artifact categories that matter most and the vendor-specific locations to check for each.
The Four Artifact Categories to Check
Regardless of vendor, a successful pre-patch exploitation typically leaves evidence in four categories. Check all four before declaring clean.
1. Authentication log anomalies during the exploitation window: Authentication events from unexpected IPs, unusual hours, or unknown user agents in the period between the CVE's public disclosure and your patch application date. This window is your exposure window. Attackers exploiting zero-days often move within 24-72 hours of disclosure.
2. Unauthorized administrative accounts: New local admin accounts created after initial compromise are how attackers maintain access after the vulnerability is patched. A new admin account survives patching, firmware upgrades, and factory resets unless explicitly removed.
3. Configuration changes: Modified routing rules, new VPN tunnels, added firewall rules permitting unexpected traffic, or changed authentication settings that create a persistent backdoor access path.
4. Webshell or dropper artifacts in web-accessible directories: These are executable files (PHP, Perl, Python scripts, compiled binaries) dropped by attackers to maintain persistent remote code execution. They survive patching and often survive reboots unless explicitly removed.
Fortinet FortiGate and FortiOS
Recent critical CVEs include FortiOS SSL-VPN path traversal (CVE-2022-42475), credential exposure (FortiBleed, 2024), and authentication bypass chains.
Check authentication logs:
get log memory filter
get log memory raw-filter
execute log filter category 0
execute log filter device disk
execute log filter severity information
execute log display
Look for failed authentication attempts followed by success from unexpected IPs, and for API authentication using the FGFM protocol from external addresses.
Check for unauthorized admin accounts:
get system admin
Compare the output against your known administrator list. Any account you did not create is attacker-created persistence. Pay attention to accounts with accprofile super_admin that were added in the exploitation window.
Check configuration change history:
get system log history
Look for configuration commits during off-hours or from administrative IPs you do not recognize.
Check for file artifacts:
SSL-VPN webroot on older FortiOS versions is at /var/www/sslvpn/ and /migadmin/. Post-exploitation webshells in reported incidents appeared as .php files with randomized 8-character names. Compare file modification times against the exploitation window.
Fortinet-specific persistence: CISA advisory AA24-087A documents attackers modifying the crontab on compromised FortiGate devices. Check /var/spool/cron/crontabs/ for unexpected entries.
Artifacts that survive reboot: Admin account changes, configuration changes, crontab entries, and files in persistent storage (/data/, /opt/) survive reboots. Files in /tmp/ do not.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Palo Alto Networks PAN-OS and GlobalProtect
The most significant PAN-OS exploitation in recent years involved CVE-2024-3400 (command injection via GlobalProtect cookie) and CVE-2026-0257 (authentication bypass).
Check GlobalProtect auth logs:
Log into the web UI and navigate to Monitor > Logs > System. Filter by subtype eq vpn and review the exploitation window. Look for authentication attempts using the SESSID cookie parameter manipulation pattern documented in the CVE-2024-3400 technical analysis: specifically, shell metacharacters in the user-agent or cookie fields.
Check for admin account changes:
show admins all
show config running | match admin
Compare against your admin baseline. New accounts with type superuser are the highest concern.
Check commit history:
show config audit-log direction forward
This shows all configuration commits with admin user, source IP, and timestamp. Commits from unexpected users or IPs during the exploitation window are indicators.
Check for webshell artifacts:
CVE-2024-3400 exploitation placed shell scripts in /var/appweb/htdocs/global-protect/. On GlobalProtect devices, check:
find /var/appweb/htdocs -name "*.php" -newer /etc/paloalto/configd/configd.service
find /opt/pancfg/mgmt -name "*.py" -newer /etc/paloalto
Any unexpected file modification times in these directories during the exploitation window is a confirmed indicator.
Palo Alto's verification tool: For CVE-2024-3400, Palo Alto released a Threat Prevention signature (Threat ID 95187) and a detailed remediation guide including a script to check for exploitation artifacts. Use the vendor-provided verification tool first.
Ivanti Connect Secure and Policy Secure
Ivanti CVEs including CVE-2023-46805, CVE-2024-21887, and CVE-2024-21893 were mass-exploited with webshell deployment. Mandiant confirmed 30% of patched organizations still had active webshells.
Use Ivanti's Integrity Checker Tool (ICTool) first: Ivanti released an Integrity Checker Tool specifically designed to detect compromise artifacts on Connect Secure devices. Run this before doing manual checks. The tool checks file hashes against known-good baselines and reports modifications. Download it from Ivanti's security portal.
Manual webshell check: Webshells from the CVE-2023-46805/21887 campaigns were placed in web-accessible Perl and Python file locations:
/home/webserver/htdocs/
/home/webserver/htdocs/dana-na/
/home/perl/
Look for files with recent modification timestamps that do not match the rest of the directory. Perl webshells from these campaigns typically had MD5 hashes starting with 1a or b3: check against the IOC list in CISA advisory AA24-060B.
Check for unauthorized accounts: Navigate to System > Users > Administrator Realms and verify the user list against your known accounts.
Factory reset consideration: For Ivanti devices with confirmed compromise indicators, Ivanti's advisory and CISA's guidance both recommend a factory reset followed by clean reconfiguration rather than attempting in-place remediation. The web-accessible file structure makes it difficult to guarantee complete webshell removal without starting from a clean image.
After Your Checks: What to Do with the Results
If you find no indicators across all four categories during the exploitation window, document your findings with timestamps and preserve the logs. Update your vulnerability tracking record with 'no evidence of pre-patch compromise' and the date of verification.
If you find any indicators, treat it as a confirmed breach. The response steps:
- Do not reboot the device yet: memory forensics may be needed if the attacker used a memory-only dropper.
- Preserve a full configuration backup and log export before any remediation.
- Assume all credentials accessible to the device are compromised: VPN user credentials, RADIUS shared secrets, certificates, any passwords stored in the device configuration.
- Isolate the device from the production network while investigation continues.
- Engage your incident response retainer or a forensics vendor with perimeter device experience. Memory acquisition from network devices requires vendor-specific tooling.
- Rotate all credentials that the device could have accessed: do this regardless of whether you complete a full forensic investigation.
The bottom line
Patching a firewall CVE eliminates the attack path but does not remove what the attacker already installed. For every major perimeter device CVE, run four checks during the exploitation window: authentication log anomalies, unauthorized admin accounts, configuration changes, and webshell artifacts in web-accessible directories. The vendor-specific paths differ, but the four categories are consistent. If any check is positive, assume full compromise and rotate all credentials the device could access before beginning remediation.
Frequently asked questions
Does patching a firewall CVE remove an active compromise?
No. Patching closes the vulnerability that allowed initial access, but it does not remove backdoor accounts, webshells, or persistence mechanisms the attacker installed before the patch. You must explicitly check for and remove these artifacts after patching.
How do I check if my Fortinet firewall was compromised?
Run 'get system admin' to check for unauthorized admin accounts, review authentication logs for the exploitation window using 'execute log display', check /var/spool/cron/crontabs/ for attacker-added cron jobs, and inspect web-accessible directories for unexpected PHP files. Compare all findings against your known baseline.
What firewall products are most frequently exploited according to CISA KEV?
Fortinet FortiOS (SSL-VPN and management interface vulnerabilities), Palo Alto Networks PAN-OS (GlobalProtect and management interface), Citrix NetScaler (ADC and Gateway), and Ivanti Connect Secure are consistently the most-exploited perimeter device categories in the CISA KEV catalog. These products have direct internet exposure and management interfaces that, when exploited, provide immediate network access. Any unpatched critical CVE in these products on an internet-facing deployment should be treated as equivalent to a CISA KEV entry.
How long after a firewall CVE is disclosed do attackers typically exploit it?
For high-profile network appliance CVEs in Fortinet, Citrix, Ivanti, and Palo Alto products, mass exploitation typically begins within 2 to 5 days of public disclosure, and sometimes within hours if a proof-of-concept is published simultaneously. Several 2024 and 2025 Ivanti and Fortinet CVEs were exploited by nation-state actors before CISA KEV listing: in some cases before the CVE was even publicly disclosed. Emergency patching SLAs for this product category should target 24 hours for internet-exposed management interfaces.
How do I check Palo Alto Networks firewall for pre-patch compromise?
For PAN-OS compromise verification: check for unauthorized local admin accounts ('show admins all' in operational mode), review authentication logs for the exploitation timestamp window ('show log system direction equal backward'), inspect the filesystem for unexpected files in /tmp and /opt/pancfg/mgmt/saved-configs directories, verify that management interface access controls were set correctly before the vulnerability window, and compare running configuration against your last known-good backup. For CVEs involving the GlobalProtect portal, also check for new VPN user accounts and unusual authentication patterns.
After confirming a firewall compromise, what is the correct sequence for remediation without creating a network outage?
Remediation without outage requires parallel preparation before cutover. Step 1: provision a replacement firewall or restore a clean backup image in a staging environment -- do not attempt in-place remediation of a compromised firewall, as attackers frequently leave secondary backdoors that survive configuration restoration. Step 2: export the current running configuration for policy reconstruction (not for direct import, since the config file may contain backdoors). Step 3: rebuild the firewall from a known-good firmware image and import only the policy sections (rules, objects, NAT), not admin accounts or authentication configuration. Step 4: validate the rebuilt configuration in a lab environment against sample production traffic captures. Step 5: schedule a maintenance window, pre-stage the replacement device, execute cutover. The cutover window is typically 15 to 30 minutes for a prepared replacement. Notify upstream ISP and downstream critical systems owners of the maintenance window. Post-cutover: verify all existing VPN tunnels re-establish, that NAT is functioning correctly for key applications, and that logging is forwarding to your SIEM. Document the incident timeline for a post-incident review.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.