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. Het vormt wel een bedreiging voor gestolen computers waarbij BitLocker nu dus geen databescherming meer biedt, merkt Bleeping Computer op.

Naast YellowKey geeft Nightmare-Eclipse nog een zerodaykwetsbaarheid in Windows vrij. Deze heet GreenPlasma en komt nu niet compleet met exploitcode om er misbruik van te maken. Het gaat om een manier om vanuit het account van een gewone gebruiker op Windows de vergaande 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

111

Submitter: g4wx3

Reacties (111)

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.
Je moet volgens mij wel alles doen
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]

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.
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 zijn laat hier, dit was gister 13 mei al nieuws.
De eerste (Enable TPM + PIN pre-boot authentication), is trouwens al reeds aangeraden door het Microsoft defender team.
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.
mogelijk iets dat men ooit heeft ingebouwd om recovery eenvoudiger te willen maken als het misloopt
Of mogelijk een backdoor :)
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.
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]

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.
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/
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]

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.
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]

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]

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...
Niet voor de overheden, nee. Het was overigens al bekend dat er backdoors waren voor politie e.d.
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....
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.
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.
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.
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.
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.
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]

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.
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?
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.
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.
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?!
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.
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 kunt ook een 1.4 tpm chip hebben. Bitlocker is dan vanuit Windows wel te activeren volgens mij.
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]

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]

Ik vind de woordkeuze een beetje verwarrend – niet alleen hier maar ook door de ontdekker. In mijn hoofd wordt er namelijk niets omzeild qua versleuteling. De TPM geeft gewoon de sleutel zoals met een normale boot (key material wordt niet door gebruiker gegeven of geseed). Stel dat je een gestolen laptop in handen hebt en start die op, dan boot die tot het login scherm en is de disk ook 'unlocked'. Wat YellowKey doet is het mogelijk maken om het account login scherm te bypassen, behalve dat die dat doet in de recoverymodus ipv reguliere Windows boot. Daarom vind ik dat het geen BitLocker bypass is maar een authenticatie bypass; de OS access boundaries worden hier omzeild, BitLocker is dan al 'open' op de manier die zo is ontworpen het volume te ontsleutelen. 'kraakt BitLocker encryptie' zoals in de titel vind ik daarom de plank misslaan.

En mensen zouden helemaal niet verrast moeten zijn dat toegang tot een versleutelde disk mogelijk is als die zonder apart gescheiden key material kan worden ontsleuteld. Technisch gezien was alles al aanwezig en was het wachten op een bypass van die laatste toegangsdeur.

[Reactie gewijzigd door gertvdijk op 14 mei 2026 11:02]

Inderdaad. Dit is helemaal geen bitlocker hack, het is een windows RE 'feature' waarbij je door een flag te zetten een admin elevated cmd prompt krijgt.

Bitlocker heeft er helemaal niets mee te maken behalve dat met het zetten van een bitlocker pin je voorkomt dat je boot en hiermee voorkomt dat iemand dit gebruikt.

Om te kunnen reageren moet je ingelogd zijn