WK 2026: Scoor de beste deals! Stel jouw winnende opstelling samen met behulp van ons advies.

Simpele hacktool op USB-stick kraakt BitLocker-encryptie op Windows-pc's

Een vrijgegeven hacktool maakt het mogelijk om de BitLocker-versleuteling van Windows te omzeilen en toegang tot opgeslagen gegevens te krijgen. Windows-pc's en -servers zijn kwetsbaar. Voor misbruik van het YellowKey-gat is wel fysieke toegang tot een computer nodig.

De proof-of-conceptcode voor YellowKey is publiek vrijgegeven op Microsofts ontwikkelplatform GitHub. De anonieme securityonderzoeker, Nightmare-Eclipse, die de zerodaykwetsbaarheid vond, biedt ook gedetailleerde technische informatie om misbruik te maken van dit beveiligingsgat in de schijfencryptie van Windows. Daarbij stelt deze hacker dat het een bewuste backdoor in Windows lijkt te zijn.

Deze speculatie berust op het feit dat de misbruikte kwetsbaarheid alleen zit in een Windows-component die aanwezig is in het image van de Windows Recovery Environment. De component bevindt zich ook in een reguliere Windows-installatie, maar heeft dan niet de functionaliteit waarin de bug zit die het omzeilen van BitLocker mogelijk maakt, legt de hacker uit in de documentatie bij YellowKey.

Gevaar voor gestolen computers

De ontdekte kwetsbaarheid, die nu net na Microsofts maandelijkse patchronde is geopenbaard, is niet van toepassing op Windows 10. Alleen Windows 11, Windows Server 2022 en Windows Server 2025 zijn geraakt. Voor misbruik is wel fysieke toegang tot een computer nodig. De hacktool moet immers vanaf een USB-stick draaien. Hij vormt wel een bedreiging voor gestolen computers, waarbij BitLocker nu geen databescherming meer biedt, merkt Bleeping Computer op.

Naast YellowKey geeft Nightmare-Eclipse nog een zerodaykwetsbaarheid in Windows vrij. Deze heet GreenPlasma en hiervoor is geen exploitcode om er misbruik van te maken. Het gaat om een manier om vanuit het account van een gewone gebruiker op Windows de verregaande systeemrechten te verkrijgen. Deze verhoging van privileges kan meer macht opleveren dan een beheerdersaccount heeft.

BitLocker wachtwoord. Bron: Microsoft

Door Jasper Bakker

Nieuwsredacteur

14-05-2026 • 10:33

240

Submitter: g4wx3

Reacties (240)

240
232
129
7
0
81

Sorteer op:

Weergave:

Jammer dat het artikel het niet benoemd maar de volgende mitigations zijn een optie, waarbij KB5025885 de meest makkelijke optie is.

Security teams should take the following actions immediately:
  • Enable TPM + PIN pre-boot authentication— the single most effective control, preventing TPM from releasing the VMK during any manipulated boot sequence.
  • Deploy KB5025885 — this Microsoft update migrates boot manager signing to CA 2023 and introduces revocation controls that eliminate the downgrade path. “Systems that have completed the KB5025885 migration, moving the boot manager signature to the newer Windows UEFI CA 2023 certificate, are also protected against this downgrade path.”
  • Verify boot manager certificate — mount the EFI partition and use sigcheck to confirm the active bootmgfw.efi is signed under CA 2023, not the legacy PCA 2011.
  • Remove the WinRE recovery partition on high-security workloads where pre-boot authentication cannot be enforced, minimizing the attack surface exposed to this class of exploit.
  • Enable TPM + PIN pre-boot authentication— the single most effective control, preventing TPM from releasing the VMK during any manipulated boot sequence.
Dit helpt niet, volgens de auteur v/d exploit.
No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
Ik ben er (denk ik!) achter WAAROM dit zo is. Sterker nog, Microsoft heeft er zelf een blog aan gewijd.
WinRE Design Changes Summary

To summarize the impact of the design changes, as long as WinRE.wim is trusted, and no risky recovery tools are triggered, the OS volume is auto-unlocked allowing WinRE to recover it without requiring any user intervention. In contrast, If WinRE.wim is modified without authorization or a risky recovery tool is triggered, the OS volume is re-locked, preventing WinRE from accessing it.
Wat hier staat is dat WinRE het OS volume automatisch kan unlocken (!!) en alleen re-locked in bepaalde condities (risky tools). Dit houd in dat de Volume Master Key (VKM) automatisch ontsleuteld in het geheugen komt.

En ik verwacht dat dit hetgeen is, wat YellowKey uit WinRE misbruikt. Ze hebben dus die unlock functie nodig én de trusted WinRE.wim. En gezien het een niet-versleutelde partitie is... Et voilá.

Zeer interessante must-read: https://techcommunity.microsoft.com/blog/microsoft-security-blog/bitunlocker-leveraging-windows-recovery-to-extract-bitlocker-secrets/4442806
Het lijkt er niet op dat je WinRE automatisch binnen komt zonder PIN, als de 'Tpm And Pin' Key Protector is ingeschakeld (en de 'Tpm' Key Protector uitgeschakeld).

Dus die passage is dan niet relevant. Staat ook onder aan de blog: "To further enhance the security of BitLocker, we recommend enabling TPM+PIN for pre-boot authentication. This significantly reduces the BitLocker attack surfaces by limiting exposure to only the TPM."
Als ik het zo lees is de aanwezigheid van de usb key (met specifieke inhoud/format!) voldoende om in WinRE Bitlocker te laten unlocken. Ik blijf denken dat er toch een unlock plaatsvindt en dan wellicht een directe unlock.


(bron Arstechnica artikel hierover van 14 mei. Erg interessant over transactional ntfs bits die dit kunnen 'verklaren'. Ik heb de link helaas niet zo snel.)
Als je alleen de 'TPM' Key Protector gebruikt, zoals het standaard geleverd wordt dus, dan is WinRE opstarten voldoende om in WinRE BitLocker te ontsluiten. Dat is zodat voor consumenten de recovery omgeving gewoon meteen werkt.

De bestanden op de USB opslag zorgen er voor dat er een commando prompt gestart wordt, zonder dat je je gebruikersnaam en wachtwoord hoeft in te geven.

FsTx wat door YellowKey misbruikt wordt, is iets anders dan het Transactional NTFS (TxF) van Windows Vista. Zit ook echt gewoon in andere .DLLs, en .SYS driver bestanden.

[Reactie gewijzigd door Henk Poley op 18 mei 2026 16:03]

Dat is wel bizar! Ik beschouw encryptie zonder sleutel die de gebruiker weet eigenlijk altijd als géén encryptie. Maar ik ging er daarom ook vanuit dat mijn eigen BitLocker, waarbij ik een lang en complex pre-boot wachtwoord heb, nooit te kraken is zonder die invoer te weten... Ben heel benieuwd naar de implementatie van BitLocker in dit geval! (En blij dat ik Windows alleen voor sommige games gebruik, en Linux met LUKS voor al het andere)
De talk 'BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets' tijdens 39C3 (CCC conferentie, 39e editie) gaat er verder op in wat de internals zijn en hoe dit soort aanvallen werken.

Maar nee, je zit niet verkeerd, propere implementatie van encryptie zou nooit bypassbaar mogen zijn, behalve met een $5 wrench. Als je Windows 'moet' gebruiken: Veracrypt.
Dit was ook mijn eerste gedachte, toen ik nog windows draaide gebruikte ik gewoon een WW voor unlocken (het opslaan van een secret buiten mijn hoofd vond ik niet echt geschikt)

ben ook wel benieuwd of het in dat geval ook werkt, en hoe, was het wachtwoord dan alleen om de encryptkey te unlocken ofzo? waardoor de key ook via andere methoden te krijgen was


en dan lees het in het artikel ook nog dat het mogelijk een bewuste backdoor is. lekker veilig en betrouwbaar
blij dat ik Windows alleen voor sommige games gebruik, en Linux met LUKS voor al het andere
Ik heb toevallig vorige week mijn vriendin overgehaald om te kiezen tussen Windows 11 Pro kopen (voor bitlocker) of Linux installeren om haar data te versleutelen. Uiteindelijk hebben we gekozen voor Zorin OS en LUKS versleuteling. Een behoorlijke stap voor een Windows-gebruiker.

Nu heb ik een mooi nieuwsartikel om te laten zien dat het een goede keus was!
offtopic:
Ik had Zorin OS nog nooit geprobeerd, maar ze wilde iets dat makkelijk was voor Windowsgebruikers. Ziet er erg mooi uit!

[Reactie gewijzigd door Sando op 15 mei 2026 10:33]

Je weet de bitlocker key toch? Je kan hem zonder problemen afdrukken voor recovery.
Dat is wellicht bij Winfows Pro. Bij windows home wordt gebruik gemaakt van drive encryptie en die sleutel staat alleen in de onedrive. Ik kan me op home niet herinneren dat ik een optie kreeg (automstisch bij opstarten) om de key op te slaan.
De sleutel staat op de MS website, dus inloggen op uw MS account via bvb een Gsm en daar de sleutel cijfers bekijken en invullen op pc.
Waarom zou je die automatisch bij opstarten die vraag moeten krijgen. Hij staat online in je account. Je kan hem opzoeken bij de BitLocker config. Hij is makkelijk zat op papier te krijgen. Hij is zeker niet verborgen of niet te verkrijgen zoals werd beweerd
Je moet volgens mij wel alles doen
Ik ben zeer benieuwd hoe dat zou moeten werken.

