惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Proofpoint News Feed
Microsoft Azure Blog
Microsoft Azure Blog
Microsoft Security Blog
Microsoft Security Blog
T
The Exploit Database - CXSecurity.com
Hacker News - Newest:
Hacker News - Newest: "LLM"
云风的 BLOG
云风的 BLOG
Jina AI
Jina AI
Martin Fowler
Martin Fowler
博客园 - 司徒正美
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
A
About on SuperTechFans
H
Heimdal Security Blog
O
OpenAI News
T
The Blog of Author Tim Ferriss
Recent Announcements
Recent Announcements
C
CXSECURITY Database RSS Feed - CXSecurity.com
Spread Privacy
Spread Privacy
博客园_首页
H
Help Net Security
阮一峰的网络日志
阮一峰的网络日志
Project Zero
Project Zero
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Help Net Security
Help Net Security
I
InfoQ
L
Lohrmann on Cybersecurity
V
V2EX
Y
Y Combinator Blog
V
Vulnerabilities – Threatpost
G
Google Developers Blog
S
Secure Thoughts
I
Intezer
Blog — PlanetScale
Blog — PlanetScale
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
有赞技术团队
有赞技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Vercel News
Vercel News
www.infosecurity-magazine.com
www.infosecurity-magazine.com
N
News and Events Feed by Topic
S
Schneier on Security
NISL@THU
NISL@THU
B
Blog RSS Feed
F
Full Disclosure
U
Unit 42
Google DeepMind News
Google DeepMind News
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
L
LangChain Blog
博客园 - 【当耐特】
G
GRAHAM CLULEY

Sysdig Blog

