FulcrumSec Playbook: Sådan opdager og stopper du gruppen bag Novo Nordisk-bruddet

FulcrumSec-trusselaktørgruppen hævder for nylig at have stjålet mere end et terabyte data fra Novo Nordisk. Nyheden om bruddet fylder forsiderne verden over, og det er ikke første gang i år, at de har brudt sig ind hos en stor organisation. Men trods gruppens seneste “succes” har FulcrumSecs fremgangsmåde vist sig at følge nogle helt bestemte mønstre. Og hvor der er mønstre, har forsvarerne en mulighed for at komme et skridt foran.

FulcrumSec er hverken en nationalstatsaktør eller en ransomware-gruppe. De har ikke jagtet zero-day exploits eller kendte sårbarheder for at få fodfæste. I stedet – som det så ofte er tilfældet – var det en ærlig organisatorisk fejltagelse, der førte til et massivt datatab: Følsomme credentials blev efterladt i fuld offentlighed. Det er en velkendt historie, men én vi kan lære af.

Hvad ved vi så om, hvordan FulcrumSec opererer, og hvordan kan sikkerhedsteams forbedre deres synlighed og detektion?

Hvem er FulcrumSec, og hvem er deres mål?

FulcrumSec er en økonomisk motiveret gruppe af trusselaktører, der retter sig mod cloud-native virksomheder for at stjæle følsomme data. Når de først har brudt sig ind i offerets miljø, bruger gruppen dataene til afpresning. Hvis deres krav ikke imødekommes, sælger FulcrumSec de stjålne data videre. Det er også værd at bemærke, at der ikke er nogen kryptering eller systemforstyrrelser involveret i et FulcrumSec-brud. De kalder selv deres afpresningsmodel for “steal and squeeze” – stjæl og pres.

Gruppen, der også er kendt under tilnavnet “The Threat Thespians” (Trusselsskuespillerne), har været aktive siden mindst september 2025. Indtil dato har de krævet ansvar for cirka 25 ofre fra 11 lande, hvoraf de fleste har hovedsæde i USA. Deres mål hører primært hjemme inden for erhvervs- og forbrugertjenester, teknologi og sundhedssektoren – men den fælles røde tråd er cloud-hosting og dårlig identitetshygiejne.

FulcrumSecs Playbook

Cloud-angreb er et tveægget sværd – de er nemme at gentage, hvilket ofte gør dem mere forudsigelige for forsvarerne. FulcrumSecs taktikker, teknikker og procedurer (TTP’er) har været konsistente på tværs af deres brud. Gruppen har endda selv været åben om sine metoder og offentliggjorde et manifest med tekniske detaljer efter bruddet på LexisNexis tidligere i år. Det betyder, at forsvarerne med lidt analyse og proaktiv indsats har en reel mulighed for at stoppe dem.

Lad os se nærmere på disse mønstre.

Fase 1: Indledende adgang

FulcrumSec bruger én af tre døre – ingen af dem kræver nye teknikker eller specialudviklet værktøj. De leder simpelthen efter, hvilke døre organisationer har efterladt ulåste.

Dør ét: Hardcodede eller eksponerede credentials. Da de brød ind hos Novo Nordisk, hævder FulcrumSec, at de kom ind via to offentligt tilgængelige sandbox- og udviklingssubdomæner, der var tiltænkt at være private og sandsynligvis var blevet glemt: dev.nnedl.pub.aws.novonordisk.com og datahub-sand.novonordisk.com. Deres JavaScript indeholdt en Azure container registry-credential og et GitHub personal access token, der havde adgang til hundredvis af private repositories.

Under bruddet på fintech-platformen youX i februar 2026 udnyttede gruppen credentials, der havde været aktive i et produktionsmiljø siden 2021, samt uroterede JSON Web Token (JWT) signeringshemmeligheder.

Hvad kan detekteres? Tyveri af credentials sker ofte, inden der er nogen cloud-aktivitet at spore. Så selvom du måske ikke kan gribe en hemmelighed i det øjeblik, den forlader systemet, kan du opdage dens første brug i en uventet sammenhæng. Det dækker over adfærd som unormale API-kald fra en nyoprettet containeridentitet, en container registry-credential der bruges uden for normale åbningstider eller fra en uventet kilde-IP, eller et GitHub-token der pludselig bruger nye rettigheder. Selvom selve credentials måske er legitime, er den uregelmæssige kontekst, de bruges i, det røde flag.