De enige manier om TPM+PIN te omzeilen is als Microsoft automatisch de backup key van Microsoft's servers haalt (in dat geval kun je het probleem voorkomen door je sleutel niet bij MS te leggen).
Er staat dus een niet werkende workaround bovenaan in de reacties, maar eigenlijk is het grote nieuws dat dit een doelbewuste backdoor lijkt te zijn. Dat is toch precies de meest kwaadaardige verwachting waarvan iedereen steeds denkt: Zou het zo zijn? Nee toch, dat zou wel erg brutaal zijn.
TPM + PIN en TPM + PIN pre-boot authentication (wat niet benoemd wordt door de auteur) zijn wel twee hele verschillende dingen.
Ik heb code en de werking van de TPM inmiddels iets beter bestudeerd, en ik denk dat de ‘TPM and PIN’ Key Protector bypass bluf, dan wel onbegrip van het systeem is.

Het Dictionary Attack (DA) beleid zit in de TPM chip zelf. Om die te wijzigen heb je autorisatie binnen de TPM lockout hierarchy nodig. Oftewel, je moet de TPM eerst ontsluiten, en daar heb je in ieder geval die PIN voor nodig. Standaard mag je 32 (31?) pogingen doen in de 2 uur. Dus 384 pogingen per dag. 7 jaar voor alle PIN.

Maar.. ik laat me (niet) graag verrassen.

Misschien gaat het nog om een soort nep BitLocker prompt, dat de PIN dan ergens opslaat. Dus dat de aanvaller nog eens langs moet komen om dan de echte aanval te doen.

[Reactie gewijzigd door Henk Poley op 16 mei 2026 10:41]

De eerste (Enable TPM + PIN pre-boot authentication), is trouwens al reeds aangeraden door het Microsoft defender team.
Dat krijg je wel nooit verkocht in een bedrijfsomgeving...
N=1,maar ik heb een startup pin wel al tegengekomen bij een multinational. Nu was dit wel niet van de bitlocker, maar van de bios (is ook al 7 jaar geleden ofzo), maar ga er niet te snel vanuit dat je dit niet verkocht krijgt bij bedrijven

Nu goed, alles hangt af van het risico en veel security was afkomstig van de groep waar HQ in Mexico lag, waar kartels wel eens durvden te blackmailen en personeel te ontvoeren.
Ik bedoel dan eerder bedrijven waar de PC niet primair is. In een ziekenhuis krijg je de vakbond op uw dak als verpleegkundigen nog eens een extra code moeten ingeven voor ze kunnen beginnen werken :-)
Je zou er moeten van uit gaan dat bitlocker gewoon veilig is, ook zonder pincode.
Helemaal mee eens dat in een scenario van een gedeeld apparaat het toevoegen van een pre-boot PIN frustreert en het doel voorbij schiet. Een thin client of een PC die automatisch de gebruikersprofielen verwijdert na uitloggen is een mooi technisch alternatief. Maar daar hoef je niet te stoppen, een goede security officer kijkt verder dan software maatregelen.

Stel het is een PC die gekoppeld is aan apparaat die om latency redenen bestanden lokaal moet opslaan. Dan kan een elektronisch slot op de deur de rol van een pre-boot PIN overnemen. Goed, dan ben je nog steeds kwetsbaar voor iemand die een pasje van een medewerker ontvreemd. Dan maak je de afweging of de gegevens op de PCs in kwestie gevoelig genoeg zijn dat het investeren in een biometrisch systeem voor toegang tot de ruimte de moeite waard is. Misschien is het genoeg om toegang tot het pand of de afdeling te beveiligen met biometrisch toegangscontrole.
Dat zou nog wel lukken als het alleen een PIN zou zijn.

Maar het vervelende is, is dat je Windows update systeem niet meer 'smooth' loopt. Je zal per update die een reboot vergt, meermaals je laptop moeten starten en je PIN moeten opgeven. Dát is wat gebruikers naar gaan vinden.

Ikzelf ondervindt dit ook omdat ik het alleen bij mijzelf heb aangezet. Met updates zet ik mn laptop uit. De volgende dag gaat het aan, vraagt een PIN en gaat weer uit. En ik maar wachten tot ie opstart, blijkt ie uit te staan... En soms is dit meerdere keren achter elkaar. Nóg vervelender zou dit zijn voor mensen met externe schermen die hun laptop dichtklappen na het aanzetten, dan moet ie weer open.

Niet onoverkomelijk, maar gewoon irritant voor velen. Zeker nadat Microsoft juist de updates zoveel makkelijker heeft gemaakt met de update & shutdown optie.
En mensen die hun pc van thuis uit overnemen dan... lukt ook plots niet meer.
Die mensen zijn sowieso al af. Zorg voor een deftige thuiswerk optie die niet afhankelijk is van de lokale poetsvrouw om beschikbaar te zijn.
Een Pin is nog altijd schijnveiligheid, je eigen medewerkers/collega’s kunnen nog steeds misbruik hier van maken. Ook is het zo dat een Pin vaak snel uitlekt uit gemak, net als bijv een gasten wifi wachtwoord, binnen no time de hele wereld over (bij wijze van)
Zeker als de BitLocker pin op een plak notitie aan het scherm hangt of 123456 is.
Bor Coördinator Frontpage Admins / FP Powermod @Accretion14 mei 2026 13:02
Wanneer je moedwillig authenticatiegegevens gaat delen faalt vrijwel elk systeem (behalve misschien biometrie). Dat is gewoon user error.

Zelfs in jouw voorbeeld heb je wel het device en de pin nodig. Die pincode werkt alleen op het betreffende device (tenzij je dezelfde PIN overal instelt en dat zou dom zijn). Je kan een PIN complexiteitseisen meegeven waarmee je het wat betreft regels soortgelijk kan maken aan een wachtwoord.

[Reactie gewijzigd door Bor op 14 mei 2026 13:04]

Doet me denken aan mijn tijd op de Helpdesk.

Ja tuurlijk kan ik uw wachtwoord resetten, het is nu twaalf vierendertig zesenvijftig achtenzeventig

.....Owh wacht ik pak even een papiertje dan kan ik het opschrijven, kan je het nog eens herhalen?
Een PIN is geen schijnveiligheid, het is alleen zwakker dan een (deftig) wachtwoord.

Het voordeel van een PIN is is dat deze apparaatgebonden is, in plaats van accountgebonden. Het lekken van een PIN is daarom minder impactful, helemaal bij een goede inrichting. En mag daarom wel wat zwakker zijn dan een wachtwoord in ruil voor het gemak. Je kan die zwakte bijvoorbeeld weer afvangen met periodiek MFA eisen.

Zo'n combinatie houd het laagdrempelig en de combinatie is veiliger dan alleen een wachtwoord wat nog altijd heel gebruikelijk is. Security is altijd een afweging tussen absolute veiligheid en gemak. Maak het te lastig en mensen gaan er omheen werken.

Het zou ook niet moeten uitmaken of je gasten wifi wereldwijd bekend is. De meeste toko's hebben dit op papier of bordjes staan.
Aanvulling. De opstart PIN werkt in het geval van Microsoft als een rate limiter. Je moet die PIN op het betreffende systeem invoeren. Na een aantal mislukte pogingen mag je a) wachten en b) de bitlocker key in zijn geheel invullen Rebooten kan ook, maar kost ook weer tijd. Gaat op die manier even duren voor je een PIN van 6 cijfers hebt gebruteforced.

Zonder PIN start Windows op en kun je via een lokaal netwerk, USB schijf of wat dan ook,alle mogelijke exploits en brute force attacks (zonder rate limits) loslaten op een systeem. Zolang je toegang hebt tot de fysieke machine is het dan "relatief" gemakkelijk om in breken.
En vergeet niet dat gemak ook juist kan bijdragen aan het verlagen van de kans dat een risico impact heeft. Dat is de reden dat Single-Sign-On juist ook een risico mitigerende maatregel is.
Bor Coördinator Frontpage Admins / FP Powermod @Technoid14 mei 2026 13:02
Een PIN is geen schijn veiligheid en in dit geval device gebonden; het werkt alleen op het device waar het is ingesteld.
Als je eigen collega niet kan vertrouwen heb je andere zorgen aan je hoofd. Maar het is waar, een pin is gevoelig voor scholder surfing en mensen hebben de neiging om dezelfde pin voor alles te kiezen (bankkaart, smartphone, hello for business) gelukkig heb je bij zowel bitlocker als bij hello for business de optie om complexe wachtwoord af te dwingen en ben je niet beperkt tot decimale getallen. Maar dan heb je weer het probleem dat mensen een complex wachtwoord moeten onthouden. Nu goed je moet het risico zelf inschatten. Voor mij persoonlijk, is encryptie nog steeds een tool om te belemmeren dat mensen zomaar toegang hebben tot data bij een opportuniteitsdiefstal of verlies van een laptop, want als je echt toegang willen tot je data... Well, there's an xkcd for that https://xkcd.com/538/
En dan ben je weer niet meer met een PIN bezig maar met een wachtwoord. Gewoon leren van een combinatie van PIN en biometrics te gebruiken. De PIN op BitLocker en Windows Hello voor het aanmelden in Windows.

