LAPSUS$ Is Back. This Time It's Pharma.

This post covers an unconfirmed claim. AstraZeneca has not confirmed or denied a breach as of 26 March 2026. All references to what LAPSUS$ “has” or “obtained” should be read as claims, not established fact.

What’s New This Week

As of 26 March 2026, AstraZeneca has still not issued any public statement. Security Week confirmed the forum posting is real and the group is actively soliciting buyers. The CSO Online piece published around 25 March connects this LAPSUS$ activity to the wider Trivy supply chain campaign that compromised over 1,000 enterprise SaaS environments – suggesting this is not an isolated incident but part of a coordinated resurgence.

Changelog

A threat actor identifying itself as LAPSUS$ has posted on a hacker forum claiming to have breached AstraZeneca. They say they have approximately 3GB of internal data packaged in a .tar.gz archive, and they’re selling it – not dumping it publicly. Interested buyers are directed to contact them via the Session secure messaging app. Password-protected paste links with redacted secrets have been shared as proof of access.

AstraZeneca has not commented. No statement, no denial, nothing. That silence tells you nothing either way – large organisations routinely say nothing until they know what they’re dealing with.

What the claim is, what the sample suggests, and why this matters even before confirmation – that’s what this post is about.

What LAPSUS$ Claims They Have

The alleged archive, identified in a directory tree as AZU_EXFIL, contains a repository named als-sc-portal-internal. Based on the structure, this appears to be an internal supply chain portal managing pharmaceutical distribution functions: demand forecasting, inventory tracking, product master data management, SAP system integration, and On-Time In-Full (OTIF) delivery metrics.

Beyond the supply chain portal, the claimed dataset includes:

• Source code across Java Spring Boot applications, Angular frontends, and Python scripts
• Terraform configurations for AWS and Azure, and Ansible roles for infrastructure automation
• Private cryptographic keys, HashiCorp Vault credentials, and authentication tokens for GitHub and Jenkins CI/CD pipelines

If accurate, that last category is not just a data leak. It’s a master key collection.

What HackRead’s Sample Analysis Found

HackRead reviewed samples from three categories included as proof material. Their assessment is worth examining closely because it’s one of the few attempts at independent technical analysis rather than just repeating the claim.

GitHub Enterprise User Data. The samples contained structured records with employee names, cost centre references, license types listed as Enterprise, enterprise roles and permissions, 2FA status, GitHub usernames, and org roles including Owner and Member. HackRead assessed the data structure as consistent with real enterprise GitHub exports and noted that the presence of accounts with Owner-level privileges across multiple repositories is highly sensitive if the data is authentic. Critically, they noted this is not consistent with public scraping – you can’t reconstruct this structure from public GitHub data.

Third-Party / Contractor Access Data. This category contained access requests and onboarding records for external collaborators from IQVIA, Parexel, and Labcorp – three major contract research organisations in the pharmaceutical industry. The records include internal user IDs, full names, email addresses, company affiliations, and access status to internal systems including Confluence. HackRead rated this moderate to high risk, noting that contractor relationship data is particularly useful for social engineering even if the primary perimeter holds.

Generic Financial Data. The third category contained what appears to be generic industry statistics – assets, salaries, total income, expenditure fields labelled “All industries.” HackRead assessed this as low risk with no direct connection to AstraZeneca, and noted it looks like filler included to bulk up the sample.

Two out of three categories show characteristics consistent with real internal data. One is padding. That’s not a clean bill of health, but it’s also not proof of a comprehensive breach.

Why CI/CD Credential Exposure Is the Real Problem

Even if AstraZeneca discovers tomorrow that the intrusion was limited in scope, the alleged presence of GitHub and Jenkins authentication tokens in the dump creates a downstream problem that doesn’t go away when the immediate incident is closed.

Credentials stored in CI/CD pipelines are often long-lived and broadly scoped. Jenkins service accounts frequently have write access to production deployment targets. GitHub tokens with Owner-level permissions can modify branch protection rules, approve pull requests, push to protected branches, and access private repositories across the organisation. Vault credentials can unlock secrets for multiple services simultaneously.

If those tokens exist in the claimed dump, and if they haven’t been rotated since the alleged breach window, anyone who acquires the data – not just the initial threat actor – has access to AstraZeneca’s deployment infrastructure. The private sale model means this data could move through several hands before it surfaces in a targeted attack.

