The Stryker breach didn't match the playbook. That shouldn't be a surprise.

On the morning of March 11, employees at Stryker Corporation offices across 79 countries turned on their laptops and found them wiped and unusable. Personal phones enrolled in the company's BYOD programme had been factory reset overnight, taking photos, banking apps, and authenticator tokens with them. Login pages had also been defaced with the logo of Handala, a persona operated by Iran's Ministry of Intelligence and Security (MOIS).

In a break from the standard Handala playbook, there was no ransomware, no malware, and no exploit chain. The attacker simply logged into Microsoft Intune with compromised Global Administrator credentials, abused a legitimate feature, and wiped over 80,000 systems, servers, and mobile devices.

What a Handala attack was supposed to look like

Handala has a reputation for being a manual, hands-on intrusion team whose TTPs have typically included VPN credential brute-force for initial access (hundreds of logon attempts from commercial VPN nodes), supply chain compromise via managed service providers, RDP as the primary lateral movement method, ADRecon for Active Directory enumeration, LSASS credential dumping via comsvcs.dll, and GPO logon scripts for wiper distribution.

If you had invested in detection logic around Handala's documented toolkit (BiBi Wiper file extensions, Cl Wiper's EldoS RawDisk driver calls, No-Justice partition table manipulation, Karma Shell's Base64-with-XOR web shell patterns) none of it would have fired. Wiper malware signatures, web shell indicators, RawDisk driver loading, MBR/GPT manipulation, SharePoint exploitation patterns, anomalous RDP/SMB lateral movement: all reasonable detection priorities given the group's threat intelligence profile, but all irrelevant when it mattered most.

What Handala actually did

The Stryker attack departs from the documented baseline across the kill chain.

An organisation with detections built around malware signatures, file system manipulation, and anomalous process execution would be unprepared for an attack with zero malware artifacts, where every action was a legitimate administrative command.

But while the methods were different, the core objective — mass destruction of data — is entirely consistent with previous campaigns, just through a legitimate management plane rather than custom malware.

The kill chain looks different now

The attack path was devastatingly simple. It didn't require lateral movement because there was nothing to move laterally through. It didn't require privilege escalation because they directly compromised a global administrator account. Every device managed by Intune was already within reach.

The traditional network-centric kill chain collapses into: compromise identity, access management plane, execute objective.

This is not specific to Iran-aligned actors. Russian groups are leveraging AITM phishing kits and abusing Microsoft 365 OAuth tokens via consent attacks. Scattered Spider built an operational model around social engineering and SSO account takeover. And now Handala has demonstrated that a nation-state destructive operation can be executed entirely by abusing legitimate enterprise tooling.

This kind of attack is more direct, faster to execute, and carries a significantly lower barrier to entry. You don't need custom malware and exploit development when you can log in using as-a-Service kits or partner with an access brokering specialist.

The big picture of Iranian cyber TTPs

Iran's offensive cyber capability is split between two rival intelligence bureaucracies. The Ministry of Intelligence and Security (MOIS) runs groups like APT34, MuddyWater, Scarred Manticore, and Void Manticore, which tend toward long-dwell espionage and coordinated destructive operations, often using a documented dual-actor handoff model where Scarred Manticore conducts stealthy espionage before handing targets to Void Manticore (Handala) for destruction.

The Islamic Revolutionary Guard Corps (IRGC) runs a wider set of groups, including APT33/Peach Sandstorm, APT35/Charming Kitten, APT42, Tortoiseshell/Imperial Kitten, Cotton Sandstorm, and CyberAv3ngers. IRGC groups cover espionage, destructive attacks, influence operations, election interference, ICS targeting across U.S. water and wastewater facilities), and individual surveillance.

IRGC groups have already shifted to identity-first TTPs

On the IRGC side, the shift toward identity-centric operations is well-documented:

• APT33/Peach Sandstorm shifted decisively toward credential-based initial access starting in early 2023, with Microsoft documenting large-scale password spray campaigns targeting thousands of organisations, Golden SAML attacks for persistent cloud access, and the use of fraudulent Azure subscriptions for C2 infrastructure.

• APT42, assessed by Mandiant to operate on behalf of the IRGC-IO, has made credential harvesting and MFA bypass its core competency, operating almost entirely within cloud environments post-compromise and registering its own Microsoft Authenticator on compromised accounts for persistent access.

• APT35 (aka Imperial Kitten/Tortoiseshell) was observed targeting cloud identities in November 2025, deploying the Evilginx2 AitM toolkit against Microsoft 365 users in Israel.

• CrustyKrill (TA455/Smoke Sandstorm) uses fake Google Meet and Microsoft Teams pages with a live operator intercepting 2FA codes in real time, alongside Azure Web Apps for C2.

A joint advisory from six nations (FBI, CISA, NSA, CSE, AFP, ASD, advisory AA24-290A, October 2024) confirmed the pattern at the government level, documenting Iranian actors using brute force, password spraying, and MFA push bombing to compromise critical infrastructure accounts since October 2023, and assessing that the actors sell this access on cybercriminal forums.

MOIS groups are changing their approach too

MOIS groups have historically focused on different approaches, with APT34's tradecraft centring on DNS tunneling, custom backdoors, and web shell persistence, and MuddyWater relying on spearphishing with RMM tool abuse. But there are recent indications of a shift.

Cloudflare's 2026 Threat Report profiles ConvolutedKrill (APT34/OilRig) as a credential-theft specialist that leverages compromised government accounts to exploit regional trust between state entities, using compromised government email to send lures to other state organisations.

There is also recent evidence from March 2026 that MOIS-linked actors (including Handala) are now directly engaging with the criminal ecosystem, which would enable them to more readily access identity-based initial access capabilities through as-a-Service kits and relationships with initial access brokers.

