UEFI Bootkit: Bootkitty op Linux en de erfenis van BlackLotus

Informatic Digital » Linux » UEFI Bootkit: Bootkitty op Linux en de erfenis van BlackLotus

De UEFI-bootkits zijn een van de meest verontrustende vectoren in het moderne dreigingslandschap geworden: ze draaien vóór het besturingssysteem, kunnen verdedigingen uitschakelen en persistentie bereiken met verhoogde privileges. De afgelopen jaren zijn we van louter Bewijs van concept naar echte actieve gevallen zoals BlackLotus op Windows, en nu verschijnt het eerste op Linux gerichte ontwerp, genaamd Bootkitty, dat een nieuw stadium opent voor het ecosysteem van gratis software.

Dit artikel verzamelt en organiseert belangrijke informatie uit meerdere erkende bronnen om uit te leggen hoe de UEFI-bootkits, wat onderscheidt Bootkitty op Linux, waarom markeerde BlackLotus een voor en na in Windows, op welke indicatoren van een compromis moet je letten en wat defensieve maatregelen Toepassen. Daarnaast worden relevante cases zoals LoJax, ESPecter, MoonBounce en MosaicRegressor besproken, evenals gerelateerde MITRE ATT&CK-detectieregels en -tactieken.

Wat is een UEFI-bootkit en waarom vormt het een ernstig risico?

Een UEFI-bootkit is een schadelijke code die wordt uitgevoerd in de vroege stadia van het opstarten, wanneer de firmware de computer initialiseert en voordat de besturingssysteem blokkeert of infecteert de controle overnemen. Door op zo'n laag niveau te opereren, kunnen ze remmende mechanismen zoals het verifiëren van handtekeningen of het laden van legitieme drivers, het implementeren van payloads in de kernel- of gebruikersmodus en het verborgen blijven voor veel traditionele tegenmaatregelen.

Het is belangrijk om onderscheid te maken tussen verschillende niveaus van boot-malware: firmware-implantaten (bijvoorbeeld LoJax in 2018) wijzigen de SPI-flash direct, terwijl bootkits zich doorgaans op de beter toegankelijke EFI-systeempartitie (ESP) bevinden, maar met capacidades vergelijkbaar met het vroegtijdig overnemen van de controle over het opstartproces.

De recente ontwikkeling van kwetsbaarheden in UEFI en het gebrek aan tijdige herroepingen Defecte binaire bestanden in de herroepingsdatabase (dbx) hebben het voor aanvallers gemakkelijker gemaakt om ondertekende maar kwetsbare componenten te misbruiken om Secure Boot omzeilen, zoals het geval was bij de CVE-2022-21894 (Baton Drop) exploitatie in de BlackLotus-zaak.

Historische context: van PoC's op Windows tot cases in het wild

De eerste grote publieke demonstratie van een UEFI-bootkit Moderne ontwikkeling dateert uit 2012, toen Andrea Allievi een PoC documenteerde die in Windows-omgevingen met UEFI kon draaien. Dit werd gevolgd door andere tests – EfiGuard, Boot Backdoor, UEFI-bootkit – die de technische haalbaarheid van de aanpak aantoonden.

Na die eerste fase van experimenteren duurde het jaren voordat de actieve bedreigingen op echte systemen. In 2021 werden ESPecter (onderzocht door ESET) en de FinSpy bootkit (geanalyseerd door Kaspersky) uitgebracht, en in 2023 werd BlackLotus uitgebracht, de eerste bekende bootkit die UEFI Secure Boot omzeilde. volledig bijgewerkte uitrusting met Windows 11.

Tot voor kort hadden al deze zaken één ding gemeen: ze waren uitsluitend gericht op WindowsDit paradigma wordt doorbroken met de ontdekking van Bootkitty, gericht op Ubuntu en dus op de wereld Linux.

Bootkitty: eerste UEFI-bootkit gericht op Linux

In november 2024 werd een onbekende UEFI-applicatie (bootkit.efi) die na analyse Bootkitty bleek te zijn, de eerste UEFI-bootkit ontworpen voor Linux, specifiek voor bepaalde versies van Ubuntu. Volgens de beschikbare telemetrie is er geen bewijs van implementatie in het wild; alles wijst erop dat proof of concept vroeg, met meerdere ontwikkelingsartefacten.

