Executive summary

Amazon reported on 18 March 2026 that the Interlock ransomware group exploited CVE-2026-20131 in Cisco Secure Firewall Management Center (FMC) Software as a zero-day from 26 January, which Amazon puts at 36 days before Cisco disclosed it on 4 March. The post's own timeline is more guarded, describing “threat activity potentially related to CVE-2026-20131” from that date, and the paragraph that gives 36 days also calls Interlock's lead “a week's head start” without reconciling the figures. Cisco's advisory, as first published on 4 March, says the flaw lets an unauthenticated, remote attacker execute arbitrary Java code as root, gives it a Common Vulnerability Scoring System (CVSS) base score of 10.0 and lists no workarounds. The US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities (KEV) catalogue on 19 March, due 22 March, with known ransomware campaign use marked “Known” and no group named. We assess it is likely (B2) that Interlock's exploitation began before the disclosure, as Amazon reports, so defenders whose FMC management interface was reachable from the internet should review activity from 26 January.

Contextual background

Cisco's advisory, as first published on 4 March 2026, places the flaw, insecure deserialisation of a user-supplied Java byte stream, in the web-based management interface of FMC Software. An attacker could exploit it by sending a crafted serialised Java object to that interface and, if successful, execute arbitrary code and elevate privileges to root. The advisory says the flaw affects FMC Software and Cisco Security Cloud Control (SCC) Firewall Management regardless of device configuration, that Cisco upgrades SCC, a software-as-a-service (SaaS) offering, with no user action required, and that Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) Software are not affected. It notes that the attack surface is reduced if the FMC management interface does not have public internet access. This first version said Cisco's Product Security Incident Response Team (PSIRT) was not aware of any public announcements or malicious use. It lists no fixed releases in its text, pointing instead to the Cisco Software Checker, which returns the earliest fixed release for a given version.

The Common Vulnerabilities and Exposures (CVE) record that the National Vulnerability Database (NVD) received from Cisco's PSIRT on 4 March carries the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and Common Weakness Enumeration (CWE) entry CWE-502. NVD's initial analysis of 19 March lists the affected FMC releases individually, from the 6.4 series to 10.0.0.

CISA's 19 March alert says it added the flaw “based on evidence of active exploitation”. In the catalogue file published that day, the entry covers FMC Software and SCC Firewall Management, carries CWE-502, and was added on 19 March 2026 with a due date of 22 March 2026, three days later. The required action is to apply mitigations per vendor instructions, follow Binding Operational Directive (BOD) 22-01 guidance for cloud services, or discontinue use if mitigations are unavailable. BOD 22-01 binds Federal Civilian Executive Branch (FCEB) agencies to the due date; CISA urges all organisations to prioritise timely remediation. Known ransomware campaign use is “Known”, but the catalogue names no group: the link to Interlock is Amazon's.

Technical analysis

Discovery, as Amazon describes it. Amazon says that after Cisco's disclosure it searched its MadPot sensor network, a system of honeypot servers, for current or past exploitation of the flaw. Its summary ties the activity from 26 January to Interlock outright; its timeline calls it potentially related to the CVE. Amazon describes Hypertext Transfer Protocol (HTTP) requests to a specific path in the affected software, whose bodies contained Java code execution attempts and two embedded web addresses: one delivering configuration data for the exploit, the other meant to confirm success by making a vulnerable target perform an HTTP PUT request and upload a generated file. Amazon says it sent the expected PUT request itself, posing as a compromised system, and that Interlock then issued commands to fetch and execute a malicious Linux Executable and Linkable Format (ELF) binary from a remote server. That host, Amazon reports, distributed Interlock's whole toolkit from per-target paths that also received artefacts uploaded from compromised hosts. Amazon says a misconfigured infrastructure server exposed the complete toolkit.

Attribution, as Amazon presents it. Amazon attributes the ELF binary and associated artefacts to the Interlock ransomware family on “convergent technical and operational indicators”: a ransom note and Tor negotiation portal consistent with Interlock's branding and infrastructure, the note's invocation of data protection regulations, which Amazon calls Interlock's documented practice, and a campaign-specific organisation identifier that fits Interlock's per-victim tracking. Its timestamp analysis indicates that the actor most likely operates three hours ahead of Coordinated Universal Time (UTC), in UTC+3, with 75–80 per cent confidence. The post names no country.

