Secure Boot: Baton Drop-patch werkt pas na handmatige stap

Kaspersky-onderzoekers hebben een UEFI-bootkit ontleed die Secure Boot omzeilde op Windows-machines die volledig waren bijgewerkt. Niet omdat er een update miste, maar omdat de bijbehorende patch een handmatige stap vereist die vrijwel niemand zet. Het onderzoeksrapport verscheen op 22 oktober op Securelist; BleepingComputer berichtte er vrijdag over.

Een kopie van BlackLotus

De bootkit, door Kaspersky BlackX genoemd, werd begin 2026 aangetroffen bij diplomatieke diensten in Tadzjikistan, Oezbekistan en Turkmenistan. Kaspersky schrijft de campagne met gemiddelde zekerheid toe aan APT41, de Chinese groep die ook bekendstaat als Brass Typhoon en Wicked Panda.

BlackX lijkt sterk op BlackLotus, de bootkit die in 2022 voor 5.000 dollar op een hackersforum werd aangeboden en die ESET in maart 2023 in het wild aantrof. Beide misbruiken Baton Drop (CVE-2022-21894) om eigen Machine Owner Keys te installeren, waarna willekeurige EFI-bestanden geladen kunnen worden en Secure Boot niets meer tegenhoudt. De broncode van BlackLotus is nooit volledig openbaar geworden, dus gaat Kaspersky ervan uit dat de aanvallers die hebben nagebouwd of gekocht.

Belangrijke nuance: dit is geen aanval op afstand. Kaspersky zag de bootkit pas geplaatst worden nadat de aanvallers al beheerdersrechten hadden. BlackX is het middel om daarna te blijven zitten, onder het besturingssysteem.

De patch die je zelf moet aanzetten

Het interessante deel van het rapport gaat niet over de malware, maar over de patch. De getroffen machines waren bij, en toch werkte het lek. De oplossing voor Baton Drop trekt namelijk het certificaat "Windows Production PCA 2011" in, en die intrekking gebeurt niet automatisch bij het installeren van de update. Er wordt alleen een registervlag gezet onder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot en een geplande taak Secure-Boot-Update aangemaakt. De beheerder moet die stap zelf afmaken.

Daar is een reden voor: automatisch intrekken kan dual-bootsystemen onstartbaar maken die nog op dat certificaat vertrouwen. Maar het is uiterst ongebruikelijk dat een beheerder ná een geslaagde update nog iets doet, schrijft Kaspersky, en de instructies staan diep op de Microsoft-site begraven. Microsoft kondigde een "Enforcement Phase" aan waarin de intrekking wél automatisch zou gebeuren; die fase is er nog niet. In de Windows IT Pro-blog hierover staat sinds juni 2024 een redactionele noot dat de planning "onder evaluatie" is.

Op 19 oktober 2026 is het certificaat verlopen. Dat helpt niet: volgens Kaspersky kunnen de kwetsbare bestanden daarna nog steeds geladen worden, tenzij het certificaat op de blokkadelijst staat.

Wat de bootkit daarna doet

De UEFI-payload injecteert een kernel-driver, ondertekend met een inmiddels ingetrokken certificaat van een Chinees bedrijfje. Die driver schakelt callbacks van beveiligingssoftware uit en knoeit met ETW-providers, zodat monitoring niets meer ziet. Opent iemand een bestand van de bootkit, dan krijgt hij een verwijzing naar de rekenmachine terug. Daarna volgen twee spionagepayloads: een RAT die Google Drive, OneDrive of Yandex.Disk als commandokanaal gebruikt, en een gesideloade DLL die een Rust-payload start.

Wat je nu kunt doen

Microsoft beschrijft de volgorde in de blogpost hierboven en in KB5025885. Kort samengevat, en met de waarschuwing dat Microsoft dit expliciet eerst op representatieve testmachines wil zien:

• Controleer eerst of het nieuwe vertrouwensanker binnen is. In een PowerShell-venster als beheerder: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'. Komt daar True uit, dan is de DB-update geslaagd.
• Pas de DBX-intrekking nooit toe vóór die DB-update. Microsoft waarschuwt dat het systeem dan niet meer opstart.
• Reken erop dat opstartmedia die met het oude certificaat uit 2011 zijn ondertekend na de intrekking niet meer werken: herstel-usb's, installatiemedia en vooral PXE-netwerkboot.
• Zet BitLocker-herstelsleutels veilig voordat je herstart, en controleer of de UEFI-firmware op de laatste versie van de leverancier staat.