Cisco FMC CVE-2026-20131: Zero-Day Defense Playbook

CVE-2026-20131 is a CVSS 10.0 remote code execution vulnerability in Cisco Secure Firewall Management Center (FMC) that lets an unauthenticated attacker send a crafted HTTP request, trigger insecure Java deserialization, and land a root shell on your firewall management plane. No credentials required. No user interaction. The Interlock ransomware group had this zero-day in active exploitation 36 days before Cisco published a single advisory. By the time your team saw the CVE number on March 4, 2026, Interlock had already been inside victim networks since January 26.

This playbook covers exactly what happened, how Interlock’s kill chain works from initial HTTP request to ransomware deployment, and the specific commands and detection rules you need to find, contain, and close this exposure before it becomes your incident.

What CVE-2026-20131 Actually Does

CVE-2026-20131 exists in the web-based management interface of Cisco Secure Firewall Management Center Software. The root cause is CWE-502: deserialization of untrusted data. When the FMC management web interface receives an HTTP request containing a serialized Java object, it deserializes the payload without sufficient validation. An attacker who sends a specially crafted serialized Java object to that interface gets arbitrary Java code execution, which escalates automatically to root on the underlying device.

The CVSS 3.1 vector string is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Breaking that down: network-reachable, low complexity, no privileges needed, no user interaction, with changed scope and high impact across confidentiality, integrity, and availability. A perfect 10.0 is genuinely rare; this is one of the cleaner paths to full firewall infrastructure control you will see in enterprise software.

The scope-changed rating is worth understanding. Cisco FMC is not just one box; it is the central management plane for your entire Firepower/FTD deployment. A successful exploit does not just compromise the FMC appliance. It gives the attacker the ability to modify firewall rules across every managed device, suppress alerts, capture packets network-wide, and use the FMC as a pivot point into every network segment your firewalls touch.

CISA added CVE-2026-20131 to the Known Exploited Vulnerabilities catalog on March 19, 2026, with a mandatory remediation deadline of March 22 for federal agencies. That three-day window reflects how seriously this is being treated at the government level.

Affected Versions and Patch Targets

The vulnerability affects Cisco Secure Firewall Management Center software across a wide version range. Cisco confirmed these as vulnerable (source: NVD CPE data as of March 25, 2026):

• All 6.x versions (no patch available in this branch; upgrade required)
• 7.0.x through 7.0.8.1 (patch target: 7.0.6.3 or later)
• 7.1.0 through 7.1.0.3 (upgrade to 7.2.x or later)
• 7.2.0 through 7.2.10.2 (patch target: 7.2.5.1 or later)
• 7.3.0 through 7.3.1.2 (upgrade to 7.4.x or later)
• 7.4.0 through 7.4.5 (patch target: 7.4.2.1 or later)
• 7.6.0 through 7.6.4 (patch available; check Cisco advisory for current minimum)
• 7.7.0 through 7.7.11 and 10.0.0 (patch available; verify against Cisco advisory)

Note: Cisco Security Cloud Control (SCC) Firewall Management is also listed in the CISA KEV entry for this CVE. If you are using cloud-managed FMC, follow Cisco’s guidance on SaaS-delivered patch deployment separately from on-premises instances.

To confirm your running version from the FMC CLI:

show version

Or via the REST API:

GET /api/fmc_platform/v1/info/serverversion

How Interlock Ransomware Used This Zero-Day

Amazon’s threat intelligence team documented Interlock’s campaign in detail after recovering artifacts from a misconfigured attacker infrastructure server. The timeline matters: exploitation began January 26, 2026. Cisco disclosed the CVE on March 4. That is a 36-day window during which Interlock operated with a zero-day, meaning no signatures existed, no patch was available, and behavioral detections were the only viable defense.

Zscaler ThreatLabz observed exploit attempts in the wild beginning March 6, 2026, targeting technology and software organizations in the United States. The payloads matched publicly available proof-of-concept code for the deserialization flaw, confirming that within two days of disclosure, commodity exploitation was already underway alongside Interlock’s more targeted operations.

The Kill Chain: Stage by Stage

Stage 1: Initial access via HTTP deserialization. Interlock sent crafted HTTP POST requests to a specific path on the FMC web management interface. The request body contained a malicious serialized Java object. When the FMC deserializes it, Interlock’s Java code executes as root. The observed user-agent was Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0. The TLS fingerprint (JA3: b885946e72ad51dca6c70abc2f773506) is a reliable IoC for both January and March 2026 activity.