Belangrijke update: Begin december 2024 werd bevestigd dat dit een academisch project was, ontwikkeld door deelnemers aan het Koreaanse Best of the Best (BoB)-programma. Het beoogde doel was: bewustmaking over risico's en moedig proactieve maatregelen aan. Dit artikel sluit aan bij wat analisten opmerkten: een functionele bootkit, maar met beperkte ondersteuning en tekenen van PoC, geen afgewerkt wapen voor massacampagnes.

PoC-compatibiliteit, handtekening en signalen

Bootkitty wordt geleverd met een zelfondertekend certificaat, dus het werkt niet als Secure Boot is ingeschakeld, tenzij de certificaten van de aanvaller handmatig worden toegevoegd. De logica probeert echter de kernelboot voort te zetten met normaliteit patchen van verificatiefuncties in het geheugen voordat GRUB de controle opgeeft.

De compatibiliteit is beperkt. Om functies te vinden die u wilt wijzigen, gebruikt u bytepatronen gecodeerd die niet meerdere kernel- of GRUB-versies omvatten, waardoor het alleen operationeel is in specifieke configuraties en vatbaar is voor crashes als de offset niet overeenkomt met de versie aanwezig is.

Onder de PoC-artefacten vallen twee routines op die op het scherm een ​​ASCII-afbeelding afdrukken met de naam Bootkitty en een lijst met mogelijke auteurs; bovendien worden bij het opstarten specifieke strings en verwijzingen weergegeven, zoals "BlackCat", die niets te maken hebben met de ALPHV/BlackCat-ransomwaregroep. Het binaire bestand overschrijft ook de versiestring en -banner van Linux met de tekst “BoB13”.

Uitvoeringsketen en hooks in UEFI en GRUB

Bij het opstarten controleert Bootkitty de status van SecureBoot Het leest de gelijknamige UEFI-variabele. Vervolgens worden hooks geïnstalleerd in de UEFI-authenticatieprotocollen — EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication en EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState — om EFI_SUCCES waardoor de daadwerkelijke evaluatie van de UEFI PE-beeldintegriteit teniet wordt gedaan.

Laad vervolgens vanuit de ESP een legitieme GRUB die zich op het hardgecodeerde pad bevindt /EFI/ubuntu/grubx64-real.efi (waarschijnlijk een kopie die de aanvaller heeft neergezet). Met GRUB in het geheugen, nog niet actief, de bootkit patches en haken verschillende kritische punten, waaronder:

• peimage::start_image (ingebed in GRUB), om het moment te onderscheppen waarop de kernel EFI-stub (vmlinuz.efi) in het geheugen wordt geladen. Vanaf hier lokaliseert en patcht Bootkitty de routine die verantwoordelijk is voor de kerneldecompressie, hoogstwaarschijnlijk zstd_decomprimeren_dctx afhankelijk van de build.
• shim_lock_verifier_init, onderdeel van shim_lock in GRUB, hoewel de toegepaste hook irrelevant is omdat een andere hook voorkomt dat deze wordt uitgevoerd, en de modificatie introduceert ook de vlag GRUB_VERIFY_FLAGS_SINGLE_CHUNK, die in theorie hardt uit verificatie.
• grub_verifiers_open, die is aangepast om onmiddellijk terug te keren zonder handtekeningcontroles uit te voeren, waardoor de normale stroom van verificatie in GRUB.

Kernel decompressie hook en geheugenpatches

De kernel-decompressiehook herstelt tijdelijk de originele bytes, staat de authentieke functie toe de afbeelding te decomprimeren en past vervolgens patches toe op de geheugen van de reeds uitgebreide kernel. Deze fase is cruciaal voor het uitschakelen van besturingselementen en het voorbereiden op het laden van extra modules of binaire bestanden.

Meer specifiek herschrijft de waargenomen logica de versiestring met “BoB13”, wijzigt de functie module_sig_controle om 0 terug te geven (zodat de kernel ongetekende modules accepteert, zelfs als Secure Boot is ingeschakeld, met CONFIG_MODULE_SIG_FORCE of met module.sig_enforce=1), en vervangt de eerste omgevingsvariabele van de init-proces door “LD_PRELOAD=/opt/injector.so /init”.