Dør to: Upatchede, offentligt tilgængelige applikationer. Hos LexisNexis udnyttede FulcrumSec CVE-2025-55182 (React2Shell) – en kritisk remote code execution (RCE)-sårbarhed i React Server Components. Organisationen havde ikke patchet denne sårbarhed siden den blev offentliggjort i december 2025, og FulcrumSec kunne bare gå direkte ind ad fordøren.

Hvad kan detekteres? Dette varierer fra sag til sag, fordi detektionskrav pr. definition er forskellige for næsten enhver sårbarhed. I dette tilfælde er React2Shell et webserver-exploit, så en alarm skal udløses ved uventet procesoprettelse fra webserverprocessen, uregelmæssig kommandoudførelse, udgående forbindelser eller API-kald.

Dør tre: Fejlkonfigureret storage eksponeret mod internettet. Ud over credentials og sårbarheder scanner FulcrumSec også for fejlkonfigurationer. De har faktisk en hel sektion på deres lækageside dedikeret til det, de kalder “Index of /Shame.” Ud over de credentials og nøgler, de fandt hos youX, var der også en usikret MongoDB Atlas-klynge. Dnkluderer desuden Azure storage accounts, Databricks notebooks, AWS S3 buckets og Qualtrics-miljøer.

I FulcrumSecs første bekræftede brud – på teknologivirksomheden Avnet i september 2025 – fik de initial adgang via en offentligt tilgængelig, fejlkonfigureret cloud storage-tjeneste, der var koblet til et internt salgsværktøj. De brugte deen stjålet OpenAI API-nøgle til at vende ofrets egne credentials mod dem.

Hvad kan detekteres? Hold øje med uventet optælling (enumeration) af cloud storage-buckets eller containere fra en identitet, der normalt ikke rører dem – især hvis det kombineres med List- eller Describe-kald på tværs af tjenester i hurtig rækkefølge. Det er et klassisk eksempel på reconnaissance

Fase 2: Credential harvesting

Når angriberne er inde i et cloud-miljø med adgang til én enkelt credential, har de unikke muligheder foran sig.støj for at udnytte alt det, der er inden for rækkevidde. FulcrumSec er ingen undtagelse. Forskellen er, at etangreb i cloud-verden ikke drejer sig lateralt gennem netværket, som en traditionel angriber ville gøre. De drejer gennem rettigheder.

Hos LexisNexis placerede det indledende fodfæste via React-containeren dem inde i en Amazon Elastic Container SeLawfirmsStoreECSTaskRole), der havde læseadgang til alle hemmeligheder på AWS-kontoen. Denne enefejlkonfigurerede IAM-rolle låste 53 klartekst AWS Secrets Manager-poster op – herunder masteroplysninger til produktions-Redshift, VPC-databaser, Salesforce, Oracle og analyseplatforme. Det er en alvorlig blast radius uden behov for at eskalere rettigheder.

Hos Novo Nordisk hævder FulcrumSec, at de brugte det indledende GitHub-token til at klone de interne repositories, det havde adgang til, og derigennem finde yderligere credentials. Derefter brugte de to måneder på at bevæge sig lateralt på tværs af AzDevOps, GitHub, AWS og Hugging Face ved hjælp af disse credentials.

Hvad kan detekteres? List*-, Describe*- og Get*-API-kald på tværs af flere tjenester fra én enkelt rolle eller identitet kan signalere cloud-enumeration og er et klart advarselstegn. Du også holde øje med en containeridentitet, der aldrig har kaldt Secrets Manager og pludselig læser alle poster, elleret i én region og pludselig kalder API’er fra en ny region. Udviklermæssige uregelmæssigheder kan ogsådetekteres – f.eks. masserepository-kloning ud over rammerne for normale CI/CD-mønstre, tokenbrug uden for normale arbejdslokationer og -tidspunkter, samt lateral bevægelse på tværs af miljøer, der ikke er en normal identitetssti.

Fase 3: Dataindsamling

