Satine Sentinel: March 13, 2026

March 13, 2026

Iran went kinetic in cyberspace this week, and the attack vector wasn’t phishing or a zero-day. It was your organization’s own device management platform turned against you. A $100B medical device manufacturer had its entire global fleet wiped from a cloud console in the same time it takes your SOC to triage a tier-2 alert. Separately, the largest healthcare billing processor most clinicians have never heard of confirmed what investigators already suspected: an attacker spent eleven months inside their insurance eligibility system, quietly draining records for 3.4 million patients before anyone noticed. And a financially motivated ransomware crew just showed the rest of the threat landscape how to commission custom malware in an afternoon using whatever AI model was handy enough to bypass safety filters.

This week: the Handala campaign demonstrates why your MDM solution is now a weapon of mass disruption, why healthcare supply chain vendors are the Change Healthcare incident waiting to repeat, and what AI-generated ransomware tooling looks like in a live-fire engagement before the techniques become commodity.

Handala Wipes Stryker Across 79 Countries via Microsoft Intune Abuse

What happened: On March 11, the Iran-linked Handala group executed a destructive wiper operation against Stryker Corporation, a $25B Fortune 500 medical device manufacturer. Employees at offices across 79 countries powered on their devices to find them wiped and login screens replaced with the Handala logo. Stryker’s SEC filing confirmed “a global network disruption to our Microsoft environment” while explicitly stating no ransomware or malware was detected, a framing that obscures the actual attack mechanism. Manufacturing, shipping, and product design operations went offline, with roughly 5,500 employees in Cork, Ireland alone sent home.

Technical details that matter:

Initial Access / Persistence: Entry vector not officially confirmed, but British researcher Kevin Beaumont and other threat intelligence analysts assess Handala’s pattern as credential harvesting followed by prolonged dwell time (“break in, lay low for months, exfiltrate, then delete everything including org backups”). The absence of malware detection is consistent with living-off-the-land via administrative tooling.
Execution: Attackers appear to have abused Microsoft Intune (Endpoint Manager), the cloud-based MDM solution, to issue a remote wipe command against all enrolled devices simultaneously. This explains Stryker’s “no malware” statement: they’re technically correct, the wipe was executed through a legitimate admin function.
MITRE ATT&CK: T1485 (Data Destruction), T1561 (Disk Wipe), T1072 (Software Deployment Tools used maliciously), T1491 (Defacement), T1005 (Data from Local System for exfil)
Scope: Handala claims 200,000+ systems, servers, and mobile devices wiped and 50TB of data exfiltrated. Windows devices were hit hardest. Stryker instructed employees to immediately uninstall Intune and disconnect from all networks.
Geopolitical trigger: Handala framed the attack as retaliation for a February 28 U.S. missile strike on a school in Minab, Iran. Palo Alto’s Unit 42 links Handala to Iran’s MOIS (Ministry of Intelligence and Security) as the “Void Manticore” cluster.
Concurrent operation: On the same day, Handala claimed a separate breach of Verifone’s Israeli payment infrastructure, publishing screenshots of merchant dashboards, terminal identifiers, Windows server access, and internal network paths. Verifone denied any confirmed breach or service disruption, but independent researchers reviewing the screenshots assessed the screenshots show access to a management plane coordinating thousands of POS terminals, not a single merchant endpoint. The Verifone claim remains unverified but technically plausible given the screenshot detail.

Why critical institutions should care: The Stryker attack is not a healthcare story. It is a universal story about what happens when an organization’s device management platform becomes the attacker’s most powerful tool. Every enterprise running Microsoft Intune, Jamf, VMware Workspace ONE, or any comparable MDM solution has handed a potential adversary the keys to a remote wipe of every managed device in the fleet. The attack required no malware, no lateral movement in the traditional sense, and generated no alerts that a conventional security stack would catch. Stryker’s SEC filing noting “no ransomware or malware” is technically accurate and operationally misleading at the same time. The Intune administrative console was the weapon. For healthcare specifically, the ripple risk extends beyond Stryker’s own operations: the company’s devices are embedded in surgical suites and emergency departments globally, and every day of manufacturing and shipping disruption is a day that critical device inventory does not reach hospitals.

