Vercel Security Incident: What Developers Need to Know Right Now
April 22, 2026
At 3:30 in the morning on 11 March 2026, something started happening across Stryker Corporation’s global network. There was no alarm. No explosion. No ransomware note demanding Bitcoin. Employees would not find out until they got to their desks a few hours later.
By the time the European offices opened that morning, the situation inside Stryker had already been described internally as a “severe, global disruption.” Staff in Ireland had been sent home. Crisis communications had shifted to personal WhatsApp groups because corporate systems were already gone. And across 79 countries, tens of thousands of employees were staring at blank screens — their laptops, company phones, and even their personal devices showing nothing but a slingshot boy logo where the login page used to be.
That logo belonged to Handala. And what they had just done had never quite been done like this before.
No malware was used. Not a single exploit. Not one line of custom attack code. They had taken a Fortune 500 medical technology company — $25 billion in annual revenue, 56,000 employees, devices embedded in hospital supply chains across 61 countries — and knocked it completely offline using nothing more than the company’s own IT management tools.
Who Is Handala — And Why They Did This
Before getting into the technical mechanics, it helps to understand who pulled this off — because Handala is not what it appears to be.
On the surface, Handala presents as a hacktivist group. They take politically charged positions, use symbolic imagery, and frame their attacks as acts of resistance. The slingshot boy logo is a direct reference to Palestinian resistance iconography. But multiple independent intelligence firms — Palo Alto Unit 42, Check Point Research, CrowdStrike, and Microsoft — all assess Handala as a front group operated directly by Iran’s Ministry of Intelligence and Security (MOIS).
The group operates under several names: Void Manticore, Storm-0842, Dune, Red Sandstorm, Banished Kitten. They run regional personas too, including Karma and Homeland Justice. The “hacktivist” label gives Iran plausible deniability. The actual capability behind the attacks is a state-intelligence apparatus.
Handala stated the Stryker attack was retaliation for ongoing US and Israeli military strikes on Iran. That matters because it tells you this was not a financially motivated attack. The goal was not extortion. The goal was maximum disruption — and then a very public, very humiliating message.
Stryker just happened to be in the crosshairs. Any large US company with the same architectural gaps would have been equally vulnerable.
The Attack Did Not Start on 11 March
Here is the part that should make every IT administrator uncomfortable: what happened at 3:30am was not the beginning. It was the end.
Check Point Research, which tracked Handala’s activity in the months before the attack, identified hundreds of login attempts and brute-force probes against VPN infrastructure linked to the group. After Iran’s internet shutdown in January 2026, the group switched from commercial VPN nodes to Starlink IP ranges, deliberately blending into legitimate satellite traffic to avoid detection.
The Handala logo appearing on login screens before the wipe was not a spontaneous act. You cannot gain access to a Global Administrator account, navigate to the Intune console, configure a company-wide wipe policy, and execute it across 79 countries in a single session. The attackers had been inside — quietly — for months. The wipe was the final act of a long operation that had prioritised infiltration, reconnaissance, and data theft first.
Stryker had also disclosed a separate breach in December 2024, in which unauthorised access between May and June of that year led to the exfiltration of personally identifiable information and medical records. Whether footholds from that earlier intrusion fed directly into the March 2026 attack is still under investigation. But the timeline is worth noting.
How They Actually Got In: AiTM Phishing and Session Token Theft
This is the technical core of the attack, and it is the part that most organisations are not prepared for.
The question everyone asks about the Stryker attack is: how did they get past MFA? And the honest answer is that they did not bypass MFA at all. They stole what MFA produced. This mirrors the approach used in the recent Vercel incident.
What is AiTM Phishing?
Traditional phishing steals your password. That is old and increasingly ineffective because passwords alone are not enough to access most enterprise systems. Adversary-in-the-Middle (AiTM) phishing goes a step further.
In an AiTM attack, the attacker sets up a transparent proxy — usually using a framework like Evilginx — that sits between the victim and the real login page. The victim sees the legitimate Microsoft login. They enter their password. They complete their MFA challenge. Everything looks completely normal. But behind the scenes, every request and response passes through the attacker’s proxy.
When Microsoft issues the session token after a successful MFA login — that token is the thing that says “this person has already been verified” — the attacker captures it in real time. They now have a fully authenticated session that belongs to whoever just logged in. No password needed. No MFA needed. The hard work of authentication has already been done, and they have the result.
The attacker imports the stolen session cookie into an anti-detect browser, which masks their infrastructure and makes the access look like it is coming from a legitimate source. To Microsoft Entra ID, it looks like a normal authenticated session. To Stryker’s security tools, nothing unusual has happened.
This is why standard MFA — SMS codes, push notifications, authenticator app OTPs — does not stop AiTM attacks. Those methods protect the login. AiTM attacks happen after the login.
From Session Token to Global Administrator
Once inside Stryker’s Microsoft Entra ID (formerly Azure Active Directory) environment with a compromised high-privilege account, the rest was straightforward. Not easy — but straightforward.
With Global Administrator access, the attackers had effective control over Stryker’s entire Microsoft 365 tenant. They could create new admin accounts to maintain access if discovered. They could modify conditional access policies. They could reach every system that federated with Entra ID for authentication. And they could access the Microsoft Intune console.
What they did next was elegant in a deeply unsettling way.
The Weapon: Microsoft Intune’s Own Remote Wipe Feature
Microsoft Intune is an endpoint management platform used by enterprises worldwide. Its job is to manage device fleets — rolling out configurations, enforcing compliance policies, pushing software updates, and handling things like lost or stolen devices. It is a legitimate, important, widely trusted tool.
One of its built-in features is Remote Wipe. If an employee loses their phone, an IT administrator can log into the Intune console and issue a factory reset command to that device remotely. It is the kind of capability that exists in every MDM platform and for very good reasons.
Handala used it on every device Stryker had enrolled. All at once.
They accessed the Intune console through the compromised Global Administrator session, and issued enterprise-wide factory reset commands across the entire device fleet. No malware was deployed. No exploit was used. They used a built-in administrative feature, exactly as it was designed to work, just not for the purpose it was designed for.
Between approximately 5:00am and 8:00am, corporate laptops, company phones, virtual servers, and personal devices enrolled in Stryker’s BYOD (Bring Your Own Device) programme were all factory reset simultaneously. Employees who had connected their personal phones to access corporate email lost everything on those devices too — photos, personal banking apps, and importantly, the authenticator apps they relied on for two-factor login on personal accounts.
Stryker confirmed the attack was not ransomware and that no malware was deployed. The investigation, led with Palo Alto Networks, confirmed the attackers inserted a malicious non-malware file to abuse the Intune environment.
The BYOD Problem Nobody Talks About
The personal device angle deserves its own moment because it is the part of this attack that is most easily overlooked — and most likely to affect employees at your organisation.
When a company runs a BYOD programme, employees enrol their personal devices in the company’s MDM platform to access corporate email, calendar, and applications. This is standard practice. It is operationally sensible. It means the company does not have to provision hardware for every remote worker.
But enrolment in Intune means the Intune console has management authority over that device. Not just corporate apps — the entire device. When Handala issued the wipe command, there was no distinction made between company-owned hardware and employee-owned hardware. Both were enrolled. Both were wiped.
Employees lost personal photos, banking application data, personal contacts, eSIMs, and the authenticator apps tied to their personal accounts. In some cases, the MFA apps used for personal banking and financial accounts were gone. The collateral damage extended well beyond Stryker’s corporate perimeter and into people’s personal lives.
This is a risk that most organisations document somewhere in their BYOD policy and then never revisit. The Stryker attack makes it impossible to ignore.
The Scale of the Damage
To understand the business impact, consider what getting wiped simultaneously means at Stryker’s scale.
Ordering systems went offline. Manufacturing operations halted. Shipping and distribution were disrupted. The company confirmed in an SEC filing that the attack had a material impact on its first quarter earnings. Staff across 79 countries could not access their machines. A company with 56,000 employees and products in hospital supply chains across six continents came to a near-complete operational stop.
Handala claimed to have wiped more than 200,000 devices and exfiltrated 50 terabytes of data. Stryker has not confirmed those specific numbers, and the group has a documented pattern of exaggerating impact for psychological effect. What is confirmed is that the disruption was severe, widespread, and real enough to show up in quarterly earnings reports.
Stryker said it was fully operational again by mid-March. But the investigation — involving Palo Alto Networks, CISA, and law enforcement — is ongoing.
What Your Security Stack Would Have Missed
This is the part of the Stryker attack that should genuinely worry any security team.
The entire attack — from session token theft to device wipe — generated no malware signatures, no suspicious process execution, no anomalous file system changes, and no exploit activity. Every action the attacker took was a legitimate administrative command issued through a legitimate platform using a legitimately authenticated session.
Standard endpoint detection tools look for malware. This attack had none. Firewalls look for suspicious traffic. The attacker used Microsoft’s own cloud infrastructure. SIEM rules typically flag unusual process execution, lateral movement, and credential abuse patterns. The lateral movement here was a single authenticated cloud login. The credential abuse looked like a normal admin session.
An organisation with detection logic built around Handala’s previous toolkit — wiper malware signatures, web shell indicators, RDP anomalies — would have seen nothing. Because none of that was used.
What would have caught it:
- Alerts on new Global Administrator account creation
- Conditional access policies flagging logins from unusual locations or device fingerprints immediately after MFA completion
- Multi-admin approval requirements for high-impact Intune actions like device wipe
- Phishing-resistant authentication (FIDO2 hardware keys or Windows Hello for Business) on all admin accounts
Without those controls, this attack is essentially invisible until the wipe command executes.
What You Need to Do Now
1. Enforce Phishing-Resistant MFA on All Admin Accounts
Standard MFA does not stop AiTM attacks. Full stop. Any administrator account — Global Admin, Intune Admin, Security Admin, or any privileged role in Entra ID — should be protected with phishing-resistant authentication only.
That means FIDO2 hardware security keys (YubiKey, etc.), Windows Hello for Business with TPM, or Passkeys bound to the physical device. These methods cryptographically tie the authentication to the device, so a session token stolen by a proxy is useless without the physical key.
Deploy a Conditional Access policy in Entra ID that enforces Authentication Strengths for all high-privilege roles. Do not exempt any service accounts or break-glass accounts from this requirement.
2. Require Multi-Admin Approval for Destructive Intune Actions
Microsoft Intune has a Multi-Admin Approval feature for high-impact actions. Enable it for device wipe, factory reset, and retire commands. This means a single compromised admin account cannot execute a mass wipe alone — a second admin must approve the action.
This single control would have broken the Stryker attack chain at its final stage.
Navigate to: Intune Admin Centre → Tenant Administration → Multi Admin Approval → configure approval requirements for Device Actions.
3. Restrict Global Administrator Usage
No one should be using a Global Administrator account for day-to-day work. Global Admin is for emergencies and provisioning — not for managing Intune day-to-day.
Use least-privilege role assignments. Intune Administrators should have Intune Admin role only. Security teams should have Security Reader or Security Operator unless an action specifically requires more. Restrict which accounts can create new Global Admin accounts, and alert immediately on any such creation.
4. Audit Your BYOD Programme
Review what authority your MDM platform has over enrolled personal devices. Communicate clearly to employees what the company can and cannot do to their personal device through the MDM. Consider scoping BYOD enrolment to a containerised work profile rather than full device management, which limits the wipe scope to the work container only rather than the entire device.
5. Monitor for AiTM Indicators
Configure your SIEM and identity protection tools to alert on:
- Token replay: a session token being used from a different IP or device than where it was issued
- New admin account creation — especially new Global Admin accounts
- Sign-ins from unfamiliar geographies or ISPs immediately after MFA completion
- Concurrent sessions with mismatched device fingerprints
- Any Intune bulk action on more than a threshold number of devices
Microsoft Entra ID Protection has risk signals for some of these. Supplement with custom detection rules if your SIEM supports it.
6. Treat Your MDM Console Like Production Infrastructure
Most organisations protect their Intune console at the same level as any other business application. After Stryker, that posture is indefensible.
Access to Intune Admin should require phishing-resistant MFA plus a Privileged Access Workstation (PAW) — a hardened, dedicated device used exclusively for administrative access, with no email, no browsing, no personal apps. These are not new concepts in security. They are just not consistently implemented for MDM platforms.
The Bigger Lesson Here
The Stryker attack is not really a story about Microsoft Intune. Intune behaved exactly as designed. The real lesson is about what happens when identity becomes the perimeter — and that perimeter is not protected accordingly.
Modern enterprise infrastructure is built on trust. Active Directory trusts Entra ID. Entra ID issues tokens that grant access to Intune, SharePoint, Exchange, Teams. Intune has management authority over every enrolled device. If you compromise one identity at the right privilege level, you do not need to move laterally through the network. You are already everywhere.
This is the same pattern we are seeing across the biggest incidents of 2026. The Axios npm supply chain attack. The Vercel breach via a compromised AI tool’s OAuth token. And now this. Attackers are not breaking through walls. They are using valid keys.
The traditional kill chain — initial access, privilege escalation, lateral movement, objective — is collapsing into something much simpler in cloud-native environments: compromise identity, reach management plane, execute. No malware required. No exploit needed. Just administrative access and the patience to wait for the right moment.
CISA issued specific guidance on securing Intune environments following the Stryker attack, urging all US organisations to review their MDM configurations regardless of size or industry.
That guidance is worth reading. But the real takeaway is simpler: your device management console is now a high-value target. It deserves the same protection you give your most critical production systems.
Quick Reference Summary
| Date | 11 March 2026 |
| Attacker | Handala (MOIS-linked Iranian threat group) |
| Initial access method | AiTM phishing / session token theft (VPN credential compromise also suspected) |
| Pivot point | Microsoft Entra ID Global Administrator account |
| Weapon used | Microsoft Intune’s built-in Remote Wipe feature |
| Malware deployed | None |
| Devices affected | ~80,000 confirmed; 200,000 claimed by attacker (unverified) |
| Countries impacted | 79 |
| Business impact | Manufacturing, ordering, and shipping halted; material Q1 earnings impact |
| What would have stopped it | Phishing-resistant MFA + Multi-Admin Approval for wipe actions |
Writing technical cybersecurity content that actually gets read — and ranked — is harder than it looks. If you need clear, accurate incident breakdowns, threat analysis, or security guides for your blog or security team, get in touch.