Toolkit, as Amazon describes it.

  • A PowerShell script that inventories Windows hosts, including Hyper-V virtual machines, browser artefacts and Remote Desktop Protocol (RDP) authentication events, and stages the results on a network share in per-host folders, compressed into ZIP archives.
  • Remote access trojans (RATs) in JavaScript and in Java that use WebSocket connections for command and control, with shell access, file transfer and proxying of Transmission Control Protocol (TCP) traffic.
  • A Bash script that turns Linux servers into HAProxy relays for HTTP traffic, with a cron job that truncates all *.log files under /var/log every five minutes.
  • A memory-resident webshell: a Java class file that registers a ServletRequestListener, intercepts HTTP requests without writing files to disk and runs decrypted Java bytecode in memory.
  • A TCP server on port 45588 that Amazon reads as a beacon to confirm code execution or port reachability.

Amazon says Interlock deployed ConnectWise ScreenConnect alongside its custom implants and used Certify, an open-source tool for exploiting misconfigurations in Active Directory Certificate Services (AD CS).

The mapping is ours; each row rests on behaviour Amazon describes.

Technique Basis in Amazon's post
T1190 Exploit Public-Facing Application HTTP requests carrying Java code execution attempts to a specific path in the affected software
T1505.003 Server Software Component: Web Shell Java class file that registers a listener and intercepts HTTP requests in memory
T1059.001 Command and Scripting Interpreter: PowerShell Windows reconnaissance script
T1219 Remote Access Tools ScreenConnect deployed alongside custom implants
T1090 Proxy Linux servers configured as HAProxy relays
T1070.002 Indicator Removal: Clear Linux or Mac System Logs Cron job truncating *.log files under /var/log every five minutes
T1649 Steal or Forge Authentication Certificates As a precaution: Interlock's use of Certify, a tool designed to exploit AD CS misconfigurations; Amazon does not say whether any certificate was requested or forged

Impact assessment

Cisco says the flaw needs no authentication, yields root, affects FMC regardless of device configuration and has no workaround, so short of the fixed release its advisory offers one lever: limiting who can reach the management interface.

Amazon says Interlock has historically targeted sectors where operational disruption creates maximum pressure for payment. Education accounts for the largest share, followed by engineering, architecture and construction firms, manufacturing and industrial organisations, healthcare providers, and government and public sector entities. The July 2025 joint advisory below sets out a double extortion model in which systems are encrypted after data is exfiltrated, and Amazon says this campaign's ransom note adds the threat of regulatory fines by invoking data protection regulations.

Indicators of compromise

The indicators below are a selection from Amazon's 18 March post, defanged: four Internet Protocol (IP) addresses, one domain and one Transport Layer Security (TLS) fingerprint. The post lists more, including command-and-control (C2) addresses and domains, further TLS fingerprints, the ransom negotiation portal and two file hashes. Amazon cautions that most file hashes are not reliable indicators, because Interlock modified most scripts and binaries downloaded to different targets.

Indicator Amazon's label Amazon's activity window
206.251.239[.]164 Exploit source IP address January 2026
199.217.98[.]153 Exploit source IP address March 2026
89.46.237[.]33 Exploit source IP address March 2026
cherryberry[.]click Exploit support domain January 2026
37.27.244[.]222 Staging host IP address March 2026
b885946e72ad51dca6c70abc2f773506 Exploit TLS JA3 fingerprint January and March 2026

Amazon's table lists one HTTP user-agent string, one JA3 fingerprint and one JA4 fingerprint as observed in both January and March 2026; its January IP address and domain differ from the March ones. The user-agent string is a standard Firefox 136 string for Windows and on its own will match legitimate browsers.

Detection and hunting guidance

Start with exposure: test from outside the network whether each FMC management interface is reachable from the internet.

