The Setup Was Already in Your Logs

Iran Was Inside Before the War Started. Here Is What That Looks Like.

The Server We Found on March 6

On March 6, five days before Handala wiped 200,000 Stryker devices, I published a threat intelligence report on an exposed Iranian operational server. The hostname was sdrhi. The primary IP was 157.20.182.49. The server was live, the directory was open, and whoever owned it was actively running credential operations against Israeli, Egyptian, UAE, and Jordanian targets.

That report is here: Iranian Threat Actor: Tools, Techniques, IOCs and IOAs (March 6, 2026).

I called it Iranian state-consistent based on the targeting profile, the Persian-language code artifacts, and the infrastructure patterns. What I did not say at the time, because I did not have the confirmation, was which group I was looking at.

I know now.

What We Were Looking At

The sdrhi server was running mass OWA brute force against 280 Israeli IP addresses. It was hosting Neo-reGeorg webshells on Exchange servers at the Portuguese Immigration Service and an unknown host at 69.167.160.144. It had already exfiltrated passport scans, credit card data, payroll records, and biometric databases from EgyptAir's Riyadh maintenance station. It was running Rclone to move stolen ERP backups from Wasabi cloud storage to Put.io. Custom brute force tooling with Persian-language comments. Operator handle of Sam across tmux sessions. Twenty-plus compartmentalized workspaces organized by operation.

The same week, Broadcom's Symantec Carbon Black Threat Hunter Team published a report on MuddyWater, the MOIS-affiliated APT also tracked as Seedworm, Temp Zagros, and Static Kitten. Their analysis documented a campaign running since early February 2026 targeting a U.S. bank, a U.S. airport, non-governmental organizations in the U.S. and Canada, and the Israeli operations of a defense and aerospace software supplier. The new backdoor they found was named Dindoor, running on the Deno JavaScript runtime. The second backdoor was a Python tool called Fakeset. Both signed with certificates from the same certificate cluster previously linked to MuddyWater tooling.

The exfiltration tool: Rclone. The destination: Wasabi cloud storage.

The victim list in the Symantec report matches the sdrhi targeting list almost exactly. EgyptAir. Israeli organizations across healthcare, hosting, immigration, and intelligence. The Jordanian government. UAE companies. Jewish and Israeli-linked NGOs. U.S. entities.

Ctrl-Alt-Intel, an independent threat research collective, separately accessed what they assessed to be MuddyWater infrastructure hosted in the Netherlands during the same period and pulled the same victim profile from the logs. Same tooling. Same target set. Same exfil infrastructure.

What I was looking at on March 6 was the pre-positioning phase.

The Two-Team MOIS Playbook

This is how MOIS runs destructive operations. It is not one group. It is a workflow.

Team one is MuddyWater. Their job is access. They get in quietly, establish persistence, harvest credentials, move laterally, and sit. They do not burn the network. They are there to collect and to hand off. They have been inside U.S. and Israeli infrastructure since at least early February.

Team two is Void Manticore, operating publicly as Handala. Their job is destruction. They receive the credentials and the access map that team one built. They do not need to find their way in. They show up to an unlocked house with a gasoline can.

At approximately 3:30 AM EDT on March 11, Handala activated those Entra ID Global Administrator credentials, logged into the Intune admin console, and issued mass wipe commands across every enrolled device in Stryker's fleet. No lateral movement. No novel exploit. No payload on endpoint. One API call to a cloud management plane that had been pre-accessed and pre-validated.

The 50 terabytes of data that Handala claims to have exfiltrated did not come out that morning. That data walked out during the dwell phase, while the IT team was looking at clean logs. The wipe was the closing message, not the operation.

What This Means for Your Environment

On March 10, one day before the Stryker wipe, the U.S. Intelligence Community issued a flurry of warnings to American companies and government agencies. FBI and NSA explicitly warned defense contractors. The warnings were not hypothetical. MuddyWater was already in.

Symantec's senior intelligence analyst put it plainly: already having a presence on U.S. and Israeli networks prior to the current hostilities means MuddyWater is in a potentially dangerous position to launch attacks. That was written about networks they confirmed. The number of networks they did not confirm is an open question.