Stage 2: Payload delivery and ELF binary drop. The exploit request embedded two URLs: one to pull configuration data supporting the exploit, and a second to confirm successful exploitation by triggering an HTTP PUT request from the compromised host. After confirmation, Interlock delivered a Linux ELF binary from their staging server. The staging host IP 37.27.244[.]222 was active in March 2026.

Stage 3: Reconnaissance. Interlock deployed a PowerShell script that systematically enumerates the Windows environment: OS and hardware details, running services, installed software, Hyper-V VM inventory, browser artifacts from Chrome, Edge, Firefox, and IE (including stored credentials), active network connections correlated with processes, ARP tables, iSCSI data, and RDP authentication events from Windows event logs. Results are staged to a network share (\\JK-DC2\Temp), compressed into per-host ZIP archives, then the originals are deleted.

Stage 4: Persistence via dual RATs. Interlock deployed two redundant remote access trojans. The JavaScript implant profiles the host using PowerShell and WMI, then establishes command-and-control over persistent WebSocket connections with RC4-encrypted messages using per-message 16-byte random keys. The Java implant provides functionally identical capability, built on GlassFish ecosystem libraries with Grizzly for non-blocking I/O. Having both means if defenders identify and remove one, Interlock retains access through the other.

Stage 5: Infrastructure laundering. A Bash script compiles HAProxy 3.1.2 from source and configures it as an HTTP reverse proxy listening on port 80. A cron job runs every five minutes to truncate all log files under /var/log and suppress shell history. This aggressive log erasure creates disposable relay nodes that make attribution and traffic tracing extremely difficult.

Stage 6: Memory-resident webshell. As an alternative payload, Interlock deployed a Java class file that, when loaded by the JVM, registers a ServletRequestListener with the server’s StandardContext. This fileless webshell intercepts HTTP requests for specially crafted parameters containing AES-128 encrypted command payloads. The decryption key is derived from the MD5 hash of the hardcoded seed “geckoformboundary99fec155ea301140cbe26faf55ed2f40”. Decrypted payloads execute as compiled Java bytecode loaded dynamically into the JVM, leaving no files on disk for traditional AV to detect.

Stage 7: Lateral movement and privilege escalation. Interlock used Certify (SHA-256: d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be) to exploit Active Directory Certificate Services misconfigurations, identify vulnerable certificate templates, and obtain authentication-capable certificates for privilege escalation and persistence. ConnectWise ScreenConnect was deployed alongside custom implants to provide a redundant legitimate-looking remote access path. Volatility, the open-source memory forensics framework, was also recovered from Interlock’s toolkit.

Stage 8: Ransomware deployment and double extortion. Interlock follows a double-extortion model: encrypt files and threaten to publish exfiltrated data. The ransom note references multiple data protection regulations to pressure victims with both operational disruption and regulatory exposure. The TOR negotiation portal (hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php) was active as of March 2026.

Temporal analysis of attacker activity timestamps indicates the Interlock operators most likely work in UTC+3, with peak activity between 12:00 and 18:00 and a probable sleep window from 00:30 to 08:30. Amazon assessed this with 75-80% confidence based on systematic analysis across all UTC offsets.

Detection: What to Hunt Right Now

Your detection priority should follow the kill chain. Start with the exploit attempt itself, then work forward through post-exploitation indicators.

Network Detection

Block and alert on the known exploit source IPs immediately. From the AWS threat intelligence report, confirmed active IPs:

• 206.251.239[.]164 (exploit source, active January 2026)
• 199.217.98[.]153 (exploit source, active March 2026)
• 89.46.237[.]33 (exploit source, active March 2026)
• 144.172.94[.]59, 199.217.99[.]121, 188.245.41[.]78 (C2 fallback IPs)
• 144.172.110[.]106, 95.217.22[.]175 (backend C2 IPs)

Block and alert on the C2 and exploit support domains:

• browser-updater[.]com, browser-updater[.]live
• os-update-server[.]com / .org / .live / .top
• ms-server-default[.]com, initialize-configs[.]com
• ms-global.first-update-server[.]com, ms-sql-auth[.]com
• kolonialeru[.]com, sclair.it[.]com, cherryberry[.]click

For IDS/IPS detection, add Snort rules targeting Java deserialization payloads directed at the FMC management interface. A Snort 3 rule targeting the serialization marker and the exploit user-agent pattern:

alert http $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (
  msg:"CVE-2026-20131 Cisco FMC Java Deserialization Exploit Attempt";
  flow:established,to_server;
  http.method:"POST";
  http.header:"User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0)";
  content:"aced0005"; http_client_body; nocase;
  metadata:affected_product Cisco_FMC, cve CVE-2026-20131;
  priority:1;
  classtype:attempted-admin;
  sid:9002613; rev:1;
)