The Stryker attack path is operationally consistent with the direction the Iranian threat ecosystem has been moving, even though it departs from Handala's own documented TTPs. Many of Handala's previous methods — targeting managed service providers and IT vendors, malware spearphishing, VPN credential stuffing — can be repurposed in identity-focused social engineering attacks, particularly when boosted with widely available tools already powering criminal campaigns.

The problem with over-indexing on TTPs

Threat intelligence has real value. Attributing campaigns to named groups, mapping their techniques to MITRE ATT&CK, and generating detection rules gives defenders a meaningful starting point. The problem is treating a specific actor's historical TTP catalogue as the primary basis for detection logic, rather than combining it with the broader trends in attacker behaviour visible across the entire landscape.

A documented TTP catalogue is a historical record, not a predictive model. Operators are creative and pragmatic. If the path of least resistance into a Fortune 500 company is a compromised admin credential and a legitimate MDM feature, no serious attacker is going to deploy custom wiper malware instead because that's what they used last time.

If your threat model says you're a plausible target for an Iranian threat group, and the trend data tells you that identity compromise is the most common initial access method across all actors, the rational response is to harden your identity infrastructure, not just deploy signatures for BiBi Wiper. When the specific actor profile crowds out the general trend data, you end up building defences against the last attack and leaving yourself exposed to the shift that every actor is going through.

Evaluating the security guidance

In the wake of the breach, industry guidance has settled around enforcing phishing-resistant MFA on privileged accounts, implementing just-in-time privilege activation via PIM, enabling Multi Admin Approval for high-risk Intune operations, configuring anomaly alerting on bulk device actions, and segregating administrative identities from everyday user accounts. This is all sound advice, but these recommendations are designed to limit what an attacker can do after an account has already been compromised — introducing friction, but not blocking them entirely.

The detection challenges compound this. Entra ID sign-in logs and Intune audit logs exist in separate systems with separate correlation IDs. Tracing a sign-in to a subsequent device action requires deliberate log integration that many organisations haven't implemented. The logs do record "wipe ManagedDevice" events, but in most deployments they are not wired to real-time alerting. And the underlying action, Intune's Remote Wipe, is a legitimate feature used routinely in enterprise IT. The attack could have succeeded even with all of these in place.

In a world where a compromised account can be rapidly exploited, it's vital to focus on improving detection and prevention as early as possible in the kill chain — combating initial access techniques themselves.

Initial access TTP breakdown

The most likely identity-based initial access methods leveraged by Handala (or its affiliates) in the Stryker scenario come down to two scenarios.

Scenario 1: Weak or compromised credentials (likely infostealer-sourced)

This is the most likely source of the breach, and has been suggested by others in the security community with evidence of historical infostealer infections containing what appears to be M365 admin credentials.

Given the credentials seem to be months to years old, this would explain why a recent malware compromise has not been linked to the breach. It's also a reminder that an initial breach can lie dormant until an attacker opts to capitalize — often the case where initial access brokers are involved.

It's tempting to treat credential attacks as a solved problem, but the data suggests otherwise. Of the last million logins recorded by Push, 1 in 4 were password-based (not SSO), 2 in 5 lacked MFA, and 1 in 5 used a weak, breached, or reused password.

The Snowflake breach is the canonical example: ShinyHunters breached over 165 organisations, and over a billion records, by logging into Snowflake tenants with stolen credentials. 80% of compromised accounts had prior breach exposure dating back to 2020.

Infostealers can be delivered in many ways, with ClickFix-style attacks being the preferred modern method. Credential and session theft can also result from malicious browser extensions siphoning data directly from pages visited in the browser, though this is a less prevalent method and less aligned with Handala's previous VPN credential stuffing operations.

Whether this is an internal admin or a contractor working for an outsourced IT provider, infostealer-driven credential theft is a highly likely root cause.

Scenario 2: Spearphishing with an AitM or device code phishing payload

AitM phishing is the default phishing approach today. It reliably bypasses most forms of MFA, can be rapidly spun up using off-the-shelf tools with detection evasion features, and can be delivered over any channel — with social media apps like LinkedIn increasingly the chosen vector instead of email.

Device code phishing is a fast-growing alternative (we've observed a 15x increase this year) that is particularly effective in this scenario. It's a post-auth attack where all a victim needs to do is enter an attacker-provided code into a legitimate app page for their account to be compromised. There's no credential theft or MFA bypass involved, meaning it circumvents even phishing-resistant controls like passkeys. It also works particularly well when targeting a Microsoft admin account, since Intune exploitation can be performed with CLI access.

Both methods could have involved a voice-based component seen in recent campaigns, as well as major breaches last year.

Closing thoughts

The Stryker attack reflects what attackers everywhere — from ransomware affiliates to nation-state operators — are already doing. Identity-based initial access, abuse of legitimate management tooling, and living-off-the-land execution are the current standard operating procedure.

Even with a perfectly hardened environment, most public breaches today involve attackers hijacking SSO mechanisms to move into connected applications, exfiltrating data for resale or extortion, and in some cases leveraging cloud services and admin platforms to deploy ransomware (the Scattered Spider playbook of dropping ransomware via VMware management portal being a well-documented example).

The majority of attackers will have no interest in destructively wiping an Intune environment — that's difficult to monetise. But the techniques that enabled the Stryker wipe are the same as those that enable financially motivated breaches at scale, pointing to a challenge that extends well beyond Iranian threat actors and MDM hardening.

If your defensive posture was calibrated primarily against a specific actor's historical playbook rather than the broader evolution in attacker methods, Stryker is what that gap looks like.

About Push Security

Push Security's browser-based security platform provides comprehensive detection and response capabilities against the leading cause of breaches. Push blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong — you can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your identity attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.