AstraZeneca Breach Exposure: What Lunar Saw Before the Incident

On March 23, 2026, AstraZeneca appeared in public reporting for a cybersecurity incident that touched parts of its corporate environment. While the technical root cause is still being investigated internally, it’s clear that months before the breach hit the news, credentials tied to AstraZeneca were already circulating in infostealer logs.

Lunar’s telemetry picked up a small but meaningful set of astrazeneca.com credentials exposed in late 2025. It’s a familiar pattern, in which a Windows machine is quietly infected, a handful of logins are stolen, and following a long gap, a malicious actor turns those credentials into real access.

What Lunar Saw Before the AstraZeneca Incident

Looking back over our data, we saw a clear exposure window in October 2025, when four distinct credential sets tied to astrazeneca.com personas appeared in Rhadamanthys infostealer logs.

Those credentials came from a mix of corporate and personal Windows endpoints, all used to access business‑related third‑party portals. On March 24, 2026, after the incident became public, Lunar ran a correlation and confirmed that the activity from last October lined up as a clear precursor window.

That kind of gap is typical of how today’s access‑broker ecosystem works: credentials are stolen, bundled, and sometimes traded more than once before someone decides to use them against a specific target.

Snapshot: Key Exposure Details

• Domain involved: astrazeneca.com
• Observed exposure window: October 2025
• Approximate distinct exposures: 4 credential sets
• Primary malware: Rhadamanthys infostealer
• Impacted infrastructure: Mixed corporate and personal Windows endpoints
• Targeted service categories: Third‑party portals used for business operations

Four users is a small number in the context of a global pharmaceutical company, but each of those identities used third‑party services that plug into AstraZeneca’s day‑to‑day workflows. One exposed account is often enough to get an attacker started.

Infostealers and the Power of Valid Accounts

Modern attackers increasingly prefer a login page to an exploit kit. Rather than hammering away at software flaws, they go after people’s browsers and reuse whatever those browsers remember.

Rhadamanthys is a good example of that model. Once it lands on a Windows device, typically through a phishing link, a malicious installer, or a “free” cracked download, it quietly pulls out:

• Stored browser credentials and autofill data
• Session cookies that can sometimes be replayed to sidestep MFA
• System metadata and, in many cases, cryptocurrency wallets and other sensitive artifacts

All of this feeds into what MITRE ATT&CK calls Valid Accounts (T1078): using real usernames and passwords instead of trying to break software. With working credentials in hand, an adversary can impersonate a legitimate user in third‑party portals, cloud apps, or partner systems. To a SOC watching from inside, early activity can look like a normal session from a familiar user.

A Likely Attack Pattern (Without Pointing to a Single Account)

Lunar is not claiming that any of the four exposed accounts we observed in October 2025 was the direct entry point for AstraZeneca’s March 2026 incident. What we can say is that the telemetry fits a pattern we see regularly in identity‑driven attacks:

1. Infection on a corporate or personal device: A user working with AstraZeneca‑related systems clicks a phishing link or installs a malicious file on a Windows endpoint. Rhadamanthys is dropped in the background.
2. Exfiltration of credentials: The infostealer scraps the browser for logins and cookies, including those used to access third‑party portals tied to AstraZeneca’s operations, and sends everything back to its operators.
3. Brokerage and stockpiling: Credentials are wrapped into automated logs and pushed to underground markets or private channels. Initial Access Brokers tag AstraZeneca entries and may keep them on the shelf for weeks or months.
4. Reconnaissance and access attempts: When someone decides to act, they use those stolen credentials to test access to VPNs, cloud services, or partner portals. If one works, and MFA or device checks aren’t strong enough, this becomes a quiet foothold for a broader intrusion.

It’s less a smash‑and‑grab than a slow burn, in which attackers steal first, wait, then see where those identities can take them.

The Human Factor and Shadow IT

Every exposed credential in this window came from a Windows endpoint, but not all of those machines lived inside AstraZeneca’s managed environment. Some were personal devices that employees or contractors used to reach business portals, while others were corporate laptops doubling as personal browsing devices.

In practice, that looks like:

• Logging into a vendor or clinical trial portal from a home PC
• Keeping “remember me” turned on in the browser for work accounts
• Mixing work logins and personal accounts in the same browser profile

Those personal or dual‑use machines rarely have the same EDR coverage, patching cadence, or hardening as core corporate assets, but they still store company credentials and session cookies. When Rhadamanthys lands on one of those devices, it doesn’t care whether the machine sits on a home network or behind a corporate firewall, the browser is enough.

That’s how the perimeter quietly dissolves. The first compromise happens outside the official environment, while the impact lands squarely inside it.

Defensive Takeaways for Identity‑Driven Risk

The Rhadamanthys activity we saw in October 2025, lined up against AstraZeneca’s March 2026 incident, is another reminder that identity protection can’t stop at the login page. A few practical steps help close the gap between exposure and misuse:

• Monitor for infostealer‑harvested credentials: Pull in third‑party threat intelligence that flags when user accounts show up in fresh logs. Treat each appearance as a small incident and reset the password, revoke active sessions, and review recent activity on that account.
• Enforce hardware‑based MFA on high‑value access paths: For admin accounts and critical third‑party portals, move beyond SMS and basic push‑based MFA toward FIDO2/WebAuthn security keys. That makes stolen passwords and many replayed cookies much harder to leverage.
• Strengthen endpoint integrity and limit unsupervised access: Ensure strong EDR coverage across corporate Windows assets, and set clear rules for accessing business‑critical portals from unmanaged personal devices. Where you can’t fully block BYOD, use conditional access and risk‑based policies to keep the most sensitive access on trusted endpoints.

Infostealers aren’t going away. The goal is to make the identities they capture less valuable, and to shorten the time between when credentials are stolen and when they can be classified as safe again. 

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.”