Stryker’s Breach Exposure: What Lunar Saw Before the Headlines

On March 11, 2026, medical technology company Stryker (stryker.com) confirmed a cybersecurity incident. For most people, that’s one more breach headline in a long list. For security teams, it raises a sharper question: were attackers already sitting on valid Stryker logins long before anyone noticed?

Lunar’s telemetry says that is indeed the case. Throughout much of 2025, we saw credentials tied to Stryker accounts turning up in infostealer logs. While we’re not talking about thousands of accounts, they are enough to matter, especially when those logins touched Microsoft 365 and third‑party portals that are used daily.

A Quick Snapshot

Here’s what stood out in the data:

• Exposure window: May 2025 to December 2025
• Correlation date: March 11, 2026 (the day Stryker disclosed the incident)
• Approximate number of exposed credential sets: 14
• Infostealers involved: LummaC2 and Rhadamanthys
• Devices: A mix of corporate and personal Windows machines
• Services touched: Enterprise identity (M365) and external portals 

Fourteen accounts might look small on a spreadsheet. In real life, a single exposed user can unlock mailboxes, shared docs, vendor systems, or customer‑facing tools. Multiply that by 14 and you get a very real window of opportunity.

What We Saw Before March 11

Our view starts well before the breach announcement.

Through the second half of 2025, we repeatedly picked up Stryker‑related logins inside infostealer logs being traded or shared. The pattern was pretty clear:

• During late spring into summer, the first wave of LummaC2 logs with stryker.com accounts mixed in were detected.
• From early fall into winter, more exposures were found, including accounts clearly tied to M365 and business portals.

These logs weren’t just email addresses. They typically included:

• Saved usernames and passwords.
• Active session cookies and tokens.
• Autofill data that hints at which apps and portals people use. 

If you’re an attacker or an access broker, that’s a ready‑made starter kit. You don’t need to guess the login URL or brute‑force a password. You’re handed working credentials plus the map.

Why Infostealers Make Valid Accounts So Dangerous

The infostealer tools involved here, namely LummaC2 and Rhadamanthys, aren’t there to encrypt files or wipe drives. They’re built to sit quietly and empty the browser’s pockets.

Once they land on a Windows machine, they pull out:

• Whatever the browser remembered for you (passwords, usernames).
• Cookies and tokens that keep you logged in.
• A bit of context about the system and the sites you visit. 

From there, attackers don’t need a fancy exploit chain. They can just sign in with the same details a Stryker employee uses. That’s the idea behind valid accounts: using real logins instead of breaking software.

When those logins belong to M365 or a key external app, the path from a single infected laptop to meaningful access is short. An attacker can read emails, see internal conversations, download files, or pivot into other systems that trust that identity. And, at least early on, this all looks exactly like a normal user session.

How An Attack Like This Usually Plays Out

We’re not pointing at any one account and saying this was the gateway the attackers broke into Stryker. But the story fits a pattern we’ve seen many times. Simplified, it tends to look like this:

1. A user’s device gets infected: Someone uses a Windows machine like a corporate laptop or a home PC to check mail or log into a vendor portal. They open a convincing attachment, install a free tool, or click a bad ad, and an infostealer quietly installs.
2. Credentials are scraped and shipped out: The malware scoops up saved passwords, cookies, and autofill data tied to corporate accounts and sends everything back to its operators.
3. The data gets bundled and passed around: Those stolen details are wrapped into logs and offered on markets or in closed channels. Access brokers label them by company so Stryker‑specific entries are easy to spot.
4. Someone uses the logins as if they owned them: A buyer signs into M365 or a portal with those credentials, or reuses the cookies. If the account isn’t protected by strong, phishing‑resistant MFA and tight device controls, the login looks routine. 

In the end, there is no exploit banner and no obvious malware on a server. This is just another user session that isn’t actually the user.

The Role of Home Devices

One detail we can’t ignore: these infections likely didn’t all come from locked‑down Stryker hardware. Some originated on personal Windows machines.

That tracks with how people really work:

• Checking corporate mail from a home desktop.
• Logging into a billing or partner portal from a family laptop.
• Letting the browser remember corporate passwords on devices IT never touches. 

Those home devices rarely have the same protection stack as corporate laptops. Yet the browser still holds Stryker logins and sessions. If someone in the household installs a cracked app or hits a malicious ad, an infostealer can ride along and quietly collect everything.

From Stryker’s side, that machine barely exists. From an attacker’s perspective, it’s incredibly useful.

What Security Teams Can Take Away

The gap between the 2025 exposure window and the March 2026 incident is the real story here. Credentials can be stolen and then sit in a drawer, sometimes literally in a log file, for months before anyone decides to use them.

A few practical moves help shrink that gap:

• Strong MFA where it matters most: For admin roles, high‑risk users, and M365 in general, push toward hardware‑backed, phishing‑resistant methods, not just SMS or simple push prompts. That way, a stolen password or cookie isn’t enough on its own.
• Clear lines on unmanaged devices: Decide which services should never be accessed from personal machines and enforce that through policy and conditional access. If you can’t fully block BYOD, at least treat those sessions as higher risk.
• Treat exposed credentials like incident alerts: When accounts from stryker.com show up in infostealer logs, that’s a signal. Use threat‑intel feeds to spot those exposures quickly, force resets, kill active sessions, and review what those accounts have been doing. 

You can’t stop attackers from trying to harvest credentials. You can make it much harder for those credentials to turn into quiet, long‑running access.

Disclaimer

This report is based on telemetry observed by Lunar and publicly available information. The findings presented are provided for informational purposes only. Lunar does not claim direct attribution, nor does it assert that the observed credential exposures were the definitive cause of the reported security incident. This analysis represents a correlation of temporal data points and does not constitute a “smoking gun” or identify “patient zero.”