Het idee achter LD_PRELOAD is om prioriteit te geven aan het laden van een ELF gedeeld om functies te overschrijven of extra logica in te voegen, een veelgebruikte techniek bij aanvallen in de gebruikersomgeving. De aanwezigheid van "/init" in de LD_PRELOAD-waarde is opvallend; de exacte betekenis is niet helemaal duidelijk en versterkt de interpretatie dat we te maken hebben met een vroege ontwikkeling.

Tijdens laboratoriumtests gaf het systeem de kernel weer als bedorven na het opstarten met Bootkitty; daarnaast kun je in dmesg de gewijzigde strings en de trace van de variabele LD_PRELOAD zien, die ook te zien is in /proc/1/omgevingOp computers waarop Secure Boot is ingeschakeld, is een empirische indicatie dat de kernel akkoord gaat met het laden van een module ongetekend tijdens runtime, wat niet mag gebeuren zonder voorafgaande patching.

BCDropper en BCObserver: bijbehorende hulpstukken

Tegelijkertijd wordt een niet-ondertekende kernelmodule genaamd BCDropper, geüpload naar VirusTotal door dezelfde afzender als de bootkit. Het bevat verwijzingen naar "BlackCat" in debugstrings en paden, en een functie voor het verbergen van bestanden (filtert namen met voorvoegsels zoals "injector”, in lijn met de LD_PRELOAD die verwijst naar /opt/injector.so).

BCDropper extraheert een ingebedde ELF genaamd BCO-server in /opt/observer en voert het uit via /bin/bash. Het verwijdert ook zijn eigen trace uit de lijst met geladen modules en biedt functies voor rootkit de typische (het verbergen van bestanden, processen, poorten), hoewel de dropper ze niet allemaal rechtstreeks exploiteert.

BCObserver wacht daarentegen totdat de displaymanager start. gdm3 en probeert vervolgens /opt/rootkit_loader.ko te laden met behulp van de systeemoproep eindige_module, waardoor ervoor gezorgd wordt dat de module wordt geïnjecteerd wanneer het systeem de grafische opstartprocedure al heeft voltooid.

Er is geen absolute zekerheid dat deze stukken aan dezelfde auteur zijn gekoppeld als Bootkitty, maar het patchen van module_sig_controle suggereert dat het doel was om het laden van niet-ondertekende modules mogelijk te maken, wat aansluit bij wat BCDropper/BCObserver doet.

Relevante MITRE ATT&CK IoC's en technieken

de volgende indicatoren van betrokkenheid en classificaties kunnen helpen bij het zoeken naar initiële signalen in Linux-omgevingen waar de PoC mogelijk is getest:

SHA-1	Naam	opsporing	Beschrijving
35ADF3AED60440DA7B80F3C452047079E54364C1	bootkit.efi	EFI/Agent.A	Bootkitty UEFI-bootkit.
BDDF2A7B3152942D3A829E63C03C7427F038B86D	dropper.ko	Linux/Rootkit.Agent.FM	BCDropper.
E8AF4ED17F293665136E17612D856FA62F96702D	waarnemer	Linux/Rootkit.Agent.FM	BCO-server.

De meest prominente MITRE ATT&CK-mapping voor deze set stukken en waargenomen gedrag, nuttig voor een Bedreigingsmodel essentieel:

tactiek	ID	Naam	Beschrijving
Ontwikkeling van hulpbronnen	T1587.001	Ontwikkelmogelijkheden: Malware	Bootkitty is een UEFI-bootkit nieuw.
	T1587.002	Ontwikkelmogelijkheden: Code Signing-certificaten	Voorbeeld ondertekend met gecertificeerde zelfondertekend.
Uitvoering	T1106	Native API	BCObserver gebruikt eindige_module om een ​​LKM te laden.
	T1129	Gedeelde modules	Bootkitty-kracht LD_PRELOAD in begin.
Volharding	T1574.006	Hijack-uitvoeringsstroom: dynamische linkerkaping	Omgevingspatching init met LD_PRELOAD.
	T1542.003	Opstarten vóór besturingssysteem: Bootkit	Inzet in de EZP.
verdediging ontduiking	T1014	Rootkit	BCDropper als LKM voor verhulling.
	T1562	Aantasting van verdedigingen	Verificatie van uitschakelen bedrijven in GRUB en kernel.
	T1564	Verberg artefacten	Verberg uw module in de lijst modules del kernel.

Sporen op Linux-systemen en suggesties voor mitigatie

Forensisch bewijs, zoals de gewijzigde versie van de kernel, is aangetroffen in de getroffen Ubuntu-installaties. BoB13 (zichtbaar met uname -v), aanpassingen aan de bootbanner (dmesg) en aanwezigheid van LD_PRELOAD in /proc/1/omgevingHet is mogelijk dat de kernel als besmet wordt gemarkeerd. Dit gebeurt niet zonder de bootkit.

Een snelle oplossing wanneer de bootkit GRUB vervangt, is om het legitieme GRUB-bestand te retourneren. /EFI/ubuntu/grubx64-real.efi naar de oorspronkelijke locatie in /EFI/ubuntu/grubx64.efi, zodat shim de authentieke GRUB opstart. Onthoud dat dit alleen betrekking heeft op de stadium een specifieke waarbij de inzet precies zo is geweest.

BlackLotus: het paradigmatische geval in Windows

BlackLotus werd bekend omdat het zijn taken kon uitvoeren UEFI-bootkit zelfs op een volledig gepatchte Windows 11 met Secure Boot ingeschakeld. Het was sinds oktober 2022 te koop voor $ 5.000 ($ 200 per upgrade), met geofencing om systemen uit Armenië, Wit-Rusland, Kazachstan, Moldavië, Roemenië, Rusland en Oekraïne te vermijden.

De kwetsbaarheid uitgebuit CVE-2022-21894 (Baton Drop), gepatcht door Microsoft in januari 2022, maar nog steeds exploiteerbaar enige tijd later omdat kwetsbare en ondertekende binaire bestanden nog steeds niet aan de lijst met UEFI-intrekkingen (dbx). Het installatieprogramma plaatst kopieën van geldig ondertekende kwetsbare bootloaders om persistentie te bereiken en Secure Boot te omzeilen.

Onder zijn vaardigheden was hij in staat om: desactivar BitLocker, Memory Integrity (HVCI) en Microsoft Defender implementeren een bestuurder in de kernel die de bootkit-bestanden op de ESP beschermt, en een HTTP-downloader in de gebruikersmodus die binnen winlogon.exe, met anti-VM-, anti-debugging- en verduisteringstechnieken. De bootkit was klein (ongeveer 80 KB), wat gunstig is voor de geheimhouding.

Er zijn interne kettingen en merkwaardige artefacten gedocumenteerd, zoals verwijzingen naar de serie Higurashi in componentnamen en het zelfondertekende certificaat, evenals ongebruikte, verduisterde berichten. Deze details verminderen het gevaar niet, maar bieden wel context over de aard ervan. desarrollo.

Hoe Windows het opstarten beschermt: Secure Boot, Trusted Boot, ELAM en Measured Boot

In Windows bestaat de opstartketen uit verschillende lagen. Beveiligd Opstarten valideert firmware- en bootloader-handtekeningen; Trusted Boot controleert de integriteit van de kernel- en bootcomponenten; ELAM geeft prioriteit aan het laden van een antimalwaredriver vóór andere niet-Microsoft-opstartdrivers; en Gemeten laars registreert hashes in de TPM voor externe attestatie.

Gecertificeerde computers hebben standaard Secure Boot ingeschakeld en vertrouwen het certificaat. Microsoft en andere goedgekeurde laders. Het ingeschakeld houden van de Microsoft UEFI CA van derden vergroot echter het aanvalsoppervlak tot trust in bootloaders van meerdere distributies, inclusief die met bekende kwetsbaarheden. Veel geharde kernelapparaten vereisen het uitschakelen van het vertrouwen in die externe CA om de houding standaard.

Om Linux in beschermde omgevingen toe te staan, is de aanbevolen aanpak: toevoegen het expliciet ondertekenen van de gewenste bootloader in de UEFI-database of, als laatste redmiddel, het uitschakelen van Secure Boot — een maatregel die de bescherming tegen bootkitDeze wijzigingen vereisen in ieder geval handmatige ingrepen in de firmware en kunnen niet door malware worden geautomatiseerd.

De attestatie met Gemeten laars Hiermee kan een vertrouwde server beoordelen of een eindpunt zijn bootchain intact houdt. De TPM ondertekent het bewijs en maakt het, in combinatie met extra telemetrie, mogelijk om gecompromitteerde apparaten op netwerken te isoleren. cuarentena totdat de schade is verholpen.

Proactieve detectie- en bewakingsregels

Naast de native Windows-instrumentatie heeft de community Sigma-regels Handig voor het detecteren van activiteiten die verband houden met deze scenario's. Dit omvat het aanmaken van een firmwarebestand onder System32 door een niet-systeemproces, of uitschakelen Detectie van geheugenintegriteit (HVCI) met behulp van registersleutels (MITRE ATT&CK-technieken T1562 en T1112). Deze detecties worden toegewezen aan meerdere SIEM's/EDR's/XDR's.

Voor Linux is het handig om te correleren events boot (journald/dmesg), wijzigingen in de omgevingsvariabelen uname -v en PID 1, en controle op niet-ondertekende moduleladingen of Operaciones verdacht over ESP. Het integreren van deze sporen met gedragsregels in de EDR verbetert de kans op het ontdekken van een poging tot ESP. volharding vroeg.

Groter plaatje: LoJax, ESPecter, MoonBounce, MosaicRegressor en nieuwe signalen

Het eerste UEFI-firmware-implantaat dat in het wild werd waargenomen, was LoJax (2018), gevolgd door campagnes met MosaicRegressor en MoonBounce, waarbij de laatste opmerkelijk is omdat hij de lat hoger legt op het gebied van verfijning in rootkits UEFI. In 2021 toonden ESPecter en de FinSpy-bootkit aan dat de pre-OS-fase nog steeds een aantrekkelijk doelwit was voor acteurs Geavanceerd.

Op het gebied van Linux is Bootkitty de eerste Prueba functioneel in zijn soort, met een beperkte reikwijdte. En al in 2025 verschenen er verwijzingen naar "HybridePetya"als een evolutie van de Petya-familie met UEFI-bootkit-mogelijkheden, met samples die van VirusTotal zijn geüpload PoloniaHoewel de analyse nog voorlopig is, is het een herinnering dat deze categorie bedreigingen nog steeds bestaat. uitbreiding.

Praktische aanbevelingen om risico's te verminderen

In Linux-omgevingen onderhouden Beveiligd Opstarten actief, het toepassen van firmware- (UEFI) en kernelupdates en het up-to-date houden van de herroepingslijst (dbx) zijn niet-onderhandelbare pijlers. Controleer of module.sig_enforce is ingesteld op 1 of dat CONFIG_MODULE_SIG_FORCE is ingeschakeld waar dat van toepassing is en voorkomt dat modules van niet-vertrouwde bronnen worden geladen.

Controleer de partitie regelmatig EZP Het scant op ongeautoriseerde wijzigingen in paden zoals /EFI/ubuntu/grubx64.efi en controleert of er geen verdachte kopieën (grubx64-real.efi) zijn. Elke wijziging in de verificatiestroom GRUB moet onderzocht worden.

In Windows wordt naast Secure Boot ook Trusted Boot afgedwongen, HVCI wanneer ondersteund door de hardware, en neemt TPM-gebaseerde externe attestatie met beleid over voorwaardelijke toegangMinimaliseert de afhankelijkheid van externe CA's indien dit niet strikt noodzakelijk is en versnelt de acceptatie intrekkingen wanneer ze fouten in opstartcomponenten publiceren.

Sommige commerciële oplossingen integreren UEFI-scanners die de firmware op fouten kunnen controleren. kwaadaardige componentenESET beweert de enige leverancier te zijn in de top 20 van endpoint-inkomsten die deze geïntegreerde mogelijkheid aan zijn klanten biedt, een aanpak die waarde kan toevoegen aan defensie diepgaande hardware.

Uit het verloop van de recente campagnes blijkt duidelijk dat de startschakel een prioriteit blijft. telemetrie Met de juiste firmware-/bootloader-beveiliging en systematische integriteitscontroles is het mogelijk om de lat aanzienlijk hoger te leggen en het leven van ontwikkelaars moeilijker te maken. tegenstanders.

De stand van de techniek van de UEFI-bootkits bevestigt dat de grens tussen PoC en de echte werking steeds sneller wordt overschreden: Bootkitty laat zien dat Linux al in de schijnwerpers staat, BlackLotus consolideerde de levensvatbaarheid op Windows en het defensie-ecosysteem moet prioriteit geven aan boothygiëne, dbx-updates en monitoring IoC's en verificatie op afstand om pogingen tot persistentie vóór besturingssysteem in de kiem te smoren.