{"id":32,"date":"2026-03-21T09:19:07","date_gmt":"2026-03-21T09:19:07","guid":{"rendered":"https:\/\/vanbeekcloud.nl\/?p=32"},"modified":"2026-03-21T09:26:06","modified_gmt":"2026-03-21T09:26:06","slug":"the-intune-stryker-breach-what-happened-and-how-to-defend-against-it","status":"publish","type":"post","link":"https:\/\/vanbeekcloud.nl\/index.php\/2026\/03\/21\/the-intune-stryker-breach-what-happened-and-how-to-defend-against-it\/","title":{"rendered":"The Intune Stryker Breach \u2014 what happened and how to defend against it"},"content":{"rendered":"\n\n
\n

What happened<\/h3>\n

\n On March 11, 2026, Stryker Corporation \u2014 one of the world’s largest medical technology companies \u2014 was hit by a devastating cyberattack. The Iran-linked hacktivist group Handala claimed responsibility. They allegedly exfiltrated 50 terabytes of corporate data and then used the built-in remote wipe capability of Microsoft Intune to wipe tens of thousands of devices across 79 countries. No malware, no ransomware \u2014 just abuse of existing management tooling.\n <\/p>\n <\/div>\n\n \n

\n

How the attack worked<\/h3>\n

\n The attackers followed an attack chain that demonstrates how dangerous a compromised admin account becomes when no additional security layers are in place:\n <\/p>\n

\n
\n 1<\/span>\n
\n
Initial account compromise<\/div>\n

The attackers gained access to an internal Stryker administrator account. The exact initial attack vector has not been publicly confirmed, but the result was access with elevated privileges.<\/p>\n <\/div>\n <\/div>\n

\n 2<\/span>\n
\n
Global Administrator account created<\/div>\n

Using the compromised account, they created a new Global Administrator account in Entra ID. This gave them near-unlimited control over the entire Microsoft environment.<\/p>\n <\/div>\n <\/div>\n

\n 3<\/span>\n
\n
Data exfiltration<\/div>\n

Before striking, the attackers allegedly exfiltrated 50 TB of corporate data \u2014 undetected.<\/p>\n <\/div>\n <\/div>\n

\n 4<\/span>\n
\n
Mass wipe via Intune<\/div>\n

Through the Intune portal, they issued a remote wipe command against all enrolled devices. Laptops, desktops, and even personal phones enrolled through Stryker’s BYOD program were wiped \u2014 including photos, eSIMs, and authenticator apps.<\/p>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n\n \n

\n

The impact<\/h3>\n

\n The consequences were massive and extended far beyond the loss of devices:\n <\/p>\n

\n
\n
Tens of thousands of devices wiped<\/div>\n

Laptops, desktops, and mobile phones across 79 countries were wiped in one sweep using the legitimate Intune wipe function.<\/p>\n <\/div>\n

\n
BYOD devices affected<\/div>\n

Personal phones of employees were factory-reset too \u2014 photos, eSIMs, and authenticator apps were lost along with corporate data.<\/p>\n <\/div>\n

\n
Supply chain disrupted<\/div>\n

Ordering, shipping, and supply chain systems went offline. Operations and deliveries to hospitals were delayed.<\/p>\n <\/div>\n

\n
50 TB of data stolen<\/div>\n

In addition to the wipe, the attackers claimed to have exfiltrated 50 terabytes of corporate data.<\/p>\n <\/div>\n <\/div>\n <\/div>\n\n \n

\n

Why this was possible<\/h3>\n

\n What stands out about this attack is that no malware was involved. The attackers purely abused the built-in functionality of Microsoft Intune. This raises the question: what was missing in the security posture?\n <\/p>\n

    \n
  • \n \n <\/svg>\n <\/span>\n No Multi-Admin Approval<\/strong> \u2014 A single admin was able to execute destructive actions like a mass wipe without requiring approval from a second administrator.<\/span>\n <\/li>\n
  • \n \n <\/svg>\n <\/span>\n Overly broad admin permissions<\/strong> \u2014 The compromised account apparently had sufficient privileges to create a Global Admin, indicating insufficient role-based access control.<\/span>\n <\/li>\n
  • \n \n <\/svg>\n <\/span>\n Insufficient monitoring<\/strong> \u2014 The creation of a new Global Admin account and the initiation of a mass wipe should have triggered alerts long before the damage was done.<\/span>\n <\/li>\n
  • \n \n <\/svg>\n <\/span>\n BYOD without wipe protection<\/strong> \u2014 Personal devices in the BYOD program were hit with a full wipe instead of only corporate data being removed (selective wipe).<\/span>\n <\/li>\n <\/ul>\n <\/div>\n\n \n
    \n

    How to defend against this<\/h3>\n

    \n Following this incident, CISA and Microsoft published concrete hardening guidelines. These are the measures you can implement today:\n <\/p>\n <\/div>\n\n \n

    \n

    \n 1<\/span>\n Enable Multi-Admin Approval\n <\/h4>\n

    \n Configure access policies in Intune that require a second administrator to approve destructive actions. This means a remote wipe, script deployment, or RBAC role change will only execute after a second admin has signed off.\n <\/p>\n

    \n Intune Admin Center → Tenant administration → Multi-admin approval → Access policies\n <\/div>\n <\/div>\n\n \n
    \n

    \n 2<\/span>\n Phishing-resistant MFA for all admin accounts\n <\/h4>\n

    \n Enable phishing-resistant MFA (FIDO2 keys, Windows Hello for Business, or certificate-based authentication) for all accounts with administrative privileges. Standard MFA via SMS or push notifications is not sufficient \u2014 these methods are vulnerable to MFA fatigue and adversary-in-the-middle attacks.\n <\/p>\n

    \n Entra ID → Protection → Conditional Access → Require authentication strength: Phishing-resistant MFA\n <\/div>\n <\/div>\n\n \n
    \n

    \n 3<\/span>\n Apply least privilege and RBAC\n <\/h4>\n

    \n Use Intune’s built-in Role-Based Access Control to grant administrators only the minimum permissions they need. Nobody needs standing Global Admin rights for day-to-day management. Use Privileged Identity Management (PIM) for just-in-time activation of elevated roles with time limits and approval workflows.\n <\/p>\n <\/div>\n\n \n

    \n

    \n 4<\/span>\n Monitor and alert on admin actions\n <\/h4>\n

    \n Set up alerts for the creation of new admin accounts, bulk device actions, and changes to Conditional Access policies. Use Microsoft Sentinel or Defender for Cloud Apps to automatically detect and block suspicious patterns such as a mass wipe outside business hours.\n <\/p>\n <\/div>\n\n \n

    \n

    \n 5<\/span>\n Rethink your BYOD policy\n <\/h4>\n

    \n For BYOD devices, use App Protection Policies instead of full device enrollment. This way, in the event of an incident, you can remove only corporate data (selective wipe) without touching personal data. Employees will not lose their photos, eSIMs, or personal authenticator apps.\n <\/p>\n <\/div>\n\n \n

    \n

    \n 6<\/span>\n Conditional Access for privileged actions\n <\/h4>\n

    \n Restrict access to the Intune Admin Center and destructive Graph API calls to compliant, managed devices from known locations. Combine this with sign-in risk policies so that suspicious login attempts are automatically blocked or require additional verification.\n <\/p>\n <\/div>\n\n \n

    \n

    Conclusion<\/h3>\n

    \n The Stryker breach demonstrates that your most powerful management tool can also be your largest attack surface. Microsoft Intune is designed to manage devices at scale \u2014 and that is exactly what the attackers did, only with destructive intent. The lesson is clear: treat your management plane as a tier-zero asset. Multi-Admin Approval, phishing-resistant MFA, least privilege, and proactive monitoring are no longer nice-to-haves. They are the minimum baseline.\n <\/p>\n <\/div>\n\n \n

    \n

    Relevant technologies<\/h4>\n
    \n Microsoft Intune<\/span>\n Entra ID<\/span>\n Conditional Access<\/span>\n PIM<\/span>\n RBAC<\/span>\n FIDO2<\/span>\n <\/div>\n <\/div>\n\n","protected":false},"excerpt":{"rendered":"

    How attackers wiped tens of thousands of devices through Microsoft Intune without deploying any malware, and what concrete steps CISA and Microsoft recommend to prevent the same from happening to you.<\/p>\n","protected":false},"author":1,"featured_media":36,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,4],"tags":[],"class_list":["post-32","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-intune","category-security"],"_links":{"self":[{"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/posts\/32","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/comments?post=32"}],"version-history":[{"count":1,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/posts\/32\/revisions"}],"predecessor-version":[{"id":34,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/posts\/32\/revisions\/34"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/media\/36"}],"wp:attachment":[{"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/media?parent=32"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/categories?post=32"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vanbeekcloud.nl\/index.php\/wp-json\/wp\/v2\/tags?post=32"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}