En zero-day-sårbarhet publisert 12. mai 2026 gjør det mulig å omgå BitLocker i standardkonfigurasjoner av Windows 11. Selv om de tekniske detaljene er interessante, er det de potensielle konsekvensene som er mest alvorlige. La oss se nærmere på hva YellowKey forteller oss om default-config som sikkerhetsstrategi.
Tidslinje
- En forsker som kaller seg Nightmare-Eclipse publiserte 12. mai et fungerende exploit («YellowKey») som omgår BitLocker på Windows 11, Windows Server 2022 og Windows Server 2025 i standardkonfigurasjon.
- Angrepet krever fysisk tilgang og en USB-pinne. Ingen brute-force. Ingen kryptografisk brudd. Ingen recovery key.
- Sårbarheten ligger i Windows Recovery Environment (WinRE), ikke i BitLocker selv. Den utnytter en kryss-volum-feil i de transaksjonelle NTFS-loggene.
- Windows 10 er ikke berørt. Komponenten finnes også der, men uten den funksjonaliteten som gjør angrepet mulig.
- Per 16. mai 2026 har Microsoft verken publisert en CVE eller en patch. TPM+PIN stopper den publiserte PoC-en pålitelig. Forskeren hevder at en variant også fungerer mot TPM+PIN, men uten å ha publisert dokumentasjon eller bevis.
- Den viktigste lærdommen handler ikke om BitLocker. Den handler om at sikkerhet aldri har vært ett enkelt valg, men en sikkerhetsreise, hvor det må tas velg for et helt system, ikke bare en komponent.
12. mai 2026 – hva skjedde?
12. mai 2026 publiserte en pseudonym sikkerhetsforsker et exploit kalt YellowKey. Det er et svært enkelt verktøy som, med fysisk tilgang til en Windows 11 maskin med full diskkryptering, kan låse opp BitLocker beskyttede disker på under to minutter. Dette er ikke et kryptografisk angrep. AES er ikke brutt. Forskeren oppdaget at gjenopprettelsesmiljøet (WinRE), som er signert, låst ned og en del av Windows installasjonen, kan lures til å lese opp disken der et annet beskyttet volum ligger, og deretter sette til side sikkerhetsbegrensninger for den gjenopprettede kommandoen.
Will Dormann fra Thorns Labs reproduserte exploitet og oppsummerte det presist på Mastodon: en \System Volume Information\FsTx mappe på én harddisk kan endre filer på et annet volum når Windows prøver NTFS transaksjonsrullering. Kevin Beaumont bekreftet at exploitet er reelt og anbefalte umiddelbart TPM+PIN som mitigasjon.
Det er to ting verdt å merke seg her. Den ene er den tekniske mekanismen. Den andre er en signert Microsoft komponent som plutselig ser ut til å kunne brukes til å åpne døren igjen, ordtaket «safe like a backdoor». Det er en sterk påstand. Den er ikke verifisert. Men den fortjener en grunnleggende seriøs ettertanke.
Hvorfor dette betyr mer enn enda en zero-day
Det er også derfor YellowKey er mer interessant enn mange andre zero-days.
De fleste zero-day-sårbarheter følger et kjent mønster:
- En angriper på internett sender en payload til offeret, via e-post, nettside eller Office-fil.
- En lokal bruker eskalerer privilegier på en allerede kompromittert maskin.
YellowKey passer ikke helt inn i noen av disse kategoriene. Den handler om noe mer grunnleggende: hva som skjer når tilliten mellom systemkomponenter bryter sammen.
Det er et verdensbilde mange virksomheter fortsatt har bygget sine sikkerhetsmodellene sine rundt: «Alle bærbare enheter skal ha BitLocker aktivert.» Punktum! Compliance-kolonnen er oppfylt. ISO-rapport godkjent!
Problemet er at «BitLocker aktivert» for mange i praksis har vært synonymt med standardkonfigurasjon: Windows 11 levert med TPM only, uten pre boot PIN, automatisk opplåsing ved oppstart. Det er den konfigurasjonen YellowKey angriper. Og det er den konfigurasjonen som har gjort BitLocker enklere å rulle ut i stor skala.
«Det vi har trodd vi styrte, har enten ikke vært der, eller vært usynlig. Det vi faktisk styrte, har enten vært der og angrepet med en USB-pinne, eller vært usynlig.»
For den reelle forskjellen mellom pålitelighet, skalerbar kontroll og kontroll på et hotellrom i et fiendtlig regime — er forskjellen mellom de to innstillingene nedenfor.
Det tekniske bak YellowKey
For lesere som ønsker dypere innsikt: her er idéen, så presist som mulig oppsummert fra offentlige kilder. Forbeholdet følger med en gang: ingen utenfor Microsoft kjenner alle detaljene fullt ut.
Trinn 1: TPM låser opp volumet
I standard BitLocker oppsett er Volume Master Key (VMK) forseglet til TPM-en. TPM-en frigir nøkkelen når boot kjeden matcher forventede målinger (PCR verdier). Windows Recovery Environment er en signert Microsoft komponent og regnes som en del av den målte boot kjeden. Når WinRE starter, frigir TPM-en VMK-en automatisk.
Dette er ikke i seg selv en sårbarhet, det er designet. Brukervennlighet over absolutt sideeffekt.
Trinn 2: Transactional NTFS replay krysser volumgrenser
Transactional NTFS (TxF) er en mekanisme for atomiske filoperasjoner. Den lagrer transaksjonslogger i mapper som \System Volume Information\FsTx, også når systemet kjører i recovery mode.
Det publiserte angrepet utnytter at replay mekanismen tilsynelatende kan følge katalogreferanser på tvers av volumer. En FsTx mappe på et eksternt volum, for eksempel en USB-pinne, kan dermed påvirke filer på et annet volum, i dette tilfellet boot volumet. Dette er kryss volum bugen som sannsynligvis gjør angrepet mulig.
Trinn 3: WinRE starter et fritt skall
winpeshl.ini i WinRE brukes for å begrense recovery skallet til den vanlige recovery menyen. Når den slettes — og det er nettopp dette de preparerte FsTx loggene gjør, faller WinRE tilbake til en standard cmd.exe.
Trinn 4: BitLocker er allerede låst opp
Ved å holde Ctrl under recovery oppstart havner systemet direkte i kommandolinjen. BitLocker volumet er allerede montert og lesbart, fordi TPM-en frigav nøkkelen i trinn 1.
Windows 10 ser ikke ut til å være rammet. Den samme fstx.dll komponenten finnes i Windows 10 WinRE imaget, men uten den utløsende funksjonaliteten. Forskeren tolker dette som at problemet ble introdusert senere. Det er en sterk konklusjon. Men observasjonen er interessant, og stemmer foreløpig med de tekniske funnene som er publisert.
Hvorfor TPM+PIN stopper den publiserte PoC-en
TPM+PIN krever at brukeren oppgir et pre boot passord før TPM-en frigir VMK-en. Siden YellowKey er avhengig av automatisk opplåsing via WinRE, brytes hele kjeden når PIN blir påkrevd, både teknisk og operasjonelt.
Hva du bør gjøre denne uken
Disse anbefalingene gjelder organisasjoner med Windows 11 klienter, Windows Server 2022 eller Windows Server 2025:
1. Kartlegg konfigurasjonen
Bruk Intune Endpoint Security rapporter eller PowerShell:
Get BitLockerVolume | manage bde -protectors -get C:for å identifisere hvilke enheter som kjører TPM only. Prioriter bærbare PC-er som forlater lokalene og enheter brukt av privilegerte brukere.
2. Slå på TPM+PIN på prioriterte enheter
Dette stopper den publiserte PoC-en pålitelig. Bruk Intune Settings Catalog under kategorien BitLocker og policyen:
Computer Configuration > Administrative Templates > Windows Components >
BitLocker Drive Encryption >
Operating System Drives > Require additional authentication at startupMinimum PIN lengde bør være 8 alfanumeriske tegn. Husk å etablere helpdesk rutiner før bred utrulling.
3. Aktiver UEFI administratorpassord og deaktiver USB boot
Dette blokkerer den enkleste leveringsvektoren for exploitet. Hvis angriperen ikke kan starte fra USB uten å oppgi UEFI passord, faller den publiserte PoC-en bort.
4. Vurder å deaktivere WinRE på særlig utsatte systemer
Kommandoen:
reagentc /disablefjerner angrepsvektoren midlertidig. Tradeoffen kan være betydelig, siden enkelte gjenopprettingsfunksjoner blir utilgjengelige. Dette er operasjonelt besværlig, men kan være et aktuelt tiltak for systemer med høyt beskyttelsesbehov.
5. Implementer deteksjon
Microsoft Defender XDR Advanced Hunting, Palo Alto Networks Cortex XDR Pro eller tilsvarende løsninger, kan finne spor etter exploit kjeder knyttet til USB boot, mistenkelige endringer i FsTx strukturer på flyttbare medier, modifikasjon av winpeshl.ini og unormalt bruk av reagentc.exe. Tilsvarende varslinger kan rulles ut via Intune Proactive Remediations.
6. Aksepter at endpoint EDR og AV ikke vil se alt
Microsoft Defender,Palo Alto Networks Cortex XDR, CrowdStrike, ingen av disse kjører i WinRE. Selve angrepet skjer i et vindu der EDR-en din er blind. Deteksjon må derfor skje to andre steder: i forkant (UEFI-logger, fysisk sikring, USB-policy som hindrer at angrepet i det hele tatt får starte), og i etterkant (etterforskning på OS-nivå, søk etter slettet winpeshl.ini, FsTx-rester, modifiserte filer på BitLocker-volumet, uventet reagentc.exe-bruk i hendelseslogger).
Det YellowKey faktisk utfordrer
Det mest interessante med YellowKey er kanskje ikke selve angrepet, men antakelsene rundt det.
Mange organisasjoner har de siste ti årene behandlet BitLocker som en avkrysningsboks i compliance-rammeverket. Det er forståelig. CIS Controls, NIST CSF, PCI DSS og CIS Benchmarks har alle sammen lenge anbefalt full diskkryptering på endepunkter. Microsoft har levert BitLocker som standard, og standardkonfigurasjonen har i praksis blitt behandlet som «god nok» for produksjon, med et nivå av sikkerhet som implisitt er inkludert.
Men en sikkerhetsstrategi må alltid starte med spørsmålene standardkonfigurasjonen aldri har stilt:
- Hvilken trusselmodell beskytter denne kontrollen mot?
- Hvilke svakheter bygger kontrollen på, og hva skjer hvis de antakelsene endrer seg?
- Hvor mye legger vi til grunn for at kontrollen faktisk leverer det den lover?
For BitLocker i TPM only modus har svarene lenge vært:
- Trusselmodell: stjålne bærbare PC-er der angriperen ikke har domenetilgang eller spesialverktøy
- Antakelser: boot kjeden er trygg, WinRE oppfører seg som forventet, og angriperen kan ikke endre UEFI innstillinger
- Tilleggskontroller: UEFI passord, deaktivert USB boot og pre boot autentisering for høyrisikobrukere
Disse truslene var aldri svake. Microsoft har i mange år anbefalt pre boot autentisering i sin egen BitLocker dokumentasjon. Men sikkerhetscompliance har ofte gjort det mulig å stoppe ved «BitLocker enabled», og dermed bevege seg bort fra anbefalingene som faktisk reduserte risikoen.
YellowKey er en påminnelse om at default aldri har vært synonymt med sikkert. Default er en optimalisering for utrulling, drift og brukervennlighet. Ikke nødvendigvis for motstandsdyktighet mot fysisk tilgang, recovery miljøer eller avanserte trusselmodeller.
Dette argumentet er heller ikke nytt. Det ligger blant annet bak CIS Control 4 («Secure Configuration of Enterprise Assets and Software») og NSMs grunnprinsipp 2.1.3 («Etabler en sikker IKT arkitektur»). YellowKey er ikke starten på den diskusjonen, bare den siste påminnelsen om hvorfor den fortsatt er relevant.
Den egentlige lærdommen
Microsoft vil etter all sannsynlighet patche YellowKey i en kommende Patch Tuesday syklus. CVE vil bli tildelt. Påvirkningen vil bli klassifisert som «fysisk tilgang kreves», og den klassifiseringen vil sannsynligvis redusere prioriteten hos mange.
Men «fysisk tilgang kreves» er en svak trøst når en bærbar PC blir glemt på et hotellrom, beslaglagt i en grensekontroll eller midlertidig ute av syne på en reise. Trusselmodellen for moderne virksomheter har lenge inkludert slike scenarioer, også før YellowKey.
Det som gjør dette interessant, er derfor ikke bare selve angrepet, men hva det sier om hvordan vi vurderer sikkerhetskontroller. En kontroll er ikke nødvendigvis sterk fordi den er standardisert, enkel å rulle ut eller enkel å rapportere på. Den er sterk hvis den fortsatt holder når forutsetningene endrer seg.
YellowKey er først og fremst en påminnelse om det.
nLogic Security
nLogic er en pålitelig nordisk partner for nettverks- og sikkerhetsløsninger med høy ytelse, og hjelper virksomheter med å bygge sikkerhet som et system. Denne artikkelen om YellowKey er utarbeidet av nLogic Security, sikkerhetsteamet i nLogic.
Teamet arbeider med sikkerhetsarkitektur, endpoint sikkerhet, identitetskontroller, deteksjon og operasjonell sikkerhet i komplekse virksomhetsmiljøer.
Arbeidet handler ikke bare om teknologi, men om å forstå hvordan sikkerhetskontroller faktisk oppfører seg når de møter reelle trusler, nye angrepsmetoder og operative kompromisser.
Disse artiklene er en del av nLogics arbeid med kunnskapsdeling, analyse og praktisk risikoreduksjon i moderne virksomhetsmiljøer — med fokus på hvordan sikkerhetskontroller faktisk fungerer når de møter reelle trusler, operative kompromisser og nye angrepsmetoder.
Powered by Knowledge. Security at the Core.
Ta kontakt for mer informasjon
