On Wednesday, Pro-Iran hackers successfully wiped the entire device fleet of Stryker, a medical manufacturing company. The method? Intune compromise. A Reddit thread confirms the employee experience was a sudden Intune device wipe, and the official company statement confirms that the “Microsoft environment” was affected (indicating that all Intune-managed devices were likely impacted). Both desktop and mobile devices were affected, indicating this was not traditional, malware‑based ransomware.
At first glance, this seems like a nightmare scenario, and begets several important questions:
- Why is this even possible to do with Intune at scale?
- What safeguards were missed?
- What can we do to protect our own company (and Cyclotron’s Intune customers) to prevent this attack method?
Part 1: Does Intune limit mass wipe actions?
My first reaction to the news was, “Wait, that shouldn’t be possible.” Microsoft Intune does not let you run wipe commands en masse by default. From MS Learn:
When running commands over API, no such limit is documented. So, the attack wasn’t done through the GUI – it had to be done via Graph API/PowerShell script.
It’s worth noting that Intune provides a feature called Multi-Admin Approval (MAA), which limits certain remote actions like Wipe, Retire, and Delete without a second approval. This could help; there’s no indication of whether Stryker had this feature on. MAA is great at protecting against accidental wipe activities, but is not effective at protecting against intentional wipe activities. If an attacker has permissions to create another admin account, MAA becomes useless.
Part 2: What permissions enabled this attack?
To wipe devices, attackers must obtain:
- Global Admin, Intune Admin, or one of the few Intune RBAC admin roles with wipe permissions.
- Ability to connect to the Graph API via PowerShell or similar method. Graph API connections are not enabled by default – they require OAuth app approval; however, Entra does not require approval for OAuth apps by default. Admins must enable requests via policy in Entra. As a double-whammy, Global Admins by default can approve these requests themselves.
Using those permissions, it’s trivial to ask AI to build a script to wipe all tenant devices at once – which, based on available evidence, is exactly what the attackers did.
Wait, that’s it?
Yup. Intune is an incredibly capable tool; a wipe action usually occurs within minutes of the admin click or Graph API request.
The only complicated part of this attack is getting Intune admin permissions (1 account if MAA is not enabled, 2 if MAA is enabled); everything else is pretty simple. Using Global Admin permissions, 1 account could do everything, including creating a second admin account to fulfill MAA approvals and grant API access.
How do I protect my Intune tenant from compromise?
The absolute best thing you can do is implement a strong privileged access strategy using Microsoft Entra’s capabilities (primarily E5/P2 at minimum). A privileged access strategy should include requirements for PAWs (Privileged Access Workstations, or physical administrative devices that are the only way admins can do work – or attempt compromise).
In the diagram above, the tenant is configured to only allow admins to use PAWs to sign in. This type of configuration is wonderful at preventing attackers from getting access to an admin account, as the admin account is never used outside the tightly-secured PAW. This means compromised standard accounts/devices will not lead to compromised admin accounts.
Other important items:
- Tightly limit your Global Admin permissions to only those who should be able to delete the tenant, adjust billing, or change every setting. This is very, very few people in your org. Microsoft’s recommendation is two to four Global Admins per tenant.
- Tightly limit your Intune admin permissions so that very few admins have full Intune Admin permissions in Entra.
- Instead, adopt Intune RBAC roles and keep the “Wipe” permission off your preferred custom roles. This limits your blast radius if most of your IT admins are compromised.
- Enforce Privileged Identity Management (PIM) for all role escalations. PIM should require strong authentication to escalate roles like Intune Admin. PIM can also be used to control security groups for Intune-specific roles. This helps with MFA and secondary admin escalation approval.
- Tightly control who can access Graph API PowerShell, which is an app registration in Entra. Each user requires approval to use it, but it’s easy to forget about the important things you need to do to require approval for all OAuth apps and to not provide org-wide consent for Graph API PowerShell use.
- You can also improve this strategy by preventing human accounts or admin accounts from using Graph API, and instead rely on managed identities where permission is explicitly granted to non-human objects for specific purposes. This strategy helps with both governance and blast radius from an identity perspective.
- Enable Multi-Admin Approval in Intune. It’s not perfect, but it does help add one layer of security to make it harder to accidentally or intentionally wipe. In this case, MAA would not have prevented the attack if Global Administrator (GA) permissions were used, as a GA can create another admin account and satisfy the MAA requirement.
- Enable alerts at your SIEM for Intune admin audit logs, so you can generate alerts on sensitive actions like wipe events.
- Enable a minimum of MFA for admins via Conditional Access, but a phishing resistant requirement is better.
- Enable phishing-resistant requirements to access Microsoft admin portals/services (or even better, all access). You can prevent insecure Intune service access by requiring a passkey or Windows Hello for Business.
- Implement strong identity governance with Entra Suite/IDG. Features like Access Reviews, Access Packages, and Verified ID can help enforce least-privilege on admin accounts, ensure stale permissions are removed, and explicitly verify human access for highly sensitive events.
- Do not MDM-enroll your user’s personal devices in a way that would allow a Wipe command. Customers make this mistake with iOS management the most. Avoid using iOS Device Enrollment mode on personal devices, as it allows full device wipe, For Android, the Android Enterprise Work Profile mode is a great option.
Additional lessons to learn
This is all ironic in a sense, as a big reason for Microsoft’s cloud-native architecture is the reduced chance of ransomware impact. It’s a lot harder to abuse local desktop permissions and jump device-to-device if you’re on an Entra-joined, cloud-only device instead of an Active Directory (AD) domain-joined device where devices can see and interact with each other on the network. However, if an attacker can do the extra-tough work of compromising Intune admin permissions, every Entra-joined, Intune-enrolled device becomes easy to compromise through the same architecture that you use to manage and secure them.
To be clear on the above point – from a security perspective, it’s always better to be cloud-native than domain-joined, because it’s a lot harder to compromise an Intune tenant than run common, traditional ransomware that abuses poorly-secured AD environments. We see AD-based attacks all the time, but Intune attacks are rare (so far). That might change starting this week.
Can Cyclotron help us with this?
Yes! Cyclotron provides full-service deployment for all the above recommendations as part of our Privileged Access Strategy deployments. We take an end-to-end approach to ensure your organization has robust protections in place, aggressively remove security exceptions, and improve the end-user experience while doing so.