If your organization has Israeli business ties, federal contracts, aerospace or medical device operations, or is running cloud-managed endpoints in a Microsoft environment, you need to answer one question before anything else: is your Entra ID Global Administrator activation requiring a fresh phishing-resistant MFA challenge, or is it accepting a session that already passed MFA?

Because that is the gap. That is what got Stryker.

The PIM Authentication Context Gap

The "Require MFA on PIM activation" checkbox in Entra looks like it solves this. It does not. If a session has already satisfied MFA requirements, PIM sees that and passes through. A stolen session token carries a valid MFA claim. The attacker does not get prompted again. They just activate the role. The fix is Authentication Context bound to FIDO2 or certificate-based authentication. That is in the detection pack.

What We Confirmed in the 72 Hours After the March 12 Post

Stryker confirmed manufacturing and shipping were disrupted, not just IT. The company is running additional shifts to address backlog. The SEC 8-K language is specific: the timeline for full restoration is not yet known.

The forensic picture from Stryker's own customer update page tells you exactly what survived and why. Everything running on Linux, AWS, or GCP was untouched: Vocera, care.ai, LifePAK, Mako, iBedVision, SurgiCount. Every one of those runs on independent infrastructure. Everything enrolled in Intune on Windows was destroyed. This is not a broad network compromise. It is a targeted strike on a single management plane.

The LIFENET clarification matters: hospitals disconnecting from LIFENET was a precaution they chose, not a Stryker system failure. Stryker confirmed LIFENET was operational throughout.

SYK dropped approximately nine percent in the days following the attack, losing roughly six billion dollars in market cap. The attack landed two days after Stryker launched its SmartHospital Platform at HIMSS 2026, a cloud-connected hospital ecosystem designed to link devices, data, and care teams. They told the healthcare sector to trust them with connected hospital infrastructure and 48 hours later their own Microsoft environment was wiped globally. That timing follows every SmartHospital sales conversation for the next year.

The MOIS-Cybercrime Alliance

The MOIS-cybercrime alliance is operational. Check Point documented MuddyWater using Qilin ransomware-as-a-service infrastructure to attack Israeli hospitals. MOIS is renting criminal infrastructure for plausible deniability. This is the same pattern the March 6 report documented: Iranian operators using commercial tools and commercial VPN exit nodes to obscure their tracks.

The Detection Pack

The original detection pack (v1) shipped March 12 and covers the full Handala wipe chain: Intune bulk wipe detection, Starlink ASN authentication, Iranian ASN authentication, off-hours admin console access, and executive-targeted psyop email delivery. It is here: Handala Detection Pack v1.

Detection Pack v2 adds five new rules covering the MuddyWater pre-positioning IOCs (Dindoor, Fakeset, Rclone to Wasabi and Backblaze), the PIM Authentication Context gap that enabled the Stryker wipe, the bulk wipe threshold control with a three-layer prevention architecture, stale session token detection, and Rclone exfiltration to known MuddyWater cloud infrastructure. It is here: Handala Detection Pack v2.

What to Do Today

1. Check whether your Global Administrator and Intune Administrator PIM role settings use the "Require Azure MFA" checkbox OR Authentication Context. If it is just the checkbox, you have the same gap Stryker had. Fix it today.
2. Enable Intune Multi-Admin Approval for wipe, retire, and delete actions. Ten minutes. No additional cost.
3. Deploy the bulk wipe threshold alert from v2. Five wipes in 15 minutes from a single identity is your automated tripwire.
4. Hunt your sign-in logs right now for authentications from AS14593 (SpaceX Starlink) and the Iranian ASN list from v1 that touched admin roles in the past 30 days. This is the retroactive check for pre-positioning.
5. Search your Intune audit logs for any wipe or retire events outside business hours in the past 30 days. The Stryker wipe hit at 3:30 AM EDT. If someone wiped devices at 2 AM and you do not have a ticket for it, that is an incident.

ThreatHunter.ai is an 18-year SDVOSB cybersecurity company. MILBERT is our identity threat detection platform, purpose-built to find credential-based attacks at the pre-use phase. ARGOS is our managed detection and response service with human analysts on watch around the clock. If you want us to deploy these rules, tune them against your baseline, or run a retroactive hunt across your Entra and Intune logs, reach out.