The hex string “aced0005” is the Java serialization magic header. Any HTTP POST carrying this to your FMC management port should be treated as a confirmed exploit attempt.

Additionally, alert on the confirmed TLS JA3 hashes:

• b885946e72ad51dca6c70abc2f773506 (active January and March 2026)
• f80d3d09f61892c5846c854dd84ac403 (active March 2026)

Host-Based Detection

On the FMC appliance itself, check for signs of compromise:

# Check for unexpected listening ports (particularly 45588)
ss -tlnp | grep -v -E '(443|80|8305|8443)'

# Check for new or modified Java class files under FMC app directories
find /opt/firepower -name "*.class" -newer /etc/issue -ls

# Check for unexpected HAProxy installations
which haproxy && haproxy -v

# Check cron for log erasure patterns
crontab -l
ls /var/spool/cron/
grep -r "truncate\|HISTFILE" /etc/cron*

For Windows endpoints reachable from the FMC network:

# Hunt for PowerShell staging to network shares matching Interlock pattern
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4688} |
  Where-Object {$_.Message -match "Compress-Archive.*\\JK-DC2\\Temp"}

# Hunt for ScreenConnect remote access tool
Get-Service | Where-Object {$_.DisplayName -match "ScreenConnect"}
Get-Process | Where-Object {$_.Name -match "ScreenConnect|connectwise"}

Check for the Certify binary using the confirmed hash:

Get-FileHash -Algorithm SHA256 -Path (Get-ChildItem -Recurse -Path C:\ -Filter "*.exe").FullName |
  Where-Object {$_.Hash -eq "D1CAA376CB45B6A1EB3A45C5633C5EF75F7466B8601ED72C8022A8B3F6C1F3BE"}

FMC Audit Log Review

In the FMC web interface, navigate to System > Monitoring > Audit. Look for unexpected administrative actions: rule modifications, access control policy changes, logging configuration changes, and user account creation. Any administrative action you cannot tie to a change ticket is worth investigating. If Interlock achieved root access, they may have suppressed audit forwarding; check that your external syslog target is still receiving FMC events.

Containment: Isolating the Management Plane

If you have not already done this, the single most impactful containment action is removing the FMC management interface from any internet-accessible network path. This is not a new principle; it has been best practice for years. But Cisco’s advisory explicitly notes that attack surface is reduced when the management interface lacks public internet access, and Zscaler’s recommendation is to place management planes behind a zero trust access layer with inside-out connectivity.

On a perimeter firewall above the FMC, restrict access to the management port (default TCP 443 for the web UI, TCP 8305 for FMC-to-FTD management channel):

# Cisco ASA ACL example restricting FMC management access
access-list FMC_MGMT_RESTRICT extended permit tcp host 10.10.1.50 host 192.168.100.10 eq 443
access-list FMC_MGMT_RESTRICT extended permit tcp 10.10.1.0 255.255.255.0 host 192.168.100.10 eq 8305
access-list FMC_MGMT_RESTRICT extended deny ip any host 192.168.100.10
access-group FMC_MGMT_RESTRICT in interface outside

If you suspect the FMC is already compromised, do not trust any of its current policy state. Your containment actions should proceed in this order:

1. Isolate the FMC appliance at the network layer before taking any on-box actions. A compromised FMC could have active connections back to attacker infrastructure, and cleanly cutting those before investigation preserves better forensic context than working on a live compromised system.
2. Snapshot or image the FMC disk before any remediation if your environment allows it. The memory-resident webshell will not survive a reboot, but may be recoverable from a live image.
3. Review your managed FTD devices independently. If an attacker controlled the FMC, assume all policy on managed devices should be treated as suspect until you have verified it against a known-good baseline.
4. Rotate all service accounts, API keys, and certificates associated with the FMC. Interlock’s reconnaissance script specifically harvests browser-stored credentials; if any admin browsers were connected to the FMC during compromise, those credentials should be treated as compromised.

For broader incident handling procedures, your incident response planning should have a pre-defined playbook for management plane compromises that differs from endpoint compromises. The FMC sits above your security controls; a standard endpoint IR workflow does not account for the fact that the attacker may have modified the very policies you are relying on for containment.

Patching: What to Apply and How to Verify

Cisco released patches across all supported branches. Based on Zscaler ThreatLabz’s analysis, the minimum secure versions are:

• 7.0.x: update to 7.0.6.3 or later
• 7.2.x: update to 7.2.5.1 or later
• 7.4.x: update to 7.4.2.1 or later
• 6.x: no in-branch fix available; upgrade to a supported 7.x release