En dan mensen aanmoedigen om de verplichte PIN op Windows Hello niet hetzelfde te zetten als de BitLocker PIN, al merk je dan weer dat mensen hun PIN gaan vergeten voor Windows Hello wanneer ze die toch eens nodig hebben.
Een PIN is zo veilig als je hem zelf maakt. Als je collega's je wachtwoord/PIN weten, is er iets misgegaan binnen je bedrijf. Daar kan geen PIN tegenop.
Dit omdat je hiermee andere aanvallen ook tegen gaat. Tot op heden was het zo dat je in principe de sleutel kunt afluisteren op de communicatiebus tussen de TPM chip en de CPU. Dat voorkom je met de PIN code omdat bij het gebruik van een PIN code de TPM enkel de sleutel zal vrijgeven als je de juiste PIN code aanbiedt. Dit in tegenstelling tot standaard BitLocker waarbij de key gewoon door het OS kan opgevraagd worden.

Deze nieuwe aanval lijkt het dan weer mogelijk te maken om vanuit de WinRE omgeving ook de sleutel te kunnen opvragen, mogelijk iets dat men ooit heeft ingebouwd om recovery eenvoudiger te willen maken als het misloopt, maar wat achteraf dus een beveiliginsprobleem lijkt te zijn.
Het lijkt bij design te zijn. Je kunt nu vanuit Windows booten naar de recovery omgeving zonder invoer van de PIN. Dat maakt recovery op afstand mogelijk. PIN vereist dat je fysiek toegang hebt tot de machine.

Overigens kun je middels een registry key die PIN tijdelijk uitschakelen, zodat je een systeem op afstand kunt beheren en zelfs rebooten zonder op locatie te moeten zijn.
mogelijk iets dat men ooit heeft ingebouwd om recovery eenvoudiger te willen maken als het misloopt
Of mogelijk een backdoor :)
Waar komt deze tekst vandaan? Wat heeft KB5025885 precies met deze exploit te maken?

#edit
Inmiddels hierboven beantwoord, thanks!

[Reactie gewijzigd door meowmofo op 14 mei 2026 11:08]

KB5025885, het wisselen van bootloader certificaten, heeft hier niets mee te maken.

[Reactie gewijzigd door Henk Poley op 15 mei 2026 16:36]

Security teams should take the following actions immediately:
  • Enable TPM + PIN pre-boot authentication— the single most effective control, preventing TPM from releasing the VMK during any manipulated boot sequence.
TPM + PIN lijkt op dit moment slechts een tijdelijke oplossing te zijn. Volgens de onderzoeker die de exploit heeft ontdekt, is deze combinatie niet voldoende voor volledige bescherming, aangezien hij ook de combinatie TPM + PIN ook kan omzeilen. Zijn proof‑of‑concept (POC) heeft hij echter nog niet vrijgegeven zie zijn blogpost:

"Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough." https://deadeclipse666.blogspot.com/2026/05/were-doing-silent-patches-now-huh-also.html
Geen van die dingen zijn echte patches als je weet hoe BitLocker werkt. Het enige dat het bovenstaande doet is zorgen dat die specifieke tool niet langer ondertekend is, waardoor de TPM het weigert te booten maar het gat zit er nog steeds moest de bootloader en tool door Microsoft ondertekend worden… dus het antwoord gooit hout op het vuur dat dit een gat is die ingebouwd is. Om het op te lossen zou de hele encryptie op de schop moeten en moet elke byte herschreven worden.
WinRE verwijderen zorgt er volgens mij voor dat remote wipen via Intune niet meer werkt. Niet erg handig dus.
Bor Coördinator Frontpage Admins / FP Powermod @HKLM_14 mei 2026 10:56
Heb je een bron voor deze informatie? Bij Microsoft zelf kan ik nog maar weinig vinden helaas.

Hier zou MS bovenop moeten zitten!

Update: deze info is o.a. hier te vinden: https://www.cryptika.com/...ypted-disks-in-5-minutes/

[Reactie gewijzigd door Bor op 14 mei 2026 11:00]

Microsoft is inderdaad wat stil, ik zag hem ook nog niet in de defender portal bij de adviezen.

Mijn lijstje is gebaseerd op het lijstje van de security onderzoekers van intrinsec.

https://www.intrinsec.com/en/contournement-bitlocker-la-realite-des-downgrade-attacks/
ze silent-patchen zijn exploits zonder er ruchtbaarheid aan te willen geven:
I just noticed that Microsoft silently patched the RedSun vulnerability, no CVE, no nothing, just a silent patch.
Nightmare-Eclipse/RedSun: The Red Sun vulnerability repository

geeft direct SYSTEM rechten
Specifiek TPM met PIN staat in het gelinkte artikel van bleepingcomputer en wordt ook onafhankelijk gemeld door Kevin Beaumont die ook in dat artikel genoemd wordt, de andere punten haal ik niet uit de zo snel beschikbare info.
Dus alles met het 2023 cert is veilig? In de meeste fleets is men daar al druk mee bezig lijkt me? Dus op enterprise gebied niet echt een grote impact?
Nee, de tool die achterdeurtoegang heeft is ondertekend met de oudere certificaten, het enige dat gebeurt met nieuwe certificaten is dat de achterdeur niet meer ondertekend is, en dus niet meer draait. Maar als je je eigen TPM ondertekent, en de tool ondertekent (of Microsoft ondertekent de tool met hun 2023 certificaat) werkt het gewoon.

Zo ook verwijderen van de tool of de partitie, je kunt het altijd terugzetten of van een trusted boot disk gebruiken.
Als dat zo zou zijn was deze exploit niet zo erg. Ik ben er (nog) niet ingedoken maar het lijkt me sterk.
Volgens mij, en Pangram, is die tekst door een of andere chatbot uit de duim gezogen.

KB5025885 veranderd alleen een bootloader certificaat, en heeft niets met het starten van autofstx.exe, of het FsTx proces binnen de Windows Recovery Environment te maken.
Jammer dat het artikel het niet benoemd maar de volgende mitigations zijn een optie, waarbij KB5025885 de meest makkelijke optie is.

Security teams should take the following actions immediately:
  • Enable TPM + PIN pre-boot authentication— the single most effective control, preventing TPM from releasing the VMK during any manipulated boot sequence.
  • Deploy KB5025885 — this Microsoft update migrates boot manager signing to CA 2023 and introduces revocation controls that eliminate the downgrade path. “Systems that have completed the KB5025885 migration, moving the boot manager signature to the newer Windows UEFI CA 2023 certificate, are also protected against this downgrade path.”
  • Verify boot manager certificate — mount the EFI partition and use sigcheck to confirm the active bootmgfw.efi is signed under CA 2023, not the legacy PCA 2011.
  • Remove the WinRE recovery partition on high-security workloads where pre-boot authentication cannot be enforced, minimizing the attack surface exposed to this class of exploit.
Jij bent geen security specialist of hacker verwacht ik? Ook niet erg natuurlijk wat je hier aangeeft klopt van geen kanten. KB5025885 is gereleased op 9 mei 2023 dus deze oplossing raad jij aan om dit te voorkomen? Dit werkt niet.... Dit betreft een ZERODAY.

WINRE disablen is de enige optie momenteel, naast het instellen van BIOS startup pin/password. (Als je deze weet kun je dit als nog uitvoeren.)

Vandaag uitvoerig onderzoek gedaan enkel het disablen van WINRE is dus de enige mitigatie die werkt voor dit probleem. De gast die deze exploit gemaakt heeft deze PIN bypass (nog) niet gereleased want deze is al erg zat...

De andere Bitlocker bypass BitUnlocker van eergisteren daarbij klopt je verhaal wel.
Nightmare-Eclipse /Chaotic Eclipse is dezelfde persoon/groep die RedSun, BlueHammer en nu dus Greenplasma en YellowKey heeft gedropt. Vorige keer is er geen artikel over verschenen, maar het is wel duidelijk dat hij vroeger met MSRC heeft samengewerkt tot ze hem tekort gedaan hebben
First post : I never wanted to do this...

I never wanted to reopen a blog and a new github account to drop code...

But someone violated our agreement and left me homeless with nothing. They knew this will happen and they still stabbed me in the back anyways, this is their decision not mine.
dan
Public disclosure

I was not bluffing Microsoft and I'm doing it again.

https://github.com/Nightmare-Eclipse/BlueHammer

Unlike previous times, I'm not explaining how this works, yall geniuses can figure it out.

Also, huge thanks to MSRC leadership for making this possible !!! And a special thanks to Tom Gallagher !
Ik heb zo het gevoel dat hij nog wel meer dingen gaat uitbrengen die héél veel mensen serieus wat kopzorgen gaat geven tot ze met hem een overeenkomst bereiken.

zijn laatste blogpost van gisteren:
Chaotic Eclipse: May 2026

I just noticed that Microsoft silently patched the RedSun vulnerability, no CVE, no nothing, just a silent patch. Not surprised they never admit their mistakes but considering it was under active exploitation, having zero advisory is insane.

Now regarding YellowKey, lots of you are wondering how does one even find such backdoor ?

I'll tell you how, it took me more time trying to get it to work than the amount of sleep I had in two years combined. No AI involved, no help in any shape or form. I could have made some insane cash selling this but no amount of money will stand between me and my determination against Microsoft.