Then look back to 26 January. From Amazon's description of the exploit traffic, we derive three hunts for proxy, firewall and FMC logs:

  • inbound HTTP requests to an FMC management interface from Amazon's exploit source addresses or carrying its TLS fingerprints;
  • outbound HTTP PUT requests from an FMC to an external host, the confirmation step Amazon describes;
  • an FMC fetching an executable from an external server, the next stage Amazon observed.

Amazon's own detection opportunities are PowerShell scripts staging data to network shares with hostname-based directory structures, Java ServletRequestListener registrations in web application contexts, HAProxy installations with cron jobs that delete logs, and TCP connections to unusual high-numbered ports such as 45588. It also advises reviewing ScreenConnect deployments for unauthorised installations.

A generic proxy-log query for the second and third hunts, to adapt to your schema:

-- Outbound web requests from FMC management addresses since 26 January 2026
SELECT event_time, src_ip, dest_host, http_method, url
FROM proxy_logs
WHERE src_ip IN (SELECT mgmt_ip FROM asset_inventory WHERE product = 'Cisco Secure FMC')
  AND event_time >= '2026-01-26'
ORDER BY event_time;

Amazon says the relay script truncates the *.log files under the relays' /var/log every five minutes, so we expect the usable evidence to sit on the defender's side: the FMC, nearby firewalls and proxies, and central log stores.

Incident response guidance

  1. Upgrade every FMC to the fixed release that the Cisco Software Checker identifies for its version; where the checker also returns a “Combined First Fixed” release, which fixes all the advisories it identifies, we suggest that one. Cisco said on 4 March that it upgrades SCC Firewall Management itself.
  2. Where an FMC management interface was reachable from the internet at any point since 26 January, treat the FMC as possibly compromised: preserve its logs and those of the surrounding firewalls and proxies before upgrading, and search them from 26 January for the indicators in Amazon's post.
  3. Review ScreenConnect deployments for installations that administrators did not make, as Amazon advises.
  4. As a precaution, because Amazon reports that Interlock used Certify, review AD CS for vulnerable certificate templates and enrolment permissions, and for authentication-capable certificates issued to unexpected requesters since 26 January.

These are our recommendations except where a source is named.

Mitigation recommendations

  • Management interface exposure: keep the FMC management interface off the public internet, which Cisco says reduces the attack surface; we also recommend restricting it to administrative networks.
  • Vulnerability management: the July 2025 joint advisory on Interlock recommends prioritising patches for known exploited vulnerabilities in internet-facing systems.
  • Logging: Amazon recommends comprehensive logging with secure, centralised log storage kept separate from systems that could be compromised.
  • Remote access: the same joint advisory recommends preventing unknown or untrusted origins from accessing remote services on internal systems. We add an allowlist of approved remote access software.

Historical context and related activity

The Federal Bureau of Investigation (FBI), CISA, the Department of Health and Human Services (HHS) and the Multi-State Information Sharing and Analysis Center (MS-ISAC) described Interlock in a joint #StopRansomware advisory of 22 July 2025. It says the Interlock variant was first observed in late September 2024, targeting business, critical infrastructure and other organisations in North America and Europe. The initial access routes it describes are drive-by downloads from compromised legitimate websites, which it calls uncommon among ransomware groups, and the ClickFix social engineering technique. It lists ScreenConnect among the actors' tools, noting a cracked version in at least one incident. Amazon's account adds a different route: exploitation of an internet-facing management interface.

In the catalogue as published on 19 March 2026, earlier Cisco firewall entries marked as known ransomware use include three ASA and FTD flaws: CVE-2020-3580, added on 3 November 2021, CVE-2023-20269, added on 13 September 2023, and CVE-2020-3259, added on 15 February 2024.

Future outlook

This section is assessment. Amazon describes the campaign as active, lists two exploit source addresses as active in March 2026, and says it continues to monitor Interlock's operations. We assess that further attempts to exploit CVE-2026-20131 against unpatched FMC instances are likely (B2) in the coming weeks, with the exposure concentrated in management interfaces that are both unpatched and reachable from the internet.

Further reading