For 7.6.x, 7.7.x, and 10.0.x, verify against the current Cisco advisory at sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-rce-NKhnULJh, as additional point releases may be required. Cisco’s own advisory is the authoritative source for patch availability per branch.

After patching, verify the update applied correctly:

show version | include Version
show version | include Build

Then validate that no unexpected accounts, SSH keys, or sudoers entries exist on the FMC system. Even after patching a clean system, if you were running a vulnerable version between January 26 and your patch date, you should treat the FMC as potentially compromised and run a compromise assessment alongside the patch.

Network Segmentation: Closing the Lateral Movement Path

The Interlock attack chain demonstrates why FMC access control matters beyond just the initial exploit. Once they had the FMC, they used it to reach Windows environments for reconnaissance and credential harvesting, then moved laterally using Active Directory certificate abuse via Certify. Your segmentation posture around the FMC needs to account for both inbound exploitation risk and outbound reach from a compromised FMC.

Management plane isolation. The FMC should sit in a dedicated management VLAN with no direct routing to production workloads. Outbound connectivity from the FMC should be restricted to Cisco licensing servers, the software update infrastructure, and your central logging destination. Any unexpected outbound HTTP or HTTPS connections from the FMC are high-confidence indicators of compromise.

FMC-to-FTD channel control. FMC communicates to managed FTD devices over TCP 8305. This channel should be a direct, dedicated path with no internet egress. If this channel traverses shared network segments, an attacker who compromises the FMC can use it to push malicious policy to all managed firewalls.

Admin access via jump hosts only. No direct browser access to the FMC from general corporate endpoints. All FMC administrative sessions should originate from dedicated, hardened jump hosts that are themselves subject to strong authentication, session recording, and behavioral monitoring. This limits the credential harvest risk from Interlock’s browser artifact collection.

For the broader architecture approach to management plane protection, the zero trust architecture guide covers how to apply inside-out connectivity principles so that management interfaces like FMC are never directly reachable from the internet or from general network segments.

Active Directory hardening. Interlock used Certify to exploit AD CS misconfigurations. Run Certify or Certipy against your own AD CS environment to identify vulnerable certificate templates before attackers do:

# Using Certify to enumerate vulnerable templates
.\Certify.exe find /vulnerable

# Using Certipy (Python alternative)
certipy find -u [email protected] -p Password -dc-ip 10.10.1.1 -vulnerable

Templates with ENROLLEE_SUPPLIES_SUBJECT, Client Authentication EKU, and Manager Approval disabled are the primary targets. Any vulnerable templates should be remediated before you consider this incident contained, regardless of whether you found direct evidence of Certify execution in your environment.

Proactive Threat Hunting

Given that Interlock operated for 36 days before disclosure, treat any FMC running a vulnerable version since January 26 as a potential compromise requiring active investigation, not just patching. A threat hunting playbook for this scenario should focus on three hypothesis areas: initial exploitation evidence, post-exploitation persistence, and lateral movement artifacts.

For initial exploitation evidence, query your perimeter firewall and WAF logs for HTTP POST requests to the FMC management interface from the known exploit source IPs or matching JA3 hash b885946e72ad51dca6c70abc2f773506. Even if you see no successful exploitation, confirm the volume and source of requests to that interface over the January 26 to March 4 window.

For persistence, look for Java class files with recent modification timestamps under FMC application directories, unexpected ServletRequestListener registrations in Java application context logs, and TCP connections to port 45588 in your network flow data.

For lateral movement artifacts, query your EDR for PowerShell executions that match Interlock’s recon pattern: scripts that call Get-WmiObject, collect browser history paths, and create compressed archives in network share directories. This behavioral signature is more reliable than file hashes, since Amazon’s analysis confirmed Interlock varied artifacts across targets specifically to defeat signature-based detection.

Indicators of Compromise: Complete Reference

The following IoCs are drawn directly from Amazon’s threat intelligence report, published March 18, 2026. Due to Interlock’s artifact variation across targets, file hashes (except the two listed below) are not reliable indicators; prioritize network-based IoCs.