Funny thing is, no one and I say again NO ONE has managed to figure out how YellowKey works, the real root cause is still not unknown by the general public. I think it will take a while even for MSRC to find the real root cause of the issue. I just never managed to understand why this vulnerability is sooo well hidden.

Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.

I can't wait when I will be allowed to disclose the full story, I think people will find my crashout very reasonable and it definitely won't be a good look for Microsoft.

[Reactie gewijzigd door dasiro op 14 mei 2026 12:46]

Hoewel het aankaarten van security problemen goed werk is komt het zo in het open imho zo wel een beetje sneu over als je die commentaren leeft. Ik ben niet zo'n van dit soort op het oog acties van rancune en persoonlijke vendetta's spelend met de veiligheid van andermans data. Heeft weinig weg van responsible disclosure so en dat is jammer.

Of ze hem tekort gedaan hebben vind ik dan echt weer niet te concluderen uit deze posts. Enkel dat deze persoon die mening is toegedaan. Echter hoeft zijn mening natuurlijk geen (absolute) waarheid te zijn. Er zijn ook genoeg mensen die vinden dat ze te kort gedaan zijn door bedrijven of bijvoorbeeld de overheid, maar waar dit feitelijk niet zo is en dat enkel in hun beleving speelt bijvoorbeeld. En die halen dan dus ook vaak keer op keer bakzeil in procedures, terwijl ze wel kwaad blijven, want hoe vaak ze ook horen dat het niet zo is, ze blijven overtuigd en zitten dan ook vaak vol rancune.

[Reactie gewijzigd door Dennism op 14 mei 2026 12:56]

Als ik het zo lees, is het gewoon een klokkenluider die ZEER belangrijk en goed werk levert in de wereldwijde beveiliging van Windows gebruikers.

Het heeft juist veel weg van responsible disclosure, maar als je door zo'n bedrijf zo weggezet / kapotgemaakt wordt, dan zou ik de PoC ook op GitHub zetten. Wat er nu gebeurt is wat een klokkenluider doet: naming & shaming.

Stel je eens voor, hypothetisch dus, dat jouw ontdekking eigenlijk een CIA-achterdeur zou zijn, denk je dat jouw melding bij instanties, naast MS, iets zou bewerkstelligen?
Ik ga niet al z'n post quoten, maar volgens hem zou het zover gekomen zijn dat hij zelfs dakloos geworden is. Uiteraard zijn er veel unknowns, maar dat iemand dit soort exploits open en bloot op het internet gooit ipv ze te verkopen geeft toch aan hoe wanhopig hij is en tegelijk ook oprecht een fix te willen zien door te weigeren om ze te verkopen/black-hat te gaan (voor zover we weten uiteraard).
Ouch, pijnlijke exploits! Zeker als je zo op Bitlocker 'moet' vertrouwen.

Ik betwijfel of men kan ooit sluitend kan bewijzen dat het om een backdoor gaat, maar met de CIA/Amerikaanse honger èn bewezen Amerikaanse backdoor in (naar ik dacht) Cisco apparatuur, zou het mij absoluut niks verbazen.

Ik ben benieuwd of er ergens simpel uitgelegd gaat worden waarom het omzeilen van Bitlocker werkt, welk gat het misbruikt.
Deze gebruiker op X legt het wel aardig uit:
Microsoft shipped code that checks for a flag called "FailRelock" in every Windows 11 recovery image. When it's set to 1, after recovery unlocks your BitLocker drive, it never relocks it.

How it works:

1. Recovery tools look for a config file called RecoverySimulation.ini on the OS drive

2. If Active=Yes, it enables "test mode" for the recovery tools

3. Test mode unlocks your BitLocker drive but a flag called FailRelock tells it to skip relocking

4. cmd.exe spawns with full access to your "encrypted" drive
https://x.com/weezerosint/status/2054299771817660433?s=46

[Reactie gewijzigd door HKLM_ op 14 mei 2026 10:58]

Hoe kan recovery het unlocken zonder iets geheims dat alleen de gebruiker weet? Als dat kan, lijkt het me fundamenteel kapot. Ik dacht altijd dat BitLocker:
  • Vrijwel alles op de schijf versleutelt.
  • Die sleutel versleutelt (praktischer) met iets dat de gebruiker weet, en vervolgens ergens op de schijf of in TPM opslaat.
  • Unlocken betekent dat ergens in het geheugen de sleutel staat en alles realtime ontsleuteld kan worden, maar niet ontsleuteld is op de schijf.
Maar misschien wordt de sleutel ook versleuteld met iets van MS. Zodat MS er nog altijd bij kan?
Standaard vereist bitlocker geen pre boot authenticatie en kan de TPM de key dus vrijgeven tijden het opstarten (immers anders kan je niet op het Windows login screen komen).

Dat kan je ook strenger instellen, waarbij de gebruiker een extra wachtwoord / pin of hardware key moet invoeren om de TPM de key te laten vrijgeven.

[Reactie gewijzigd door Dennism op 14 mei 2026 12:38]

Dat is (vind ik) dan een twijfelachtige standaard. En een pin of hardware key is wellicht een drempel voor sommigen. Het zou m.i. opgedeeld kunnen worden in twee delen.
  • Eerste deel dat nodig is om een (Windows) login scherm te tonen, zodat de gebruiker op de gebruikelijke en gebruikersvriendelijke manier zich kan authenticeren. De code/files hiervoor hoeven niet eens versleuteld te worden want die zijn voor iedereen hetzelfde. Enkel ge-signed. Secure boot?
  • Het tweede deel (al het overige) kan versleuteld worden met een sleutel die ontsleuteld wordt met de bovengenoemde authenticatie (waarin een geheim zit) van de gebruiker.
Maar zo werkt het dus niet. Dank voor de toelichting.
TPM/PIN zouden niet helpen
Dat vindt ik interessant, kan je dat uitbreiden?
de maker van de tool schrijft het zelf, maar de PoC daarvoor geeft hij (voorlopig) niet vrij:
Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
Thanks!

Dat... Dat is nog veel pijnlijker, en ik had niet verwacht dat dit nog kon bij dit issue!
De PIN voor een Microsoft implementatie gebeurt met een miniem branded Microsoft drivers/OS. Dus de TPM moet de key overdragen om BitLocker te openen zodat een Microsoft scherm achter de PIN kan vragen en dat is hetzelfde niveau waar de tool draait (pre-boot).

In principe moet heel die zooi naar buiten, net als in Linux, een kleine kernel kan zich in de EFI partitie bevinden die in Linux naar de PIN/key vraagt, maar de EFI partitie is maar 200MB maximum (per deze spec https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf) en op vele systemen kleiner, dus daar kan Microsoft niets mee doen omdat hun basis kernel om iets op het scherm te toveren al meer dan 350MB is.

Daarom maken ze dus naast de EFI partitie gebruik van een tweede (500M-1G) partitie waar de BitLocker zooi zich bevindt die dan de derde partitie waar de rest van het OS zich bevindt opent. Het probleem zit zich in die tweede partitie, eenmaal dit open kan, is de tool beschikbaar, de overgang EFI -> tussenpartitie is niet beveiligd met een PIN en kan niet beveiligd worden met de Microsoft implementatie.

Wat veiliger zou zijn is EFI implementatie die de PIN vraagt voor de bootsector geladen wordt van de schijf, maar dan kun je evengoed een PIN vragen voor elk niveau (1-7) van de TPM, of dynamische controle via het netwerk zoals wordt gedaan met vb. Tang en Keylime in Linux - een gelijkaardige implementatie in Windows bestaat, maar oof, bijna onbruikbaar en ongedocumenteerd buiten Azure.
Je verhaal hebt mij aan het denken gezet en ik ben dingen gaan nazoeken.

Er zijn 3 partities in dit spel.
  1. EFI (200Mb)
  2. Windows (C:)
  3. WinRE (Recoverypartition) (766 MB in mijn geval)
(U)EFI start \EFI\Microsoft\Boot\bootmgfw.efi. Dit is de prompt die de BitLocker PIN vraagt in het pre-boot verhaal. WinRE kan altijd starten, deze partitie is nooit BitLockered.

Ik ben het niet eens met het stukje "Daarom maken ze dus naast de EFI partitie gebruik van een tweede (500M-1G) partitie waar de BitLocker zooi zich bevindt" BitLocker draait 100% zelfstandig vanuit EFI. Er is géén 'tussenpartitie'. Dat het probleem in de WinRE zit, ja, dat klopt zeker.
BitLocker draait 100% zelfstandig vanuit EFI.
Dat klopt niet. UEFI firmware laadt ESP:\EFI\Microsoft\Boot\bootmgfw.efi, die laadt C:\Windows\System32\winload.efi, en die laadt de kernel en de bootdrivers.

Het grootste deel wordt dus geladen van de Windows partitie, en het draait dus zeker niet zelfstandig op de EFI partitie.

[Reactie gewijzigd door Sando op 15 mei 2026 10:52]

Ok, wellicht is mn bewoording niet compleet/correct.

Het punt was, alleen de EFI partitie bevat het BitLocker unlock scherm. Pas bij een succesvolle invoering wordt de key vrijgegeven en pas dáárna kan winload.efi uitgelezen worden voor verdere afhandeling.