Nogle moderne cloud-native angreb kan køre fra ende til anden på få minutter. En angriber kan stjæle credentials på tre minutter eller eksfiltrere en database på under en time.FulcrumSec smadrer dog ikke bare igennem og stikker af – de samler information stille og roligt. Det er det, der gør dem farlige i miljøer med huller i detektionen.

Novo Nordisk-operationen løb angiveligt fra marts til juni – det er over to måneder med vedvarende adgang.de lang dwell time. FulcrumSec tager, hvad de har brug for, metodisk: kildekode, interne AI-modeller, proprietærforskning, kliniske data, medarbejderregistre eller produktionsdetaljer. Når offeret opdager, at der er et problem, har modstanderen allerede opbygget en omfattende samling af efterretninger og data.

Hvad kan detekteres? En adfærdsmæssig baseline er nøglen her. Hold øje med tegn som vefra databaser, object storage eller koderepositories fra identiteter, der normalt ikke tilgår disse ressourcer– eller som gør det, men ikke i det omfang eller den kadence. Runtime visibility, der kontekstuelt forbinder workload-adfærd med den identitet, der står bag den, vil hjælpe med at afdække en sporbar tidslinje.

Fase 4: Eksfiltrering

FulcrumSec flytter data ud i stilhed over uger. Fem af de 26 ofre tegner sig for krav om næsten fem terabyte komprimerede stjålne data – eller hundredtusindvis af følsomme filer. FulcrumSec eksfiltrerer ved hjælp af legitime overførselsværktøjer indikator for kompromittering, der viser, hvornår de begynder at flytte data – ingen malware-signatur, intetbrugerdefineret C2-framework, ingen offentlige YARA-regler eller filhashes. Traditionel endpoint- og signaturbaseret detektion ser ingenting.

Hvad kan detekteres? Hold øje med uventede mængder data, der bevæger sig fra cloud stoories til uventede destinationer, på usædvanlige tidspunkter, fra identiteter, der normalt ikke rører disseressourcer.

Fase 5: Afpresning

Når FulcrumSec kontakter et offer, kommer de velforberedte. De deler fillister, eksempeldata og forhandlingstidslinjer. Hvis offeret ikke betaler – eller holder lav profil – eskalerer FulcrumSec offentligt. De udgiver på deres darkweb- og offentlige lækagesider, poster på brudforummer og nævner til tider endda ledere ved navn. Derefter tilbyder de data

Hvad mønstrene fortæller os

På tværs af alle dokumenterede FulcrumSec-operationer – og faktisk næsten alle cloud-native brud – dejl op:

• Hemmeligheder befinder sig i kode, hvor de ikke hører hjemme. Hardcodede tokens i JavaScript, PI-nøgler i CI/CD-logs – det er indgangspunkterne.
• Cloud-identiteter er over-permissioneret. LexisNexis’ ECS task role, der låste hele en AWS-konto op, er det tydeligste eksempel – men det underliggende problem er universelt: maskinidentiteter – servicekonti, containerroller, udvikler-tokens – ophober rettigheder, der langt overstiger det nødvendige. Se bare, hvor laeret cloud-identitet faktisk kan nå. Det gør ondt, og det er langt mere udbredt, end de fleste tror. Ifølge SysdigsCloud-Native Security and Usage Report 2025, Nordics Regional Highlights, opretholder 60% af organisationer Norden risikable serviceidentiteter.
• Detektionshuller lader dwell time vokse. FulcrumSec har ikke brug for fart, fordi de drager fordel af usynlighed. Miljøer uden adfærdsbaseret detektion på cloud-identitet, repository-adgang og runtime workload-aktivitet giver dem ugenogle tilfælde – selv efter at en organisation har opdaget det indledende indbrud – kan den ikke se, hverede er brugt.
• Patching taber stadig kapløbet. React2Shell-sårbarheden (CVE-2025-55182) var på CISA KEV med en syv-dages afhjælpningsfrist. LexisNexis blev brudt to måneder efter den frist var udløbet. Dette er ikke unikt for LexisNexis – detsystemisk problem med internetvendt applikationsinfrastruktur, og det bliver kun værre. Nu godt inde i 2026 ser vi t inden for blot fire timer efter offentliggørelse.