Indicator	Type	First Seen
206.251.239[.]164	Exploit source IP	January 2026
199.217.98[.]153	Exploit source IP	March 2026
89.46.237[.]33	Exploit source IP	March 2026
144.172.94[.]59	C2 fallback IP	March 2026
199.217.99[.]121	C2 fallback IP	March 2026
188.245.41[.]78	C2 fallback IP	March 2026
144.172.110[.]106	Backend C2 IP	March 2026
95.217.22[.]175	Backend C2 IP	March 2026
37.27.244[.]222	Staging host IP	March 2026
browser-updater[.]com / .live	C2 domain	March 2026
os-update-server[.]com / .org / .live / .top	C2 domain	March 2026
ms-server-default[.]com	Exploit support domain	March 2026
initialize-configs[.]com	Exploit support domain	March 2026
ms-global.first-update-server[.]com	Exploit support domain	March 2026
ms-sql-auth[.]com	Exploit support domain	March 2026
kolonialeru[.]com	Exploit support domain	March 2026
cherryberry[.]click	Exploit support domain	January 2026
b885946e72ad51dca6c70abc2f773506	Exploit TLS JA3	Jan and Mar 2026
f80d3d09f61892c5846c854dd84ac403	Exploit TLS JA3	March 2026
d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be	Certify (offensive tool)	March 2026
6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f	Screen locker binary	March 2026

For RCE vulnerabilities in other management platforms, the RCE hardening guide for Langflow CVE-2026-33017 covers parallel principles that apply whenever a management interface becomes an unauthenticated attack surface.

Frequently Asked Questions

Is CVE-2026-20131 exploitable if the FMC management interface is only accessible from internal networks?

The vulnerability requires network access to the FMC web management interface, but “network access” includes any attacker who has already compromised an internal system. Cisco notes that lack of public internet access reduces the attack surface, but it does not eliminate the risk. Interlock’s post-exploitation toolkit demonstrates they actively pursue lateral movement, so an internally-accessible-only FMC sitting on a flat network segment is still at risk after any initial internal compromise.

How do I know if my FMC was compromised during the zero-day window before March 4?

Check your FMC and perimeter firewall logs for HTTP POST requests matching the known exploit source IPs and TLS JA3 hash b885946e72ad51dca6c70abc2f773506 between January 26 and March 4, 2026. Also hunt for unexpected Java class files, HAProxy processes with aggressive log deletion cron jobs, and TCP connections to port 45588. If your logging was not comprehensive during that window, treat any vulnerable FMC as potentially compromised and conduct a full compromise assessment before restoring to normal operations.

Does Cisco Security Cloud Control also need patching for CVE-2026-20131?

Yes. The CISA KEV entry specifically names both Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management. If you use cloud-managed FMC through SCC, follow Cisco’s specific guidance for cloud-delivered patching, which differs from the on-premises FMC upgrade process.

Can a Snort rule on an upstream FTD device detect exploit attempts against the FMC?

Yes, if your FTD devices have visibility to traffic destined for the FMC management interface. The Java serialization magic header (aced0005) in an HTTP POST body is a reliable detection anchor. The Snort rule in the detection section above targets this pattern. Zscaler ThreatLabz has also published AppProtection rules for Java deserialization via ysoserial tools under threat IDs 6000322 and 6000042, which map to this exploit mechanism.

What is Interlock’s typical attack timeline after initial FMC compromise?

Based on Amazon’s technical analysis, Interlock’s post-compromise sequence moves from initial ELF binary delivery to full reconnaissance within hours. Their PowerShell recon script, dual RAT deployment, and infrastructure laundering configuration are all automated components that can complete network enumeration, credential harvesting, and C2 establishment before a human analyst has reviewed the initial alert. The group operates with peak activity between 12:00 and 18:00 UTC+3, suggesting a business-hours operational tempo that may align investigative windows for defenders in UTC-heavy time zones.

Should I upgrade directly to the latest FMC version, or patch to the minimum secure version first?

If your environment and change management process allow it, upgrade to the current recommended release rather than stopping at the minimum secure version. The minimum versions confirmed at time of disclosure (7.0.6.3, 7.2.5.1, 7.4.2.1) represent the patch boundary, but subsequent point releases may contain additional security fixes. Consult the Cisco Firepower Management Center new features roadmap to understand what is current in your branch and balance security urgency against stability testing requirements for your specific environment.

---

If your FMC is running a vulnerable version and you have not yet confirmed whether it was accessed during the January 26 to March 22 window, treat that as an open incident requiring active investigation, not just a patch ticket. The combination of a perfect 10.0 CVSS score, a 36-day zero-day window, and a ransomware group with documented double-extortion operations makes this one of the higher-consequence enterprise vulnerabilities of 2026. Confirm your version, check your logs, and apply the patch today.

ShieldOperations tracks active CVE exploitation and publishes defense playbooks as soon as credible threat intelligence is available. Contact us directly if you need help assessing your FMC exposure or running a compromise assessment on potentially affected infrastructure.