Wat ik dus probeerde te zeggen is dat de unlock allen plaatsvind door de software vanuit de EFI partitie, daar is de WinRE partitie niet inherent voor nodig.
Oja de Bitlocker-prebootcode zit wel op de EFI. En ik moet toegeven dat ik niet helemaal snap hoe deze backdoor werkt
In een systeem heb je EFI disk/partitie (waar je certificaten zitten) -> ESP (winloader) -> C: in de ESP kun je in principe met PIN of biometrie of netwerk unlocken. Je kunt dit gemakkelijk in Proxmox zien waar je een extra schijf aanlegt, die EFI partitie kan al dan niet verborgen zijn in de hardware, maar in firmware of sommige oudere systemen (32-bit Intel Mac, ARM) zijn EFI binaries gewoon zichtbaar als een FAT12 partitie. Het is dezelfde plaats waar je je eigen certificaten zet als je de Microsoft signed kernel meuk niet vertrouwt.

Een betere uitleg:

https://neodyme.io/en/blog/bitlocker_screwed_without_a_screwdriver/

Keys worden dus blijkbaar geladen voordat je PIN gevraagd word. Een pre-boot auth kan hierbij helpen maar dat moet dan ingebakken worden voor de overgang naar een Linux of Microsoft kernel.

[Reactie gewijzigd door Guru Evi op 15 mei 2026 13:46]

"Keys worden dus blijkbaar geladen voordat je PIN gevraagd word"
In jouw eigen link schrijft de auteur:

Eerst
Short answer: use a pre-boot PIN, or apply KB5025885.
en daarna
Mitigation
Option 1: pre-boot authentication In my opinion, this is the most secure “easy” solution available.
Dus ik snap je niet wanneer je schrijft dat de keys worden geladen voordat er naar de PIN wordt gevraagd.


Daarnaast wil ik je wijzen op de link na de link van mijn post hier ietjes boven. Het blogartikel van Microsoft (BitUnlocker) is gepost in augustus 2025 terwijl jouw artikel uit januari 2025 komt. Hierin staat oa:
To mitigate BitLocker downgrade attacks, we advise enabling the REVISE mitigation. This mechanism enforces secure versioning across critical boot components, preventing downgrades that could reintroduce known vulnerabilities in BitLocker and Secure Boot.
En dit is wat jouw screwdriver artikel aangeeft: attacking by downgrading.

[Reactie gewijzigd door Triblade_8472 op 15 mei 2026 14:06]

Er zijn 2 soorten PIN: preboot PIN en BitLocker + PIN (Windows Hello). Zover ik zie raadt Microsoft de BitLocker + Windows Hello als mitigatie. Preboot PIN is enorm lastig, want de machine start niet voor updates/remote control en zover ik weet is “Enhanced BitLocker PreBoot PIN” (equivalent met FileVault paswoord op Mac) enkel maar ondersteund in Windows met Intune.

[Reactie gewijzigd door Guru Evi op 15 mei 2026 15:27]

Ik zie eigenlijk heel weinig recommendations omtrend BitLocker, buiten het te gebruiken.
Alleen dit kan ik vinden:
For secure administrative workstations, it's recommended to:
  • use a TPM with PIN protector
  • disable standby power management
  • shut down or hibernate the device before it leaves the control of an authorized user
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures

[Reactie gewijzigd door Triblade_8472 op 15 mei 2026 15:43]

Dit is wel wat duidelijker dan de OP tekst. ;)
Ik weet niet of het een stoer verhaal was, maar tijdens mijn vakantie sprak ik iemand die op een security IT afdeling van de Nederlandse recherche werkt, en volgens hem kunnen computers en smartphones verrassend snel worden gekraakt.
Ook als de schijven beveiligd zijn met BitLocker, True/VeraCrypt en vergelijkbare oplossingen. IOS/OSX apparaten idem dito volgens hem.

Zoals ik het zie, is elk systeem uiteindelijk te kraken. t is niet of het gebeurt, maar wanneer.

Ik heb vooral het idee (aanname) dat crypt tools als schijnveiligheid bedoelt is.
Niets is veilig...
Misschien ben ik naief maar Veracrypt is open source en ik zie dan ook even niet hoe daar ongemerkt een backdoor in zou kunnen zitten. Ik gebruik al tijden geen bitlocker meer vanwege de multiboot die ik heb, die lastig is met secure-boot. Ik doe Windows met VeraCrypt en linux met LUKS.

Totdat echt het tegendeel bewezen is geloof ik in de oprechtheid van deze encryptiemethoden.
Niet voor de overheden, nee. Het was overigens al bekend dat er backdoors waren voor politie e.d.
Is het niet wat optimistisch/naief om te veronderstellen dat alleen de politie/overheid instellingen over dit soort middelen beschikt om backdoors of kwetsbaarheden te gebruiken. In de praktijk is het toch zo dat opsporingsdiensten met relatief beperkte of gereguleerde tools "dienen" werken, terwijl (denk ik) criminelen en andere kwaadwillenden juist de beschikking hebben over de zwaardere, minder gebonden varianten.

Het voelt daardoor soms alsof de overheden met klapperpistooltjes moet werken, terwijl de echte kwaadwillende met het serieuze materieel rondloopt, zonder regeltjes..

[Reactie gewijzigd door Audione0 op 14 mei 2026 13:24]

Ze moeten sowieso toestemming hebben om te mogen hacken.
Ik geloof niet dat er backdoors in veracrypt en truecrypt zitten. Heb je hier enige links/bewijs van, of is het gewoon een 'roddel' ?
Er is een verschil tussen een backdoor en een exploit. De ene is bewust en de andere niet.
Ook daar heb ik nog niets van vernomen/gehoord wbt vera/truecrypt. Dus betrouwbare bronnen graag.
Dit is gewoon waar. Welke encryptie je ook gebruikt, er zal altijd een exploit in zitten. Ik denk ook dat dankzij AI, dit nu een flinke boost gaat krijgen.

Wel denk ik dat opensource hierin meer helpt, dan alles van MS dat gesloten is. Ik zal altijd LUKS gebruiken (of iets dat daar op lijkt). Alles wat in de cloud (niet zelf) kan worden opgeslagen (zoals bitlocker-keys), is in feite al onbetrouwbaar. Daarnaast blijft MS een bedrijf dat backdoors nooit heeft tegengehouden (ja, ik geloof daarin).
Ik vind het lastig te rijmen dat Microsoft encryptie aanbiedt in de vorm van BitLocker, maar anderzijds backdoors toelaat. Erg tegenstrijdig...

#Roomser dan de paus, maar de duivel vind ik ook wel lekker

Encryptie is een grote grap!
Ik installeer altijd Btilocker op de laptops die ik uitgeef op m'n werk. Maar in feite kan ik daar dus net zo goed mee stoppen begrijp ik, want het is een back-door, dwz een feature, en geen bug. Ik neem aan dat ze het dus ook niet gaan fixen?

Ik wordt niet heel veel wijzer van dit artikel moet ik zeggen... Want ik weet nog steeds niet echt waar ik nu aan toe ben. Moet ik stoppen met Bitlocker omdat het geen zin meer heeft in feite, of moet ik gewoon wachten op een fix van Microsoft?
Je moet toegang hebben tot de fysieke laptop of pc, dus het beschermt nog steeds enigzins. Alleen iemand met een usb stick kan het zo omzeilen. Bij de meeste bedrijven zijn usb-sticks inmiddels verboden.

Dit is ook van belang:

"Deze speculatie berust op het feit dat de misbruikte kwetsbaarheid alleen zit in een Windows-component die aanwezig is in het image van de Windows Recovery Environment. Het component bevindt zich ook in een reguliere Windows-installatie, maar heeft dan niet de functionaliteit waarin de bug zit die het omzeilen van BitLocker mogelijk maakt, legt de hacker uit in de documentatie bij YellowKey."

[Reactie gewijzigd door Tourmaline op 14 mei 2026 11:07]

Maar het idee van BitLocker is dat je data niet op straat liggen als een laptop gejat wordt. Aangezien de dieven zich niks aantrekken van een USB-verbod (tenzij je met superlijm de poorten dichtprakt) en vast een Recovery-USB kunnen bakken, is de beveiliging daartegen alsnog 0.

Vervelender: dat geldt retroactief, alle laptops die het afgelopen jaar gestolen zijn kunnen nu alsnog unlocked worden.
Lijmen hoeft niet, je hebt ook gewoon van die dopjes die je in je usb poorten kunt stoppen voor beveiliging/stof...


Je kunt ook in Windows zelf usb toegang uitschakelen. Dan kun je er instoppen wat je wilt maar werkt het ook niet. USB uitzetten in bios kan ook. In de meeste grote bedrijfsomgevingen zijn usb-sticks inmiddels verboden. De kans dat het op lokatie zal gebeuren is wel erg klein.

Tja, als iemand een laptop verliest is het wat lastiger al heb je tegenwoordig ook software die je lokatie kan tonen van de laptop en je kunt op afstand wissen.

[Reactie gewijzigd door Tourmaline op 14 mei 2026 11:41]