Sådan forsvarer du dig mod cloud-afpresning

FulcrumSecs Playbook er ikke særlig tykt. De har identificeret de samme huller hos snesevis af cloud-native mål.en forsvarlig Playbook – så her er, hvor du kan begynde:

Eliminer hemmeligheder fra kode og build-artefakter

Scan Git commit-historikker, CI/CD pipeline-logs, containerimages og client-side JavaScript for eksponerede credoduktion. Dette skal være kontinuerligt – ikke en engangsrevision. Hemmeligheder, der er eksponeret, børbehandles som kompromitterede. Rotation er en inddæmningspraksis, ikke en forholdsregel.

Erstat langlivede personal access tokens og statiske registry-credentials med kortlivede, snævert afgrænset alte En credential med en 90-dages udløb og snæver afgrænsning er et dramatisk mindre problem end et uroteret token fratidligere år med bred repository-adgang – men jo strammere, jo bedre.

Kortlæg og reducer maskinidentiteternes blast radius

For hver maskinidentitet – IAM-roller, servicekonti, ECS task roles, containeridentiteter eller udviklertokens – spørg dig selv: Hvor langt kan den nå, hvis den kompromitteres? De fleste organisationer har aldrig gennemgået denne øvelse systematisk, fordi det er en omstændig proces. Alligevel opretholder mange af de samme organisationer tusindvis ellidentiteter.

Håndhæv princippet om mindste privilegium (least privilege), opdel brede roller i per-service-roller, og hvis en container, der kører et juridisk research-frontend, ikke behøver læseadgang til alle kontoens hemmeligheder – så fratag den den adgang.

Patch internetvendte applikationer… hurtigere

Angribere udnyttede aktivt React2Shell, længe inden LexisNexis blev brudt af FulcrumSec. Hullet var ikke mangel nglende handling. Internetvendte applikationer – især dem, der håndterer autentifikation eller kører undercloud-roller – skal have en accelereret patchingkadence sammenlignet med interne systemer. En prioriteret sårbarhedsplan er afgørende.

Detektér adfærd, ikke kun posture

Posture er vigtig. Undgå hardcodede hemmeligheder, og giv ikke roller for mange rettigheder. Men proaktiv posture management alene opdager ikke trusselgrupper som FulcrumSec, når de først er inde i dit miljø. Det, der fanger dem, er adfærdsbaseret detaf anomalier: uregelmæssige regioner, kald, bevægelser eller adgangsmønstre. Disse adfærdssignaler kræver ikke kendr eller signaturer – de kan detekteres ud fra selve aktiviteten.

Korrelér på tværs af identitet, cloud og runtime

FulcrumSecs operationer spænder over flere kontrolplaner: koderepositories, IAM, workloads og cloud storage. En ét lag, ser kun en del af historien. Det starter med en container, der forespørger instance metadata service. Denne adfærd hænger sammen med en IAM-rolle, der foretager uventede Secrets Manager-kald, som igen hænger sammen med unormal databaseaktivitet. Hvert enkelt hændelse isoleret set kan måske bortforklares. Tilsammen er de uomtvistelige.

Sikkerhedsprogrammer, der korrelerer identitetshændelser, cloud control plane-aktivitet og runtime workload-adfæer efterforskere mulighed for hurtigt at forstå omfanget. De bekræfter ikke blot, at en hændelse har fundet sted– de kan spore præcis, hvor blast radius nåede hen, og hvad der blev tilgået.

Konklusion

Ikke alle cloud-native trusselaktører er teknisk sofistikerede som nationalstatsaktører – og det behøver de heller ikke at være. FulcrumSec finder de samme huller, udnytter de samme fejltagelser og eksekverer den samme spillebog med konsistente resultater hos snesevis af ofre. Novo Nordisk-bruddet er det seneste, men det ligner strukturelt det, de gjorde hosndre.

Den ubehagelige sandhed er, at disse brud ofte sker, fordi cloud-miljøer ophober credential debt og identity sprawl hurtigere, end de fleste sikkerhedsprogrammer kan følge med til eller løse. De adfærdssignaler, der ville afsløre en modstander, som lever skjult inde i et miljø, er ofte blot et hul – men med de rette detektioner på plads til at fremhæve disse mønet.