TL;DR: Attackers used infostealer logs, AiTM session theft, privilege escalation, and Microsoft Intune control-plane access to factory-reset about 200,000 endpoints across 79 offices without custom malware, according to SlashID’s analysis of the Stryker breach. The breach shows why endpoint-management privileges need stronger identity controls, not just better device hardening.
At a glance
What this is: This analysis reconstructs how attackers abused Microsoft Intune control-plane access to reset endpoints at scale, using stolen credentials and session theft rather than custom malware.
Why it matters: It matters because endpoint-management privileges can become a mass-impact wiper path when identity controls around admin sessions, privilege elevation, and control-plane access are too weak.
Context
The core issue is not device hardening alone. When an attacker reaches a cloud management plane with enough authority, the management console becomes an execution path for destructive action across the fleet.
In this case, the identity problem sat inside the device-management workflow. The article ties the breach to infostealer logs, adversary-in-the-middle session theft, and privilege escalation before the Intune pivot, which makes it an identity-led control-plane abuse case rather than a conventional endpoint malware event.
That pattern is typical of modern cloud administration risk, where the management plane is more powerful than the endpoint itself. The practical question is which identity controls actually constrain that power before a reset command reaches thousands of devices.
Key questions
Q: What breaks when endpoint management access is stolen through an AiTM session?
A: The break is not only authentication but trust in the session itself. If a stolen browser session can reach the management plane, an attacker may inherit admin authority without re-authentication, which means device controls become available through a live, legitimate-looking session instead of a noisy login event.
Q: Why do privileged device-management accounts create fleet-wide risk?
A: Privileged device-management accounts create fleet-wide risk because the control plane concentrates authority over many endpoints in one place. If an attacker reaches an admin role, they can often use trusted administrative functions to change policy, trigger resets, or disable protections across the entire tenant.
Q: What are the warning signs that a management-plane compromise is underway?
A: Warning signs include unusual admin session patterns, unexpected policy changes, bulk device actions, and administrative activity from locations or devices that do not match normal operator behaviour. Those signals matter because the attacker may be using legitimate tooling rather than malware, which can hide the compromise inside routine operations.
Q: How should organisations limit the impact of Intune-style abuse?
A: Organisations should limit impact by removing standing administrative privilege, separating high-risk actions from routine management, and requiring strong authentication for privileged sessions. The goal is to make mass-impact actions difficult to perform even if one account or session is compromised.
Technical breakdown
How infostealer logs and AiTM sessions unlock the first foothold
The attack begins with identity material stolen outside the target environment, then reused to get a live foothold. Infostealer logs capture credentials, cookies, or session artefacts, while adversary-in-the-middle techniques can intercept authentication flows and reuse authenticated sessions. That combination matters because it bypasses simple password assumptions and often defeats weak MFA implementations that do not bind the session to device, network, or phishing-resistant factors. In a cloud management context, the initial foothold is valuable only if it can be turned into an authenticated administrative session. That is why identity proofing alone is not enough once session theft is in play.
Practical implication: treat stolen-session risk as an authentication and token-security problem, not just a phishing problem.
Why privilege escalation in endpoint management becomes fleet-wide power
Endpoint-management platforms centralise authority over thousands of devices, so a small increase in privilege can produce a very large blast radius. The article’s chain moves from stolen access to privilege escalation, which suggests the attacker crossed into a role that could issue management actions at scale. In Intune-style control planes, the distinction between read-only access, scoped management rights, and tenant-wide administrative authority is decisive. Once an attacker reaches a role that can push policy or device actions, the platform itself becomes the delivery mechanism. This is a privilege design issue as much as an incident response issue.
Practical implication: enforce least privilege and task-scoped elevation on endpoint-management roles before one account can act across the fleet.
How a management plane becomes a non-encrypting wiper
The destructive step was not malware execution on the endpoint. Instead, the attacker used management authority to trigger factory resets through Microsoft Intune, turning a legitimate device-control channel into a wiper plane. That matters because the payload is administrative instruction, not code. Traditional endpoint protections look for malicious binaries, but a control-plane attack can achieve impact through trusted tooling and signed management actions. The mechanism is living off the land at the administration layer: valid platform capabilities are abused to create destructive outcomes that appear operationally normal unless identity and behavioural controls detect the misuse.
Practical implication: monitor privileged management actions as potential attack execution, not merely as routine administration.
Threat narrative
Attacker objective: The attacker’s objective was to weaponize trusted endpoint-management authority to destroy availability across a global device fleet while avoiding malware-based detection.
- Entry came through stolen identity material, including infostealer-derived credentials and AiTM-assisted session theft, rather than custom malware delivery.
- Credentialed access then enabled privilege escalation inside the environment, giving the attacker higher-value management authority.
- That authority was used to pivot into Microsoft Intune and issue destructive device-management actions at scale.
- The final impact was roughly 200,000 endpoints factory-reset across 79 offices, producing mass disruption without encrypting files.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity governance failed at the control plane, not the endpoint. The Stryker breach shows that endpoint-management privileges can function as destructive execution authority when they are not governed like high-risk access. Intune was not merely an admin console in this case. It became the mechanism for mass impact once the attacker reached the right role and session state. Practitioners should treat management-plane authority as privileged execution, not ordinary device administration.
Ephemeral session trust is the assumption that collapsed first. Access review processes were designed for durable entitlements, yet the article’s chain began with stolen credentials and live session theft that can be consumed before any periodic review occurs. That assumption fails when the attacker reuses authenticated state to move straight into privilege escalation and administrative action. The implication is that access governance must account for session provenance and runtime trust, not just assigned roles.
Identity blast radius is now determined by admin reach, not asset count. A single compromised management role can touch tens of thousands of endpoints because cloud device-management systems concentrate control. That changes how Zero Trust Architecture should be applied: the question is not only whether a device is trusted, but whether the management actor is continuously trusted for each control action. Practitioners should model endpoint-management access as a fleet-wide force multiplier.
Just-in-time privileged access becomes a containment control when destructive actions are possible. The breach underscores that standing administrative access in endpoint-management systems gives an attacker too much time to escalate and act. When the platform itself can reset devices or alter policy at scale, persistent privilege expands impact far beyond the initial foothold. The practical conclusion is that privileged access governance for Intune-like systems must be measured by how little standing authority remains available after authentication.
Living off the land now extends to infrastructure administration. The article frames the attack as living-off-the-land because the attacker used legitimate cloud management capabilities rather than custom malware. That widens the category of abuse practitioners need to defend against: signed, trusted, and operationally normal actions can still be destructive when identity controls fail. Security teams should assume trusted administration channels are part of the attack surface.
What this signals
Management-plane abuse is now an identity problem with endpoint consequences. Security programmes that still treat device hardening and identity governance as separate workstreams will miss the control point that matters most here. When administrative authority can reset or reconfigure the fleet, the real boundary is the trustworthiness of the privileged session, not the endpoint alone.
Access review alone cannot contain session theft. The Stryker pattern shows why governance cycles that examine assigned roles after the fact do not stop an attacker who has already captured live session state. Teams need stronger issuance-time controls, tighter privilege boundaries, and behavioural monitoring for destructive management actions.
Zero Trust Architecture has to reach the control plane. It is not enough to verify the user once at sign-in and then assume platform actions remain safe. For endpoint-management systems, every high-risk administrative action should be treated as a fresh trust decision, especially where wipe, reset, or policy-broadcast capabilities exist.
For practitioners
- Harden endpoint-management administrator sessions Require phishing-resistant authentication for all privileged Intune and endpoint-management roles, and bind admin sessions to device and context so stolen cookies are less reusable.
- Reduce standing privilege in device-management roles Move endpoint-management administrators to just-in-time elevation so no account can retain destructive control over the fleet outside an approved task window.
- Separate read, policy, and wipe authority Split management-plane permissions so no single role can both modify device policy and trigger large-scale remediation or reset actions.
- Monitor high-risk management actions as attack signals Treat factory reset commands, bulk policy pushes, and unusual admin session sequences as behavioural anomalies that deserve investigation alongside endpoint alerts.
- Review third-party and infostealer exposure paths Search for credentials and session artefacts that could be reused against management consoles, then revoke or rebind any affected administrative access.
Key takeaways
- The breach demonstrates that a cloud management console can become a wiper mechanism when privileged identity controls fail.
- The reported impact reached roughly 200,000 endpoints across 79 offices, showing how concentrated management authority can create extreme blast radius.
- Limiting standing privilege, strengthening privileged session authentication, and separating destructive actions from routine administration are the controls most directly implicated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Stolen access and reused sessions exposed the management plane to compromise. |
| NHI-05 — Overprivileged NHI | The breach depended on management authority broad enough to reset endpoints at scale. | |
| NHI-07 — Long-Lived Secrets | Persistent privileged access increases the window for session theft and escalation. | |
| Recommendation — Audit administrative access paths for stolen-session exposure and revoke compromised NHI access immediately. Reduce Intune and endpoint-management roles to least-privilege scopes that cannot trigger fleet-wide destructive actions. Eliminate standing privileged credentials and move administrative access to short-lived, task-scoped issuance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle controls are central when stolen credentials and sessions enable admin abuse. |
| AC-6 — Least Privilege | The attacker escalated into a role with excessive management authority. | |
| IA-9 — Service Identification and Authentication | Cloud management actions rely on trusted non-human and platform authentication paths. | |
| Recommendation — Apply IA-5 to rotate, revoke, and tightly govern authenticators used for device-management administration. Apply AC-6 to restrict endpoint-management permissions to the minimum needed for each administrative task. Use IA-9 to authenticate management-plane services and constrain trusted administrative interactions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident shows how excessive entitlements can turn a management platform into an attack path. |
| Recommendation — Review PR.AA-05 entitlements for endpoint-management roles and remove broad destructive privileges. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0008 — Credential Access; Privilege Escalation; Lateral Movement | The attack chain moved from stolen credentials to elevated control and broad device impact. |
| Recommendation — Map suspicious admin activity to TA0006, TA0004, and TA0008 to accelerate detection and containment. | ||
Key terms
- Control Plane Abuse: Control plane abuse occurs when an attacker uses legitimate administrative interfaces to perform destructive or high-impact actions. In NHI terms, the problem is not malware execution but trusted authority that can scale changes across many systems at once.
- Adversary-in-the-Middle Session Theft: Adversary-in-the-middle session theft captures authentication material during live login flows and reuses it to impersonate the user. Unlike simple password theft, it can preserve access continuity, which makes reauthentication and token binding essential for privileged consoles.
- Privilege control plane: A privilege control plane is the layer that coordinates request, approval, provisioning, expiration, and session oversight across environments. It does not replace native cloud permissions. Instead, it creates a consistent governance path so auditors and security teams can trace access from request to action without manual reconstruction.
- Just-in-Time Privileged Access Management: A control model that grants elevated access only for a defined task or session, then removes it automatically. In cloud environments, it reduces the time privileged credentials remain usable and makes misuse harder to sustain. The value depends on strong approval, logging, and revocation processes.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org