The FulcrumSec playbook: How to detect and stop the group behind the Novo Nordisk breach

The FulcrumSec threat actor group recently claimed to have stolen more than a terabyte of data from global pharmaceutical company Novo Nordisk, the manufacturer of Ozempic and Wegovy. News of the breach is making headlines worldwide, and this isn’t the first time this year they have breached a major organization. However, despite the group’s recent “success,” FulcrumSec’s playbook has shown a few definitive patterns. And where patterns exist, defenders have an opportunity to get ahead.

FulcrumSec isn’t a nation-state threat actor or a ransomware group. They haven’t pursued zero-day exploits or popular vulnerabilities for initial access. Instead, as is often the case, an honest organizational mistake led to a massive data loss: Sensitive credentials were left exposed. It’s a familiar story, but one we can learn from.

So, what do we know about how FulcrumSec operates, and how can security teams improve their visibility and detections?

Who is FulcrumSec, and who do they target?

FulcrumSec is a financially motivated group of threat actors that targets cloud-native businesses for sensitive data. Once they're able to breach a victim’s environment, the group leverages the data for extortion. If their demands are not met, FulcrumSec then sells whatever data they’ve stolen. It’s important to note, too, that there is no encryption or disruption involved in a FulcrumSec breach. They call their extortion model “steal and squeeze.”

Also known as “The Threat Thespians,” FulcrumSec has been active since at least September 2025. To date, they have claimed approximately 25 victims from 11 countries, most of whom are headquartered in the US. Their targets largely fall into business and consumer services, technology, and healthcare sectors, but their unifying target priorities are ultimately cloud hosting and poor identity hygiene.

The FulcrumSec playbook

Cloud attacks are a double-edged sword – they are easy to repeat, which often makes them more predictable for defenders. FulcrumSec’s tactics, techniques, and procedures (TTPs) have been consistent across their breaches. The group itself has even been transparent about its methods, publishing a manifest with technical details following its breach of LexisNexis earlier this year. That means, with some analysis and proactive effort, defenders have an opportunity to thwart them.

Let’s explore some of those patterns.

Stage 1: Initial access

FulcrumSec enters through one of three doors, none of which requires a novel technique or custom tooling. They look for which doors organizations leave unlocked.

Door one: Hardcoded or exposed credentials. When they breached Novo Nordisk, FulcrumSec claims they entered via two public-facing sandbox and development subdomains that were meant to be private and were likely forgotten: dev.nnedl.pub.aws.novonordisk.com and datahub-sand.novonordisk.com. Their JavaScript contained an Azure container registry credential and a GitHub personal access token, which had access to hundreds of private repositories.

During its breach of fintech platform youX in February 2026, the group exploited credentials that had been active in a production environment since 2021, as well as unrotated JSON Web Token (JWT) signing secrets.

What’s detectable? Credential theft often happens before any cloud activity. So while you may not be able to catch a secret leaving, you can catch its first use in an unexpected context. That includes behaviors like anomalous API calls from a newly active container identity, a container registry credential used outside regular hours or from an unexpected source IP, or a GitHub token using new permissions. While the credential may be legitimate, the irregular context in which it’s being used is the red flag.

Door two: Unpatched public-facing applications. At LexisNexis, FulcrumSec exploited CVE-2025-55182 (React2Shell), a critical remote code execution (RCE) vulnerability in React Server Components. The organization hadn't patched this vulnerability since its December 2025 disclosure, and FulcrumSec was able to walk right in.

What’s detectable? This will vary on a case-by-case basis because detection requirements, by nature, vary for nearly every vulnerability. In this case, React2Shell is a web server exploit, so an alert must trigger for unexpected process spawning from the web server process, irregular command execution, outbound connections, or API calls.

Door three: Misconfigured storage exposed to the internet. In addition to credentials and vulnerabilities, FulcrumSec also scans for misconfigurations. In fact, they have an entire section of their leak site dedicated to what they call the “Index of /Shame.” In addition to the credentials and keys they were able to surface from youX, there was also an unsecured MongoDB Atlas cluster. Their documented target list also includes Azure storage accounts, Databricks notebooks, AWS S3 buckets, and Qualtrics environments.

