Why Ransomware Groups Are Targeting Firewalls and VPN Appliances

Updated March 2026: Analysis of the Interlock ransomware campaign exploiting a zero-day in Cisco Secure Firewall Management Center, based on Amazon threat intelligence published March 18, 2026.

Ransomware groups have shifted their initial access strategy. Rather than phishing an employee, the most capable operators are targeting the network appliances your organisation trusts most: firewalls, VPN concentrators, and security management platforms. These devices carry privileged access to everything behind them, are rarely covered by endpoint detection tools, and are often left internet-exposed on their management interfaces.

The Interlock ransomware group was exploiting a critical vulnerability in Cisco Secure Firewall Management Center 36 days before Cisco's public disclosure (Amazon, 2026). No patch existed. No scanner would have flagged it. Diligent vulnerability management would not have closed it.

This is not a one-off. It is a pattern that has played out across Fortinet, SonicWall, Ivanti, and now Cisco. "Patch faster" would not have helped here.

Get articles like this delivered to your inbox. Subscribe to CyberDesserts for practical security analysis, no vendor spin.

Why Ransomware Groups Now Target Perimeter Appliances

The business logic is simple. Perimeter appliances are high-value targets that defenders consistently under protect.

A compromised firewall or VPN gateway provides persistent, privileged access to every network segment it protects. Most organisations have endpoint detection and response tools across their workstations and servers. Perimeter appliances sit outside that coverage. They do not run EDR agents. They frequently fall outside SIEM log collection unless someone specifically built that pipeline. And because they carry the label "security device," teams assume they are hardened.

That assumption is the vulnerability.

These appliances also carry significant attack surface. Management interfaces, web portals, API endpoints, and authentication handlers all need to be implemented correctly across every release. One parsing error in a web handler, one unvalidated input, and an unauthenticated attacker has code execution as root on your security infrastructure.

I have watched organisations spend seven figures on perimeter appliances and then expose the management interface to the internet with default credentials on local accounts. The trust placed in these devices is rarely matched by the controls placed around them. When ransomware operators noticed that gap, they became a target.

Which Ransomware Groups Have Exploited Firewall and VPN Vulnerabilities?

The following cases are all confirmed or directly linked to ransomware operations. This is not a hypothetical trend.

Sources: Amazon (2026), Forescout (2025), Fortinet PSIRT (2025), Arctic Wolf (2024), CISA (2025)

A few details in this table deserve attention beyond the headline.

The SonicWall intrusions were not purely a patching failure. Every account Akira exploited was a local SonicWall account with no Active Directory integration. None had MFA enabled (Arctic Wolf, 2024). They did not need a sophisticated exploit chain. They used a login page and a working password.

The second Fortinet row is the one that should concern security teams most. Attackers planted a symlink between the device's user filesystem and root filesystem, hiding it inside the SSL-VPN language file directory - a location that survived the patch entirely. Organisations that updated on time still had an active foothold they could not see (Fortinet PSIRT, 2025). The appliance was patched. The attacker still had access.

The Cisco FMC case adds a different dimension: a genuine zero-day, held for 36 days before any defender knew to look. Full technical detail on Interlock's toolkit from this campaign is published in Amazon's March 2026 advisory.

One clarification worth making: CVE-2026-20131 affects Cisco Secure Firewall Management Center, the platform used to manage Cisco firewalls, not the firewall data plane itself. If your FMC is not internet-accessible, your immediate exposure profile is different. But the management plane being targeted is arguably the worse outcome. An attacker with control of your firewall management platform has full visibility into your network policy and can manipulate the controls you depend on for everything else.

How Do You Detect a Compromise When the Breached Device Is Your Security Tool?

This question gets avoided in vendor material. It deserves a direct answer.

Detection degrades significantly when the compromised device is your perimeter security infrastructure. If your firewall management platform ships logs to your SIEM, and an attacker has persistent access on that device, they sit between your detection capability and the events you are trying to detect. This is not theoretical. Interlock automated evidence destruction on a five-minute timer, wiping log files on a cycle short enough that most investigators would find nothing useful (Amazon, 2026). They built that into their standard deployment because they have done this enough times to know defenders check logs first.