Op afstand wissen, werkt dat als de laptop nooit het internet op komt?
Nee, maar een dief zal toch windows willen activeren en op internet willen???Eventueel voor cloud files....
Een dief die uit is op de data, zal het vast prima vinden eerst offline de data eraf te moeten halen. Als de data eenmaal gejat is, kan je prima met een clean install de hardware weer benutten.
Heb ik laatst geprobeerd. Behalve Absolute’s “Persistence" die op firmware niveau werkt is er niets dat een herinstallatie van Windows overleeft.
Zorg na installatie van Windows dat er niet meer vanaf USB geboot kan worden. En zet dan natuurlijk ook een password op het BIOS zodat het niet zomaar aangepast kan worden.
Deze exploit is niet gebaseerd op booten van een USB stick.
Het artikel zegt letterlijk dat de hacktool vanaf een USB stick moet draaien. Maar het lijkt er idd op dat dat niet klopt. Je kan ook de recovery partitie aanpassen door de disk tijdelijk in een andere machine te steken.
Zoals ik het begrijp moet je in de Windows Recovery Environment booten, niet van de USB stick. Maar de files op de USB stick zorgen er wel voor dat de Windows RE een admin shell opent.

Van de YellowKey github:
How to reproduce :

Copy the FsTx folder to "YourUSBStick:\System Volume Information\FsTx" as is and make sure to use a filesystem that's compatible with Windows (NTFS is preferable but I think FAT32/exFAT should work as well). Funny thing is, the vulnerability is extremely convenient, you don't even need to plug an external storage device, you can just pull out the disk, copy the files in the EFI partition, put it back and it will still work. That's how bad it is.

Plug the USB stick in your target windows computer with bitlocker protection turned on.

Reboot to Windows Recovery Environment Agent (you can do that by holding SHIFT and clicking on the restart button using your mouse)

Once you click on the restart button, lift your finger off the SHIFT key and hold CRTL and do NOT lift your finger off it.

If you did everything properly, a shell will spawn with unrestricted access to the bitlocker protected volume.

[Reactie gewijzigd door jeroenvj op 14 mei 2026 12:38]

Ik interpreteer het als: De WinRE kun je zowel vanaf USB als vanaf de interne disk draaien. USB is makkelijker want dan hoef je niet de interne disk eruit te schroeven en aan te passen. Maar de bestanden moeten in de WinRE installatie staan waarvan je opstart.

Could be wrong though.
Ik zou zeggen probeer het eens ;) , voorzover ik het begrijp staat er geen WinRE op de YellowKey USB stick bestanden.
En ik denk dat ze juist een USB recovery stick bedoelen, die dan met hun eigen bestanden gepatched wordt.

Herstelstation - Microsoft Ondersteuning
Maar als jr van wi dows naar re moet booten, dan heb je toch al controle?
Ik heb het niet geprobeerd maar als Bitlocker aanstaat denk ik dat je normaal nog steeds je Biltocker moet unlocken?
Niet echt. Je moet zorgen dat er een pre-boot PIN op staat zodat de TPM-chip de sleutel pas vrijgeeft na het invoeren van de PIN.
Ja maar dit is wel echt heel naar voor mijn gebruikers. Mag ik ze allemaal gaan uitleggen waarom ze nu een pin extra moeten gebruiken bij het booten...
Dank voor je reactie.
Bitlocker heeft een modus waarbij je voordat Windows opstart eerst een PIN moet ingeven. Dit lost waarschijnlijk dit probleem op. Standaard Bitlocker ontgrendelt de disk als je opstart door middel van de TPM. Daarom krijg je het normale inlogscherm te zien.
Neen, je moet daar niet mee stoppen. De encryptie zelf is niet gekraakt en Microsoft lost het probleem ook gewoon op. Maar wil je echt zeker zijn, vereis dan een PIN code voor je BitLocker bij het opstarten. Dan zal de TPM de sleutel enkel en alleen afgeven als iemand de PIN code invoert, ook in een recovery omgeving.

Verder kan je ook gewoon de recovery partitie verwijderen mocht je dat wensen. Dan is dit probleem ook weer gemitigeerd.
Heb je een bron voor dat Microsoft dit probleem gaat oplossen? Ik heb dat bericht niet kunnen vinden namelijk. Dank.
Sowieso, wat is het nut van bitlocker behalve full drive encryption als het systeem niet aan staat?

Je kan beter voorkomen dat je systeem uberhaupt remote of lokaal wordt geexploit.

Bitlocker is dan alleen nog nuttig voor (letterlijk) de schroot.

Net zo onzinnig als RAM encryption als het systeem al draait. xD

Ok er zijn wat use cases, niche.
Sowieso, wat is het nut van bitlocker behalve full drive encryption als het systeem niet aan staat?
Precies dat is dus het nut. BitLocker is er primair om te voorkomen dat men bij de data kan van een gestolen/verloren laptop (of portable drive, maar die zijn in de meeste gevallen al een no-go bij organisaties).
Ik blijf het toch bizar vinden.. iets als BitLocker zou toch theoretisch zo in elkaar moeten zitten dat zelfs MS de boel niet kan ontgrendelen.

Als het op een of andere manier mogelijk is om zonder een wachtwoord de key van de disk te krijgen heb je er dus niets aan.
Er zitten dus meer backdoors in Amerikaanse apparaten/software dan in Chinese...... :+
China houd er simpelweg gewoon een andere werkwijze op na. Waarom iets voorzien van een backdoor als vrijwel alles ook gewoon te hacken is?
En Amerika, Europese landen doen dat niet? Vooral Rusland is erg actief met hacken.
Dat is niet wat ik zeg. Ik wijs alleen op het backdoor stukje.
Er zitten dus meer backdoors in Amerikaanse apparaten/software dan in Chinese...... :+
Dat is extreem slecht te onderbouwen. Hoe onderscheid je een backdoor van een bug?
Door uitgebreid onderzoek en snowden.
Maar Snowden heeft niets gezegd over algemeen aanwezige backdoors.
Hij heeft wel iets gezegd over een partij apparatuur voor een specifieke afnemer, die door de NSA is onderschept en van een backdoor is voorzien.
Windows zitten ook backdoors in voor politie e.d.

https://www.dutchitchannel.nl/news/466427/nieuwe-windows-backdoor-ontdekt-in-bits-functie-van-windows

Amerikaanse software/hardware is minstens net zo onveilig als de rest.

[Reactie gewijzigd door Tourmaline op 14 mei 2026 12:38]

We gebruiken veel meer Amerikaanse dan Chinese software dus gewoon het feit dat we meer zien vanuit Amerikaanse hoek betekend niets.
Bij Amerika is sinds het prism verhaal wel bekend dat er daadwerkelijk backdoors gemaakt worden. Het is ook geverifieerd dat Cisco apparatuur van backdoors wordt voorzien.

Er wordt /eerst een tijd geleden behoorlijk geschreeuwd vanuit Amerikaanse kant dat Chinese apparatuur backdoors heeft en dat de overheid kan mee kijken. Maar er zijn volgens mij geen concrete bewijzen dat het ook gebeurt.

In de koude oorlog had Amerika ook al de methode van wij kunnen iets dus we gaan er vanuit dat onze vijanden het zelfde doen of nog erger.
Je krijgt dan helaas wel -1, maar ik vermoed dat je wel gelijk hebt.
Vertel eens waar je vermoeden op is gebaseerd?

- hoeveel backdoors zitten er in Amerikaanse apparaten/software?
- hoeveel backdoors zitten er in Chinese apparaten/software?

Ik vermoed dat jij 2x "geen idee" antwoord.

En ik vermoed dat de -1 gebaseerd is op het feit dat dit soort uitspraken gewoon 'onderbuik leegloperij' is. En daar heb je niet zoveel aan op een forum als Tweakers. Dan kun je beter naar joop of geenstijl gaan.
Tot op heden geen aantoonbare backdoors in Chinese aparatuur ontdekt, wel in apparatuur van bijv. Cisco

https://www.infoworld.com/article/2179244/snowden-the-nsa-planted-backdoors-in-cisco-products.html


https://www.tomshardware.com/tech-industry/cyber-security/iran-claims-us-exploited-networking-equipment-backdoors-during-strikes


Tot op heden berust het Amerikaans bewijs alleen op "afpersing" vanwege de handelsoorlog met China.

In huawei aparatuur is nog niets aangetoond.

[Reactie gewijzigd door Tourmaline op 14 mei 2026 11:26]

Het tweede artikel is enkel speculatie. (Het kan kloppen, maar hoeft niet.)

De backdoor waar het eerste artikel over gaat is specifiek in een bepaalde partij ingebouwd. Die partij was door de NSA onderschept, aangepast en doorgestuurd. Dus geen standaard backdoor die in alle apparaten zit, in afwachting tot iemand er gebruik van wil maken.
Kan je dan uitleggen wat dit betekend, als het enkel speculatie is?
Meanwhile, the U.S. hasn’t addressed Iran's specific allegations, but has publicly confirmed that it conducted cyber operations against Iran's communications infrastructure. Chairman of the Joint Chiefs of Staff, General Dan Caine, said during a March 2nd Pentagon briefing that U.S. Cyber Command and U.S. Space Command were the “first movers” in so-called Operation Epic Fury, the military campaign launched against Iran at the end of February. Caine said coordinated space and cyber operations disrupted Iranian communications and sensor networks before strikes began.
De speculatie is dat ze gebruik hebben gemaakt van een backdoor.