Masterclass: AI is more than ChatGPT and LLMs CVE-2026-39987 update: How attackers weaponized marimo to deploy a blockchain botnet via HuggingFace 5 steps to securing AI workloads Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours Security briefing: March 2026 The Sysdig MCP server is now available in AWS Marketplace Risk isn’t reduced until you take action: How teams resolve issues in the cloud AI infrastructure security: Why it deserves its own category Three pillars for building effective runtime-powered cloud defense, the right way Closing the cloud security gap with runtime security Seeing risk isn’t stopping it: Why visibility alone isn’t enough TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions AI coding agents are running on your machines — Do you know what they're doing? Runtime security for AI coding agents: Protecting AI-assisted development How runtime insights power every cloud security use case CVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours Inline Cloud Response: Accelerating AWS threat containment for SOC teams Runtime malware detection for AWS Fargate Detecting CVE-2026-3288 & CVE-2026-24512: Ingress-nginx configuration injection vulnerabilities for Kubernetes Malware detection with Sysdig Security briefing: February 2026 Leveling up Kubernetes Posture: From baselines to risk-aware admission Eliminating runtime blind spots: How CleanStart and Sysdig build continuous trust across the container lifecycle LLMjacking: From Emerging Threat to Black Market Reality Real risks live at runtime: Why CISOs must care about deep telemetry in 2026 Sysdig named a Leader in the Forrester Wave™: Cloud Native Application Protection Solutions, Q1 2026 How to run rootless containers AI-assisted cloud intrusion achieves admin access in 8 minutes Security briefing: January 2026 Securing GPU-accelerated AI workloads in Oracle Kubernetes Engine Bringing OSS runtime security to AWS: Falco integration with AWS Security Hub CSPM Our customers have spoken: Sysdig rated a Strong Performer in Gartner® Voice of the Customer for Cloud-Native Application Protection Platforms Protecting sensitive business data in preparation for the organization's Gen AI VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits AI is still a workload: A practical guide to securing AI workloads How threat actors are using self-hosted GitHub Actions runners as backdoors How Sysdig Sage delivers AI-powered, real-world vulnerability management Security briefing: December 2025 Top 10 ways to get breached in 2026 EtherRAT dissected: How a React2Shell implant delivers 5 payloads through blockchain C2 Introducing runtime file integrity monitoring and response with Sysdig FIM How to detect multi-stage attacks with runtime behavioral analytics EtherRAT: DPRK uses novel Ethereum implant in React2Shell attacks Detecting React2Shell: The maximum-severity RCE vulnerability affecting React Server Components and Next.js The rise of AI agents: How autonomous AI Is transforming cloud security Kubernetes 1.35 - New security features The Urgency of Securing AI Workloads for CISOs Security briefing: November 2025 Quantum and the cloud: Science fiction turned security strategy Cloud security, the right way: What the industry should demand (and why "good enough" isn't) Return of the Shai-Hulud worm affects over 25,000 GitHub repositories Detecting CVE-2024-1086: The decade-old Linux kernel vulnerability that’s being actively exploited in ransomware campaigns What’s old is new again: How to demystify AI security with AIBOMs Securing Kubernetes with agentic cloud security How agentic cloud security reduces real risks Hunting reverse shells: How the Sysdig Threat Research Team builds smarter detection rules Shifting left with AI and MCP: Sysdig + Amazon Q Developer How Falco and Stratoshark close the gap between open source runtime detection and deep forensic analysis Investigating security issues with ChatGPT and the GitHub MCP server New runc vulnerabilities allow container escape: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881 Harden your LLM security with OWASP Security briefing: October 2025 How agentic AI is changing cloud security Kubernetes Incident Response: Detect, investigate, and contain in under 10 minutes Sysdig recognized as a Cloud Security Leader in Latio Tech Cloud Security Market Report AI echolocation of cloud risks using Sysdig & Snyk MCP servers Sysdig MCP Server: Bridging AI and cloud security insights Understanding CVE-2025-49844: “RediShell” Critical Remote Code Execution in Redis How Sysdig secures your containers and Kubernetes Sysdig Security Briefing: September 2025 Cloud security, the right way: The 3 pillars of real-time defense Open source spotlight: Bringing web application security to Falco with Falcoya's Nginx plugin Malicious NPM packages: Are you exposed? AI for SOC teams: 5 cloud security prompts to start your day with Sysdig Sage™ Shai-Hulud: The novel self-replicating worm infecting hundreds of NPM packages ZynorRAT technical analysis: Reverse engineering a novel, Turkish Go-based RAT Modern vulnerability management, built for the cloud Build your AWS incident response playbook with open source tools 2025 Gartner® CNAPP Market Guide: Runtime visibility is no longer optional Threat hunting with Sysdig: Uncovering “IngressNightmare” Open source spotlight: From alerts to action with AI-powered Falco Vanguard From triage to action: How Sysdig’s agentic cloud security platform slashes noise and accelerates remediation The vision comes to life: Agentic cloud security with Sysdig Sage™ Data security findings: A technical deep dive Connecting runtime to source: Sysdig and Semgrep integration Fix what matters, faster: How Sysdig and Semgrep are unifying security without silos – from code to runtime Defending sensitive data with Sysdig Secure Redefining cloud security, the right way Join the movement: The Sysdig Open Source Community is live A smarter, safer cloud in the age of AI Unifying detection and response: Sysdig + Cortex XSOAR for security at cloud speed The future of security is open, and it needs a unified hub: The Sysdig Open Source Community is here CVE-2025-53104: Command injection via GitHub Actions workflow in gluestack-ui Why MCP server security is critical for AI-driven enterprises What’s new in Sysdig — June 2025 AI-powered CNAPP with Sysdig Sage™ Revolutionizing Cybersecurity Search with Sysdig Sage™ Sysdig Threat Bulletin: Iranian Cyber Threats The end of the prioritization-only era: Vulnerability management needs action Dangerous by default: Insecure GitHub Actions found in MITRE, Splunk, and other open source repositories
The FulcrumSec playbook: How to detect and stop the group behind the Novo Nordisk breach
Crystal Morin · 2026-06-25 · via Sysdig Blog

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.