There are still detection opportunities. But they require preparation before an incident.

External, immutable logging is the baseline. Logs shipped to a collector outside the compromised device's reach cannot be wiped by a cron job running on that device. If your perimeter appliances are not shipping authentication events, configuration changes, and outbound connections to an external SIEM, that single gap undermines everything else on this list. It is also the gap that appears most consistently in post-incident reviews across the Fortinet, SonicWall, and Cisco cases above.

Network telemetry becomes your primary signal. When the appliance cannot be trusted as a reporting source, network-layer monitoring matters more. Watch for unexpected outbound connections from management interfaces, traffic to newly registered domains, and connections to unusual high-numbered ports. All of this is visible at the network layer regardless of what the appliance reports about itself.

Hunt your security appliances explicitly. Most threat hunting programmes focus on endpoints and servers. Perimeter appliances are often absent from hunt scope entirely. Add them. Configuration changes outside approved change windows, unexpected outbound connections, new processes: these devices deserve the same scrutiny as any high-privilege server in your environment.

How to Defend Against Perimeter Appliance Zero-Days When No Patch Exists

Amazon's advisory covers the immediate response for CVE-2026-20131: patch, check IoCs, look for unauthorised remote access tools. What it does not address is the architectural question: what should have been in place already to limit the blast radius of an exploit that no patch could prevent?

This is where defence in depth becomes a practical conversation rather than a compliance phrase.

Isolate management interfaces from internet access.

Every case in the table above involved an internet-accessible management or VPN interface. The Fortinet advisories explicitly identified internet-exposed management interfaces as the at-risk population (Forescout, 2025). The SonicWall cases followed the same pattern. The Cisco FMC case followed the same pattern.

Management interface isolation is not a zero-day mitigation specifically. It is a configuration baseline that predates all of these CVEs and reduces the exploitable surface for all of them. Management access belongs on an out-of-band network, reachable only through a dedicated jump host with strong authentication. Not on a public IP.

If CVE-2026-20131 affected your organisation because your FMC was internet-facing, the zero-day was one problem. The exposed management interface was a separate problem, and that one was solvable before January 26.

Design the jump host to restrict access.

A jump host reduces attack surface only if it is the sole path to the management interface. The pattern I have seen fail repeatedly in enterprise environments: the jump host exists, but the management interface remains reachable directly as a convenience fallback, which defeats the purpose entirely.

A properly implemented jump host architecture means the appliance management interface is unreachable via any other network path. Authentication to the jump host should use phishing-resistant MFA. Session recording on the jump host gives you an audit trail that exists independently of the managed device. And the jump host itself needs patching discipline. A poorly maintained bastion is a different entry point, not a security control.

Replace local accounts with centralised authentication.

The SonicWall intrusions were made significantly easier by local device accounts with no Active Directory integration and no MFA (Arctic Wolf, 2024). Akira needed no sophisticated exploit once those conditions were met.

Where vendors support it, local accounts on perimeter appliances should be replaced by centralised authentication tied to your identity provider. This means compromised local credentials do not automatically translate to valid access, and account lifecycle management is enforced consistently rather than left to per-device configuration.

If local accounts are unavoidable, MFA is non-negotiable. Passwords should also rotate independently of general migration processes - the SonicWall cases included organisations whose Gen 6 credentials carried over into Gen 7 deployments untouched.

Segment the appliance from what it manages.

A compromised management platform should not have unrestricted lateral movement capability into internal systems. If your FMC does not need to reach HR systems, domain controllers, or internal infrastructure segments to perform its function, network controls should enforce that restriction regardless of what credentials an attacker holds post-compromise.

Segmentation here does not mean isolating the FMC from the devices it manages - that traffic path stays intact. It means the FMC cannot reach anything beyond what it needs to do its job: the management interfaces of its managed devices, DNS, and NTP.

The jump host is a one-way street. Administrators connect from the jump host to the FMC. The FMC has no legitimate reason to initiate connections back to the jump host, and your firewall rules should enforce that asymmetry explicitly. A compromised FMC with no permitted outbound path to the jump host cannot use that access as a stepping stone, regardless of what credentials an attacker holds on the device.