Dat er een aanval is geweest op een deel van de ICT-infrastructuur is inderdaad duidelijk.
En die deel is Amerikaanse hardware en het is ze gelukt. Blijft nog weinig speculatie over. We weten historisch gezien al dat ze allemaal backdoors hadden en we weten ook dat de regering nu ook aandringt op backdoors en verzwakking van encryptie. Meer informatie dan dit ga je krijgen, dit is al veel.
Dus jij wilt beweren dat die Amerikaanse hardware zo goed, zo ondoordringbaar en zo veilig is dat zo'n aanval enkel enkel succesvol kan zijn met een opzettelijk aanwezige backdoor?
Goh, als dat eens waar zou kunnen zijn.
Beetje raar dat je namens mij een tekst verzint en vervolgens op je eigen verzinsel reageert alsof je met mij praat 😂
Ik verzin niets.

Jij suggereert dat de Amerikaanse cyberaanval op de Iraanse ICT infrastructuur zo succesvol was omdat een deel van die infrastructuur op Amerikaanse apparatuur draait. Dan noem je backdoors en speculeer je dat die Amerikaanse apparatuur dus backdoors bevat waar gebruik van is gemaakt.
Ik kom dan tot de logische conclusie dat volgens jouw redenering de cyber-aanval dus enkel succesvol kon zijn dankzij die backdoors en dat die Amerikaanse apparatuur zonder die backdoors dus ondoordringbaar zou zijn.

En vervolgens probeer je mijn logica belachelijk te maken, omdat je wilt verbloemen dat de door jou gegeven feiten totaal geen onderbouwing zijn van jouw gespeculeerde conclusie.
Precies de reden waarom routers in de vs uit het buitenland nu worden geweerd. Zodat elke us based router dadelijk is voorzien van spyware. Het zal me echt niets verbazen.
In het verleden is Cisco meer een apparaat geweest waarvan je kunt beweren dat dit speciaal voor de NSA ontwikkelde apparatuur is. Hoe dat nu zit weet ik niet, maar ze hebben vast minder goed detecteerbare backdoors. Microsoft is spyware, kun je zelf zo opzoeken. Android is spyware, hoef je ook geen raketgeleerde voor te zijn. De Amerikaanse overheid heeft als verplichting dat ieder Amerikaans bedrijf ieder stukje data overhandigd als hier een verzoekt voor is. Ook data die in de EU verwerkt wordt. Het is eigenlijk schrikbarend dat dit niet breder gedragen wordt en dat er niet actiever in de hele EU alternatieven gepromoot wordt.
De reactie die jij geeft is wederom een van het niveau van kop in het zand steken en doen alsof het allemaal niet zo'n ding is terwijl er ontiegelijk veel data via Amerikaanse server loopt.
Inderdaad, dat verwacht je!

FileVault op de Mac is niet te omzeilen, dus ook niet door Apple. Met forensische tools en brute force kun je het proberen, maar succes is niet gegarandeerd. Met andere woorden: FileVault is zeer veilig, in tegenstelling tot BitLocker.
Filevault is toch gewoon hetzelfde als Bitlocker met Pre boot authenticatie?
In principe doet Apple hetzelfde, maar is de achterliggende gedachte anders: FileVault gaat voor de meest simpele manier om encryptie met een hardware-gebaseerde sleutel te implementeren en doet dat op alle apparaten hetzelfde. Microsoft is flexibeler (met/zonder pre-boot authenticatie, verschillende versies TPM, allerlei enterprise key escrow systemen) maar daardoor is het risico op onveilige configuraties ook hoger.
Dat is in principe gewoon standaard bij bitlocker en andere full disk encryption methodes voor de boot disk, immers de disk moet unlocked zijn om te kunnen booten en tot het scherm te komen waar je jouw password in kan geven.

Juist daarom heb je een optie om een '2de' login scherm te introduceren in bitlocker (Pre Boot authenticatie), waarbij de disk inderdaad pas na het ingeven van een wachtwoord unlocked wordt. Zonder deze Pre Boot authenticatie beschermd bitlocker vooral tegen diefstal van de schijf (je kan deze niet unlocken in een ander systeem zonder de recovery key), maar als je hele device wordt gestolen en men kan zonder verdere beveiliging op op het inlogscherm komen ben je al voorbij bitlocker en zit men al bij de volgende verdedigingslijn (authenticatie).
Wie steelt er nou een schijf uit een apparaat en niet het hele apparaat?

En waarom niet standaard de schijf unlocken bij elke boot zoals bij MacOS (ik heb daar eigenlijk nooit zo een probleem mee 2x wachtwoord invoeren)

Is het hele BitLocker dan niet een beetje een wassen neus? Menig bedrijf heeft BitLocker aan staan voor als de medewerker de PC in de trein achterlaat. Dan heb je daar dus niets aan.

En waarom niet het OS niet encrypten en de rest van de bestanden wel?
Degene die niet wil dat je ziet dat je iets gejat hebt? Schijf past in je binnenzak, hele computer niet...
En waarom niet standaard de schijf unlocken bij elke boot zoals bij MacOS (ik heb daar eigenlijk nooit zo een probleem mee 2x wachtwoord invoeren)

En waarom niet standaard de schijf unlocken bij elke boot zoals bij MacOS (ik heb daar eigenlijk nooit zo een probleem mee 2x wachtwoord invoeren)
Voor consumenten was dat mogelijk denk ik beter geweest, maar gaat ook je implementatie graad verlagen, iets dat mogelijk weer negatief werkt. Jij kan het geen probleem vinden, net als ik. Maar implementeer zoiets maar eens bij je hele familie of in een bedrijf, geheid dat een deel van de mensen er direct over begint te klagen, want 'oh zo gebruikers onvriendelijk'.
Is het hele BitLocker dan niet een beetje een wassen neus? Menig bedrijf heeft BitLocker aan staan voor als de medewerker de PC in de trein achterlaat. Dan heb je daar dus niets aan.
Bitlocker is heel flexibel in de opties en manieren van configureren. Je kan het bijvoorbeeld ook centraal administreren zakelijk via bijv. Intune of SCCM. Je kan bepaalde hardware configuraties juist toestaan of juist verbieden. Nadeel daar van is dat je het ook kan afzwakken (bijv. door geen pre boot authenticatie te doen, of hardware oudere hardware toe te staan).

Echter denk ik niet dat Bitlocker daardoor een wassenneus is, immers als je de beste beveiliging wil gebruik je de variant niet zonder pre boot authenticatie, zorg je dat je altijd up-to-date bent e.d. en stricte implementaties gebruikt en ook afdwingt doormiddel van policies.

Echter de variant zonder dat alles, die consumenten veel gebruiken omdat deze standaard wordt uitgerold (Iets dat Filevault op de mac bijvoorbeeld volgens mij doet), voldoet eigenlijk prima voor wat deze moet doen voor de gemiddelde consument, zorgen dat een gelegenheidsdief niet zomaar zonder wat te moeten doen bij de data kan zoals 'vroeger' toen je bijvoorbeeld maar hoefde te booten in dos modus om gewoon bij de data te kunnen, wachtwoorden te resetten en dat soort zaken.

Die gelegenheidsdief gaat over het algemeen niet proberen bitlocker te kraken, die gooit er een nieuw OS op en wil de boel zo snel mogelijk verkopen. Terwijl als er helemaal geen versleuteling geweest zou zijn deze dief misschien wel even wat gaan neuzen.
En waarom niet het OS niet encrypten en de rest van de bestanden wel?
Als je dat wil zijn er andere tools als je bijvoorbeeld folder encryptie wil (kan je ook gebruiken naast bitlocker), dit soort tools (bitlocker, Filevault e.d.) zorgt er juist voor dat je over dit soort zaken niet na hoeft te denken. De hele disk is immers voorzien van encryptie.

[Reactie gewijzigd door Dennism op 14 mei 2026 12:27]

Wie steelt er nou een schijf uit een apparaat en niet het hele apparaat?
Voor een laptop is het stelen van het apparaat inderdaad makkelijker. Maar het apparaat wordt wel gemist wanneer de gebruiker het nodig heeft of simpelweg mee wil nemen.

Wanneer je toegang hebt tot de ruimte waar een PC staat met voor jou interessante gegevens, kan het handiger zijn om enkel de harde schijf mee te nemen. De PC blijft staan en wordt niet meteen gemist. Je kan de schijf ook verwisselen voor een geprepareerd exemplaar dat foutmeldingen genereert bij het booten. Dan kan ontdekking nog meer vertraagd worden.

En buiten dat, een losse schijf duw je iets makkelijker in je binnenzak dan een hele PC of server.
Als een schijf niet ge-encrypt is (met bitlocker), en je steelt het hele apparaat, dan moet je alsnog een paswoord ingeven om toegang tot de schijf te krijgen.
Door dan de schijf in een andere PC te steken (als 2e schijf), kan je alle data uitlezen, zonder dat je het windows paswoord nodig hebt. Dat is denk ik, het idee achter de optie om de schijf eruit te halen.
Wie steelt er nou een schijf uit een apparaat en niet het hele apparaat?
Externe USB disk?
Gisteren getest en het werkt als een zonnetje!
Erg vervelend als je van Bitlocker afhankelijk bent en je medewerkers rond huppelen met laptops.
Je hebt ook nog 3rd party versleutel software voor het versleutelen van eventuele hdd's of mappen.
Dat gebruiken de meeste bedrijven niet voor M365 data lokaal zou Purview gebruikt kunnen worden. Echter is dit meer een uitzondering dan de standaard vandaag de dag.
3rd party hoeft zelfs niet per se. BL gebruik ik ook voor externe hdd's en voor virtuele.
Gewoon op de desktop en niet voor de opstartpartitie.