Key sources:

TriZetto Provider Solutions: Eleven Months Inside the Healthcare Billing Stack

What happened: On March 6, Cognizant-owned TriZetto Provider Solutions filed breach notifications with state attorneys general confirming that 3,433,965 patients had their protected health information stolen. The attacker first accessed TriZetto’s insurance eligibility web portal in November 2024. The company did not detect the intrusion until October 2, 2025, nearly eleven months later. Notification letters to affected patients did not begin until February 2026, more than a year after the initial compromise. The breach targeted TriZetto’s revenue cycle management infrastructure, specifically the insurance eligibility verification system used by healthcare providers to confirm patient insurance coverage before treatment.

Technical details that matter:

Access vector: Unauthorized access to an external-facing web portal used by TriZetto’s healthcare provider clients. The breach is classified as an external system hacking incident. No ransomware group has claimed responsibility and no stolen data has appeared on dark web leak sites, suggesting either ongoing negotiation, data held in reserve, or a threat actor with different objectives than immediate monetization.
Dwell time: 327 days between initial access and detection. The absence of detection across nearly a year indicates no meaningful behavioral anomaly detection, egress filtering, or data access monitoring on the portal environment.
Data classes compromised: Full names, birth dates, addresses, Social Security numbers, Medicare beneficiary identifiers, health insurance member numbers, provider names, health insurer names, primary insured information, and detailed demographic and health insurance data. Not payment card or bank account data.
Supply chain blast radius: TriZetto touches an estimated 200 million Americans across 875,000 healthcare provider locations. This is not a breach of a single hospital. The eligibility verification data stolen aggregates patient records from every provider that used TriZetto for insurance checks, meaning the actual victim population is distributed across thousands of unrelated healthcare organizations. OCHIN Epic, a non-profit managing EHR systems for rural and community providers, confirmed approximately 9% of its patient network was affected.
No attacker attribution: No group has claimed the intrusion. The 11-month, low-and-slow pattern without data publication is consistent with either a sophisticated financially motivated actor waiting for the right leverage moment, or a state-sponsored operation collecting healthcare intelligence at scale.

Why critical institutions should care: TriZetto is the Change Healthcare scenario with the volume turned down just enough to avoid systemic outages, but with the same underlying architecture failure: a single administrative vendor sitting between patients, providers, and insurers, aggregating sensitive records from thousands of sources into a single compromise point. The 327-day dwell time is not exceptional in healthcare, it is normal. Security operations in healthcare consistently underinvest in monitoring administrative and billing infrastructure relative to clinical systems, treating revenue cycle management platforms as lower-sensitivity environments despite the fact that they aggregate SSNs, Medicare identifiers, and insurance data at population scale. The data stolen in this breach is ideal for medical identity theft and targeted spear phishing: an attacker who knows your Medicare number, insurer, provider name, and birth date can craft credential-harvesting campaigns that are extremely difficult to distinguish from legitimate communications.

Key sources:

Interlock Ransomware Deploys AI-Generated Slopoly Backdoor

What happened: IBM X-Force published analysis on March 12 documenting an early 2026 Interlock ransomware attack in which the threat actor, tracked as Hive0163, deployed a previously unseen backdoor called Slopoly. IBM assessed with strong confidence that Slopoly was generated using a large language model, making it one of the first documented instances of AI-generated custom malware deployed in a production ransomware operation by a financially motivated group. The attack began with a ClickFix social engineering lure, progressed through multiple backdoor stages, and terminated in Interlock ransomware payload delivery. Hive0163 maintained access to the compromised server for over a week before deploying the final payload.

Technical details that matter:

Initial Access (T1566/T1204): ClickFix social engineering, a technique where users are tricked into manually executing a malicious command, typically via a fake browser error page prompting a clipboard paste into Run or PowerShell.
Slopoly (AI-Generated Backdoor): Deployed as a PowerShell script into C:\ProgramData\Microsoft\Windows\Runtime\ by a builder tool. Functions as a C2 client supporting: download/execute of EXE, DLL, and JavaScript payloads; adjustable beacon intervals; SOCKS5 proxy tunneling; reverse shell establishment; self-update and self-termination. IBM’s indicators of AI authorship include extensive inline comments, structured logging, well-named variables, organized error handling, and an unused “Jitter” function consistent with iterative LLM development artifacts. The script described itself internally as a “Polymorphic C2 Persistence Client” but does not exhibit true runtime polymorphism; the builder instead randomizes configuration values and function names per-instance.
Additional Tooling: NodeSnake (JavaScript backdoor with SOCKS5 and reverse shell via WebSockets), InterlockRAT (more capable follow-on C2 framework), AzCopy (Microsoft Azure data transfer utility used for exfiltration), Advanced IP Scanner (reconnaissance).
Interlock Ransomware Payload: 64-bit PE delivered via JunkFiction loader, typically dropped in temp folders. Runs as a SYSTEM-level scheduled task. Uses Windows Restart Manager API to release file locks before encryption. AES-GCM per-file encryption with RSA-protected session keys. Appends .!NT3RLOCK or .int3R1Ock extensions. Ransom note: FIRST_READ_ME.txt.
Threat actor context: Hive0163 has assessed ties to former ITG23 crypter developers and the Rhysida ransomware operators. Previous Interlock victims include the Texas Tech University System, DaVita (dialysis), Kettering Health, and the City of Saint Paul, Minnesota.
AI safety evasion: IBM noted that variable naming conventions within Slopoly indicate the model was explicitly prompted to produce malicious functionality, meaning whatever safety controls existed in the underlying model were bypassed. IBM could not determine which model was used; code quality suggests a less advanced model.

Why critical institutions should care: The significance here is not the sophistication of Slopoly itself: IBM was explicit that AI-generated malware does not yet pose a fundamentally novel threat from a technical standpoint. The significance is what it signals about the barrier to entry. Threat actors who previously needed weeks to develop a new backdoor can now commission one in an afternoon, with cleaner code and better operational documentation than most human-authored malware. IBM’s framing is correct: this disproportionately enables threat actors by compressing development time. The ClickFix initial access vector is worth particular attention for institutional environments. It requires no vulnerability exploitation and bypasses most email security controls because the payload is manually executed by the user, not delivered as an attachment. If your security awareness training still models threats as suspicious attachments or unknown links, it does not address the manual execution scenario that ClickFix exploits.

Key sources:

The Pattern This Week

Three different threat actors. Three different objectives. One consistent theme: attackers are operating inside the administrative control plane, not outside it.

Handala did not hack Stryker’s devices. They took control of the console that manages Stryker’s devices and used it as designed. The attacker who spent 327 days inside TriZetto did not breach a hospital. They quietly aggregated records through the billing layer that hospitals trust implicitly. Hive0163 did not develop a sophisticated new tool in-house. They prompted a language model into producing a functional C2 client and deployed it the same week.

The defender’s problem across all three incidents is the same problem restated at different layers: trusted systems, trusted platforms, and trusted administrative functions are the attack surface your detection stack is not watching. Your MDM console does not generate a SIEM alert when an admin issues a remote wipe. Your billing portal does not flag anomalous eligibility query volume after eleven months of baseline drift. Your malware sandbox detects signatures, not well-commented PowerShell that behaves exactly like the tool it claims to be.

The controls that would have caught each of these attacks exist. Multi-person authorization for high-impact MDM operations. Behavioral egress monitoring on provider-facing web portals. Execution policy controls that block unsigned PowerShell in non-standard directories. The gap is not technical. It is that critical institutions continue to treat administrative infrastructure as a secondary monitoring priority until it becomes the primary incident.

See you next week.