The Stryker cyberattack is a useful case study for any IT leader running Microsoft 365 and Intune. Attackers obtained valid credentials, escalated privileges to Intune Admin, and used Intune itself to wipe devices at scale. No malware. No exploit. A privileged account doing admin things at 3:30 AM.
No malware means no EDR alert. No exploit means no firewall flag. A privileged user logged in and did admin level things. That looked normal based on how the system was configured. Mid-market organizations running Intune without monitoring privileged activity in real time have the same exposure.
Why Traditional Security Tools Miss This
Endpoint detection tools watch for malicious code. Perimeter firewalls watch for anomalous traffic. Neither watches for a Global Admin logging in from a foreign ASN at 3 AM and queueing device wipes.
That activity lives in identity and audit logs. Specifically, in Entra ID sign-in logs and Intune audit logs. Most organizations are not watching them in real time.
If an attacker gets into a privileged account, Intune gives them the ability to wipe, retire, or reconfigure every managed device in your tenant. No additional tools required.
5 Things to Check in Your Environment Right Now That Would Have Prevented This
Pull these up this week. These are all best practices.
1. Intune Audit Logs - Last 30 Days
Go to Intune admin center and pull the audit logs. Filter for wipe, retire, and delete actions. Look for anything that happened off-hours, came from an unfamiliar IP, or has no corresponding change ticket. The Stryker activity hit at approximately 3:30 AM.
2. Entra ID Sign-In Logs for Privileged Roles
Filter sign-in logs for Global Admin and Intune Admin roles. Look for sign-ins from AS14593 (Starlink) or Iranian ASN ranges. Attackers use residential proxy services and satellite internet specifically because they do not show up on traditional block lists. Sign-ins from unexpected ASNs or geographies are a priority.
3. Use Phish-resistant MFA on Every Privileged Account
Check what MFA methods your admins are using. SMS, TOTP apps, and push notifications are all phishable. Move privileged accounts to Passkeys, FIDO2 hardware keys, or certificate-based authentication.
4. Your PIM Configuration
Privileged Identity Management (PIM) in Entra ID controls who can activate privileged roles and under what conditions. If your PIM policy only requires standard MFA to activate Global Admin or Intune Admin, you are at risk. Configure Authentication Context to enforce phishing-resistant authentication specifically for privileged role activation. Check your conditional access policies and confirm this is in place.
5. Intune Multi-Admin Approval
In the Intune admin center, go to Tenant Administration and look for Multi Admin Approval. Configure it to require a second administrator to approve high-risk actions before they execute. Protect wipe, retire, and delete. A single compromised account should not be able to wipe your entire device fleet.
The Logging Problem
How long would it take you to notice this in your environment? It's been weeks, if you find vulnerability or any of the above isn't configured, the answer would be "too long".
Catching this type of attack before it does damage requires watching the logs in real time. It's a real defense in depth strategy. Don't just trust the configuration above, actively monitor it as well. Someone or something should be reviewing Intune audit activity and Entra ID sign-in anomalies continuously. Alerts fire when a privileged role activates at 3 AM from an unexpected location. A human investigates before the wipe queue runs. Or better yet, that suspicious login should be blocked immediately through automation. It didn't match any user persona profile and should have been flagged as an indication of compromise. Any admin would be OK getting their account disabled and having to go through a few more hoops to complete their task to prevent this type of thing if it was a false positive.
Most mid-market IT teams are not staffed for this. The people who would review the logs are the same people fielding tickets, managing projects, and handling day-to-day operations.
What a SOC Actually Watches
A Security Operations Center built on Microsoft Sentinel ingests exactly these logs. Intune audit events, Entra ID sign-ins, privileged role activations. Sentinel correlates them, fires alerts on anomalies, and puts automation and a human analyst in front of suspicious activity in seconds/minutes rather than hours/days/weeks.
ThreatDefender, eGroup's managed SOC service, is built on this stack. The Stryker attack pattern is not exotic. It is a privileged account doing destructive things at an unusual time from an unusual place. A properly tuned SIEM catches that if the attacker gets past the configuration prevention above.
Most mid-market organizations do not have a SOC. Most do not have Sentinel tuned and configured with meaningful detection rules. That gap is the exposure, independent of anything else in the stack.
Start with the five checks above. Let me know if you need any help locking it down. This is preventable.