Det første in-the-wild UEFI bootkit, der omgår UEFI Secure Boot på fuldt opdaterede UEFI-systemer, er nu en realitet
Antallet af UEFI-sårbarheder, der er opdaget i de seneste år, og fejlene i at patche dem eller tilbagekalde sårbare binære filer inden for et rimeligt tidsrum er ikke gået ubemærket hen af trusselsaktører. Som et resultat er det første offentligt kendte UEFI-bootkit, der omgår den væsentlige platformssikkerhedsfunktion – UEFI Secure Boot – nu en realitet. I dette blogindlæg præsenterer vi den første offentlige analyse af dette UEFI-bootkit, som er i stand til at køre på selv fuldt up-to-date Windows 11-systemer med UEFI Secure Boot aktiveret. Funktionaliteten af bootkittet og dets individuelle funktioner får os til at tro, at vi har at gøre med et bootkit kendt som sort lotus, UEFI bootkittet sælges på hackingfora for $5,000 siden mindst oktober 2022.
UEFI-bootkits er meget kraftfulde trusler, som har fuld kontrol over OS-startprocessen og dermed i stand til at deaktivere forskellige OS-sikkerhedsmekanismer og implementere deres egne kernetilstande eller brugertilstande i de tidlige opstartsfaser af OS. Dette giver dem mulighed for at operere meget snigende og med høje privilegier. Indtil videre er kun nogle få blevet opdaget i naturen og offentligt beskrevet (f.eks. flere ondsindede EFI-prøver vi opdagede i 2020, eller fuldt udstyret UEFI bootkits, såsom vores opdagelse sidste år – ESPecter bootkit - eller den FinSpy bootkit opdaget af forskere fra Kaspersky).
UEFI bootkits kan tabe på snighed sammenlignet med firmwareimplantater – som f.eks LoJax; det første in-the-wild UEFI-firmwareimplantat, opdaget af vores team i 2018 – da bootkits er placeret på en let tilgængelig FAT32-diskpartition. Men at køre som en bootloader giver dem næsten de samme muligheder som firmwareimplantater, men uden at skulle overvinde multilevel SPI flash-forsvaret, såsom BWE, BLE og PRx beskyttelsesbits, eller beskyttelsen fra hardware (som Intel Boot Guard ). Sikker på, UEFI Secure Boot står i vejen for UEFI bootkits, men der er et ikke ubetydeligt antal kendte sårbarheder, der tillader omgåelse af denne vigtige sikkerhedsmekanisme. Og det værste ved dette er, at nogle af dem stadig let kan udnyttes på opdaterede systemer, selv på tidspunktet for dette skrivende - inklusive den, der udnyttes af BlackLotus.
Vores undersøgelse startede med et par hits på, hvad der viste sig at være BlackLotus-brugertilstandskomponenten – en HTTP-downloader – i vores telemetri sent i 2022. Efter en indledende vurdering bragte kodemønstre fundet i prøverne os til opdagelsen af seks BlackLotus installationsprogrammer (både på VirusTotal og i vores egen telemetri). Dette gjorde det muligt for os at udforske hele udførelseskæden og indse, at det, vi havde at gøre med her, ikke kun er almindelig malware.
Følgende er de vigtigste punkter om BlackLotus og en tidslinje, der opsummerer rækken af begivenheder relateret til det:
- Den er i stand til at køre på de nyeste, fuldt patchede Windows 11-systemer med UEFI Secure Boot aktiveret.
- Det udnytter en mere end et år gammel sårbarhed (CVE-2022-21894) for at omgå UEFI Secure Boot og konfigurere persistens for bootkittet. Dette er den første offentligt kendte, in-the-wild misbrug af denne sårbarhed.
- Selvom sårbarheden blev rettet i Microsofts januar 2022-opdatering, er dens udnyttelse stadig mulig som den berørte, gyldigt underskrevet binære filer er stadig ikke blevet tilføjet til UEFI tilbagekaldelsesliste. BlackLotus udnytter dette og bringer sine egne kopier af legitime – men sårbare – binære filer til systemet for at udnytte sårbarheden.
- Det er i stand til at deaktivere OS-sikkerhedsmekanismer såsom BitLocker, HVCI og Windows Defender.
- Når det først er installeret, er bootkittets hovedmål at implementere en kernedriver (som blandt andet beskytter bootkittet mod fjernelse) og en HTTP-downloader, der er ansvarlig for kommunikationen med C&C og er i stand til at indlæse yderligere brugertilstande eller kernetilstande. .
- BlackLotus er blevet annonceret og solgt på underjordiske fora siden mindst den 6. oktoberth, 2022. I dette blogindlæg præsenterer vi beviser på, at bootkittet er ægte, og at reklamen ikke blot er en fidus.
- Interessant nok fortsætter nogle af de BlackLotus-installationsprogrammer, vi har analyseret, ikke med bootkit-installationen, hvis den kompromitterede vært bruger en af følgende lokaliteter:
- Rumænsk (Moldova), ro-MD
- Russisk (Moldova), ru-MD
- Russisk (Rusland), ru-RU
- Ukrainsk (Ukraine), uk-UA
- Hviderussisk (Hviderusland), be-BY
- Armensk (Armenien), hy-AM
- Kasakhisk (Kasakhstan), kk-KZ
Tidslinjen for individuelle hændelser relateret til BlackLotus er vist i figur 1.
Som allerede nævnt er bootkittet blevet solgt på undergrundsfora siden mindst den 6. oktoberth, 2022. På nuværende tidspunkt har vi ikke været i stand til ud fra vores telemetri at identificere den nøjagtige distributionskanal, der blev brugt til at distribuere bootkittet til ofrene. Det lave antal BlackLotus-prøver, vi har været i stand til at få, både fra offentlige kilder og vores telemetri, får os til at tro, at ikke mange trusselsaktører er begyndt at bruge det endnu. Men indtil tilbagekaldelsen af de sårbare bootloadere, som BlackLotus er afhængig af, sker, er vi bekymrede for, at tingene vil ændre sig hurtigt, hvis dette bootkit kommer i hænderne på de velkendte kriminalitetsgrupper, baseret på bootkittets nemme implementering og kriminalitetsgruppernes muligheder for at sprede sig. malware ved hjælp af deres botnets.
Er dette virkelig BlackLotus?
Der er flere artikler eller indlæg, der opsummerer information om BlackLotus (link., link. , link. og mange flere...), alt sammen baseret på informationen leveret af bootkit-udvikleren på underjordiske hackingfora. Indtil videre har ingen bekræftet eller afkræftet disse påstande.
Her er vores opsummering af påstandene fra de tilgængelige publikationer sammenlignet med det, vi opdagede, mens vi reverse engineering af bootkit-eksemplerne:
- BlackLotus' annonce på hackingfora hævder, at den har integreret Secure Boot bypass. Tilføjelse af sårbare drivere til UEFI-tilbagekaldelseslisten er i øjeblikket umuligt, da sårbarheden påvirker hundredvis af bootloadere, der stadig bruges i dag. ✅
- Sandt nok: Det udnytter CVE-2022-21894 for at bryde Secure Boot og opnå persistens på UEFI-Secure-Boot-aktiverede systemer. Sårbare drivere, som den bruger, er stadig ikke tilbagekaldt i de seneste dbx, i skrivende stund.
- BlackLotus' annonce på hackingfora hævder, at bootkittet har indbygget Ring0/Kernel-beskyttelse mod fjernelse. ✅
- Sandt: Dens kernedriver beskytter håndtag, der tilhører dens filer på EFI System Partition (ESP) mod lukning. Som et ekstra lag af beskyttelse overvåges disse håndtag kontinuerligt, og en Blue Screen Of Death (BSOD) udløses, hvis nogen af disse håndtag lukkes, som beskrevet i Beskytter bootkit-filer på ESP'en mod fjernelse sektion.
- BlackLotus' annonce på hacking-fora hævder, at den kommer med anti-virtuel maskine (anti-VM), anti-debug og kode sløring funktioner til at blokere malware analyse forsøg. ✅
- Sandt: Den indeholder forskellige anti-VM-, anti-debug- og sløringsteknikker for at gøre det sværere at replikere eller analysere. Vi taler dog bestemt ikke om nogen banebrydende eller avancerede antianalyseteknikker her, da de let kan overvindes med en lille indsats.
- BlackLotus' annonce på hackingfora hævder, at dens formål er at fungere som en HTTP-downloader. ✅
- Sandt: Dens sidste komponent fungerer som en HTTP-downloader, som beskrevet i HTTP-downloader sektion
- BlackLotus' annonce på hackingfora hævder, at HTTP-downloaderen kører under SYSTEM-kontoen inden for en lovlig proces. ✅
- Sandt: Dens HTTP-downloader kører inden for winlogon.exe proces kontekst.
- BlackLotus' annonce på hackingfora hævder det et lille bootkit med en diskstørrelse på kun 80 kB. ✅
- Sandt: Prøver, vi var i stand til at opnå, er virkelig omkring 80 kB.
- BlackLotus' annonce på hackingfora hævder, at det kan deaktiver indbyggede Windows-sikkerhedsbeskyttelser såsom HVCI, Bitlocker, Windows Defender og omgå brugerkontokontrol (UAC). ✅
Baseret på disse fakta tror vi med stor tillid til, at det bootkit, vi opdagede i naturen, er BlackLotus UEFI bootkit.
Angrebsoversigt
Et forenklet skema af BlackLotus-kompromiskæden er vist i figur 2. Det består af tre hoveddele:
- Det starter med udførelse af et installationsprogram (trin 1 i figur 2), som er ansvarlig for at installere bootkittets filer til EFI System-partitionen, deaktivere HVCI og BitLocker og derefter genstarte maskinen.
- Efter den første genstart, udnyttelse af CVE-2022-21894 og efterfølgende tilmelding af angribernes Maskine ejer nøgle (MOK) forekommer for at opnå persistens selv på systemer med UEFI Secure Boot aktiveret. Maskinen genstartes derefter (trin 2-4 i figur 2) igen.
- I alle efterfølgende opstarter udføres det selvsignerede UEFI-bootkit og implementerer både dets kernedriver og nyttelast i brugertilstand, HTTP-downloaderen. Sammen er disse komponenter i stand til at downloade og udføre yderligere brugertilstands- og driverkomponenter fra C&C-serveren og beskytte bootkittet mod fjernelse (trin 5-9 i figur 2).
Interessante artefakter
Selvom vi mener, at dette er BlackLotus UEFI bootkit, fandt vi ingen henvisning til dette navn i de prøver, vi analyserede. I stedet er koden fuld af referencer til Higurashi Når de græder anime-serier, for eksempel i individuelle komponentnavne, som f.eks higurashi_installer_uac_module.dll , higurashi_kernel.sys, og også i det selvsignerede certifikat, der bruges til at signere bootkit-binæren (vist i figur 3).
Derudover dekrypterer koden, men bruger aldrig forskellige strenge, der indeholder beskeder fra BlackLotus-forfatteren (som vist i figur 4 – bemærk, at hasherezade er en velkendt forsker og forfatter til forskellige malware-analyseværktøjer), eller blot nogle tilfældige citater fra forskellige sange, spil eller serier.
Installationsproces
Vi starter med analyse af BlackLotus-installatørerne. Bootkittet ser ud til at være distribueret i en form for installatører, der kommer i to versioner - offline og online. Forskellen mellem disse to er den måde, de opnår legitime (men sårbare) Windows-binære filer, senere brugt til at omgå Secure Boot.
- I offlineversioner er Windows-binære filer indlejret i installationsprogrammet
- I onlineversioner downloades Windows-binære filer direkte fra Microsofts symbolbutik. Indtil videre har vi set følgende Windows-binære filer blive misbrugt af BlackLotus bootkit:
- https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
- https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
- https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi
Målet med installationsprogrammet er klart – det er ansvarligt for at deaktivere Windows-sikkerhedsfunktioner såsom BitLocker-diskkryptering og HVCI og for implementering af flere filer, inklusive det ondsindede bootkit, til ESP. Når det er færdigt, genstarter den den kompromitterede maskine for at lade de tabte filer gøre deres arbejde - for at sikre, at det selvsignerede UEFI-bootkit vil blive eksekveret lydløst ved hver systemstart, uanset UEFI Secure Boot-beskyttelsesstatus.
Trin 0 – Initialisering og (potentiel) elevation
Når installationsprogrammet udføres, tjekker det, om det har nok privilegier (i det mindste krævet admin) til at implementere resten af filerne til ESP'en og udføre andre handlinger, der kræver forhøjet proces - som at slukke HVCI eller deaktivere BitLocker. Hvis det ikke er tilfældet, forsøger den at hæve ved at udføre installationsprogrammet igen ved at bruge UAC bypass-metoden beskrevet i detaljer her: UAC bypass via Program Kompatibilitetsassistent.
Med de nødvendige privilegier fortsætter den med at kontrollere UEFI Secure Boot-statussen ved at læse værdien af SecureBoot UEFI-variablen ved hjælp af en tilgængelig Windows API-funktion og bestemme Windows-versionen ved direkte at få adgang til KUSER_SHARED_DATA strukturfelter NtMajorVersion , NtMinorVersion i hukommelsen. Det gør det for at afgøre, om det er nødvendigt at omgå UEFI Secure Boot eller ej for at implementere bootkitten på ofrets system (da Secure Boot-understøttelse først blev tilføjet i Windows 8 og muligvis ikke er aktiveret på en given maskine).
Før du fortsætter til de næste trin, omdøber den den legitime Windows Boot Manager (bootmgfw.efi) binært placeret i ESP:EFIMicrosoftBoot mappe til winload.efi. Dette omdøbt bootmgfw.efi backup bruges senere af bootkittet til at starte operativsystemet eller til at gendanne den originale boot-kæde, hvis kommandoen "uninstall" modtages fra C&C-serveren - mere i C&C kommunikation sektion.
Trin 1 – Installation af filer
Hvis UEFI Secure Boot er aktiveret, fortsætter installationsprogrammet med at slippe flere filer i ESP:/EFI/Microsoft/Boot/ , ESP:/system32/ mapper. Mens førstnævnte er en standardmappe, der bruges af Windows, er sidstnævnte en brugerdefineret mappe oprettet af installationsprogrammet.
En liste over filer droppet af installationsprogrammet med en kort forklaring af hver enkelt fils rolle i udførelseskæden findes i tabel 1. Vi vil forklare detaljeret, hvordan udførelseskæden fungerer senere; Bemærk nu, at flere legitime Microsoft-signerede filer er droppet sammen med de ondsindede.
Tabel 1. Filer installeret af BlackLotus-installationsprogrammet på systemer med UEFI Secure Boot aktiveret
Folder | Filnavn | Beskrivelse |
---|---|---|
ESP:EFIMicrosoftBoot | grubx64.efi | BlackLotus bootkit, ondsindet selvsigneret UEFI-applikation. |
bootload.efi | Legitime Microsoft-signeret shim binært (midlertidigt navn, erstatter senere bootmgfw.efi efter CVE-2022-21894 udnyttelse). | |
bootmgfw.efi | Legitime, men sårbare (CVE-2022-21894) Windows Boot Manager binær, indlejret i installationsprogrammet eller downloadet direkte fra Microsoft Symbol Store. | |
BCD | Angribernes skik Boot Configuration Data (BCD) butik brugt i CVE-2022-21894 udnyttelseskæde. | |
BCDR | Sikkerhedskopiering af offerets originale BCD-butik. | |
ESP:system32 | hvloader.efi | Legitime, men sårbare (CVE-2022-21894) Windows Hypervisor Loader binær, indlejret i et installationsprogram eller downloadet direkte fra Microsoft Symbol Store. |
bootmgr.efi | Legitime, men sårbare (CVE-2022-21894) Windows Boot Manager binær, indlejret i et installationsprogram eller downloadet direkte fra Microsoft Symbol Store. | |
mcupdate_AuthenticAMD.dll | Ondsindet selvsigneret native PE binær. Denne fil udføres af hvloader.efi efter vellykket CVE-2022-21894 udnyttelse (på systemer, der bruger en AMD CPU). | |
mcupdate_GenuineIntel.dll | Ondsindet selvsigneret native PE binær. Denne fil udføres af hvloader.efi efter vellykket CVE-2022-21894 udnyttelse (på systemer, der bruger en Intel CPU). | |
BCD | Angriberes brugerdefinerede BCD brugt i CVE-2022-21894 udnyttelseskæde. |
I tilfælde, hvor offeret kører en Windows-version, der ikke understøtter UEFI Secure Boot, eller i tilfælde, hvor den er deaktiveret, er implementeringen ret ligetil. Det eneste, der er nødvendigt for at implementere det ondsindede bootkit, er at erstatte den eksisterende Windows Boot Manager (bootmgfw.efi) binær i ESP:EFIMicrosoftBoot mappe med angribernes egen selvsignerede ondsindede UEFI-applikation. Da UEFI Secure Boot er deaktiveret (og der derfor ikke udføres integritetsverifikation under opstarten), er udnyttelse ikke nødvendig, og UEFI-firmwaren udfører simpelthen den ondsindede opstartsmanager uden at forårsage sikkerhedsbrud.
Trin 2 – Deaktivering af Hypervisor-beskyttet kodeintegritet (HVCI)
For at kunne køre tilpasset usigneret kernekode senere, skal installationsprogrammet sørge for det HVCI er deaktiveret på systemet. En af vores ESET-kolleger skrev et meget informativt blogindlæg om dette emne i 2022 (Signerede kernedrivere – Ubevogtet gateway til Windows' kerne):
Virtualiseringsbaseret sikkerhed (VBS) tilbyder adskillige beskyttelsesfunktioner, hvor den mest fremtrædende er Hypervisor-Protected Code Integrity (HVCI), som også kommer som en selvstændig funktion. HVCI håndhæver kodeintegritet i kernen og tillader kun signeret kode at blive eksekveret. Det forhindrer effektivt sårbare drivere i at blive misbrugt til at udføre usigneret kernekode eller indlæse ondsindede drivere (uanset den anvendte udnyttelsesmetode), og det ser ud til, at malware misbruger sårbare drivere til at indlæse ondsindet kode var en af de hovedmotivationerne bag Microsofts implementering af denne funktion.
Som vist i figur 5, for at deaktivere denne funktion, indstiller installationsprogrammet værdien Aktiveret registreringsdatabasen under HypervisorEnforcedCodeIntegrity registreringsdatabasenøgle til nul.
Trin 3 – Deaktivering af BitLocker
Den næste funktion deaktiveret af installatøren er BitLocker Drive Encryption. Grunden til dette er, at BitLocker kan bruges i kombination med Trusted Platform Module (TPM) for at sikre, at forskellige opstartsfiler og konfigurationer, inklusive sikker opstart, ikke er blevet manipuleret, siden BitLocker-drevkryptering blev konfigureret på systemet. I betragtning af, at installationsprogrammet ændrer Windows-startkæden på en kompromitteret maskine, vil det at holde BitLocker tændt for systemer med TPM-understøttelse føre til en BitLocker-gendannelsesskærm ved næste opstart og ville tippe offeret om, at systemet var blevet kompromitteret.
For at deaktivere denne beskyttelse skal BlackLotus-installationsprogrammet:
- går gennem alle bind under RootCIMV2SecurityMicrosoftVolumeEncryption WMI-navneområde og kontrollerer deres beskyttelsesstatus ved at ringe til GetProtectionStatus metode af Win32_EncryptableVolume WMI klasse
- for dem, der er beskyttet af BitLocker, kalder det DisableKeyProtectors metode med DisableCount parameter sat til nul, hvilket betyder, at beskyttelsen vil blive suspenderet, indtil den aktiveres manuelt
Med de nødvendige beskyttelser deaktiveret og alle filer installeret, registrerer installationsprogrammet sig for at blive slettet ved næste systemgenstart og genstarter maskinen for at fortsætte med at udnytte CVE-2022-21894.
Omgå Secure Boot og etablere persistens
I denne del ser vi nærmere på, hvordan BlackLotus opnår persistens på systemer med UEFI Secure Boot aktiveret. Da den udførelseskæde, vi er ved at beskrive, er ret kompleks, vil vi først forklare grundlæggende principper og derefter grave dybere ned i tekniske detaljer.
I en nøddeskal består denne proces af to nøgletrin:
- Udnytter CVE-2022-21894 til at omgå funktionen Secure Boot og installere bootkittet. Dette muliggør eksekvering af vilkårlig kode i tidlige opstartsfaser, hvor platformen stadig ejes af firmware og UEFI Boot Services-funktioner stadig er tilgængelige. Dette gør det muligt for angribere at gøre mange ting, som de ikke burde være i stand til at gøre på en maskine med UEFI Secure Boot aktiveret uden at have fysisk adgang til det, såsom at ændre NVRAM-variabler, der kun er opstartstjenester. Og det er det, angribere udnytter til at konfigurere persistens til bootkittet i næste trin. Mere information om udnyttelse kan findes i Udnytter CVE-2022-21894 sektion.
- Indstille persistens ved at skrive sin egen MOK til MokList, Boot-services-only NVRAM-variabel. Ved at gøre dette kan den bruge en legitim Microsoft-signeret shim for at indlæse dens selvsignerede (underskrevet af den private nøgle, der hører til den nøgle, der er skrevet til MokList) UEFI bootkit i stedet for at udnytte sårbarheden ved hver boot. Mere om dette i Bootkit vedholdenhed sektion.
For at gøre den detaljerede analyse i de næste to afsnit lettere, vil vi følge trinene vist i udførelsesdiagrammet, figur 6.
Udnytter CVE-2022-21894
For at omgå Secure Boot bruger BlackLotus Baton drop (CVE-2022-21894): Secure Boot Security Feature Bypass sårbarhed. På trods af dens høje indvirkning på systemsikkerheden, fik denne sårbarhed ikke så meget offentlig opmærksomhed, som den fortjente. Selvom sårbarheden blev rettet i Microsofts januar 2022-opdatering, er dens udnyttelse stadig mulig, fordi de berørte binære filer stadig ikke er blevet tilføjet til UEFI tilbagekaldelsesliste. Som et resultat kan angribere bringe deres egne kopier af sårbare binære filer til deres ofres maskiner for at udnytte denne sårbarhed og omgå Secure Boot på opdaterede UEFI-systemer.
Desuden har en Proof of Concept (PoC) udnyttelse af denne sårbarhed været offentlig tilgængelig siden august 2022. I betragtning af datoen for den første BlackLotus VirusTotal-indsendelse (se figur 1), har malware-udvikleren sandsynligvis lige tilpasset den tilgængelige PoC til deres behov uden at ethvert behov for dyb forståelse af, hvordan denne udnyttelse fungerer.
Lad os starte med en kort introduktion til sårbarheden, der for det meste opsummerer de vigtigste punkter fra den opskrivning, der er offentliggjort sammen med PoC på GitHub:
- Berørte Windows Boot-programmer (såsom bootmgr.efi, hvloader.efi, winload.efi…) tillade fjernelse af en serialiseret Secure Boot-politik fra hukommelsen – før den bliver indlæst af applikationen – ved at bruge afkortehukommelse BCD boot mulighed.
- Dette giver angribere mulighed for at bruge andre farlige BCD-muligheder som bootdebug, testsignering eller nointegritychecks, og dermed bryder Secure Boot.
- Der er forskellige måder at udnytte denne sårbarhed på – tre af dem er offentliggjort i PoC-lageret.
- Som et eksempel viser en af PoC'erne, hvordan den kan udnyttes til at gøre det legitime hvloader.efi indlæse en vilkårlig, selvsigneret mcupdate_ .dll binær (hvor kan være Ægte Intel or AutentiskAMD, baseret på maskinens CPU).
Nu fortsætter vi med at beskrive, hvordan BlackLotus udnytter denne sårbarhed (tallene på listen nedenfor beskriver de tilsvarende trin i figur 6):
- Efter at installationsprogrammet har genstartet maskinen, fortsætter UEFI-firmwaren med at indlæse en første opstartsmulighed. For Windows-systemer er den første opstartsmulighed som standard bootmgfw.efi placeret i ESP:/EFI/Microsoft/Boot mappe på ESP. Denne gang i stedet for at henrette det oprindelige offers bootmgfw.efi (som tidligere blev omdøbt winload.efi af installationsprogrammet), udfører firmwaren den sårbare - implementeret af installationsprogrammet.
- Efter bootmgfw.efi udføres, indlæser den BCD-opstartsindstillingerne, som tidligere er blevet ændret af installationsprogrammet. Figur 7 viser en sammenligning af den legitime BCD og den modificerede.
- Som du kan se i figur 7 (sti understreget med grønt), vil den legitime Windows Boot Manager normalt indlæse Windows OS-indlæseren (WINDOWSsystem32winload.efi) som et standard bootprogram. Men denne gang, med den modificerede BCD, fortsætter det med at indlæse de sårbare ESP:system32bootmgr.efi, med undgå lav hukommelse BCD-element sat til værdi 0x10000000 og brugerdefineret: 22000023 BCD-element, der peger på en anden angriberes BCD gemt i ESP:system32bcd. Forklaringen på brugen af disse elementer kan findes i den offentliggjorte PoC:
Angriberen skal sikre, at den serialiserede Secure Boot Policy er tildelt over en kendt fysisk adresse.
[...]
undgå lav hukommelse element kan bruges til at sikre, at alle allokeringer af fysisk hukommelse er over en specificeret fysisk adresse.
• Siden Windows 10 er dette element ikke tilladt, hvis VBS er aktiveret, men da det bruges under initialisering af opstartsapplikationen, før den serialiserede Secure Boot-politik læses fra hukommelsen, indlæses Bootmgr og specificering af en brugerdefineret BCD-sti (ved hjælp af bcdfilepath element aka brugerdefineret: 22000023) kan bruges til at omgå dette.
- I næste trin, den henrettede ESP:system32bootmgr.efi indlæser den ekstra BCD placeret i ESP:system32bcd. Det analyserede indhold af denne ekstra BCD er vist i figur 8.
- På grund af muligheder indlæst fra BCD-filen vist i figur 8, bootmgr.efi fortsætter med at indlæse et andet sårbart Windows Boot Application installeret af installationsprogrammet – ESP:system32hvloader.efi – som er Windows Hypervisor Loader. Endnu vigtigere er yderligere BCD-indstillinger angivet i den samme BCD-fil (se figur 8):
- afkortehukommelse med værdi sat til 0x10000000
- nointegritychecks indstillet til Ja
- , testsignering, også indstillet til Ja
Og det er her, magien sker. Da den serialiserede Secure Boot-politik skal indlæses i fysiske adresser ovenfor 0x10000000 (på grund af undgå lav hukommelse brugt i tidligere trin), med angivelse af afkortehukommelse element vil effektivt fjerne det - således bryde den sikre boot og tillade brugen af farlige BCD-indstillinger som nointegritychecks or testsignering. Ved at bruge disse muligheder kan angriberne lave hvloader.efi udføre deres egen, selvsignerede kode.
- For at gøre dette, det samme trick som beskrevet i PoC bruges: under dens udførelse, det legitime hvloader.efi indlæser og udfører mcupdate_{GenuineIntel| AuthenticAMD}.dll native binære fra : system 32 vejviser. Kommenterede Hex-Rays dekompileret kode af funktionen fra hvloader.efi ansvarlig for at indlæse denne mcupdate*.dll binær er vist i figur 9. Bemærk at hvloader.efi ville normalt indlæse dette legitimt mcupdate*.dll binær fra:Windowssystem32, men denne gang underskrev de ondsindede angribere sig selv mcupdate*.dll udføres fra en brugerdefineret ESP-mappe, som tidligere er oprettet af installationsprogrammet (ESP:system32). Det er forårsaget af BCD-indstillingerne enhed , systemrod brugt i BCD'en fra figur 8, der angiver den aktuelle enhed som båd – hvilket betyder ESP – og også angive SystemRoot til at være roden () bibliotek på denne enhed.
- Nu, som angribernes egen signatur mcupdate*.dll er indlæst og eksekveret, fortsætter den med at udføre den sidste komponent i denne kæde – en indlejret MokInstaller (UEFI Application) – se figur 10 for detaljer om, hvordan det gøres.
Bootkit vedholdenhed
Nu kan MokInstaller fortsætte med at konfigurere persistens ved at tilmelde angribernes MOK i NVRAM-variablen og opsætte den legitime Microsoft-signerede shim binær som standard bootloader. Før du går videre til detaljer, lidt teori om shim og MOK.
shim er en første trins UEFI bootloader udviklet af Linux-udviklere til at få forskellige Linux-distributioner til at fungere med UEFI Secure Boot. Det er en simpel applikation, og dens formål er at indlæse, verificere og udføre en anden applikation – i tilfælde af Linux-systemer er det normalt GRUB bootloaderen. Det fungerer på en måde, som Microsoft kun underskriver en shim, og shim tager sig af resten - den kan verificere integriteten af en anden-trins bootloader ved at bruge nøgler fra db UEFI-variabel, og indlejrer også sin egen liste over "tilladte" eller "tilbagekaldte" nøgler eller hashes for at sikre, at komponenter, der er tillid til af begge – platform og shim-udvikler (f.eks. Canonical, RedHat, osv.) – får lov til at blive eksekveret. Ud over disse lister, shim tillader også brugen af en ekstern nøgledatabase, der administreres af brugeren, kendt som MOK-listen. Figur 11 illustrerer fint, hvordan UEFI Secure Boot med MOK fungerer.
Denne MOK-database er gemt i en NVRAM-variabel med navnet Boot-only MokList. Uden at udnytte en sårbarhed som den, der er beskrevet ovenfor, kræves der fysisk adgang for at ændre den på et system med UEFI Secure Boot aktiveret (det er kun tilgængeligt under opstart, før OS-indlæseren kalder UEFI Boot Services-funktionen ExitBootServices). Men ved at udnytte denne sårbarhed er angribere i stand til at omgå UEFI Secure Boot og udføre deres egen selvsignerede kode før et opkald til ExitBootServices, så de nemt kan tilmelde deres egen nøgle (ved at ændre MokList NVRAM-variabel) for at få shim'en til at udføre enhver applikation - underskrevet af den tilmeldte nøgle - uden at forårsage en sikkerhedsovertrædelse.
- Fortsætter med at beskrive flowet fra figur 6 – trin 8... MokInstaller UEFI-applikationen fortsætter med at konfigurere persistens for BlackLotus UEFI bootkit og dækker udnyttelsessporene ved:
- Gendannelse af ofrets originale BCD-lager fra den sikkerhedskopi, der blev oprettet af installationsprogrammet og udskiftning af efi'en med det legitime Microsoft-signerede shim, som tidligere er faldet til ESP:system32bootload.efi af installatøren.
- Oprettelse af en MokList NVRAM-variabel, der indeholder angriberens selvsignerede offentlige nøglecertifikat. Bemærk, at denne variabel er formateret på samme måde som alle andre UEFI-signaturdatabasevariabler (såsom db eller dbx), og den kan bestå af nul eller flere signaturlister af typen EFI_SIGNATURE_LIST – som defineret i UEFI-specifikationen.
- Sletning af alle filer involveret i udnyttelse fra angribernes ESP:system32 mappe.
- I sidste ende genstarter den maskinen for at få det installerede shim til at udføre det selvsignerede bootkit droppet til EFIMicrosoftBootgrubx64.efi af installatøren (grubx64.efi er normalt anden-trins bootloader som standard, der udføres af en shim på x86-64-systemer).
Koden, der udfører handlingerne beskrevet i de sidste to trin, er vist i figur 12.
BlackLotus UEFI bootkit
Når persistensen er konfigureret, udføres BlackLotus bootkit ved hver systemstart. Bootkittets mål er at implementere en kernedriver og en endelig brugertilstandskomponent – HTTP-downloaderen. Under udførelsen forsøger den at deaktivere yderligere Windows-sikkerhedsfunktioner – Virtualization-Based Security (VBS) og Windows Defender – for at øge chancen for vellykket implementering og snigende drift. Før vi hopper til detaljerne om, hvordan det gøres, lad os opsummere det grundlæggende om kernedriveren og HTTP-downloaderen:
- Kernedriveren er ansvarlig for
- Implementering af den næste komponent i kæden - en HTTP-downloader.
- Holde læsseren i live i tilfælde af opsigelse.
- Beskytter bootkit-filer mod at blive fjernet fra ESP.
- Udførelse af yderligere kernenyttelast, hvis det bliver instrueret af HTTP-downloaderen.
- Afinstallation af bootkittet, hvis det bliver instrueret af HTTP-downloaderen.
- HTTP-downloaderen er ansvarlig for:
- Kommunikerer med sin C&C.
- Udførelse af kommandoer modtaget fra C&C.
- Download og eksekvering af nyttelaster modtaget fra C&C (understøtter både kerne-nyttelaster og brugertilstande).
Det fulde udførelsesflow (forenklet), fra installationsprogrammet til HTTP-downloaderen, er vist i figur 13. Vi beskriver disse individuelle trin mere detaljeret i næste afsnit.
BlackLotus udførelsesflow
Udførelsestrinene er som følger (disse trin er vist i figur 13):
- Som et første trin udfører UEFI-firmwaren Windows-standardopstartsindstillingen, som er den fil, der normalt gemmes i EFIMicrosoftBootbootmgfw.efi. Som vi har beskrevet tidligere (Bootkit persistens sektion, 8 .a), erstattede MokInstaller-binæren denne fil med en legitim signeret shim.
- Når shim er udført, lyder det MokList NVRAM-variabel, og bruger det certifikat, der tidligere er gemt inde af angriberne til at verificere bootloaderen i andet trin – det selvsignerede BlackLotus UEFI-bootkit, der er placeret i EFIMicrosoftBootgrubx64.efi.
- Når den er verificeret shim udfører bootkittet.
- Bootkittet starter med at oprette Boot-only VbsPolicyDisable NVRAM variabel. Som beskrevet link., evalueres denne variabel af Windows OS-indlæseren under opstart, og hvis den er defineret, vil kerne-VBS-funktionerne, såsom HVCI og Credential Guard, ikke blive initialiseret.
- I de følgende trin (5. a–e) fortsætter bootkittet med et almindeligt mønster, der bruges af UEFI bootkits. Den opsnapper udførelsen af komponenter, der er inkluderet i det typiske Windows boot flow, såsom Windows Boot Manager, Windows OS loader og Windows OS kerne, og kobler nogle af deres funktioner i hukommelsen. Som en bonus forsøger den også at deaktivere Windows Defender ved at patche nogle af dens drivere. Alt dette for at opnå dens nyttelasts eksekvering i de tidlige stadier af OS-startprocessen og for at undgå detektion. Følgende funktioner er tilsluttet eller lappet:
- ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
Denne funktion er almindeligvis tilsluttet af bootkits for at fange det øjeblik, hvor Windows OS loader (winload.efi) er indlæst i hukommelsen, men er stadig ikke blevet udført – hvilket er det rigtige tidspunkt til at udføre mere patching i hukommelsen. - BlImgAllocateImageBuffer in winload.efi:
Bruges til at allokere en ekstra hukommelsesbuffer til den ondsindede kernedriver. - OslArchTransferToKernel in winload.efi:
Hooked for at fange det øjeblik, hvor OS-kernen og nogle af systemdriverne allerede er indlæst i hukommelsen, men stadig ikke er blevet udført – hvilket er et perfekt øjeblik til at udføre mere in-memory patching. Driverne nævnt nedenfor er lappet i denne krog. Koden fra denne krog, der er ansvarlig for at finde passende drivere i hukommelsen, er vist i figur 14. - WdBoot.sys , WdFilter.sys:
BlackLotus patcher indgangspunktet for WdBoot.sys , WdFilter.sys – henholdsvis Windows Defender ELAM-driveren og Windows Defender-filsystemfilterdriveren – for at vende tilbage med det samme. - disk.sys:
Bootkittet kroger indgangspunktet for disk.sys driver til at udføre BlackLotus-kernedriveren i de tidlige stadier af systeminitialisering.
- ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
- Dernæst, når OS-kernen udfører disk.sys driverens indgangspunkt, hopper den installerede hook til det ondsindede kernedriverindgangspunkt. Den ondsindede kode gendanner til gengæld originalen disk.sys for at lade systemet fungere korrekt og venter indtil winlogon.exe processen starter.
- Når den ondsindede driver registrerer, at winlogon.exe processen er startet, indsætter og udfører den den endelige brugertilstandskomponent – HTTP-downloaderen – ind i den.
Kernel driver
Kernedriveren er ansvarlig for fire hovedopgaver:
- Injicerer HTTP-downloaderen i winlogon.exe og genindsprøjte det, hvis tråden afsluttes.
- Beskytter bootkit-filer, der er installeret på ESP'en, mod at blive fjernet.
- Deaktivering af Windows Defender-processen i brugertilstand MsMpEngine.exe.
- Kommunikere med HTTP-downloaderen og om nødvendigt udføre eventuelle kommandoer.
Lad os se på dem én efter én.
HTTP-downloader persistens
Kernedriveren er ansvarlig for implementeringen af HTTP-downloaderen. Når driveren starter, venter den, indtil processen er navngivet winlogon.exe starter, før der foretages andre handlinger. Når processen er startet, dekrypterer driveren HTTP-downloaderens binære, injicerer den i winlogon.exe's adresserum, og udfører det i en ny tråd. Derefter fortsætter føreren med jævne mellemrum at kontrollere, om tråden stadig kører, og gentager injektionen, hvis det er nødvendigt. HTTP-downloaderen vil ikke blive implementeret, hvis en kerne-debugger registreres af driveren.
Beskytter bootkit-filer på ESP'en mod fjernelse
For at beskytte bootkittets filer placeret på ESP'en bruger kernedriveren et simpelt trick. Den åbner alle filer, den ønsker at beskytte, duplikerer og gemmer deres håndtag og bruger ObSetHandleAttributes kernefunktion, der specificerer Beskyt FraLuk flag indeni Håndtag Flag (OBJECT_HANDLE_FLAG_INFORMATION) parameter til 1 – hvilket beskytter håndtagene mod at blive lukket af andre processer. Dette vil forhindre ethvert forsøg på at fjerne eller ændre de beskyttede filer. Følgende filer er beskyttet:
- ESP:EFIMicrosoftBootwinload.efi
- ESP:EFIMicrosoftBootbootmgfw.efi
- ESP:EFIMicrosoftBootgrubx64.efi
Skulle en bruger forsøge at slette disse beskyttede filer, vil noget i stil med det, der er vist i figur 15, forekomme.
Som et andet beskyttelseslag, hvis brugeren eller sikkerhedssoftwaren ville være i stand til at frakoble beskyttelsesflaget og lukke håndtagene, overvåger kernedriveren dem løbende og forårsager en BSOD ved at kalde KeBugCheck(INVALID_KERNEL_HANDLE) funktion, hvis nogen af håndtagene ikke eksisterer længere.
Deaktivering af den primære Windows Defender-proces
Kernedriveren forsøger også at deaktivere den primære Windows Defender-proces – MsMpEng.exe. Det gør det ved at fjerne alle processens token-privilegier ved at indstille SE_PRIVILEGE_REMOVED kendetegner hver af dem. Som et resultat heraf burde Defender-processen ikke være i stand til at udføre sit arbejde - såsom at scanne filer - korrekt. Men da denne funktionalitet er dårligt implementeret, kan den gøres ineffektiv ved at genstarte MsMpEng.exe proces.
Kommunikation med HTTP-downloaderen
Kernedriveren er i stand til at kommunikere med HTTP-downloaderen ved at bruge en navngivet begivenhed og sektion. Navne på de navngivne objekter, der bruges, genereres baseret på ofrets MAC-adresse for netværksadapter (ethernet). Hvis værdien af en oktet er lavere end 16, lægges 16 til den. Formatet på de genererede objektnavne kan variere i forskellige eksempler. Som et eksempel, i en af de prøver, vi analyserede, for MAC-adressen 00-1c-0b-cd-ef-34, ville de genererede navne være:
- BaseNamedObjects101c1b: for den navngivne sektion (kun de første tre oktetter af MAC'en bruges)
- BaseNamedObjectsZ01c1b: for den navngivne begivenhed – samme som for sektionen, men det første ciffer i MAC-adressen erstattes med Z
I tilfælde af at HTTP-downloaderen ønsker at sende en kommando til kernedriveren, opretter den blot en navngivet sektion, skriver en kommando med tilhørende data inde og venter på, at kommandoen behandles af driveren ved at oprette en navngivet hændelse og vente indtil driveren udløser (eller signalerer) det.
Driveren understøtter følgende selvforklarende kommandoer:
- Installer kernel driver
- Afinstaller BlackLotus
En omhyggelig læser vil måske bemærke BlackLotus svage punkt her – selvom bootkitten beskytter dets komponenter mod fjernelse, kan kernedriveren narre til at afinstallere bootkitten fuldstændigt ved at oprette de ovennævnte navngivne objekter og sende afinstallationskommandoen til den.
HTTP-downloader
Den sidste komponent er ansvarlig for kommunikation med en C&C-server og udførelse af eventuelle C&C-kommandoer modtaget fra den. Alle nyttelaster, vi var i stand til at opdage, indeholder tre kommandoer. Disse kommandoer er meget ligetil, og som afsnitsnavnet antyder, handler det mest om at downloade og udføre yderligere nyttelast ved hjælp af forskellige teknikker.
C&C kommunikation
For at kommunikere med sin C&C bruger HTTP-indlæseren HTTPS-protokollen. Al information, der er nødvendig for kommunikationen, er indlejret direkte i downloaderens binære filer – inklusive C&C-domæner og anvendte HTTP-ressourcestier. Standardintervallet for kommunikation med en C&C-server er sat til et minut, men kan ændres baseret på data fra C&C. Hver kommunikationssession med en C&C starter med at sende en beacon HTTP POST-meddelelse til den. I prøver, vi analyserede, kan følgende HTTP-ressourcestier specificeres i HTTP POST-headerne:
- /netværk/API/hpb_gate[.]php
- /API/hpb_gate[.]php
- /gate[.]php
- /hpb_gate[.]php
Beacon-meddelelsesdataene er foranstillet med en checkin= streng, der indeholder grundlæggende oplysninger om den kompromitterede maskine – inklusive en brugerdefineret maskin-id (omtalt som hwid), UEFI Secure Boot-status, forskellige hardwareoplysninger og en værdi, der ser ud til at være et BlackLotus build-nummer. hwid genereres fra maskinens MAC-adresse (ethernet) og et systemvolumens serienummer. Formatet af meddelelsen før kryptering er som vist i figur 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ “HWID”:“%s”, “Session”:“%lu”, “Owner”:“%s”, “IP”:“%s”, “OS”:“%s”, “Edition”:“%s”, “CPU”:“%s”, “GPU”:“%s”, “RAM”:“%lu”, “Integrity”:“%lu”, “SecureBoot”:“%i”, “Build”:“%lu” } |
Figur 16. Format for beacon-meddelelse
Før meddelelsen sendes til C&C, krypteres dataene først ved hjælp af en indlejret RSA-nøgle, derefter URL-safe base64-kodet. Under analysen fandt vi to forskellige RSA-nøgler, der blev brugt i prøverne. Et eksempel på en sådan HTTP-beacon-anmodning er vist i figur 17.
Data modtaget fra C&C som et svar på beacon-meddelelsen bør starte med den to-byte magiske værdi HP; ellers behandles svaret ikke yderligere. Hvis den magiske værdi er korrekt, dekrypteres dataene efter den magiske værdi ved hjælp af 256-bit AES i CBC-tilstand med ovennævnte HWID-streng brugt som nøglen.
Efter dekryptering ligner meddelelsen beaconen, en JSON-formateret streng, og angiver en kommando-id (omtalt som Type) og forskellige yderligere parametre såsom:
- C&C kommunikationsinterval
- Udførelsesmetode at bruge
- Nyttelast filnavn
- Nyttelasttype baseret på filtypenavn(Sys, .exe eller . Dll understøttet)
- Godkendelsestoken, der formodes at blive brugt til at anmode om download af nyttelastdata
- AES-nøgle bruges til at dekryptere nyttelastdata
Alle understøttede kommandoer og deres beskrivelser er angivet i tabel 2.
Tabel 2. C&C-kommandoer
Kommandotype | Kommandobeskrivelse |
---|---|
1 | Download og kør en kernedriver, DLL eller en almindelig eksekverbar |
2 | Download en nyttelast, afinstaller bootkittet, og udfør nyttelasten - sandsynligvis brugt til at opdatere bootkittet |
3 | Afinstaller bootkittet og afslut |
I disse kommandoer kan C&C angive, om nyttelasten først skal slippes til disken, før den udføres, eller udføres direkte i hukommelsen. I tilfælde, der involverer at slippe filen til disken, kan ProgramData mappe på OS-diskenheden bruges som destinationsmappe, og filnavn og udvidelse er angivet af C&C-serveren. I tilfælde af at udføre filer direkte i hukommelsen, svchost.exe bruges som et injektionsmål. Når C&C sender en kommando, der kræver kernedriversamarbejde, eller en operatør ønsker at udføre kode i kernetilstand, vil mekanismen beskrevet i Kommunikation med HTTP-downloaderen afsnit bruges.
Anti-analyse tricks
For at gøre detektion og analyse af dette stykke malware sværere, forsøgte dets forfatter at begrænse synligheden af standardfilartefakter, såsom tekststrenge, importer eller andre ukrypterede indlejrede data til et minimum. Nedenfor er en oversigt over de anvendte teknikker.
- String og datakryptering
- Alle strenge, der bruges i prøverne, er krypteret ved hjælp af en simpel chiffer.
- Alle indlejrede filer er krypteret med 256-bit AES i CBC-tilstand.
- Krypteringsnøgler til individuelle filer kan variere fra prøve til prøve.
- Ud over AES-kryptering komprimeres nogle filer også ved hjælp af LZMS.
- API-opløsning kun køretid
- I alle eksempler (hvis relevant), løses Windows API'er altid udelukkende under kørsel, og funktions-hash i stedet for funktionsnavne bruges til at finde de ønskede API-funktionsadresser i hukommelsen.
- I nogle tilfælde en direkte syscall instruktionskald bruges til at påkalde den ønskede systemfunktion.
- Netværkskommunikation
- Kommunikerer ved hjælp af HTTPS.
- Alle meddelelser sendt til C&C af HTTP-downloaderen er krypteret ved hjælp af en indlejret RSA offentlig nøgle.
- Alle meddelelser, der sendes fra C&C til HTTP-downloaderen, er krypteret ved hjælp af en nøgle, der stammer fra ofrets maskinmiljø eller ved hjælp af en AES-nøgle leveret af C&C.
- Anti-debug og anti-VM tricks – hvis de bruges, placeres de normalt lige i begyndelsen af indgangspunktet. Der bruges kun afslappede sandkasse- eller debuggerdetektionstricks.
Afhjælpning og afhjælpning
- Først og fremmest er det selvfølgelig et must at holde dit system og dets sikkerhedsprodukt opdateret – for at øge en chance for, at en trussel vil blive stoppet lige i begyndelsen, før den er i stand til at opnå præ-OS vedholdenhed.
- Derefter er det vigtigste skridt, der skal tages for at forhindre brug af kendte sårbare UEFI-binære filer til at omgå UEFI Secure Boot, deres tilbagekaldelse i UEFI-tilbagekaldelsesdatabasen (dbx) – på et Windows-system, dbx opdateringer skal distribueres ved hjælp af Windows Updates.
- Problemet er, at tilbagekaldelse af meget brugte Windows UEFI-binære filer kan føre til at gøre tusindvis af forældede systemer, gendannelsesbilleder eller sikkerhedskopier ustartbare - og derfor tager tilbagekaldelsen ofte for lang tid.
- Bemærk, at tilbagekaldelse af de Windows-applikationer, der bruges af BlackLotus, ville forhindre installation af bootkittet, men da installationsprogrammet ville erstatte offerets bootloader med den tilbagekaldte, kunne det gøre systemet ustartbart. For at gendanne i dette tilfælde vil en OS-geninstallation eller blot ESP-gendannelse løse problemet.
- Hvis tilbagekaldelsen ville ske, efter at BlackLotus persistens er indstillet, ville bootkittet forblive funktionelt, da det bruger et legitimt shim med tilpasset MOK-nøgle til persistens. I dette tilfælde ville den sikreste afhjælpningsløsning være at geninstallere Windows og fjerne angribernes tilmeldte MOK-nøgle ved at bruge mokutil utility (fysisk tilstedeværelse er påkrævet for at udføre denne handling på grund af nødvendig brugerinteraktion med MOK Manager under opstart).
Takeaways
Mange kritiske sårbarheder, der påvirker sikkerheden af UEFI-systemer, er blevet opdaget i de sidste par år. På grund af kompleksiteten af hele UEFI-økosystemet og relaterede forsyningskædeproblemer har mange af disse sårbarheder desværre efterladt mange systemer sårbare, selv lang tid efter, at sårbarhederne er blevet rettet - eller i det mindste efter at vi fik at vide, at de blev rettet. For et bedre billede er her nogle eksempler på patch- eller tilbagekaldelsesfejl, der tillader UEFI Secure Boot-omgåelser lige fra det sidste år:
- Først og fremmest, selvfølgelig, CVE-2022-21894 – sårbarheden, der udnyttes af BlackLotus. Et år siden sårbarheden blev rettet, er sårbare UEFI-binære filer stadig ikke tilbagekaldt, hvilket gør det muligt for trusler som BlackLotus snigende at fungere på systemer med UEFI Secure Boot aktiveret, hvilket giver ofrene en falsk følelse af sikkerhed.
- Tidligt i 2022 afslørede vi adskillige UEFI-sårbarheder, der blandt andet gør det muligt at deaktivere UEFI Secure Boot. Mange berørte enheder understøttes ikke længere af OEM, og er derfor ikke rettet (selvom disse enheder ikke var så gamle - f.eks. 3-5 år på tidspunktet for afsløring af sårbarhed). Læs mere i vores blogindlæg: Når "sikker" slet ikke er sikker: Storslåede UEFI-sårbarheder opdaget i Lenovos bærbare computere
- Senere i 2022 opdagede vi en få andre UEFI-sårbarheder, hvis udnyttelse også ville gøre det muligt for angribere at deaktivere UEFI Secure Boot meget nemt. Som påpeget af medforskere fra Binært, flere enheder, der er angivet i rådgivende blev efterladt uden opdatering eller ikke lappet korrekt, selv få måneder efter rådgivningen - hvilket efterlod enhederne sårbare. Det er overflødigt at sige, at i lighed med det tidligere tilfælde vil nogle enheder forblive sårbare for evigt, da de har nået deres Slut-Of-Support-dato.
Det var bare et spørgsmål om tid, før nogen ville drage fordel af disse fejl og skabe et UEFI-bootkit, der kunne fungere på systemer med UEFI Secure Boot aktiveret. Som vi foreslog sidste år i vores RSA præsentation, alt dette gør overgangen til ESP mere gennemførlig for angribere og en mulig vej frem for UEFI-trusler – eksistensen af BlackLotus bekræfter dette.
IoC'er
Filer
SHA-1 | Filnavn | Detektion | Beskrivelse |
---|---|---|---|
05846D5B1D37EE2D716140DE4F4F984CF1E631D1 | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
A5A530A91100ED5F07A5D74698B15C646DD44E16 | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
D82539BFC2CC7CB504BE74AC74DF696B13DB486A | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
16B12CEA54360AA42E1120E82C1E9BC0371CB635 | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
45701A83DEC1DC71A48268C9D6D205F31D9E7FFB | N / A | Win64/BlackLotus.A | BlackLotus installationsprogram. |
2CE056AE323B0380B0E87225EA0AE087A33CD316 | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
5A0074203ABD5DEB464BA0A79E14B7541A033216 | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
5DC9CBD75ABD830E83641A0265BFFDDD2F602815 | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
97AEC21042DF47D39AC212761729C6BE484D064D | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
ADCEEC18FF009BED635D168E0B116E72096F18D2 | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
DBC064F757C69EC43517EFF496146B43CBA949D1 | N / A | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
0C0E78BF97116E781DDE0E00A1CD0C29E68D623D | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
74FF58FCE8F19083D16DF0109DC91D78C94342FA | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6 | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
111C4998F3264617A7A9D9BF662D4B1577445B20 | N / A | Win64/BlackLotus.B | BlackLotus HTTP-downloader. |
17FA047C1F979B180644906FE9265F21AF5B0509 | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
1F3799FED3CF43254FE30DCDFDB8DC02D82E662B | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
4B882748FAF2C6C360884C6812DD5BCBCE75EBFF | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
91F832F46E4C38ECC9335460D46F6F71352CFFED | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
994DC79255AEB662A672A1814280DE73D405617A | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
FFF4F28287677CAABC60C8AB36786C370226588D | N / A | Win64/BlackLotus.C | BlackLotus kernel driver. |
71559C3E2F3950D4EE016F24CA54DA17D28B9D82 | N / A | EFI/BlackLotus.C | BlackLotus Boot Configuration Data (BCD) lager droppet af BlackLotus-installationsprogrammet. |
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 | N / A | EFI/BlackLotus.C | BlackLotus Boot Configuration Data (BCD) lager droppet af BlackLotus-installationsprogrammet. |
547FAA2D64B85BF883955B723B07635C0A09326B | N / A | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 nyttelastindlæser. |
D1BBAA3D408E944C70B3815471EED7FA9AEE6425 | N / A | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 nyttelastindlæser. |
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB | N / A | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 udnyttelsesnyttelast – MokInstaller EFI-app. |
D6BB89D8734B3E49725362DAE9A868AE681E8BD6 | N / A | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 udnyttelsesnyttelast – MokInstaller EFI-app. |
164BB587109CFB20824303AD1609A65ABB36C3E9 | N / A | Win64/BlackLotus.D | BlackLotus Installer UAC bypass-modul. |
Certifikater
Serienummer | 570B5D22B723B4A442CC6EEEBC2580E8 |
Tommelfingerprint | C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 |
Emne CN | Når de græder CA |
Emne O | N / A |
Emne L | N / A |
Emnet S | N / A |
Emne C | N / A |
Gældende fra | 2022-08-13 17:48:44 |
Gyldig til | 2032-08-13 17:58:44 |
Netværk
IP | Domæne | Hosting udbyder | Først set | Detaljer |
---|---|---|---|---|
N / A | xrepositoryx[.]navn | N / A | 2022-10-17 | BlackLotus C&C. https://xrepositoryx[.]name/network/API/hpb_gate.php |
N / A | myrepositoryx[.]com | N / A | 2022-10-16 | BlackLotus C&C. https://myrepositoryx[.]com/network/API/hpb_gate.php |
104.21.22[.]185 | erdjknfweklsgwfmewfgref[.]com | Cloudflare, Inc. | 2022-10-06 | BlackLotus C&C. https://erdjknfweklsgwfmewfgref[.]com/API/hpb_gate.php |
164.90.172[.]211 | harrysucksdick[.]com | DigitalOcean, LLC | 2022-10-09 | BlackLotus C&C. https://harrysucksdick[.]com/API/hpb_gate.php |
185.145.245[.]123 | heikickgn[.]com frassirishiproc[.]com |
SIA VEESP | 2022-10-12 | BlackLotus C&C. https://heikickgn[.]com/API/hpb_gate.php https://frassirishiproc[.]com/API/hpb_gate.php |
185.150.24[.]114 | mit lager[.]navn | SkyLink Data Center BV | 2022-10-14 | BlackLotus C&C. mit lager[.]navn/netværk/API/hpb_gate.php |
190.147.189[.]122 | egscorp[.]net | Telmex Colombia SA | 2022-08-24 | BlackLotus C&C. https://egscorp[.]net/API/hpb_gate.php |
MITRE ATT&CK teknikker
Dette bord er bygget vha udgave 12 af MITER ATT&CK-rammerne.
Taktik | ID | Navn | Beskrivelse |
---|---|---|---|
Ressourceudvikling | T1587.002 | Udvikle muligheder: Kodesigneringscertifikater | Nogle BlackLotus-eksempler er underskrevet med selvsigneret certifikat. |
T1588.005 | Få kapaciteter: Udnytter | BlackLotus brugte offentligt kendt udnyttelse til at omgå UEFI Secure Boot. | |
Udførelse | T1203 | Udnyttelse til klientudførelse | BlackLotus-installatører kan udnytte CVE-2022-21894 til at opnå vilkårlig kodeudførelse på systemerne med UEFI Secure Boot aktiveret. |
T1559 | Inter-proces kommunikation | BlackLotus HTTP-downloader bruger navngivne sektioner til at sende kommandoer til kernetilstandskomponenten. | |
T1106 | Native API | BlackLotus HTTP-downloader bruger forskellige native Windows API'er til at opnå kodeudførelse på den kompromitterede maskine. | |
T1129 | Delte moduler | BlackLotus HTTP-downloader kan indlæse og udføre DLL'er modtaget fra C&C-serveren. | |
Vedholdenhed | T1542.003 | Pre-OS Boot: Bootkit | BlackLotus bootkit installeres på EFI-systempartitionen og udføres under opstarten. |
Privilegie-eskalering | T1548.002 | Misbrugshøjdekontrolmekanisme: Omgå brugerkontokontrol | BlackLotus-installationsprogrammet forsøger at eskalere privilegier ved at omgå brugerkontokontrol. |
T1134.002 | Adgang Token Manipulation: Opret proces med Token | BlackLotus HTTP-downloader kan bruge WTSQueryUserToken og CreateProcessAsUserW til at udføre downloadede nyttelaster i en ny proces med lokale systemrettigheder. | |
Forsvarsunddragelse | T1622 | Debugger undvigelse | BlackLotus-komponenter bruger forskellige teknikker til at opdage, om en kernetilstands- eller brugertilstandsfejlfinder kører på et offer. |
T1574 | Kapringsudførelsesflow | BlackLotus bootkit kaprer forskellige komponenter inkluderet i de tidlige Windows-startprocesstadier (Windows Boot Manager, Windows OS-indlæser, Windows-kerne og specifikke drivere) for at undgå registrering ved at deaktivere forskellige Windows-sikkerhedsfunktioner (VBS, Windows Defender) og snigende udføre dens kernetilstand og komponenter i brugertilstand | |
T1562 | Forringe forsvaret | BlackLotus-komponenter kan deaktivere BitLocker og Windows Defender for at undgå registrering. | |
T1070.004 | Indikatorfjernelse: Filsletning | BlackLotus-installationsprogrammet sletter sig selv efter succesfuld implementering af filer til EFI System-partitionen. Også efter vellykket CVE-2022-21894-udnyttelse fjerner BlackLotus spor af udnyttelse ved at slette alle filer, der er inkluderet i udnyttelseskæden, fra EFI System Partition. | |
T1070.009 | Indikatorfjernelse: Klar persistens | BlackLotus kan afinstallere sig selv ved at fjerne alle bootkit-filer fra ESP'en og gendanne det oprindelige offers Windows Boot Manager. | |
T1036.005 | Masquerading: Match legitimt navn eller sted | BlackLotus forsøger at skjule sine filer installeret på ESP'en ved at bruge legitime filnavne, såsom grubx64.efi (hvis UEFI Secure Boot er aktiveret på kompromitteret maskine) eller bootmgfw.efi (hvis UEFI Secure Boot er deaktiveret på kompromitteret maskine). | |
T1112 | Rediger registreringsdatabasen | BlackLotus-installationsprogrammet ændrer Windows-registreringsdatabasen for at deaktivere Windows HVCI-sikkerhedsfunktionen. | |
T1027 | Uklare filer eller oplysninger | Næsten alle indlejrede strenge i BlackLotus-komponenter krypteres ved hjælp af en brugerdefineret kombineret chiffer og dekrypteres kun, når det er nødvendigt. | |
T1027.007 | Uklare filer eller oplysninger: Dynamisk API-opløsning | BlackLotus-komponenter bruger dynamisk API-opløsning, mens de bruger API-navnes hashes i stedet for navne. | |
T1027.009 | Uklare filer eller oplysninger: Indlejrede nyttelaster | Næsten alle indlejrede filer i BlackLotus-komponenter er krypteret ved hjælp af AES. | |
T1542.003 | Pre-OS Boot: Bootkit | BlackLotus bootkit implementeres på EFI System Partition og udføres under de tidlige OS-startstadier og er således i stand til at kontrollere OS-startprocessen og undgå registrering. | |
T1055.012 | Process Injection: Dynamic-link Library Injection | BlackLotus HTTP-downloader kan injicere en DLL i en nyoprettet svchost.exe proces ved hjælp af procesudhulning. | |
T1055.002 | Procesinjektion: Bærbar eksekverbar injektion | BlackLotus-driveren injicerer HTTP-downloaderens bærbare eksekverbare i en winlogon.exe proces. | |
T1014 | rootkit | BlackLotus-kernedriver beskytter bootkit-filerne på ESP'en mod fjernelse. | |
T1497.001 | Virtualisering/Sandbox Evasion: Systemtjek | BlackLotus anvender forskellige systemtjek, herunder kontrol af sandkassespecifikke registreringsværdier, for at opdage og undgå virtualiserings- og analysemiljøer. | |
Discovery | T1622 | Debugger undvigelse | BlackLotus-komponenter bruger forskellige teknikker til at opdage, om en kernetilstands- eller brugertilstandsfejlfinder kører på et offer. |
T1082 | Opdagelse af systemoplysninger | BlackLotus indsamler systemoplysninger (IP, GPU, CPU, hukommelse, OS-version) på en kompromitteret vært. | |
T1614 | Opdagelse af systemplacering | BlackLotus kan afslutte, hvis en af følgende systemlokaliteter er identificeret på den kompromitterede vært: ro-MD, ru-MD, ru-RU, uk-UA, be-BY, hy-AM, kk-KZ. | |
T1016 | Opdagelse af systemnetværkskonfiguration | BlackLotus HTTP-downloader kan bestemme den offentlige IP for en kompromitteret vært ved at anmode om det api.ipify[.]org service. | |
T1016.001 | System Network Configuration Discovery: Internet Connection Discovery | BlackLotus HTTP-downloader kontrollerer internetforbindelsen ved at forespørge Microsofts www.msftncsi[.]com/ncsi[.]txt | |
T1497.001 | Virtualisering/Sandbox Evasion: Systemtjek | BlackLotus anvender forskellige systemtjek, herunder kontrol af sandkassespecifikke registreringsværdier, for at opdage og undgå virtualiserings- og analysemiljøer. | |
Kommando og kontrol | T1071.001 | Application Layer Protocol: Webprotokoller | BlackLotus bruger HTTPS til kommunikation med sin C&C. |
T1132.001 | Datakodning: Standardkodning | BlackLotus koder krypterede data i C&C-kommunikation med URL-sikker base64. | |
T1573.001 | Krypteret kanal: Symmetrisk kryptografi | BlackLotus bruger 256-bit AES i CBC-tilstand til at dekryptere meddelelser modtaget fra deres C&C. | |
T1573.002 | Krypteret kanal: Asymmetrisk kryptografi | BlackLotus bruger en indlejret RSA offentlig nøgle til at kryptere meddelelser sendt til C&C. |
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
- Kilde: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- 000
- 1
- 10
- 11
- 2018
- 2020
- 2022
- 7
- 9
- a
- I stand
- Om
- over
- misbrug
- adgang
- tilgængelig
- Adgang
- Konto
- opnå
- opnår
- Lov
- aktioner
- aktører
- handlinger
- tilføjet
- Desuden
- Yderligere
- adresse
- adresser
- admin
- fremskreden
- Fordel
- reklame
- rådgivende
- AES
- påvirker
- Efter
- mod
- alias
- Alle
- allokeret
- tildelinger
- tillade
- tillader
- allerede
- Skønt
- altid
- AMD
- blandt
- analyse
- analysere
- ,
- Anime
- En anden
- api
- API'er
- app
- anvendelig
- Anvendelse
- applikationer
- passende
- APT
- Arkiv
- omkring
- artikler
- vurdering
- forbundet
- Forsøg på
- opmærksomhed
- AUGUST
- forfatter
- til rådighed
- backup
- sikkerhedskopier
- baseret
- grundlæggende
- Grundlæggende
- beacon
- fordi
- før
- Begyndelse
- bag
- være
- Hviderusland
- Tro
- jf. nedenstående
- Bedre
- mellem
- BleepingComputer
- Bloker
- Blå
- Bonus
- Støvler
- botnets
- Pause
- Breaking
- gennembrud
- bringe
- Bringe
- bredt
- bragte
- buffer
- bygge
- bygget
- indbygget
- ringe
- ringer
- Opkald
- kapaciteter
- stand
- hvilken
- forsigtig
- tilfælde
- tilfælde
- afslappet
- brydning
- forårsagede
- årsager
- forårsager
- center
- certifikat
- kæde
- chance
- lave om
- Kanal
- kontrol
- Kontrol
- cipher
- fordringer
- klar
- kunde
- Luk
- lukket
- tættere
- lukning
- kode
- kolleger
- Colombia
- kombination
- kombineret
- Kom
- kommenteret
- Fælles
- almindeligt
- kommunikere
- kommunikere
- Kommunikation
- sammenlignet
- sammenligning
- kompatibilitet
- fuldstændig
- komplekse
- kompleksitet
- komponent
- komponenter
- kompromis
- Kompromitteret
- Konceptet
- pågældende
- tillid
- Konfiguration
- BEKRÆFTET
- tilslutning
- Overvejer
- forbruger
- indeholder
- indeholder
- indhold
- fortsæt
- fortsætter
- kontinuerligt
- kontrol
- styring
- samarbejde
- Core
- Tilsvarende
- kunne
- Kursus
- dækker
- skabe
- oprettet
- skaber
- Oprettelse af
- KREDENTIAL
- kritisk
- Nuværende
- For øjeblikket
- skik
- Dangerous
- data
- Data Center
- Database
- Dato
- deaktiverer
- beskæftiger
- Død
- Dekryptér
- dyb
- dybere
- Standard
- definerede
- definitivt
- afhænger
- indsætte
- indsat
- implementering
- implementering
- udruller
- Afledt
- beskrive
- beskrevet
- ønskes
- Trods
- destination
- detail
- detaljeret
- detaljer
- opdaget
- Detektion
- Bestem
- bestemmelse
- udviklet
- Udvikler
- udviklere
- enhed
- Enheder
- DID
- forskel
- forskellige
- DIG
- direkte
- direkte
- mapper
- deaktiveret
- videregivelse
- opdage
- opdaget
- opdagelse
- distribueret
- fordeling
- Distributioner
- gør
- Domæner
- Dont
- downloade
- køre
- driver
- drivere
- Drop
- droppet
- Dropper
- dubletter
- i løbet af
- dynamisk
- hver
- Tidligt
- lettere
- nemt
- økosystem
- udgave
- effektivt
- indsats
- elementer
- OPHØJE
- forhøjet
- indlejret
- beskæftiger
- aktiveret
- krypteret
- kryptering
- Engineering
- nok
- indskrevet
- sikre
- indrejse
- Miljø
- miljøer
- væsentlig
- oprettelse
- etc.
- evalueret
- Endog
- begivenhed
- begivenheder
- Hver
- bevismateriale
- eksempel
- eksempler
- udelukkende
- udføre
- Udfører
- udførelse
- udførelse
- eksisterende
- Udgang
- Forklar
- forklaring
- Exploit
- udnyttelse
- Exploited
- exploits
- udforske
- udvidelse
- ekstern
- gennemførlig
- Feature
- featured
- Funktionalitet
- fyr
- få
- Fields
- Figur
- File (Felt)
- Filer
- filtrere
- endelige
- Finde
- finde
- Fornavn
- fast
- Blink
- flow
- følger
- efter
- følger
- evigt
- formular
- format
- Tidligere
- fora
- Videresend
- fundet
- fra
- fuld
- fuldt ud
- funktion
- funktionel
- funktionalitet
- funktioner
- yderligere
- Spil
- gateway
- genereret
- få
- given
- giver
- mål
- GPU
- Grøn
- Gruppens
- Guard
- hacking
- Håndterer
- hænder
- ske
- sker
- Hardware
- have
- headers
- link.
- Skjule
- Høj
- Hits
- Kroge
- host
- Hvordan
- Men
- HTTPS
- Hundreder
- identificeret
- identifikator
- identificere
- billede
- billeder
- straks
- KIMOs Succeshistorier
- implementeret
- gennemføre
- import
- umuligt
- in
- medtaget
- Herunder
- individuel
- oplysninger
- informative
- initial
- installere
- installeret
- i stedet
- integreret
- integritet
- Intel
- Intelligens
- interaktion
- Internet
- internetforbindelse
- Introduktion
- undersøgelse
- involverede
- IP
- spørgsmål
- IT
- selv
- januar
- Job
- spring
- Kaspersky
- Kasakhstan
- holde
- Nøgle
- nøgler
- kendt
- Efternavn
- Sidste år
- Sent
- seneste
- lancere
- lag
- føre
- Leads
- forlader
- Lenovo
- Li
- Bibliotek
- Sandsynlig
- GRÆNSE
- linux
- Liste
- Børsnoterede
- Lister
- lidt
- belastning
- loader
- lastning
- belastninger
- lokale
- placeret
- placering
- Lang
- lang tid
- Se
- taber
- Lav
- mac
- maskine
- Maskiner
- lavet
- Magic
- Main
- større
- lave
- maerker
- Making
- malware
- lykkedes
- leder
- Håndtering
- manuelt
- mange
- Match
- Matter
- max-bredde
- betyder
- mekanisme
- Hukommelse
- nævnte
- blot
- besked
- beskeder
- metode
- microsoft
- måske
- minimum
- minut
- afbødning
- tilstand
- modificeret
- ændre
- Moduler
- øjeblik
- overvåges
- skærme
- måned
- mere
- mest
- motivationer
- bevæge sig
- flere
- navn
- Som hedder
- navne
- indfødte
- nødvendig
- Behov
- Unødvendig
- behov
- netværk
- Ny
- næste
- Normalt
- nummer
- numre
- objekter
- opnå
- oktober
- Tilbud
- offline
- Gammel
- ONE
- online
- åbner
- betjene
- drift
- drift
- operatør
- Option
- Indstillinger
- ordrer
- original
- OS
- Andet
- Ellers
- Overvind
- oversigt
- egen
- ejede
- ejer
- parameter
- parametre
- del
- dele
- patch
- Patches
- lappe
- sti
- Mønster
- mønstre
- perfekt
- Udfør
- udfører
- udholdenhed
- fysisk
- stykke
- perron
- plato
- Platon Data Intelligence
- PlatoData
- PoC
- Punkt
- punkter
- politik
- mulig
- Indlæg
- Indlæg
- potentiale
- vigtigste
- tilstedeværelse
- præsentere
- forhindre
- tidligere
- tidligere
- principper
- private
- private nøgle
- privilegier
- Problem
- problemer
- udbytte
- behandle
- Behandlet
- Processer
- Produkt
- Program
- fremtrædende
- bevis
- Bevis for koncept
- korrekt
- beskytte
- beskyttet
- beskyttelse
- beskyttelse
- protokol
- forudsat
- leverer
- offentlige
- offentlig nøgle
- publikationer
- offentligt
- offentliggjort
- formål
- rejse
- RAM
- tilfældig
- hurtigt
- nået
- Læs
- Læser
- Læsning
- ægte
- Reality
- indse
- grund
- rimelige
- modtaget
- nylige
- Recover
- opsving
- referencer
- benævnt
- Uanset
- registre
- register
- fast
- relaterede
- forblive
- fjernelse
- Fjern
- fjernet
- fjernelse
- erstatte
- udskiftes
- Rapporter
- Repository
- anmode
- påkrævet
- forskning
- forsker
- forskere
- Løsning
- løst
- ressource
- svar
- ansvarlige
- REST
- genoprette
- resultere
- afkast
- vende
- roller
- rod
- rsa
- rsakonference
- Kør
- kører
- Rusland
- sikreste
- samme
- sandkasse
- Fup
- scanning
- Ordningen
- Skærm
- søgning
- Anden
- sekunder
- Sektion
- sektioner
- sikker
- sikkerhed
- synes
- afsendelse
- forstand
- seriel
- Series
- tjeneste
- Tjenester
- Session
- sæt
- sæt
- indstilling
- flere
- Del
- Kort
- bør
- vist
- Shows
- underskrive
- signaler
- underskrevet
- signering
- Skilte
- lignende
- Simpelt
- forenklet
- ganske enkelt
- siden
- SIX
- Størrelse
- So
- indtil nu
- Soft
- Software
- solgt
- løsninger
- nogle
- Nogen
- noget
- Kilder
- Space
- specifikke
- specifikation
- specificeret
- Spredning
- Stage
- etaper
- standalone
- standard
- står
- starte
- påbegyndt
- starter
- opstart
- Status
- forblive
- Trin
- Steps
- Stadig
- stoppet
- butik
- opbevaret
- ligetil
- struktur
- indsendelse
- efterfølgende
- vellykket
- Succesfuld
- sådan
- foreslår
- opsummere
- RESUMÉ
- support
- Understøttet
- Støtte
- Understøtter
- formodes
- suspenderet
- symbol
- syntaks
- systemet
- Systemer
- bord
- Tag
- tager
- tager
- taler
- mål
- opgaver
- hold
- Teknisk
- teknikker
- midlertidig
- Grundlæggende
- oplysninger
- deres
- derfor
- ting
- ting
- tusinder
- trussel
- trusselsaktører
- trusler
- tre
- Gennem
- tid
- tidslinje
- tip
- til
- i dag
- sammen
- token
- også
- værktøjer
- emne
- udløst
- betroet
- TUR
- Drejede
- Drejning
- typisk
- Ukraine
- under
- forståelse
- up-to-date
- Opdatering
- opdateret
- opdateringer
- us
- Brug
- brug
- Bruger
- sædvanligvis
- nytte
- værdi
- Værdier
- forskellige
- Verifikation
- verificeres
- verificere
- udgave
- via
- Victim
- ofre
- KRÆNKELSE
- Overtrædelser
- synlighed
- bind
- mængder
- Sårbarheder
- sårbarhed
- Sårbar
- Venter
- måder
- web
- Kendt
- Hvad
- Hvad er
- hvorvidt
- som
- mens
- Hele
- bred
- Wikipedia
- Wild
- vilje
- vinduer
- Windows 11
- inden for
- uden
- Arbejde
- virker
- Værst
- ville
- skrivning
- skriftlig
- år
- år
- Du
- Din
- zephyrnet
- nul