The other issue: source code plus infrastructure configuration is a blueprint. An attacker with Terraform configs for your AWS environment, your Spring Boot application code, and credentials for your CI/CD pipelines doesn’t need to find a zero-day. They already know where the doors are.

The Third-Party Risk That Survives a Contained Breach

Even if AstraZeneca’s own systems remain uncompromised – or were only touched at the edges – the contractor access data is independently damaging.

IQVIA, Parexel, and Labcorp are major players in pharmaceutical contract research and trial management. Their employees have legitimate, documented access to AstraZeneca internal systems. That documentation is now claimed to be in the hands of a threat actor.

This is the long tail of contractor access management: you control your own perimeter, but your contractors appear in someone else’s breach. Their staff receive a convincing spear-phishing email with accurate internal references. They authenticate with their legitimate credentials. They’re inside your network because they’re supposed to be.

Supply chain risk isn’t just about software dependencies. It’s about who has access credentials to your systems and whether a breach of their data enables access to yours.

LAPSUS$ in 2026: Not a One-Off

It would be easy to treat this as an isolated claim from a group that made headlines in 2022 and 2023. That reading is wrong.

Cyfirma research published in January 2026 via Industrial Cyber flagged the resurgence of what they’re calling “Scattered Lapsus$” – monitoring of underground forums and Telegram channels indicating the group was actively rebuilding capacity for large-scale intrusion and extortion campaigns. Push Security’s blog reports that Scattered Lapsus$ Hunters have already claimed multiple public victims in 2026 with over 60 million records breached.

The Trivy connection makes this more significant. CSO Online reported around 25 March 2026 that what began as a supply chain attack on Trivy – a widely used open source security scanner common in CI/CD pipelines – has evolved into a LAPSUS$-linked extortion campaign affecting more than 1,000 enterprise SaaS environments. Trivy is the scanner many organisations use to check container images and infrastructure configurations for vulnerabilities. If it’s been weaponised as an entry vector, the affected organisations may have no idea yet.

LAPSUS$ has historically relied on MFA fatigue attacks – social engineering users into approving authentication requests through repeated push notifications until someone accidentally or frustratedly approves. That tactic, combined with brokered access to compromised credentials, gives them the initial foothold they need without requiring sophisticated exploitation.

One More Thing That Changed: The Threat Model

The original LAPSUS$ playbook involved very public extortion – dumping partial data on Telegram, threatening to release more, causing reputational damage as a lever. That approach meant victims knew quickly.

The AstraZeneca claim involves private broker sales through an encrypted messaging app. No public dump yet. The data circulates quietly among buyers. The victim may not discover the exposure until months later, when it surfaces in a targeted intrusion, a competitor has internal source code, or a regulator asks why certain information appeared on a dark web forum.

This shift from public spectacle to quiet brokerage changes the detection window and the response calculus. You can’t assess what’s been exfiltrated if you don’t know data is circulating.

What Organisations Should Actually Do

This is where most security posts go generic. Here’s what’s specifically relevant to the attack pattern in this claim:

Rotate CI/CD credentials now, not after confirmation. If you have GitHub tokens, Jenkins service account credentials, or Vault tokens that haven’t been rotated in more than 90 days, rotate them regardless of whether you’re connected to this incident. Long-lived credentials are the attack surface. Make them short-lived.

Audit Owner-level GitHub permissions. The HackRead analysis flagged the presence of Owner-role accounts across multiple repositories as particularly sensitive. Most organisations have more people with Owner permissions than they realise. Run the audit. Demote where you can. Owner access should be exceptional, not a default for senior developers.

Review contractor access logs for anomalies. If you have IQVIA, Parexel, Labcorp, or similar CRO relationships, check your access logs for their accounts going back 60-90 days. Look for off-hours access, unusual data volumes, or access to systems outside the normal scope of those contractor relationships.

Don’t wait for AstraZeneca’s confirmation before treating this as a live threat model. The sample data is partially credible. The group is active and scaling. The Trivy supply chain campaign is already affecting thousands of environments. If your CI/CD pipeline uses Trivy and you haven’t reviewed your configuration since January, start there.

Implement short-lived credentials with OIDC where you haven’t. If your GitHub Actions or Jenkins pipelines still use long-lived PATs stored as secrets, migrate to OIDC-based authentication where the token has a 15-minute lifespan and is scoped to the specific run. It eliminates the credential theft problem entirely for that vector.

The breach is unconfirmed. The group is not.