Furthermore, during FulcrumSec’s first confirmed breach, which was of the technology company Avnet in September 2025, initial access was gained through a public-facing, misconfigured cloud storage service that was connected to an internal sales tool. They then used a stolen OpenAI API key to weaponize the victim’s credentials against themselves.

What’s detectable? Look for unexpected enumeration of cloud storage buckets or containers from an identity that doesn't normally touch them, especially if paired with List or Describe calls across services in rapid succession. This is a classic example of reconnaissance.

Stage 2: Credential harvesting

Once inside a cloud environment, with access to a single credential, attackers have unique opportunities. However, they need to make noise in order to capitalize on all that is within their reach. This has been no different for FulcrumSec breaches. The difference is that, in the cloud, an attack doesn't pivot through the network the way a traditional lateral mover would. They pivot through permissions.

At LexisNexis, the initial foothold through the React container placed them inside an Amazon Elastic Container Service (ECS) task role (LawfirmsStoreECSTaskRole), which had read access to every secret in the AWS account. This single misconfigured IAM role unlocked 53 plaintext AWS Secrets Manager entries, including master credentials for production Redshift, VPC databases, Salesforce, Oracle, and analytics platforms. That’s a serious blast radius with no need to escalate privileges.

For Novo Nordisk, FulcrumSec claims they used the initial GitHub token to clone the internal repositories it had access to and surface additional credentials. Then they spent two months using those credentials to move laterally across Azure DevOps, GitHub, AWS, and Hugging Face.

What’s detectable? List*, Describe*, and Get* API calls across multiple services from a single role or identity can signify cloud enumeration and be a clear giveaway. You can also look for a container identity that has never called Secrets Manager suddenly reading all entries, or a role that has only operated in one region calling APIs from a new region. Developer irregularities can be detected as well, such as bulk repository cloning beyond the scope of normal CI/CD patterns, token usage outside normal operating locations and hours, and lateral movement across environments that is not a normal identity path.

Stage 3: Data collection

Some modern cloud-native attacks can run end-to-end in a matter of minutes. An attacker can steal credentials in three minutes or exfiltrate a database in under an hour. However, FulcrumSec doesn't smash and grab — they accumulate information quietly. This is what makes them dangerous in environments with detection gaps.

The Novo Nordisk operation reportedly ran from March to June. That’s more than two months of continuous access. The youX breach had a similar extended dwell time. FulcrumSec takes what it needs methodically: source code, internal AI models, proprietary research, clinical data, employee records, or manufacturing details. By the time the victim knows there's a problem, the adversary has already built an extensive collection of intelligence and data.

What’s detectable? Having a behavioral baseline is the key here. Look out for signs like sustained, low-volume reads from databases, object storage, or code repositories from identities that don’t normally access those resources, or that do, but not at that cadence or scope. Runtime visibility that contextually connects workload behavior with the identity behind it will help uncover a traceable timeline.

Stage 4: Exfiltration

FulcrumSec moves data out quietly over weeks. Five victims of the 26 account for claims of nearly five terabytes of compressed stolen data, or hundreds of thousands of sensitive files. FulcrumSec exfiltrates using legitimate transfer tooling like rclone. There's no easy indicator of compromise to see them start moving data; no malware signature, custom C2 framework, public YARA rules or file hashes. Traditional endpoint and signature-based detection sees nothing.

What’s detectable? Look for unexpected volumes of data moving from cloud storage, databases, or repositories to unexpected destinations, at unusual times, from identities that don't normally touch those resources.

Stage 5: Extortion

When FulcrumSec contacts a victim, they come prepared. They share file lists, sample data, and negotiation timelines. If the victim doesn't pay, or if they go quiet, that’s when FulcrumSec escalates publicly. They publish on their dark web and public leak sites, post to breach forums, and even sometimes name executives. Then, they offer the data for private sale.

What the patterns tell us

Across every documented FulcrumSec operation, and really nearly every cloud-native breach, the same structural failures appear:

• Secrets exist in code where they shouldn’t. Hardcoded tokens in JavaScript, credentials in repositories, API keys in CI/CD logs are the entry points.
• Cloud identities are over-permissioned. The LexisNexis ECS task role that unlocked an entire AWS account is the clearest example, but the underlying problem is universal: machine identities — service accounts, container roles, developer tokens — accumulate permissions that far exceed what they need. Look how far a forgotten or compromised cloud identity can actually go. It hurts, and it’s far more common than you think. According to the Sysdig 2025 Cloud-Native Security and Usage Report Nordics Regional Highlights, 60% of organizations in the Nordics region maintain risky service identities.
• Detection gaps let dwell time compound. FulcrumSec doesn't need speed because they benefit from invisibility. Environments without behavioral detection on cloud identity, repository access, and runtime workload activity give them weeks. In some cases, even after an organization detects the initial intrusion, it can't see where else the stolen credentials have already been used.
• Patching is still losing the race. The React2Shell vulnerability (CVE-2025-55182) was in CISA KEV with a seven-day remediation deadline. LexisNexis was breached two months after that deadline passed. This isn't unique to LexisNexis, though. It's a systemic problem with internet-facing application infrastructure, and it’s only getting worse. Now well into 2026, we’re seeing new vulnerabilities being exploited within as little as four hours of disclosure.

How to defend against cloud extortion

FulcrumSec’s playbook isn’t that big. They’ve identified the same gaps across dozens of cloud-native targets. A predictable playbook is a defensible one, so here’s where you can start:

Eliminate secrets from code and build artifacts

Scan Git commit histories, CI/CD pipeline logs, container images, and client-side JavaScript for exposed credentials before they ship. This should be continuous, not a one-time audit. Secrets that are exposed should be treated as compromised. Rotation is a containment practice, not a precaution.

Replace long-lived personal access tokens and static registry credentials with short-lived, tightly scoped alternatives wherever possible. A credential with a 90-day expiration and narrow scope is a dramatically smaller problem than an unrotated token from years passed with broad repository access — but the tighter, the better.

Map and reduce the machine identity blast radius

For every machine identity, such as an IAM role, service account, ECS task role, container identity, or developer token, ask what it can reach if compromised. Most organizations have never done this exercise systematically because it’s a tedious process. Yet many of those same organizations maintain thousands or hundreds of thousands of machine identities.

Enforce least privilege, decompose broad roles into per-service roles, and if a container running a legal research frontend doesn't need read access to every secret in the account, then revoke it.

Patch internet-facing applications… faster

Attackers were actively exploiting React2Shell long before LexisNexis was breached by FulcrumSec. The gap was not intelligence. It was execution. Internet-facing applications, especially those handling authentication or running under cloud roles, need to be on an accelerated patching cadence relative to internal systems. A vulnerability prioritization schedule is key.

Detect behavior, not just posture

Posture matters. Don't have hardcoded secrets, and don't over-permission roles. But proactive posture management alone doesn't catch threat groups like FulcrumSec once they're inside your environment. What catches them is behavioral detection of anomalies: irregular regions, calls, movement, or access. These behavioral signals don't require knowing the attacker's tool or signatures; they're detectable from their activity itself.

Correlate across identity, cloud, and runtime

FulcrumSec's operations span multiple control planes: code repositories, IAM, workloads, and cloud storage. A detection that fires on only one layer sees only part of the story. It starts with a container querying the instance metadata service. That behavior connects to an IAM role making unexpected Secrets Manager calls, which connects to anomalous database activity. Each event in isolation could be explained away. Together, they're unambiguous.

Security programs that correlate identity events, cloud control plane activity, and runtime workload behavior into a unified timeline give investigators the ability to understand the scope quickly. They don’t just confirm that an incident occurred, but trace exactly where the blast radius went and what was accessed.

Conclusion

Not all cloud-native threat actors are as technically sophisticated as nation-state threat actors, nor do they need to be. FulcrumSec is finding the same gaps, exploiting the same mistakes, and executing the same playbook with consistent results across dozens of victims. The Novo Nordisk breach is the most recent, but it's structurally similar to what they did at LexisNexis, youX, Avnet, and others.

The uncomfortable truth is that these breaches often happen because cloud environments accumulate credential debt and identity sprawl faster than most security programs can track or address. The behavioral signals that would expose an adversary living inside an environment are often just a gap, but with the right detections in place to highlight those patterns, defenders can close it.