Waar zou trouwens de key staan, aangezien ik geen tpm heb. Vraagje tussendoor.
Maar als je dat soort afhankelijkheden en vereiste voor je zijn en security zeer belangrijk voor je is, dan forceer je toch sowieso pre boot authentication al? Ik zie dat in ieder geval regelmatig terug komen als eis (als je aan bepaalde maatstaven moet voldoen) of aanbeveling
Zou je wel denken maar heeft iedereen alles op orde?!
Correct maar dat is niet voor elke klant weggelegd natuurlijk om dergelijke projecten te draaien.
Voor zakelijke omgevingen: je kunt naast Bitlocker ook Personal Data Encryption inzetten. Werkt bij ons probleemloos.
Maar slechts een beperkt aantal folders. In essentie enkel de data die je syncroniserd met OneDrive. En het vereist dan wel weer dat je Windows Hello for Business gebruikt.

[Reactie gewijzigd door Blokker_1999 op 14 mei 2026 11:25]

Dat klopt, en dat is in ons geval een nuttige maatregel, we hebben weinig technisch onderlegde eindgebruikers :)
Was er niet zoiets dat (bedrijf) admins wel die PDE bestanden kunnen inzien? Als ik het goed begrijp is die Yellow hack een escalatie (tot admin niveau?). Dus dan kan de dief wel bij die "beschermde" bestanden.
Met PDE zijn bestanden versleuteld met het gebruikersaccount. Dus ook als je ze in handen hebt moet je ze met het bijbehorende Entra ID account ontsleutelen. Een privilege escalation waarbij je localadmin wordt helpt je dus nog steeds niet aan de keys want die staan in de cloud.
Neen, de bestanden zijn wel in te zien zolang de gebruiker is aangemeld. Dus als admin zou je, op het moment dat de gebruiker is aangemeld, vanop afstand naar die folders kunnen gaan en alsnog de data lezen.

Het doel van PDE is om primair op gedeelde computers te voorkomen dat mensen elkaars bestanden en folders kunnen inzien mocht er een rechtenprobleem zijn alsook voorkomen dat wanneer je helpdesk bezig is met troubleshooting en de laptop bij hen hebben dat zij dan ook niet aan de gevoelige informatie kunnen die mogelijks op je laptop staat.
Op zich een aardig complete workaround. Meest gevoelige data zal toch in die folders zitten bij eindgebruikers. Ben wel benieuwd hoeveel gebruikers nog steeds inloggen met username/password na implementeren van WhfB. Misschien maar eens events gaan verzamelen..
Als je met PDE aan de slag gaat moet je ook voor passwordless gaan anders wordt de data niet ontsleuteld. Dat is met WHfB prima te doen; het is veiliger én gebruiksvriendelijker. Die combinatie zie je niet zo vaak. Natuurlijk kan het allemaal nog veel veiliger (en duurder) als het moet maar dat moet wel in verhouding staan tot je kans op een datalek en de impact daarvan.
Zover ik hierover gelezen heb leest dit de tpm2 sleutel wat in plain text naar de kernel wordt gestuurd. Dit kan verholpen worden wanneer de key versleuteld verstuurd wordt naar de kernel.

Ik weet niet hoe LUKS hiermee omgaat in Linux, in theorie zou het dus ook in Linux moeten werken mins het in plain text verstuurd wordt vanuit TPM2 naar de kernel. Wellicht kan iemand anders dit bevestigen.

Dit kan met zo'n raspberry pi zero binnen 1 minuut uitgevoerd worden.
Zelfs als de TPM2 de sleutel in plain text verstuurd naar de kernel rijst bij mij vooral de vraag waarom een usb sleutel toegang krijgt tot communicatie tussen de TPM2 en kernel. Als dat niet mogelijk zou zijn wordt het al een stuk lastiger om de bitlocker encryptie te kraken.

[Reactie gewijzigd door jumbos7 op 14 mei 2026 11:32]

Voor mensen die op een oude machine windows 11 draaien geldt dit dus niet. Daar zitten geen tpm2 chips op.
Maar die hebben dan sowieso al geen bitlocker toch, aangezien een tpm nodig is om dit te kunnen activeren?
Je kan ook bitlocker activeren zonder TPM, je bent dan achter wel verplicht om pre-boot authenticatie te gebruiken met een wachtwoord of fysieke unlock sleutel (USB stick bijvoorbeeld, mogelijk dat iets als een yubikey er ook voor te gebruiken is). Zie bijv. BitLocker without TPM: The Complete Security Analysis, Configuration, and Hardening Guide voor wat duiding.
Dat is niet het activeren, dat is het vinden van je beveiligingssleutel wanneer je niet meer weet waar je deze opgeslagen hebt. En als je zonder TPM e.d. aan de slag gegaan bent en je komt op dat scherm en je weet je key niet meer (of hebt hem niet meer) bent je al snel het spreekwoordelijke bokje, want de kans is dan vaak vrij klein dat deze in je MS account zit. En veel groter dat je moet gaan zoeken naar een USB stick of een stuk papier waar deze opstaat.

[Reactie gewijzigd door Dennism op 14 mei 2026 12:31]

Je kunt ook een 1.4 tpm chip hebben. Bitlocker is dan vanuit Windows wel te activeren volgens mij.
ik vermoed vanwege system-recovery vereisten waarbij de gebruiker via USB toegang moet kunnen krijgen tot zijn data.
Zoals ik het lees klopt het inderdaad dat het alleen werkt via system recovery, niet in gewoon Windows!

"Deze speculatie berust op het feit dat de misbruikte kwetsbaarheid alleen zit in een Windows-component die aanwezig is in het image van de Windows Recovery Environment. Het component bevindt zich ook in een reguliere Windows-installatie, maar heeft dan niet de functionaliteit waarin de bug zit die het omzeilen van BitLocker mogelijk maakt, legt de hacker uit in de documentatie bij YellowKey."
Dit kan toch alleen maar wanneer er geen passphrase of pin nodig is? Dan is het TPM-chip -> boot -> auto-unlock. Als een laptop in zijn geheel op de vuilnisbelt ligt dan hoef je gewoon maar te booten.

Dus ik ga ervanuit dat het probleem is dat als je enkel de schijf hebt, je vervolgens kan unlocken met WinRE, wellicht omdat die de Microsoft-keys bevat die nodig zijn voor een trusted bootchain zodat de TPM unlockt.

Encryptie met een pin/pass kun je immers niet 'bypassen': de data is encrypted. De enige optie is dan dat de key ergens stiekem wordt bewaard, maar dat lijkt me in deze context niet het geval te zijn.

PS: De screenshot van de password prompt in het artikel is wat misleidend, dit is net de case waarin deze bypass niet werkt.

[Reactie gewijzigd door TheBlackbird op 14 mei 2026 10:59]

Ik mag toch echt hopen dat de sleutels niet gewoon leesbaar op de WinRE partitie staan, maar dat op die WinRE gewoon de correcte identifiers beschikbaar zijn gesteld om de key te kunnen opvragen vanuit de TPM.

En gegeven dat het aanzetten van de BitLocker PIN al voldoende lijkt te zijn om deze hack te voorkomen lijkt ook te bevestigen dat de sleutel zelf nog altijd enkel en alleen in de TPM bewaard blijkt te zijn.
preboot lijkt niet te helpen.

I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
Zonder context kan je daar niet veel mee op deze manier. Bijv. Preboot + pin is bad als hij het voor elkaar krijgt zonder de pin in te geven. Maar als hij het voor elkaar krijgt door de pin in te geven en dan hetzelfde trucje uit te halen zou dat weer vrij normaal zijn. Immers dan ben je alweer bij het authenticatie proces.

[Reactie gewijzigd door Dennism op 14 mei 2026 12:41]

Denk ik te simpel dat een hack met Yellowkey te voorkomen is door een wachtwoord op de BIOS (en het F12 bootmenu) te zetten zodat er niet via het bootmenu zomaar geboot kan worden vanaf een USB stick?

Of is dit ook weer simpel te "hacken" ?
Ik denk dat de disk in een andere PC gezet kan worden en dan alsnog gewoon gelezen kan worden.
Ha!
Dat is nog eens simpele "hack"!

Niet over nagedacht, maar klinkt logisch. (y)
Dat denk ik niet... de key staat nog steeds op de hardware zelf (TPM) dus die heb je wel echt nodig voor deze backdoor.
Op de USB stick staat geen uitvoerbare code. Je start WinRE vanop de harde schijf die in de laptop zit. Er staat enkel wat config op de USB stick, en zoals de hacker ook aangeeft kan je die ook gewoon op de EFI partitie van de harde schijf zetten mocht je daar toegang toe hebben.
Deze hack vereist sowieso fysieke toegang tot de machine. Dus dan heb je ook toegang tot de harde schijf.

Dus USB uitschakelen in BIOS e.d. gaat je niks opleveren.

Om te kunnen reageren moet je ingelogd zijn