Get this right and an attacker who lands on the FMC has a foothold they cannot move from.

Apply zero trust to your security tools, not just your users.

Security appliances are not inherently trustworthy nodes. They run software that can expose vulnerabilities. Treating perimeter appliances as unconditionally trusted infrastructure, able to reach anything they can authenticate to, is the architecture assumption that turns a single device compromise into a network-wide ransomware deployment.

Zero trust does not mean zero trust for users and unconditional trust for security infrastructure. It means what it says.

Subscribe to PSIRT notifications for every vendor in your estate.

The window between a vendor becoming aware of a vulnerability and public disclosure ranges from hours to months. PSIRT alerts give you the earliest signal for compensating controls before a patch exists. This is a free control that a surprisingly large number of organisations have not implemented. It belongs in the same category as patching cadence: operational hygiene with direct impact on exposure window.

Validate your exposure continuously, not periodically.

A quarterly vulnerability scan tells you nothing about a zero-day. Continuous Threat Exposure Management asks a different question: if an attacker compromised this appliance right now, what could they reach, and what would your detection controls catch? Validating those answers continuously means your defensive posture around high-value assets is measured rather than assumed.

For a deeper look at how CTEM works in practice, see our NIST-aligned CTEM guide.

What to Do Now

If you run Cisco Secure FMC:

1. Apply Cisco's patch for CVE-2026-20131 and verify the installed version
2. Check whether your FMC management interface is reachable from the internet and remove that exposure
3. Review Amazon's published IoCs against your logs: source IPs, C2 domains, and TLS fingerprints are in the March 2026 advisory
4. Check your environment for unauthorised remote access tool installations

For perimeter appliances broadly:

1. Audit which management interfaces are internet-facing across your entire estate
2. Verify all appliances ship logs to an external collector that the device itself cannot modify
3. Check that local accounts on appliances either have MFA enforced or are replaced by centralised authentication
4. Subscribe to PSIRT notifications for every vendor whose hardware you run
5. Add perimeter appliances explicitly to your threat hunting scope

Summary

The pattern across Fortinet, SonicWall, Ivanti, and Cisco is consistent. Ransomware operators have identified perimeter appliances as high-value, low-detection-risk targets. Internet-exposed management interfaces, local accounts without MFA, and absent external log collection have appeared in every major case reviewed here.

The Cisco FMC zero-day changes the conversation about patching speed. When no patch exists and exploitation begins 36 days before disclosure, the organisations that contain the damage are not the ones that reacted fastest. They are the ones that built their architecture around the assumption that any device, including a security device, can be compromised.

Management plane isolation, centralised authentication, network segmentation, external logging, and continuous exposure validation are not theoretical controls. They are the specific measures that would have limited the damage in each case in this article. None of them required a zero-day to exist first.

Last updated: March 2026

Security threats to perimeter infrastructure are evolving faster than most patch cycles. Subscribers get practical analysis when it matters, not a weekly digest of vendor press releases.

References

1. Amazon Web Services / CJ Moses (2026). Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls. AWS Security Blog, March 18, 2026.
2. Forescout Vedere Labs (2025). New Ransomware Operator Exploits Fortinet Vulnerability Duo. March 2025. SuperBlack ransomware and Mora_001 exploitation of CVE-2024-55591 and CVE-2025-24472.
3. Fortinet PSIRT (2025). Analysis of Threat Actor Activity. April 2025. Post-exploitation symlink technique persisting across patched FortiGate devices.
4. Arctic Wolf Labs (2024). Fog and Akira Ransomware Attacks via SonicWall SSL VPN Accounts. October 2024. Intrusions via CVE-2024-40766, local accounts with MFA disabled.
5. CISA, FBI, HHS, MS-ISAC (2025). #StopRansomware: Interlock Ransomware. Advisory AA25-203A, July 2025.
6. Cisco PSIRT (2026). Cisco Secure Firewall Management Center Software Remote Code Execution Vulnerability. Advisory cisco-sa-fmc-rce-NKhnULJh, March 4, 2026.