A heavy week. Interlock ransomware had a month-long head start on a Cisco FMC zero-day before anyone knew it existed. Iran-linked hacktivists wiped tens of thousands of Stryker devices using the company’s own endpoint management tooling. Google patched its third Chrome zero-day of 2026. And an identity protection firm got breached via a phone call. Let’s get into it.
Threat Landscape
Interlock ransomware exploits Cisco FMC zero-day (CVE-2026-20131, CVSS 10.0)
This is the big one. Amazon’s threat intelligence team revealed that the Interlock ransomware group had been exploiting CVE-2026-20131 in Cisco Secure Firewall Management Center since 26 January, a full 36 days before Cisco disclosed and patched it on 4 March. The flaw is an insecure deserialisation bug in FMC’s web management interface. Unauthenticated, remote, and it gives you root. The attack chain works by sending crafted HTTP requests containing serialised Java objects to a specific path. After gaining execution, the payload calls back to attacker infrastructure to confirm the compromise and pulls down a Linux binary tied to Interlock’s tooling. Amazon also stumbled across a misconfigured Interlock server, which exposed their full toolkit: PowerShell reconnaissance scripts that hoover up OS details, Hyper-V inventories, browser credentials, and RDP event logs across multiple hosts. Timestamp analysis puts the group in the UTC+3 time zone. CISA added it to the KEV catalogue and gave federal agencies until 22 March to patch.
What makes this worth sitting with: Cisco’s own internal security team found the bug during routine testing, but Interlock found it first. That gap, where a vulnerability exists and is being exploited but nobody on the defensive side knows about it, is the bit that keeps breaking patching-centric security models. FMC sits at the centre of firewall management for a lot of organisations, so a compromised instance gives an attacker a staging point for credential harvesting, configuration tampering, and lateral movement across the entire firewall estate.
Stryker wiped via Microsoft Intune, no malware required
On 11 March, pro-Iranian hacktivist group Handala compromised an administrator account at medical technology firm Stryker and used it to create a new Global Administrator account in their Microsoft environment. Between 05:00 and 08:00 UTC, they used Microsoft Intune’s native remote wipe command to erase data from roughly 80,000 devices. Laptops, phones, tablets. Some employees had personal devices enrolled and lost personal data. No malware. No ransomware. Just living off the land with the company’s own device management platform. Handala claimed 50TB of data theft, though investigators have found no evidence of exfiltration so far. Stryker confirmed medical devices were unaffected, but their electronic ordering, manufacturing, and shipping systems remain disrupted. The FBI seized Handala’s leak site, and CISA issued guidance urging organisations to harden their Intune environments, specifically recommending multi-admin approval for destructive actions like device wipes.
This one sits badly with me. The attacker didn’t need to write a single line of malicious code. They compromised an identity, escalated to global admin, and used a built-in feature as the weapon. If your MDM platform can wipe 80,000 devices in three hours, it can be turned against you in three hours. The question for every IT team reading this: could a single compromised admin account do the same thing in your environment right now?
Google patches Chrome zero-days number two and three for 2026
Google released an emergency update for Chrome (146.0.7680.75) fixing two actively exploited zero-days. CVE-2026-3910 (CVSS 8.8) is a type confusion bug in the V8 Maglev JIT compiler’s Phi untagging pass, where incorrect type inference lets an attacker achieve code execution inside the browser sandbox via a crafted HTML page. CVE-2026-3909 is an out-of-bounds write in the Skia graphics library with the same severity rating. Both were discovered by Google TAG on 10 March. CISA added both to the KEV catalogue with a 27 March remediation deadline. These bring Chrome’s 2026 zero-day count to three, after CVE-2026-2441 was patched in February. Google tracked 90 zero-days exploited in the wild across 2025, up from 78 in 2024, with enterprise technologies accounting for nearly half.
ConnectWise ScreenConnect session hijacking (CVE-2026-3564, CVSS 9.0)
ConnectWise disclosed a critical flaw in all ScreenConnect versions before 26.1. The vulnerability comes down to ASP.NET machine keys being stored in plaintext within server configuration files. If an attacker can access those files, through misconfiguration, another exploit, or lateral movement, they can extract the keys and forge valid session tokens. That means impersonating legitimate users and bypassing authentication entirely. ConnectWise said researchers have observed attempts to abuse disclosed ASP.NET machine key material, though the company says it has no confirmed evidence of exploitation against its own hosted instances. Cloud customers were automatically updated; on-premise deployments need to upgrade to 26.1 manually. Given ScreenConnect’s history as a target (remember the CVE-2024-1709 and CVE-2024-1708 campaign), this one deserves fast action.
Aura identity protection breached via vishing
Identity protection company Aura confirmed that roughly 900,000 records were accessed after an employee was socially engineered through a targeted voice phishing call. The attacker had access for about an hour before being cut off. Most of the exposed data came from a marketing tool inherited from an acquisition in 2021, primarily names and email addresses. Have I Been Pwned added the dataset, which also includes phone numbers, IP addresses, physical addresses, and customer service notes. No SSNs, passwords, or financial data were compromised. ShinyHunters claimed the breach and published the data on 14 March after failed extortion attempts.
The irony of an identity protection company being breached through social engineering is hard to miss. But it also makes a fair point: vishing works. It works against security companies. It works against people who should know better. This was a single phone call that gave an attacker access to nearly a million records.
Magecart skimmer hiding in favicon EXIF metadata
A newly documented Magecart campaign is embedding payment card skimming code inside the EXIF metadata of dynamically loaded third-party favicon images. The attack uses a three-stage loader chain: the initial script looks like a benign third-party include, it fetches a favicon from an attacker-controlled domain, parses the EXIF data to extract a malicious JavaScript payload, and executes it via new Function(). Stolen card data is then POSTed to an external server. Because the malicious code never touches the merchant’s source repository, no static analysis tool, repo scanner, or CI/CD pipeline check will catch it. Detection requires client-side runtime monitoring of what actually executes in the browser at checkout.
Other notable items from the week:
Microsoft’s March Patch Tuesday addressed 82 CVEs, including 8 critical flaws. CISA ordered patches for actively exploited vulnerabilities in Zimbra Collaboration Suite (CVE-2025-66376) and Microsoft SharePoint (CVE-2026-20963). A critical buffer overflow was disclosed in the GNU InetUtils telnet daemon (CVE-2026-32746, CVSS 9.8) that allows pre-authentication remote code execution. And Google’s March Android Security Bulletin patched 129 vulnerabilities including an actively exploited Qualcomm chipset integer overflow (CVE-2026-21385) affecting 234 chipsets.
Practical Guidance
Review your MDM/UEM admin controls today. If you run Intune, Jamf, VMware Workspace ONE, or similar, the Stryker incident should have you checking your own exposure. Specifically: enforce multi-factor authentication on all MDM administrator accounts, enable multi-admin approval for destructive operations like device wipes and factory resets, restrict Global Administrator creation to a break-glass process with alerting, and monitor for new admin account creation or unusual bulk device operations. Microsoft published hardening guidance for Intune after Stryker. Read it.
Patch Cisco FMC immediately and assume compromise. If you were running a vulnerable FMC instance with the management interface accessible over the network between late January and early March, patching alone is not enough. Review Amazon’s published IOCs (IP addresses, malicious domains, JA3 fingerprints). Look for unexpected outbound HTTP PUT requests from your FMC, unrecognised binaries, and suspicious configuration changes. If the FMC management interface was internet-facing, treat this as a confirmed incident until you prove otherwise.
Update Chrome and push the update to managed fleets. Three zero-days in three months. If your organisation is not enforcing automatic Chrome updates, you are running behind. Ensure version 146.0.7680.75 or later is deployed. Chromium-based browsers like Edge, Brave, and Opera will need their own updates.
Upgrade ScreenConnect on-premise to 26.1. Cloud instances were patched automatically. If you run ScreenConnect on your own infrastructure, upgrade now. Review session logs for unusual authentication activity and check whether any configuration files or backups have been accessed by unexpected accounts.
Talk to your teams about vishing. The Aura breach is a reminder that voice-based social engineering still works, and standard phishing awareness training often skips voice channels entirely. Consider running vishing simulation exercises. Establish a clear policy that sensitive account actions requested via phone calls must be verified through a second channel.
From the Field
I keep coming back to the Stryker incident because it reflects something I see regularly during engagements: the gap between what a tool can do and what people assume it will be used for. MDM platforms are designed with destructive capabilities baked in for good reason. Lost device? Wipe it. Employee leaves? Wipe it. But the assumption is always that a trusted admin will be the one pressing the button. Nobody models the scenario where the admin account is the thing that gets compromised, and now those same capabilities become the attack.
During a recent assessment on a client’s Microsoft environment, I found that a single compromised Global Administrator account would have been enough to push arbitrary scripts to every managed endpoint, wipe devices, and modify Conditional Access policies to lock out the rest of the admin team. The client had MFA on the account, which is good, but no alerting on new Global Admin creation, no multi-admin approval for bulk operations, and no separate break-glass account with monitoring. The Stryker attack is exactly that scenario played out for real.
The Cisco FMC zero-day is another one that maps to a pattern I see too often: management interfaces exposed to more of the network than they need to be. FMC consoles, vCenter instances, SIEM dashboards, backup management portals. These are high-value targets precisely because they hold credentials, configurations, and monitoring pipelines. Yet they are consistently treated as internal tooling rather than critical attack surface, and they get patched on a slower cadence than production infrastructure. If you are running any management plane console that is reachable from anything other than a dedicated management VLAN with strict access controls, you are carrying risk that the Interlock campaign just proved is being actively exploited.
On the web app side, the Magecart EXIF favicon technique matters for anyone doing ecommerce testing: your scope needs to include what runs in the browser at checkout, not just what lives in the repository. I have lost count of the number of assessments where the client’s own code is clean but their checkout page loads half a dozen third-party scripts that nobody is monitoring. Subresource Integrity (SRI) helps for scripts you control, but it does not cover dynamically loaded resources from third-party CDNs. Content Security Policy can restrict script sources, but it needs to be strict enough to actually block unexpected domains, and most CSP configurations I see in the wild are either too permissive or report-only with nobody reading the reports.
This is a Pthx newsletter edition. Subscribe to receive future editions directly.