No Malware Required: The LOLBin Playbook Behind an 80K-Device Kill Chain

April 9, 2026

By Trey Annis, Founding Software Engineer

The Stryker breach was not a surprise in its complexity, but its sheer simplicity; almost akin to the typical script-kiddie approach on offensive security:

Find a tool, use the tool, profit. In the case of this breach, the approach looked more like: obtain credentials from infostealer databases, login to server using those credentials, create global admin account, wipe 80,000 devices.

What this tells us is that somehow one of the world’s leading medical technology companies (serving 61 countries, with 56,000 employees, impacting more than 150,000,000 patients annually, and $25.1 billion in revenue for 2025), responsible for providing life-saving devices and solutions all over the world, was breached and damaged through old credentials found on the internet. Was it really this simple?

I’ve spent a good amount of time in the cybersecurity and software industry. From my own observation and experiences, it’s often not the sophisticated, complex exploits that do the most damage. Instead, it’s a mixture of various missing controls that individually are not that big of a deal, but combined create a simple-to-execute attack chain that produces grave results. In this breach, the kill chain is almost not worth talking about (but we will), and the meat of the analysis lives in the controls this organization was missing in the first place.

Step 1. The Credential Harvest (Recon)

It doesn’t take long to break down the attacker’s process on how they acquired the credentials: they got them from a dark web leak. It appears they just tested a bunch of credentials from an info leak on the dark web sold by an initial access broker, and struck gold. The most glaring part of this is that these credentials were reportedly months-old. Why weren’t these credentials rotated?

Step 2. Authentication (Initial Access)

As an attacker, it’s one thing to find that we have working credentials to an account. It’s another thing altogether to find that:

The account has no Multi-factor authentication (MFA)
The account is linked to Microsoft Entra ID and has global administrator access
The account has no safeguards in place to prevent unprecedented actions (as you will see below)

Step 3. Persistence

According to Bleeping Computer’s report (see source below), the attacker created a global administrator account after compromising the administrator account. By establishing another administrator account (with greater impact as a global administrator) with their own supplied credentials, this is their persistence mechanism in the event those stale credentials to the original account are rotated.

Step 4. The Route to Root (Lateral Movement)

The account the attackers authenticated into is an administrator. However, if the alleged creation of a Global Administrator account from the administrator account did happen, this would be lateral movement to a higher-privileged account. Actions are far more impactful (see step 5) as a global administrator.

Step 5. Actions on Objective (the end-state)

The title of this blog post starts with “No Malware Required: The LOLBin Playbook” for a reason: this was no custom nation-state tool. The attacker used Microsoft’s native Mobile Device Management (MDM) tool, Microsoft Intune. Put differently, they lived-off-the-land utilizing one or more cloud-native binaries to reach their end-state. In this case, it was total sabotage through wiping 80,000+ company devices and hardware using Microsoft Intune’s Remote Wipe feature,including employee personal devices that had logged into their company e-mail via Microsoft Outlook. Ouch.

Is This Attack Complex Enough to Get a Technical “Mid-Dive”?

Whether the steps of the kill-chain and following details appear terse because the kill-chain was really that trivial or to simply belabor the point, both were intentional. This was as straightforward as attaining credentials to an admin account and running rm -rf /. Just like in social engineering campaigns where it only takes one set of compromised credentials to find a foothold, it only takes one set of compromised credentials to be released by an initial access broker for an opportunistic attacker to exploit and pivot farther in. In this case however, those credentials were the keys to the kingdom.

Future “mid-dives” will hopefully not be as terse. But it can’t be emphasized enough how critical organizations such as this one can be “bricked” when the “lack of controls” align in the worst way imaginable.

Some Questions Still Remain

We already alluded to some above, and there are plenty more to be asked:

Why weren’t these credentials rotated?

Generally speaking, an administrator-level account should not have long-lived credentials in the first place. There already should be controls in place that rotate these credentials on a consistent basis to limit their useful life if stolen.

Was there Multifactor Authentication (MFA)?

Open-source reporting is mixed on if Stryker had MFA implemented, and at what level. It is possible that either an AiTM (Adversary-in-the-middle) attack bypassed the Microsoft Intune administrator MFA (effectively capturing the session token and holding onto it for future use), there simply wasn’t MFA implemented at all, or something else. If we presume that MFA was in place and an AiTM attack successfully captured a session token, then that begs another hypothetical question:

If MFA was implemented and was still circumvented, did the session token have a short TTL?

Best practices demand a Microsoft Intune admin account (that has the power to remotely wipe every single connected device in the fleet) have session tokens configured with a very short TTL (time-to-live).

Why was this account accessible in the first place?

There’s a concept in systems design known as a safe proxy, which is effectively a mechanism that prevents the ability to access a privileged system or account directly. If an attacker can directly access a Microsoft Intune administrator account, we can be fairly confident that a control to prevent direct access to such a privileged account simply wasn’t there. At a minimum, we should presume a privileged account should not be accessible from the public internet at an organization this size.

Why did this account have the scope and permissions to cause this much damage?

The short answer: no one constrained it. A single account shouldn’t be able to touch every device in an environment, and that capability shouldn’t be available without a second approver. The fixes are straightforward: disable the account when not in use, limit its device scope, restrict access to destructive features, and require multi-admin approval for high-impact actions. See how to do all of that here, according to Health-ISAC and Microsoft).

Push Security summarized it well:

“…The attacker simply logged into Microsoft Intune with compromised Global Administrator credentials, abused a legitimate feature, and wiped over 80,000 systems, servers, and mobile devices.”

Until next time.