אִם יִרְצֶה הַשֵּׁם
Novo Nordisk trains machine-learning models for drug discovery, molecular design, and trial optimization. It backed Denmark's first AI supercomputer. On June 11, 2026, the company disclosed unauthorized access to a limited number of internal IT systems and confirmed that pseudonymized clinical trial data had been copied.
FulcrumSec, a data-theft extortion group active since late 2025, claims a much larger operation: 1.3 TB of exfiltrated data, including source code repositories, proprietary drug compounds, trained AI models, training logs, and employee records. Novo Nordisk has not confirmed or denied the full scope. Extortion actors routinely inflate theft inventories to increase payment pressure, so FulcrumSec's published numbers should be read as claims under negotiation, not forensic findings. What follows treats them that way.
The entry vector, per Sysdig's analysis of FulcrumSec's playbook across its 25 victims, was an Azure container registry credential and a GitHub personal access token embedded in client-side JavaScript on two subdomains (dev.nnedl.pub.aws.novonordisk.com and datahub-sand.novonordisk.com) that were meant to be private. No zero-day. No malware. Two strings in a JavaScript file.
Walking the credential graph
Every post in this series has tracked the same structure: trust flows through a graph, each edge carries a verification obligation, and the breach happens at the edge nobody checks. Mini Shai-Hulud walked the npm dependency graph. TrapDoor poisoned the instruction-file graph. Mercor/LiteLLM chained four hops from a package registry into an AI training pipeline.
FulcrumSec walks the credential graph. The mechanism differs from npm in an important way. Package dependencies are transitive by design: each package explicitly declares and imports its dependencies, and the build system resolves the chain automatically. Credential chains in cloud infrastructure are not designed to be transitive. Nobody at Novo Nordisk intended the JavaScript on a sandbox subdomain to grant access to internal GitHub repositories, or intended those repositories to contain further credentials leading into Azure. The transitivity is accidental. It exists because developers store secrets in places that are reachable from other places, and nobody maps the resulting graph or audits what a single compromised credential can reach.
The shape of the traversal is the same even though the cause is different. In both cases, the attacker enters at one node and reaches nodes that were never meant to be reachable from the entry point. In both cases, the defender's blindness is structural: nobody drew the graph, so nobody can see how far a single compromised edge extends. The 2009 nth-order taxonomy describes this as hop-count expansion, each hop between entry and target lengthening the chain faster than defenders trace it. At Novo Nordisk, Sysdig reports that the security team detected the GitHub intrusion after approximately two weeks and the Azure intrusion after approximately three. Whether those timelines come from Novo Nordisk's own incident response or from FulcrumSec's account relayed through Sysdig is not clear from the public reporting. Either way, the exfiltration window was measured in weeks, not hours.
What cannot be rotated
Here is the part that makes this breach structurally different from the others in this series.
After a credential breach, the standard response is: rotate the credential, revoke the session, notify affected users. Every step assumes the stolen thing can be invalidated. A new password replaces the old one. A new API key revokes the old one. The loss is bounded by the window between theft and rotation.
If even a fraction of FulcrumSec's claimed inventory is genuine, the loss here includes assets that cannot be invalidated. A stolen molecular structure for a drug compound stays stolen. A model checkpoint gives whoever holds it the training trajectory, not just final weights. Training logs from many runs are a record of a research program's strategic decisions: what was tried, what failed, what direction the team chose. These artifacts are the kind of thing a state-backed competitor would spend years trying to reproduce. FulcrumSec says it is pursuing private sales.
The pharmaceutical industry's security investment is calibrated to the assets that carry regulatory penalties: patient data, PII, protected health information. GDPR and HIPAA set the fines. The compliance machinery is organized around those categories. Novo Nordisk's disclosure correctly emphasized that patient records were pseudonymized. That is the regulated loss. The unregulated loss, the algorithmic IP, has no mandatory notification threshold, no established damage-assessment method, and no compliance framework that forces the board to measure it. Whether this particular gap is why the JavaScript credentials were not caught is unknown. What is known is that the industry has a mature response playbook for stolen patient data and no equivalent playbook for stolen research programs.
The stealer logs saw it first
Ransomnews pulled infostealer telemetry for novonordisk.com before the breach was publicly disclosed: 211 employee credentials and 580 customer credentials were already circulating in stealer indexes, plus 2,932 harvested session cookies.
FulcrumSec may or may not have used those specific credentials. The entry vector Sysdig describes (JavaScript-embedded tokens on two subdomains) is a different class of exposure than stealer-harvested passwords. But the stealer logs show what the credential perimeter looked like from the outside: porous across multiple categories, for months, before anyone acted.
This is the observation that should change how defenders budget. Stealer-log telemetry is a leading indicator. It does not tell you who will exploit the gaps or when. It tells you the gaps exist. If your employee credentials are circulating in stealer markets, your credential perimeter is already being harvested. That does not make a breach inevitable, but it shortens the attacker's reconnaissance and raises the probability that someone will try the doors the logs have already mapped.
Why was the scan missing?
The two JavaScript credentials would have been caught by a secrets scanner configured to cover those subdomains. Why it did not happen is the question the post cannot answer from public reporting. The possibilities include: the subdomains were shadow IT that the security team did not know existed; the subdomains were decommissioned projects that were never removed; a secrets scanner was deployed but its coverage did not extend to these repositories; the scanner ran but its rules did not match the credential format; or the scan was never configured because no one assessed the risk of client-side JavaScript on sandbox environments.
Each of those failures has a different root cause and a different fix. Some are tooling problems. Some are process problems. Some are organizational visibility problems. I do not know which one applies here, and claiming to know would be guessing.
What I can say is that the cost of the missing scan, whatever its cause, is disproportionate to the cost of performing it. Secrets scanning is a solved problem at the tooling level. The hard part is not the tool. The hard part is ensuring the tool covers every place credentials might land, including the places nobody remembers exist. The verification bottleneck is a coverage problem: verification tools exist, but they do not cover the full surface of what gets deployed, because the surface grows faster than the coverage configuration.
Two strings. Two subdomains nobody was watching. A credential graph nobody had mapped. And at the far end, an AI research program that cannot be rotated back.
All as designed.