Primul kit de pornire UEFI care ocolește UEFI Secure Boot pe sisteme UEFI complet actualizate este acum o realitate
Numărul de vulnerabilități UEFI descoperite în ultimii ani și eșecurile în corecția acestora sau revocarea binarelor vulnerabile într-un interval de timp rezonabil nu au trecut neobservate de actorii amenințărilor. Drept urmare, primul kit de boot UEFI cunoscut public care ocolește caracteristica esențială de securitate a platformei – UEFI Secure Boot – este acum o realitate. În această postare pe blog vă prezentăm prima analiză publică a acestui kit de boot UEFI, care este capabil să ruleze chiar și pe sisteme Windows 11 complet actualizate cu UEFI Secure Boot activat. Funcționalitatea bootkit-ului și caracteristicile sale individuale ne fac să credem că avem de-a face cu un bootkit cunoscut sub numele de Lotus negru, kitul de boot UEFI fiind vândut pe forumuri de hacking pentru 5,000 USD începând cu cel puțin octombrie 2022.
Kiturile de boot UEFI sunt amenințări foarte puternice, având control deplin asupra procesului de pornire a sistemului de operare și, astfel, capabile să dezactiveze diferite mecanisme de securitate ale sistemului de operare și să implementeze propriile încărcături utile în modul kernel sau în modul utilizator în fazele timpurii de pornire a sistemului de operare. Acest lucru le permite să opereze foarte ascuns și cu privilegii ridicate. Până acum, doar câteva au fost descoperite în sălbăticie și descrise public (de exemplu, multiple mostre EFI rău intenționate am descoperit în 2020 sau seturi de boot-uri UEFI complet, cum ar fi descoperirea noastră de anul trecut - Setul de boot ESPecter - sau Setul de pornire FinSpy descoperit de cercetătorii de la Kaspersky).
Kiturile de boot UEFI pot pierde din stealth în comparație cu implanturile de firmware - cum ar fi LoJax; primul implant de firmware UEFI în mod natural, descoperit de echipa noastră în 2018 – deoarece bootkit-urile sunt amplasate pe o partiție de disc FAT32 ușor accesibilă. Cu toate acestea, rularea ca bootloader le oferă aproape aceleași capacități ca și implanturile de firmware, dar fără a fi nevoie să depășească apărările flash SPI pe mai multe niveluri, cum ar fi biții de protecție BWE, BLE și PRx, sau protecțiile furnizate de hardware (cum ar fi Intel Boot Guard). ). Sigur, UEFI Secure Boot sta în calea kiturilor de boot UEFI, dar există un număr deloc neglijabil de vulnerabilități cunoscute care permit ocolirea acestui mecanism de securitate esențial. Și cel mai rău dintre acestea este că unele dintre ele sunt încă ușor de exploatat pe sistemele actualizate chiar și la momentul scrierii acestui articol - inclusiv cel exploatat de BlackLotus.
Investigația noastră a început cu câteva accesări asupra a ceea ce s-a dovedit a fi componenta modului utilizator BlackLotus – un program de descărcare HTTP – în telemetria noastră la sfârșitul anului 2022. După o evaluare inițială, modelele de cod găsite în mostre ne-au adus la descoperirea a șase BlackLotus. instalatori (atât pe VirusTotal, cât și în propria noastră telemetrie). Acest lucru ne-a permis să explorăm întregul lanț de execuție și să realizăm că ceea ce aveam de-a face aici nu este doar malware obișnuit.
Următoarele sunt punctele cheie despre BlackLotus și o cronologie care rezumă seria de evenimente legate de acesta:
- Este capabil să ruleze pe cele mai recente sisteme Windows 11, complet corecţionate, cu UEFI Secure Boot activat.
- Exploatează o vulnerabilitate veche de mai mult de un an (CVE-2022-21894) pentru a ocoli UEFI Secure Boot și a configura persistența pentru bootkit. Acesta este primul abuz cunoscut în mod public al acestei vulnerabilități.
- Deși vulnerabilitatea a fost remediată în actualizarea Microsoft din ianuarie 2022, exploatarea acesteia este încă posibilă, deoarece este afectat, semnat valabil binarele încă nu au fost adăugate la Lista de revocare UEFI. BlackLotus profită de acest lucru, aducând propriile copii ale binarelor legitime – dar vulnerabile – în sistem pentru a exploata vulnerabilitatea.
- Este capabil să dezactiveze mecanismele de securitate ale sistemului de operare, cum ar fi BitLocker, HVCI și Windows Defender.
- Odată instalat, scopul principal al bootkit-ului este să implementeze un driver de kernel (care, printre altele, protejează bootkit-ul de eliminare) și un descărcator HTTP responsabil de comunicarea cu C&C și capabil să încarce încărcături suplimentare în modul utilizator sau în modul kernel. .
- BlackLotus a fost promovat și vândut pe forumuri underground începând cu cel puțin 6 octombrieth, 2022. În această postare pe blog, prezentăm dovezi că bootkit-ul este real, iar reclama nu este doar o înșelătorie.
- În mod interesant, unele dintre programele de instalare BlackLotus pe care le-am analizat nu continuă cu instalarea bootkit-ului dacă gazda compromisă utilizează una dintre următoarele locații:
- română (Moldova), ro-MD
- Rusă (Moldova), ru-MD
- rusă (Rusia), ru-RU
- Ucraineană (Ucraina), uk-UA
- Belarus (Belarus), be-BY
- armeană (Armenia), hy-AM
- Kazahstan (Kazahstan), kk-KZ
Cronologia evenimentelor individuale legate de BlackLotus este prezentată în Figura 1.
După cum am menționat deja, bootkit-ul a fost vândut pe forumuri underground din cel puțin 6 octombrieth, 2022. În acest moment, nu am reușit să identificăm, din telemetria noastră, canalul de distribuție exact folosit pentru a implementa bootkit-ul către victime. Numărul redus de mostre BlackLotus pe care le-am putut obține, atât din surse publice, cât și din telemetria noastră, ne face să credem că nu mulți actori de amenințări au început să-l folosească încă. Dar până când se va produce revocarea încărcătoarelor vulnerabile de care depinde BlackLotus, suntem îngrijorați că lucrurile se vor schimba rapid dacă acest bootkit va ajunge în mâinile grupurilor criminale bine-cunoscute, pe baza implementării ușoare a setului de boot și a capacităților de răspândire ale grupurilor criminale. malware folosind rețelele lor bot.
Acesta este cu adevărat BlackLotus?
Există mai multe articole sau postări care rezumă informații despre BlackLotus (aici, aici și aici și multe altele...), toate bazate pe informațiile furnizate de dezvoltatorul de bootkit pe forumurile de hacking underground. Până acum, nimeni nu a confirmat sau infirmat aceste afirmații.
Iată rezumatul nostru al afirmațiilor din publicațiile disponibile în comparație cu ceea ce am descoperit în timp ce am realizat inginerie inversă a mostrelor de bootkit:
- Anunțul lui BlackLotus pe forumurile de hacking susține că are integrat Secure Boot bypass. Adăugarea de drivere vulnerabile la lista de revocare UEFI este în prezent imposibilă, deoarece vulnerabilitatea afectează sute de încărcătoare de pornire care sunt încă folosite astăzi. ✅
- Adevărat: exploatează CVE-2022-21894 pentru a rupe Secure Boot și a obține persistență pe sistemele activate cu UEFI-Secure-Boot. Driverele vulnerabile pe care le folosește încă nu sunt revocate cel mai recent dbx, la momentul scrierii.
- Anunțul BlackLotus pe forumurile de hacking susține că bootkit-ul are încorporat protecție Ring0/Kernel împotriva eliminării. ✅
- Adevărat: driverul său de nucleu protejează mânerele care aparțin fișierelor sale de pe partiția de sistem EFI (ESP) împotriva închiderii. Ca un strat suplimentar de protecție, aceste mânere sunt monitorizate continuu și un Ecran Albastru al Morții (BSOD) este declanșat dacă oricare dintre aceste mânere este închis, așa cum este descris în Protejarea fișierelor bootkit de pe ESP împotriva ștergerii secţiune.
- Anunțul BlackLotus pe forumurile de hacking susține că vine cu funcții anti-mașină virtuală (anti-VM), anti-debug și ofuscarea codului pentru a bloca încercările de analiză a malware-ului. ✅
- Adevărat: conține diverse tehnici anti-VM, anti-debug și de ofuscare pentru a face mai dificilă replicarea sau analizarea. Cu toate acestea, cu siguranță nu vorbim aici despre vreo descoperire sau tehnici avansate de antianaliză, deoarece acestea pot fi depășite cu ușurință cu puțin efort.
- Reclama BlackLotus pe forumurile de hacking susține că scopul său este să acționeze ca un program de descărcare HTTP. ✅
- Adevărat: componenta sa finală acționează ca un program de descărcare HTTP, așa cum este descris în Descărcător HTTP secțiune
- Anunțul lui BlackLotus pe forumurile de hacking susține că descărcatorul HTTP rulează sub contul SISTEM în cadrul unui proces legitim. ✅
- Adevărat: programul său de descărcare HTTP rulează în winlogon.exe contextul procesului.
- Anunțul lui BlackLotus pe forumurile de hacking pretinde că este un bootkit mic cu o dimensiune pe disc de doar 80 kB. ✅
- Adevărat: mostrele pe care le-am putut obține sunt într-adevăr de aproximativ 80 kB.
- Anunțul lui BlackLotus pe forumurile de hacking susține că poate dezactivați protecțiile de securitate Windows încorporate, cum ar fi HVCI, Bitlocker, Windows Defender și ocoliți Controlul contului utilizatorului (UAC). ✅
Pe baza acestor fapte, credem cu mare încredere că bootkit-ul pe care l-am descoperit în sălbăticie este BlackLotus UEFI bootkit.
Privire de ansamblu asupra atacurilor
O schemă simplificată a lanțului de compromis BlackLotus este prezentată în Figura 2. Este alcătuită din trei părți principale:
- Începe cu executarea unui program de instalare (pasul 1 din Figura 2), care este responsabil pentru implementarea fișierelor bootkit-ului în partiția EFI System, dezactivarea HVCI și BitLocker și apoi repornirea mașinii.
- După prima repornire, exploatarea CVE-2022-21894 și înscrierea ulterioară a atacatorilor Machine Key Owner (MOK), pentru a obține persistență chiar și pe sistemele cu UEFI Secure Boot activat. Mașina este apoi repornită (pașii 2–4 din Figura 2) din nou.
- În toate pornirile ulterioare, kitul de boot UEFI autosemnat este executat și implementează atât driverul său de kernel, cât și încărcarea utilă în modul utilizator, descărcatorul HTTP. Împreună, aceste componente sunt capabile să descarce și să execute componente suplimentare în modul utilizator și driver de pe serverul C&C și să protejeze setul de boot împotriva înlăturării (pașii 5–9 din Figura 2).
Artefacte interesante
Chiar dacă credem că acesta este bootkit-ul BlackLotus UEFI, nu am găsit nicio referință la acest nume în mostrele pe care le-am analizat. În schimb, codul este plin de referințe la Higurashi când strigă seria anime, de exemplu în nume de componente individuale, cum ar fi higurashi_installer_uac_module.dll și higurashi_kernel.sys, și, de asemenea, în certificatul autosemnat utilizat pentru a semna binarul bootkit (prezentat în Figura 3).
În plus, codul decriptează, dar nu utilizează niciodată diverse șiruri de caractere care conțin mesaje de la autorul BlackLotus (după cum se arată în Figura 4 - rețineți că hasherezade este un cercetător binecunoscut și autor al diferitelor instrumente de analiză a programelor malware), sau doar câteva citate aleatorii din diferite cântece, jocuri sau serii.
Procesul de instalare
Începem cu analiza instalatorilor BlackLotus. Bootkit-ul pare să fie distribuit într-o formă de instalatori care vin în două versiuni – offline și online. Diferența dintre acestea două constă în modul în care obțin fișiere binare Windows legitime (dar vulnerabile), utilizate ulterior pentru a ocoli Secure Boot.
- În versiunile offline, fișierele binare Windows sunt încorporate în programul de instalare
- În versiunile online, fișierele binare Windows sunt descărcate direct din magazinul de simboluri Microsoft. Până acum, am văzut următoarele fișiere binare Windows abuzate de setul de boot BlackLotus:
- 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
Scopul programului de instalare este clar – este responsabil pentru dezactivarea funcțiilor de securitate Windows, cum ar fi criptarea discului BitLocker și HVCI, și pentru implementarea mai multor fișiere, inclusiv bootkit-ul rău intenționat, în ESP. Odată terminat, repornește mașina compromisă pentru a lăsa fișierele scăpate să-și facă treaba - pentru a se asigura că bootkit-ul UEFI autosemnat va fi executat în tăcere la fiecare pornire a sistemului, indiferent de starea protecției UEFI Secure Boot.
Pasul 0 – Inițializare și ridicare (potențială).
Când programul de instalare este executat, acesta verifică dacă are suficiente privilegii (cel puțin este necesar un administrator) pentru a implementa restul fișierelor în ESP și pentru a efectua alte acțiuni care necesită un proces ridicat - cum ar fi dezactivarea HVCI sau dezactivarea BitLocker. Dacă nu este cazul, încearcă să crească executând din nou programul de instalare utilizând metoda de ocolire UAC descrisă în detaliu aici: Ocolirea UAC prin asistentul de compatibilitate cu programe.
Cu privilegiile necesare, continuă, verificând starea UEFI Secure Boot citind valoarea variabilei SecureBoot UEFI folosind o funcție API Windows disponibilă și determinând versiunea Windows accesând direct KUSER_SHARED_DATA câmpuri de structură NtMajorVersion și NtMinorVersion in memoria. Face acest lucru pentru a decide dacă ocolirea UEFI Secure Boot este necesară pentru a implementa setul de pornire pe sistemul victimei (deoarece suportul Secure Boot a fost adăugat pentru prima dată în Windows 8 și este posibil să nu fie activat pe nicio mașină dată).
Înainte de a trece la pașii următori, redenumește Managerul de pornire Windows legitim (bootmgfw.efi) binar situat în ESP: EFIMicrosoftBoot directorul la winload.efi. Acest lucru a fost redenumit bootmgfw.efi backup este utilizat ulterior de bootkit pentru a lansa sistemul de operare sau pentru a recupera lanțul de pornire original dacă comanda „dezinstalare” este primită de la serverul C&C – mai multe în Comunicarea C&C secţiune.
Pasul 1 - Implementarea fișierelor
Dacă UEFI Secure Boot este activat, programul de instalare continuă cu aruncarea mai multor fișiere în ESP:/EFI/Microsoft/Boot/ și ESP:/system32/ directoare. În timp ce primul este un director standard utilizat de Windows, cel de-al doilea este un folder personalizat creat de programul de instalare.
O listă de fișiere abandonate de instalator cu o scurtă explicație a rolului fiecărui fișier în lanțul de execuție este furnizată în Tabelul 1. Vom explica în detaliu cum funcționează lanțul de execuție mai târziu; Acum rețineți că mai multe fișiere legitime semnate de Microsoft sunt eliminate împreună cu cele rău intenționate.
Tabelul 1. Fișierele implementate de programul de instalare BlackLotus pe sisteme cu UEFI Secure Boot activat
Dosar | Filename | Descriere |
---|---|---|
ESP: EFIMicrosoftBoot | grubx64.efi | Bootkit BlackLotus, aplicație UEFI rău intenționată, autosemnată. |
bootload.efi | Legitim semnat de Microsoft shim binar (nume temporar, mai târziu înlocuiește bootmgfw.efi după CVE-2022-21894 exploatare). | |
bootmgfw.efi | Legitim, dar vulnerabil (CVE-2022-21894) Windows Boot Manager binar, încorporat în programul de instalare sau descărcat direct din Microsoft Symbol Store. | |
BCD | Obiceiul atacatorilor Datele de configurare a boot-ului (BCD) magazin utilizat în CVE-2022-21894 lanțul de exploatare. | |
BCDR | Backup al magazinului BCD original al victimei. | |
ESP:system32 | hvloader.efi | Legitim, dar vulnerabil (CVE-2022-21894) Windows Hypervisor Loader binar, încorporat într-un program de instalare sau descărcat direct din Microsoft Symbol Store. |
bootmgr.efi | Legitim, dar vulnerabil (CVE-2022-21894) Windows Boot Manager binar, încorporat într-un program de instalare sau descărcat direct din Microsoft Symbol Store. | |
mcupdate_AuthenticAMD.dll | Binar PE nativ autosemnat rău intenționat. Acest fișier este executat de către hvloader.efi după exploatarea cu succes a CVE-2022-21894 (pe sisteme care utilizează un procesor AMD). | |
mcupdate_GenuineIntel.dll | Binar PE nativ autosemnat rău intenționat. Acest fișier este executat de către hvloader.efi după succes CVE-2022-21894 exploatare (pe sisteme care utilizează un procesor Intel). | |
BCD | BCD personalizat al atacatorilor folosit în CVE-2022-21894 lanțul de exploatare. |
În cazurile în care victima rulează o versiune Windows care nu acceptă UEFI Secure Boot sau în cazul în care este dezactivată, implementarea este destul de simplă. Singurul lucru care este necesar pentru a implementa kit-ul de pornire rău intenționat este înlocuirea managerului de boot Windows existent (bootmgfw.efi) binar în ESP: EFIMicrosoftBoot director, cu aplicația UEFI rău intenționată autosemnată a atacatorilor. Deoarece UEFI Secure Boot este dezactivată (și, prin urmare, nu se efectuează nicio verificare a integrității în timpul pornirii), exploatarea nu este necesară și firmware-ul UEFI pur și simplu execută managerul de pornire rău intenționat fără a provoca încălcări de securitate.
Pasul 2 – Dezactivarea integrității codului protejat prin hypervisor (HVCI)
Pentru a putea rula ulterior codul personalizat de kernel nesemnat, instalatorul trebuie să se asigure că HVCI este dezactivat pe sistem. Unul dintre colegii noștri ESET a scris o postare pe blog foarte informativă pe acest subiect în 2022 (Drivere de nucleu semnate – Poartă nepăzită către nucleul Windows):
Securitatea bazată pe virtualizare (VBS) oferă mai multe funcții de protecție, cea mai proeminentă fiind Hypervisor-Protected Code Integrity (HVCI), care vine și ca o caracteristică de sine stătătoare. HVCI impune integritatea codului în nucleu și permite doar executarea codului semnat. Previne efectiv abuzul de drivere vulnerabile pentru a executa cod kernel nesemnat sau a încărca drivere rău intenționate (indiferent de metoda de exploatare utilizată) și se pare că malware-ul care abuzează driverele vulnerabile pentru a încărca cod rău intenționat a fost unul dintre principalele motivații din spatele implementării de către Microsoft a acestei caracteristici.
După cum se arată în Figura 5, pentru a dezactiva această caracteristică, programul de instalare setează valoarea de registru Activat sub HypervisorEnforcedCodeIntegrity cheia de registry la zero.
Pasul 3 – Dezactivarea BitLocker
Următoarea caracteristică dezactivată de instalator este Criptare unitate BitLocker. Motivul pentru aceasta este că BitLocker poate fi utilizat într-o combinație cu Modul de platformă de încredere (TPM) pentru a vă asigura că diferite fișiere și configurații de boot, inclusiv Secure Boot, nu au fost modificate de când criptarea unității BitLocker a fost configurată pe sistem. Având în vedere că programul de instalare modifică lanțul de pornire Windows pe o mașină compromisă, menținerea BitLocker activat pentru sistemele cu suport TPM ar duce la un ecran de recuperare BitLocker la următoarea pornire și ar informa victima că sistemul a fost compromis.
Pentru a dezactiva această protecție, programul de instalare BlackLotus:
- parcurge toate volumele de sub RootCIMV2SecurityMicrosoftVolumeEncryption Spațiul de nume WMI și verifică starea de protecție a acestora apelând la GetProtectionStatus metodă a Win32_EncryptableVolume Clasa WMI
- pentru cei protejați de BitLocker, apelează la DisableKeyProtectors metoda cu DisableCount parametru setat la zero, ceea ce înseamnă că protecția va fi suspendată până când este activată manual
Cu protecțiile necesare dezactivate și cu toate fișierele implementate, programul de instalare se înregistrează pentru a fi șters la următoarea repornire a sistemului și repornește mașina pentru a continua la exploatarea CVE-2022-21894.
Ocolirea pornirii securizate și stabilirea persistenței
În această parte, aruncăm o privire mai atentă asupra modului în care BlackLotus atinge persistența pe sistemele cu UEFI Secure Boot activat. Deoarece lanțul de execuție pe care urmează să-l descriem este destul de complex, vom explica mai întâi principiile de bază și apoi vom aprofunda detaliile tehnice.
Pe scurt, acest proces constă din doi pași cheie:
- Exploatarea CVE-2022-21894 pentru a ocoli caracteristica Secure Boot și pentru a instala setul de boot. Acest lucru permite executarea unui cod arbitrar în fazele timpurii de pornire, unde platforma este încă deținută de firmware și funcțiile UEFI Boot Services sunt încă disponibile. Acest lucru permite atacatorilor să facă multe lucruri pe care nu ar trebui să le poată face pe o mașină cu UEFI Secure Boot activată fără a avea acces fizic la acesta, cum ar fi modificarea variabilelor NVRAM numai pentru serviciile de boot. Și de asta profită atacatorii pentru a configura persistența pentru bootkit-ul în pasul următor. Mai multe informații despre exploatare pot fi găsite în Exploatarea CVE-2022-21894 secţiune.
- Setarea persistenței prin scrierea propriului MOK la MokList, Variabilă NVRAM numai pentru servicii de pornire. Făcând acest lucru, poate folosi un document legitim semnat de Microsoft shim pentru încărcarea autosemnatului (semnat de cheia privată aparținând cheii scrise la MokList) UEFI bootkit în loc să exploateze vulnerabilitatea la fiecare boot. Mai multe despre asta în Persistența bootkit-ului secţiune.
Pentru a ușura analiza detaliată din următoarele două secțiuni, vom urma pașii indicați în diagrama de execuție, Figura 6.
Exploatarea CVE-2022-21894
Pentru a ocoli pornirea securizată, BlackLotus folosește baton drop (CVE-2022-21894): Vulnerabilitatea de ocolire a caracteristicii de securitate a pornirii securizate. În ciuda impactului său mare asupra securității sistemului, această vulnerabilitate nu a primit atât de multă atenție publică pe cât merita. Deși vulnerabilitatea a fost remediată în actualizarea Microsoft din ianuarie 2022, exploatarea ei este încă posibilă deoarece binarele afectate nu au fost încă adăugate la Lista de revocare UEFI. Drept urmare, atacatorii își pot aduce propriile copii ale fișierelor binare vulnerabile pe mașinile victimelor pentru a exploata această vulnerabilitate și a ocoli Secure Boot pe sistemele UEFI actualizate.
Mai mult, o exploatare Proof of Concept (PoC) pentru această vulnerabilitate a fost disponibilă public din august 2022. Având în vedere data primei trimiteri BlackLotus VirusTotal (vezi Figura 1), dezvoltatorul de malware probabil tocmai a adaptat PoC disponibil la nevoile lor fără orice nevoie de înțelegere profundă a modului în care funcționează acest exploit.
Să începem cu o scurtă introducere a vulnerabilității, rezumând în principal punctele cheie din articolul publicat împreună cu PoC pe GitHub:
- Aplicațiile de boot Windows afectate (cum ar fi bootmgr.efi, hvloader.efi, winload.efi…) permit eliminarea unei politici Secure Boot serializate din memorie – înainte ca aceasta să fie încărcată de aplicație – prin utilizarea trunchiază memoria Opțiunea de pornire BCD.
- Acest lucru permite atacatorilor să folosească alte opțiuni BCD periculoase, cum ar fi bootdebug, semnarea testelor, Sau verificări de lipsă de integritate, rupând astfel Secure Boot.
- Există diferite moduri de a exploata această vulnerabilitate – trei dintre ele sunt publicate în depozitul PoC.
- De exemplu, unul dintre PoC-uri arată cum poate fi exploatat pentru a face legitimitatea hvloader.efi încărcați un fișier arbitrar, autosemnat mcupdate_ .dll binar (unde poate fi GenuineIntel or AMD autentic, pe baza procesorului mașinii.).
Acum, continuăm cu descrierea modului în care BlackLotus exploatează această vulnerabilitate (numerele din lista de mai jos descriu pașii corespunzători în Figura 6):
- După ce programul de instalare repornește mașina, firmware-ul UEFI continuă cu încărcarea unei prime opțiuni de pornire. Pentru sistemele Windows, prima opțiune de pornire este implicită bootmgfw.efi situat în ESP:/EFI/Microsoft/Boot folder pe ESP. De data aceasta, în loc să-l executăm pe cel al victimei inițiale bootmgfw.efi (care a fost redenumit anterior winload.efi de către instalator), firmware-ul îl execută pe cel vulnerabil – implementat de către instalator.
- După bootmgfw.efi este executat, încarcă opțiunile de boot BCD, modificate anterior de către instalator. Figura 7 prezintă o comparație între BCD legitim și cel modificat.
- După cum puteți vedea în Figura 7 (calea subliniată cu verde), Managerul de boot legitim Windows ar încărca în mod normal încărcătorul sistemului de operare Windows (WINDOWSsystem32winload.efi) ca aplicație de boot implicită. Dar de data aceasta, cu BCD-ul modificat, continuă cu încărcarea celor vulnerabili ESP:system32bootmgr.efi, Cu evitarea memoriei reduse Elementul BCD setat la valoare 0x10000000 si personalizat: 22000023 Element BCD care indică BCD-ul altui atacator stocat în ESP:system32bcd. Explicația utilizării acestor elemente poate fi găsită în publicat PoC:
Atacatorul trebuie să se asigure că politica de pornire securizată serializată este alocată deasupra unei adrese fizice cunoscute.
[...]
evitarea memoriei reduse elementul poate fi utilizat pentru a se asigura că toate alocările de memorie fizică sunt deasupra unei adrese fizice specificate.
• Începând cu Windows 10, acest element este interzis dacă VBS este activat, dar deoarece este utilizat în timpul inițializării aplicației de pornire, înainte ca politica serializată Secure Boot să fie citită din memorie, încărcarea Bootmgr și specificarea unei căi BCD personalizate (folosind bcdfilepath element aka personalizat: 22000023) poate fi folosit pentru a ocoli acest lucru.
- În pasul următor, executat ESP:system32bootmgr.efi încarcă acel BCD suplimentar aflat în ESP:system32bcd. Conținutul analizat al acestui BCD suplimentar este prezentat în Figura 8.
- Din cauza opțiunilor încărcate din fișierul BCD prezentat în Figura 8, bootmgr.efi continuă cu încărcarea unei alte aplicații vulnerabile Windows Boot implementate de instalator – ESP:system32hvloader.efi – care este Windows Hypervisor Loader. Mai important, opțiunile BCD suplimentare sunt specificate în același fișier BCD (vezi Figura 8):
- trunchiază memoria cu valoarea setată la 0x10000000
- verificări de lipsă de integritate setată la Da
- și semnarea testelor, setat de asemenea la Da
Și aici se întâmplă magia. Deoarece politica serializată Secure Boot ar trebui să fie încărcată în adresele fizice de mai sus 0x10000000 (din cauza evitarea memoriei reduse utilizat în pașii anteriori), specificând trunchiază memoria elementul îl va elimina efectiv – astfel, întrerupeți Secure Boot și permiteți utilizarea opțiunilor BCD periculoase, cum ar fi verificări de lipsă de integritate or semnarea testelor. Folosind aceste opțiuni, atacatorii pot face hvloader.efi execută propriul cod autosemnat.
- Pentru a face acest lucru, același truc ca cel descris în PoC se foloseşte: în timpul executării sale, legitimul hvloader.efi încarcă și execută mcupdate_{GenuineIntel| AuthenticAMD}.dll binar nativ din : sistem32 director. Codul decompilat Hex-Rays comentat al funcției de la hvloader.efi responsabil pentru încărcarea acestui binar mcupdate*.dll este prezentat în Figura 9. Rețineți că hvloader.efi ar încărca în mod normal acest lucru legitim mcupdate*.dll binar din:Windowssystem32, dar de data aceasta atacatorii rău intenționați s-au autosemnat mcupdate*.dll este executat dintr-un director ESP personalizat creat anterior de instalator (ESP:system32). Este cauzată de opțiunile BCD dispozitiv și systemroot utilizat în BCD din Figura 8 specificând dispozitivul curent ca porni – adică ESP – și, de asemenea, specificând SystemRoot ca rădăcină () de pe acest dispozitiv.
- Acum, ca auto-semnat atacatorii mcupdate*.dll este încărcat și executat, continuă cu executarea componentei finale din acest lanț – un MokInstaller încorporat (aplicație UEFI) – vezi Figura 10 pentru detalii despre cum se face.
Persistența bootkit-ului
Acum, MokInstaller poate continua cu configurarea persistenței prin înscrierea MOK-ului atacatorilor în variabila NVRAM și configurarea legitimă semnată de Microsoft. shim binar ca bootloader implicit. Înainte de a trece la detalii, o mică teorie despre shim și MOK.
shim este un încărcător de încărcare UEFI din prima etapă dezvoltat de dezvoltatorii Linux pentru a face diverse distribuții Linux să funcționeze cu UEFI Secure Boot. Este o aplicație simplă și scopul ei este de a încărca, verifica și executa o altă aplicație – în cazul sistemelor Linux, este de obicei bootloader-ul GRUB. Funcționează într-un mod în care Microsoft semnează doar a shim, Şi shim se ocupă de restul – poate verifica integritatea unui bootloader din a doua etapă utilizând cheile de la db variabilă UEFI și, de asemenea, încorporează propria listă de chei sau hashuri „permise” sau „revocate” pentru a se asigura că componentele de încredere de ambele – dezvoltatorul platformei și shim (de exemplu Canonical, RedHat etc.) – pot fi executate. Pe lângă aceste liste, shim permite de asemenea utilizarea unei baze de date externe de chei gestionate de utilizator, cunoscută sub numele de listă MOK. Figura 11 ilustrează frumos cum funcționează UEFI Secure Boot cu MOK.
Această bază de date MOK este stocată într-o variabilă NVRAM de boot-only numită MokList. Fără a exploata o vulnerabilitate precum cea descrisă mai sus, este necesar acces fizic pentru a o modifica pe un sistem cu UEFI Secure Boot activat (este disponibil numai în timpul pornirii, înainte ca încărcătorul sistemului de operare să apeleze funcția UEFI Boot Services). ExitBootServices). Cu toate acestea, prin exploatarea acestei vulnerabilități, atacatorii pot ocoli UEFI Secure Boot și pot executa propriul cod autosemnat înainte de un apel către ExitBootServices, astfel încât să își poată înscrie cu ușurință propria cheie (prin modificarea codului MokList variabilă NVRAM) pentru a face shim-ul să execute orice aplicație – semnată de acea cheie înscrisă – fără a provoca o încălcare a securității.
- Continuând cu descrierea fluxului din Figura 6 – pasul 8... Aplicația MokInstaller UEFI continuă cu configurarea persistenței pentru bootkit-ul BlackLotus UEFI și acoperind pistele de exploatare prin:
- Restaurarea magazinului BCD original al victimei din copia de rezervă creată de programul de instalare și înlocuirea efi-ului cu shim-ul legitim semnat de Microsoft, trimis anterior în ESP:system32bootload.efi de către instalator.
- Crearea unui MokList Variabila NVRAM care conține certificatul de cheie publică autosemnat al atacatorilor. Rețineți că această variabilă este formatată în același mod ca orice alte variabile ale bazei de date de semnături UEFI (cum ar fi db sau dbx) și poate consta din zero sau mai multe liste de semnături de tip EFI_SIGNATURE_LIST – așa cum este definit în specificația UEFI.
- Ștergerea tuturor fișierelor implicate în exploatare din atacatorii ESP:system32 dosar.
- În cele din urmă, repornește mașina pentru a face ca shim-ul implementat să execute setul de boot autosemnat, trimis la EFIMicrosoftBootgrubx64.efi de către instalator (grubx64.efi este de obicei bootloader-ul implicit din a doua etapă executat de a shim pe sisteme x86-64).
Codul care efectuează acțiunile descrise în ultimii doi pași este prezentat în Figura 12.
Setul de pornire BlackLotus UEFI
Odată ce persistența este configurată, setul de boot BlackLotus este executat la fiecare pornire a sistemului. Scopul bootkit-ului este de a implementa un driver de kernel și o componentă finală în modul utilizator - descărcatorul HTTP. În timpul execuției sale, încearcă să dezactiveze caracteristicile suplimentare de securitate Windows – Securitate bazată pe virtualizare (VBS) și Windows Defender – pentru a crește șansele de implementare cu succes și de funcționare ascunsă. Înainte de a trece la detalii despre cum se face acest lucru, să rezumăm elementele de bază despre driverul de kernel și despre descărcatorul HTTP:
- Driverul nucleului este responsabil pentru
- Implementarea următoarei componente a lanțului – un descărcator HTTP.
- Mentinerea incarcatorului in viata in caz de reziliere.
- Protejarea fișierelor bootkit împotriva eliminării din ESP.
- Executarea de încărcări suplimentare ale nucleului, dacă acest lucru este indicat de către descărcatorul HTTP.
- Dezinstalarea setului de pornire, dacă acest lucru este indicat de programul de descărcare HTTP.
- Descărcătorul HTTP este responsabil pentru:
- Comunicarea cu C&C.
- Executarea comenzilor primite de la C&C.
- Descărcarea și executarea sarcinilor utile primite de la C&C (suportă atât sarcinile utile kernel, cât și încărcăturile utile în modul utilizator).
Fluxul complet de execuție (simplificat), de la programul de instalare la descărcatorul HTTP, este prezentat în Figura 13. Descriem acești pași individuali mai detaliat în secțiunea următoare.
Fluxul de execuție BlackLotus
Pașii de execuție sunt următorii (acești pași sunt prezentați în Figura 13):
- Ca prim pas, firmware-ul UEFI execută opțiunea implicită de pornire Windows, care este fișierul în care este stocat de obicei EFIMicrosoftBootbootmgfw.efi. După cum am descris mai devreme (Secțiunea de persistență Bootkit, 8 .a), binarul MokInstaller a înlocuit acest fișier cu un semnat legitim shim.
- Cand shim este executat, se citește MokList variabilă NVRAM și utilizează certificatul stocat anterior de către atacatori pentru a verifica bootloader-ul din a doua etapă - bootkit-ul autosemnat BlackLotus UEFI situat în EFIMicrosoftBootgrubx64.efi.
- Când este verificat, shim execută bootkit-ul.
- Bootkit-ul începe cu crearea Boot-only VbsPolicyDisable variabilă NVRAM. Așa cum este descris aici, această variabilă este evaluată de încărcătorul sistemului de operare Windows în timpul pornirii și, dacă este definită, caracteristicile de bază VBS, cum ar fi HVCI și Credential Guard, nu vor fi inițializate.
- În următorii pași (5. a–e), bootkit-ul continuă cu un model comun utilizat de bootkit-urile UEFI. Interceptează execuția componentelor incluse în fluxul de pornire tipic Windows, cum ar fi Managerul de pornire Windows, încărcătorul sistemului de operare Windows și nucleul sistemului de operare Windows și agăță unele dintre funcțiile acestora în memorie. Ca bonus, încearcă, de asemenea, să dezactiveze Windows Defender prin corecția unora dintre driverele sale. Toate acestea pentru a realiza execuția sarcinii sale utile în primele etape ale procesului de pornire a sistemului de operare și pentru a evita detectarea. Următoarele funcții sunt conectate sau corelate:
- ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
Această funcție este de obicei conectată de bootkit-uri pentru a surprinde momentul în care încărcătorul sistemului de operare Windows (winload.efi) este încărcat în memorie, dar încă nu a fost executat – acesta este momentul potrivit pentru a efectua mai multe corecții în memorie. - BlImgAllocateImageBuffer in winload.efi:
Folosit pentru a aloca un buffer de memorie suplimentar pentru driverul de kernel rău intenționat. - OslArchTransferToKernel in winload.efi:
Am prins momentul în care nucleul sistemului de operare și unele dintre driverele de sistem sunt deja încărcate în memorie, dar încă nu au fost executate – ceea ce este un moment perfect pentru a efectua mai multe corecții în memorie. Driverele menționate mai jos sunt corelate în acest cârlig. Codul de la acest cârlig responsabil pentru găsirea driverelor adecvate în memorie este prezentat în Figura 14. - WdBoot.sys și WdFilter.sys:
BlackLotus corectează punctul de intrare al WdBoot.sys și WdFilter.sys – driverul Windows Defender ELAM și, respectiv, driverul de filtru al sistemului de fișiere Windows Defender – să revină imediat. - disc.sys:
Bootkit-ul agăță punctul de intrare al disc.sys driver pentru a executa driverul de kernel BlackLotus în primele etape ale inițializării sistemului.
- ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
- Apoi, când nucleul sistemului de operare execută disc.sys punctul de intrare al driverului, cârligul instalat sare la punctul de intrare al driverului kernel rău intenționat. Codul rău intenționat restaurează la rândul său originalul disc.sys pentru a permite sistemului să funcționeze corect și așteaptă până când winlogon.exe începe procesul.
- Când driverul rău intenționat detectează că winlogon.exe procesul a început, injectează și execută componenta finală a modului utilizator – descărcatorul HTTP – în el.
Driver de kernel
Driverul nucleului este responsabil pentru patru sarcini principale:
- Se injectează descărcatorul HTTP în winlogon.exe și reinjectând-o în cazul în care firul s-a terminat.
- Protejarea fișierelor bootkit implementate pe ESP împotriva eliminării.
- Dezarmarea procesului Windows Defender în modul utilizator MsMpEngine.exe.
- Comunicarea cu descărcătorul HTTP și, dacă este necesar, efectuarea oricăror comenzi.
Să le privim unul câte unul.
Persistența descărcatorului HTTP
Driverul de kernel este responsabil pentru implementarea programului de descărcare HTTP. Când pornește driverul, așteaptă până la procesul numit winlogon.exe începe, înainte de a întreprinde orice alte acțiuni. Odată ce procesul a început, driverul decriptează binarul de descărcare HTTP, îl injectează winlogon.exespațiul de adrese și îl execută într-un fir nou. Apoi, șoferul continuă să verifice periodic dacă firul mai rulează și repetă injecția dacă este necesar. Descărcătorul HTTP nu va fi implementat dacă un depanator de kernel este detectat de driver.
Protejarea fișierelor bootkit de pe ESP împotriva ștergerii
Pentru a proteja fișierele bootkit-ului aflate pe ESP, driverul de kernel folosește un truc simplu. Deschide toate fișierele pe care dorește să le protejeze, le duplică și le salvează mânerele și folosește ObSetHandleAttributes funcția kernel care specifică ProtectFromClose steag înăuntru ManerFlags (OBJECT_HANDLE_FLAG_INFORMATION) la 1 – protejând astfel mânerele de a fi închise de orice alte procese. Acest lucru va împiedica orice încercare de a elimina sau modifica fișierele protejate. Următoarele fișiere sunt protejate:
- ESP: EFIMicrosoftBootwinload.efi
- ESP: EFIMicrosoftBootbootmgfw.efi
- ESP: EFIMicrosoftBootgrubx64.efi
În cazul în care un utilizator încearcă să ștergă aceste fișiere protejate, se va întâmpla ceva ca ceea ce este prezentat în Figura 15.
Ca un alt nivel de protecție, în cazul în care utilizatorul sau software-ul de securitate ar putea să dezactiveze indicatorul de protecție și să închidă mânerele, driverul de kernel le monitorizează continuu și provoacă un BSOD apelând la KeBugCheck(INVALID_KERNEL_HANDLE) funcția dacă vreunul dintre mânere nu mai există.
Dezarmarea procesului principal Windows Defender
Driverul de kernel încearcă, de asemenea, să dezarmeze procesul principal Windows Defender - MsMpEng.exe. Face acest lucru prin eliminarea tuturor privilegiilor de simbol ale procesului prin setarea SE_PRIVILEGE_REMOVED atribui fiecăreia dintre ele. Ca urmare, procesul Defender nu ar trebui să își poată face treaba – cum ar fi scanarea fișierelor – în mod corespunzător. Cu toate acestea, deoarece această funcționalitate este implementată prost, poate deveni ineficientă prin repornirea MsMpEng.exe proces.
Comunicare cu programul de descărcare HTTP
Driverul de kernel este capabil să comunice cu programul de descărcare HTTP folosind un eveniment și o secțiune numite. Numele obiectelor numite utilizate sunt generate pe baza adresei MAC (ethernet) a adaptorului de rețea a victimei. Dacă o valoare a unui octet este mai mică de 16, atunci i se adaugă 16. Formatul numelor obiectelor generate poate varia în diferite mostre. De exemplu, într-una dintre mostrele pe care le-am analizat, pentru adresa MAC 00-1c-0b-cd-ef-34, numele generate ar fi:
- BaseNamedObjects101c1b: pentru secțiunea numită (se folosesc doar primii trei octeți ai MAC)
- BaseNamedObjectsZ01c1b: pentru evenimentul numit – la fel ca pentru Secțiune, dar prima cifră a adresei MAC este înlocuită cu Z
În cazul în care descărcatorul HTTP dorește să transmită o comandă driverului kernel-ului, pur și simplu creează o secțiune numită, scrie o comandă cu datele asociate în interior și așteaptă ca comanda să fie procesată de driver prin crearea unui eveniment numit și așteptând până când șoferul îl declanșează (sau semnalează).
Driverul acceptă următoarele comenzi auto-explicative:
- Instalați driverul de kernel
- Dezinstalați BlackLotus
Un cititor atent ar putea observa punctul slab BlackLotus aici – chiar dacă bootkit-ul își protejează componentele împotriva înlăturării, driverul kernel-ului poate fi păcălit să dezinstaleze complet bootkit-ul creând obiectele denumite mai sus menționate și trimițându-i comanda de dezinstalare.
Descărcător HTTP
Componenta finală este responsabilă pentru comunicarea cu un server C&C și execuția oricăror comenzi C&C primite de la acesta. Toate sarcinile utile pe care le-am putut descoperi conțin trei comenzi. Aceste comenzi sunt foarte simple și, după cum sugerează numele secțiunii, este vorba în principal despre descărcarea și executarea încărcărilor utile suplimentare folosind diferite tehnici.
Comunicarea C&C
Pentru a comunica cu C&C, încărcătorul HTTP utilizează protocolul HTTPS. Toate informațiile necesare comunicării sunt încorporate direct în binarul de descărcare – inclusiv domeniile C&C și căile de resurse HTTP utilizate. Intervalul implicit pentru comunicarea cu un server C&C este setat la un minut, dar poate fi modificat pe baza datelor din C&C. Fiecare sesiune de comunicare cu un C&C începe cu trimiterea unui mesaj HTTP POST de baliză către aceasta. În mostrele pe care le-am analizat, următoarele căi de resurse HTTP pot fi specificate în antetele HTTP POST:
- /network/API/hpb_gate[.]php
- /API/hpb_gate[.]php
- /gate[.]php
- /hpb_gate[.]php
Datele mesajului de semnalizare sunt predate cu a verifica= șir, care conține informații de bază despre mașina compromisă – inclusiv un identificator personalizat de mașină (denumit HWID), starea UEFI Secure Boot, diverse informații hardware și o valoare care pare a fi un număr de compilare BlackLotus. HWID este generat de la adresa MAC a mașinii (ethernet) și un număr de serie al volumului sistemului. Formatul mesajului înainte de criptare este așa cum se vede în Figura 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” } |
Figura 16. Formatul mesajului baliză
Înainte de a trimite mesajul către C&C, datele sunt mai întâi criptate utilizând o cheie RSA încorporată, apoi codificate baza64 cu siguranță URL. În timpul analizei, am găsit două chei RSA diferite utilizate în probe. Un exemplu de astfel de solicitare de baliză HTTP este prezentat în Figura 17.
Datele primite de la C&C ca răspuns la mesajul far ar trebui să înceapă cu valoarea magică de doi octeți HP; în caz contrar, răspunsul nu este procesat în continuare. Dacă valoarea magică este corectă, datele care urmează valorii magice sunt decriptate utilizând AES pe 256 de biți în modul CBC cu șirul HWID menționat mai sus folosit ca cheie.
După decriptare, mesajul este similar cu farul, un șir format JSON și specifică un identificator de comandă (denumit Tip) și diverși parametri suplimentari, cum ar fi:
- Interval de comunicare C&C
- Metoda de execuție de utilizat
- Nume fișier de încărcare utilă
- Tipul de sarcină utilă bazat pe extensia fișierului (.sys, .executabil, Sau . Dll sprijinit)
- Jeton de autentificare care ar trebui să fie utilizat pentru a solicita descărcarea datelor de încărcare utilă
- Cheie AES folosită pentru decriptarea datelor de încărcare utilă
Toate comenzile acceptate și descrierile lor sunt listate în Tabelul 2.
Tabelul 2. Comenzi C&C
Tip de comandă | Descrierea comenzii |
---|---|
1 | Descărcați și executați un driver de kernel, DLL sau un executabil obișnuit |
2 | Descărcați o sarcină utilă, dezinstalați setul de boot și executați sarcina utilă - probabil folosită pentru a actualiza setul de boot |
3 | Dezinstalați bootkit-ul și ieșiți |
În aceste comenzi, C&C poate specifica dacă sarcina utilă ar trebui să fie mai întâi aruncată pe disc înainte de a o executa sau să fie executată direct în memorie. În cazurile care implică aruncarea fișierului pe disc, fișierul ProgramData folderul de pe volumul sistemului de operare este folosit ca folder de destinație, iar numele și extensia fișierului sunt specificate de serverul C&C. În cazul executării fișierelor direct în memorie, svchost.exe este folosit ca țintă de injecție. Când C&C trimite o comandă care necesită cooperarea driverului nucleului sau un operator dorește să execute cod în modul kernel, mecanismul descris în Comunicare cu programul de descărcare HTTP se foloseste sectiunea.
Trucuri anti-analiza
Pentru a îngreuna detectarea și analiza acestui malware, autorul său a încercat să limiteze la minimum vizibilitatea artefactelor standard ale fișierelor, cum ar fi șirurile de text, importurile sau alte date încorporate necriptate. Mai jos este un rezumat al tehnicilor utilizate.
- Criptare șiruri și date
- Toate șirurile utilizate în eșantioane sunt criptate folosind un cifru simplu.
- Toate fișierele încorporate sunt criptate folosind AES pe 256 de biți în modul CBC.
- Cheile de criptare pentru fișierele individuale pot varia de la un eșantion la altul.
- Pe lângă criptarea AES, unele fișiere sunt, de asemenea, comprimate folosind LZMS.
- Rezoluție API numai pentru runtime
- În toate eșantioanele (dacă este cazul), API-urile Windows sunt întotdeauna rezolvate exclusiv în timpul rulării, iar hashurile de funcții în loc de nume de funcții sunt folosite pentru a găsi adresele de funcții API dorite în memorie.
- În unele cazuri, o directă syscall invocarea instrucțiunii este utilizată pentru a invoca funcția de sistem dorită.
- Comunicare în rețea
- Comunică folosind HTTPS.
- Toate mesajele trimise către C&C de către descărcatorul HTTP sunt criptate folosind o cheie publică RSA încorporată.
- Toate mesajele trimise de la C&C către descărcatorul HTTP sunt criptate folosind o cheie derivată din mediul mașinii victimei sau folosind o cheie AES furnizată de C&C.
- Trucuri anti-debug și anti-VM - dacă sunt utilizate, de obicei plasate chiar la începutul punctului de intrare. Sunt folosite doar trucuri ocazionale de detectare a sandbox-ului sau a depanatorului.
Atenuări și remediere
- În primul rând, desigur, este o necesitate menținerea sistemului și a produsului de securitate actualizat – pentru a crește șansa ca o amenințare să fie oprită chiar de la început, înainte ca aceasta să poată atinge persistența pre-OS.
- Apoi, pasul cheie care trebuie făcut pentru a preveni utilizarea binarelor UEFI vulnerabile cunoscute pentru ocolirea UEFI Secure Boot este revocarea acestora în baza de date de revocare UEFI (dbx) – pe un sistem Windows, dbx actualizările ar trebui distribuite utilizând Windows Updates.
- Problema este că revocarea fișierelor binare Windows UEFI utilizate pe scară largă poate duce la ca mii de sisteme învechite, imagini de recuperare sau copii de rezervă să nu fie pornite - și, prin urmare, revocarea durează adesea prea mult.
- Rețineți că revocarea aplicațiilor Windows utilizate de BlackLotus ar împiedica instalarea kit-ului de pornire, dar, deoarece instalatorul ar înlocui bootloader-ul victimei cu cel revocat, ar putea face sistemul de nepornit. Pentru a recupera în acest caz, o reinstalare a sistemului de operare sau doar o recuperare ESP ar rezolva problema.
- Dacă revocarea s-ar produce după ce este setată persistența BlackLotus, bootkit-ul va rămâne funcțional, deoarece folosește un shim legitim cu cheie MOK personalizată pentru persistență. În acest caz, cea mai sigură soluție de atenuare ar fi să reinstalați Windows și să eliminați cheia MOK înscrisă de atacatori folosind mokutil utilitar (este necesară prezența fizică pentru a efectua această operațiune datorită interacțiunii necesare a utilizatorului cu Managerul MOK în timpul pornirii).
Takeaways
Multe vulnerabilități critice care afectează securitatea sistemelor UEFI au fost descoperite în ultimii câțiva ani. Din păcate, din cauza complexității întregului ecosistem UEFI și a problemelor legate de lanțul de aprovizionare, multe dintre aceste vulnerabilități au lăsat multe sisteme vulnerabile chiar și la mult timp după ce vulnerabilitățile au fost remediate – sau cel puțin după ce ni s-a spus că au fost remediate. Pentru o imagine mai bună, iată câteva exemple de eșecuri de patch sau revocare care permit ocolirea UEFI Secure Boot doar din ultimul an:
- În primul rând, desigur, CVE-2022-21894 – vulnerabilitatea exploatată de BlackLotus. La un an de când vulnerabilitatea a fost remediată, binarele UEFI vulnerabile încă nu sunt revocate, permițând amenințărilor precum BlackLotus să funcționeze în mod ascuns pe sisteme cu UEFI Secure Boot activat, oferind astfel victimelor un fals sentiment de securitate.
- La începutul anului 2022, am dezvăluit mai multe vulnerabilități UEFI care permit, printre altele, dezactivarea UEFI Secure Boot. Multe dispozitive afectate nu mai sunt acceptate de OEM, deci nu sunt remediate (chiar dacă aceste dispozitive nu erau atât de vechi – cum ar fi 3-5 ani în momentul dezvăluirii vulnerabilității). Citiți mai multe în postarea noastră pe blog: Când „securitatea” nu este deloc sigură: vulnerabilități UEFI cu impact ridicat descoperite în laptopurile de consumatori Lenovo
- Mai târziu, în 2022, am descoperit un alte câteva vulnerabilități UEFI, a cărui exploatare ar permite atacatorilor să dezactiveze foarte ușor UEFI Secure Boot. După cum au subliniat colegii cercetători din Binar, mai multe dispozitive enumerate în consultativ au fost lăsate nepattchate sau nu corectate, chiar și la câteva luni după aviz – lăsând dispozitivele vulnerabile. Inutil să spun, similar cu cazul precedent, unele dispozitive vor rămâne vulnerabile pentru totdeauna, deoarece au ajuns la data de încheiere a asistenței.
Era doar o chestiune de timp înainte ca cineva să profite de aceste eșecuri și să creeze un kit de boot UEFI capabil să funcționeze pe sisteme cu UEFI Secure Boot activat. După cum am sugerat anul trecut în cadrul nostru Prezentare RSA, toate acestea fac trecerea la ESP mai fezabilă pentru atacatori și o posibilă cale de urmat pentru amenințările UEFI – existența BlackLotus confirmă acest lucru.
IoC-uri
Fişiere
SHA-1 | Filename | Detectare | Descriere |
---|---|---|---|
05846D5B1D37EE2D716140DE4F4F984CF1E631D1 | - | Win64/BlackLotus.A | Instalator BlackLotus. |
A5A530A91100ED5F07A5D74698B15C646DD44E16 | - | Win64/BlackLotus.A | Instalator BlackLotus. |
D82539BFC2CC7CB504BE74AC74DF696B13DB486A | - | Win64/BlackLotus.A | Instalator BlackLotus. |
16B12CEA54360AA42E1120E82C1E9BC0371CB635 | - | Win64/BlackLotus.A | Instalator BlackLotus. |
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 | - | Win64/BlackLotus.A | Instalator BlackLotus. |
45701A83DEC1DC71A48268C9D6D205F31D9E7FFB | - | Win64/BlackLotus.A | Instalator BlackLotus. |
2CE056AE323B0380B0E87225EA0AE087A33CD316 | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
5A0074203ABD5DEB464BA0A79E14B7541A033216 | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
5DC9CBD75ABD830E83641A0265BFFDDD2F602815 | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
97AEC21042DF47D39AC212761729C6BE484D064D | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
ADCEEC18FF009BED635D168E0B116E72096F18D2 | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
DBC064F757C69EC43517EFF496146B43CBA949D1 | - | EFI/BlackLotus.B | Setul de pornire BlackLotus UEFI. |
06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
0C0E78BF97116E781DDE0E00A1CD0C29E68D623D | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
74FF58FCE8F19083D16DF0109DC91D78C94342FA | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6 | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
111C4998F3264617A7A9D9BF662D4B1577445B20 | - | Win64/BlackLotus.B | Descărcător HTTP BlackLotus. |
17FA047C1F979B180644906FE9265F21AF5B0509 | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
1F3799FED3CF43254FE30DCDFDB8DC02D82E662B | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
4B882748FAF2C6C360884C6812DD5BCBCE75EBFF | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
91F832F46E4C38ECC9335460D46F6F71352CFFED | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
994DC79255AEB662A672A1814280DE73D405617A | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
FFF4F28287677CAABC60C8AB36786C370226588D | - | Win64/BlackLotus.C | Driver de kernel BlackLotus. |
71559C3E2F3950D4EE016F24CA54DA17D28B9D82 | - | EFI/BlackLotus.C | Magazinul BlackLotus Boot Configuration Data (BCD) a fost eliminat de instalatorul BlackLotus. |
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 | - | EFI/BlackLotus.C | Magazinul BlackLotus Boot Configuration Data (BCD) a fost eliminat de instalatorul BlackLotus. |
547FAA2D64B85BF883955B723B07635C0A09326B | - | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploatare încărcător de încărcare utilă. |
D1BBAA3D408E944C70B3815471EED7FA9AEE6425 | - | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploatare încărcător de încărcare utilă. |
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB | - | EFI/BlackLotus.A | Sarcina utilă de exploatare BlackLotus CVE-2022-21894 – aplicația MokInstaller EFI. |
D6BB89D8734B3E49725362DAE9A868AE681E8BD6 | - | EFI/BlackLotus.A | Sarcina utilă de exploatare BlackLotus CVE-2022-21894 – aplicația MokInstaller EFI. |
164BB587109CFB20824303AD1609A65ABB36C3E9 | - | Win64/BlackLotus.D | Modulul de ocolire UAC al programului de instalare BlackLotus. |
certificate
Număr de serie | 570B5D22B723B4A442CC6EEEBC2580E8 |
Amprentă | C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 |
Subiectul CN | Când plâng CA |
Subiectul O | - |
Subiectul L | - |
Subiectul S | - |
Subiectul C | - |
Valabil din | 2022-08-13 17:48:44 |
Valabil pana la | 2032-08-13 17:58:44 |
Reţea
IP | domeniu | Furnizor de găzduire | Prima dată văzut | Detalii |
---|---|---|---|---|
- | xrepositoryx[.]nume | - | 2022-10-17 | BlackLotus C&C. https://xrepositoryx[.]name/network/API/hpb_gate.php |
- | myrepositoryx[.]com | - | 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 | myrepository[.]nume | SkyLink Data Center BV | 2022-10-14 | BlackLotus C&C. myrepository[.]nume/rețea/API/hpb_gate.php |
190.147.189[.]122 | egscorp[.]net | Telmex Columbia SA | 2022-08-24 | BlackLotus C&C. https://egscorp[.]net/API/hpb_gate.php |
Tehnici MITRE ATT&CK
Acest tabel a fost construit folosind Versiunea 12 din cadrul MITRE ATT&CK.
tactică | ID | Nume si Prenume | Descriere |
---|---|---|---|
Dezvoltarea resurselor | T1587.002 | Dezvoltarea capacităților: Certificate de semnare a codului | Unele mostre BlackLotus sunt semnate cu certificat autosemnat. |
T1588.005 | Obține capabilități: Exploits | BlackLotus a folosit un exploit cunoscut public pentru a ocoli UEFI Secure Boot. | |
Execuție | T1203 | Exploatarea pentru Execuția Clientului | Instalatorii BlackLotus pot exploata CVE-2022-21894 pentru a realiza executarea de cod arbitrar pe sistemele cu UEFI Secure Boot activat. |
T1559 | Comunicarea intraprocesuala | Descărcătorul BlackLotus HTTP folosește secțiunea numită pentru a transmite comenzi componentei în modul kernel. | |
T1106 | API nativ | Descărcătorul BlackLotus HTTP utilizează diverse API-uri Windows native pentru a realiza execuția codului pe mașina compromisă. | |
T1129 | Module partajate | Descărcătorul BlackLotus HTTP poate încărca și executa DLL-uri primite de la serverul C&C. | |
Persistență | T1542.003 | Bootkit pre-OS: Bootkit | BlackLotus bootkit este implementat pe partiția de sistem EFI și executat în timpul pornirii. |
Privilegiul escaladării | T1548.002 | Mecanism de control al cotei abuzive: ocoliți controlul contului utilizatorului | Programul de instalare BlackLotus încearcă să escaladeze privilegiile ocolind Controlul contului utilizatorului. |
T1134.002 | Acces Token Manipulare: Creați un proces cu Token | Descărcătorul BlackLotus HTTP poate folosi WTSQueryUserToken și CreateProcessAsUserW pentru a executa încărcături utile descărcate în cadrul unui nou proces cu privilegii de sistem local. | |
Evaziunea apărării | T1622 | Evaziunea depanatorului | Componentele BlackLotus folosesc diverse tehnici pentru a detecta dacă un depanator în modul kernel sau în modul utilizator rulează pe o victimă. |
T1574 | Fluxul de execuție a deturnării | BlackLotus bootkit deturnează diferite componente incluse în etapele timpurii ale procesului de pornire Windows (Manager de pornire Windows, încărcătorul sistemului de operare Windows, nucleul Windows și drivere specifice) pentru a evita detectarea prin dezactivarea diferitelor funcții de securitate Windows (VBS, Windows Defender) și pentru a executa în mod furtiv modul kernel. și componente în modul utilizator | |
T1562 | Deteriorarea apărărilor | Componentele BlackLotus pot dezactiva BitLocker și Windows Defender pentru a evita detectarea. | |
T1070.004 | Eliminarea indicatorului: ștergerea fișierului | Programul de instalare BlackLotus se șterge după implementarea cu succes a fișierelor în partiția EFI System. De asemenea, după exploatarea cu succes CVE-2022-21894, BlackLotus elimină urmele de exploatare prin ștergerea tuturor fișierelor incluse în lanțul de exploatare din EFI System Partition. | |
T1070.009 | Îndepărtarea indicatorului: persistență clară | BlackLotus se poate dezinstala prin eliminarea tuturor fișierelor bootkit din ESP și restabilirea Windows Boot Manager al victimei originale. | |
T1036.005 | Masquerading: potriviți numele sau locația legitimă | BlackLotus încearcă să-și ascundă fișierele implementate pe ESP folosind nume de fișiere legitime, cum ar fi grubx64.efi (dacă UEFI Secure Boot este activată pe o mașină compromisă) sau bootmgfw.efi (dacă UEFI Secure Boot este dezactivată pe mașina compromisă). | |
T1112 | Modificați registrul | Programul de instalare BlackLotus modifică registrul Windows pentru a dezactiva caracteristica de securitate HVCI Windows. | |
T1027 | Fișiere sau informații ofucate | Aproape toate șirurile încorporate în componentele BlackLotus sunt criptate folosind un cifru combinat personalizat și decriptate numai atunci când este necesar. | |
T1027.007 | Fișiere sau informații ofucate: rezoluție dinamică API | Componentele BlackLotus folosesc rezoluția dinamică API în timp ce folosesc hash-urile numelor API în loc de nume. | |
T1027.009 | Fișiere sau informații ofucate: încărcături utile încorporate | Aproape toate fișierele încorporate în componentele BlackLotus sunt criptate folosind AES. | |
T1542.003 | Bootkit pre-OS: Bootkit | BlackLotus Bootkit este implementat pe partiția de sistem EFI și executat în primele etape de pornire a sistemului de operare și, prin urmare, este capabil să controleze procesul de pornire a sistemului de operare și să evite detectarea. | |
T1055.012 | Injecție de proces: Injecție de bibliotecă de legături dinamice | Descărcătorul BlackLotus HTTP poate injecta un DLL într-un fișier nou creat svchost.exe proces folosind golirea procesului. | |
T1055.002 | Injecție de proces: injecție portabilă executabilă | Driverul BlackLotus injectează executabilul portabil de descărcare HTTP într-un winlogon.exe proces. | |
T1014 | rootkit | Driverul de kernel BlackLotus protejează fișierele bootkit de pe ESP împotriva înlăturării. | |
T1497.001 | Virtualizare/Sandbox Evasion: Verificări ale sistemului | BlackLotus folosește diverse verificări ale sistemului, inclusiv verificarea valorilor de registru specifice sandbox-ului, pentru a detecta și a evita mediile de virtualizare și analiză. | |
Descoperire | T1622 | Evaziunea depanatorului | Componentele BlackLotus folosesc diverse tehnici pentru a detecta dacă un depanator în modul kernel sau în modul utilizator rulează pe o victimă. |
T1082 | Descoperirea informațiilor de sistem | BlackLotus colectează informații despre sistem (IP, GPU, CPU, memorie, versiunea sistemului de operare) pe o gazdă compromisă. | |
T1614 | Descoperirea locației sistemului | BlackLotus se poate închide dacă pe gazda compromisă este identificată una dintre următoarele localități de sistem: ro-MD, ru-MD, ru-RU, uk-UA, be-BY, hy-AM, kk-KZ. | |
T1016 | Descoperirea configurației rețelei sistemului | Descărcătorul BlackLotus HTTP poate determina IP-ul public al unei gazde compromise prin solicitare api.ipify[.]org serviciu. | |
T1016.001 | System Network Configuration Discovery: Descoperire conexiune la Internet | Descărcătorul BlackLotus HTTP verifică conexiunea la internet interogând Microsoft www.msftncsi[.]com/ncsi[.]txt | |
T1497.001 | Virtualizare/Sandbox Evasion: Verificări ale sistemului | BlackLotus folosește diverse verificări ale sistemului, inclusiv verificarea valorilor de registru specifice sandbox-ului, pentru a detecta și a evita mediile de virtualizare și analiză. | |
Comandă și Control | T1071.001 | Protocolul stratului de aplicație: protocoale web | BlackLotus folosește HTTPS pentru comunicarea cu C&C. |
T1132.001 | Codificarea datelor: codificare standard | BlackLotus codifică datele criptate în comunicarea C&C cu baza sigură pentru URL64. | |
T1573.001 | Canal criptat: Criptografie simetrică | BlackLotus folosește AES pe 256 de biți în modul CBC pentru a decripta mesajele primite de la C&C. | |
T1573.002 | Canal criptat: Criptografie asimetrică | BlackLotus folosește o cheie publică RSA încorporată pentru a cripta mesajele trimise către C&C. |
- Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
- Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
- Sursa: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- 000
- 1
- 10
- 11
- 2018
- 2020
- 2022
- 7
- 9
- a
- Capabil
- Despre Noi
- mai sus
- abuz
- acces
- accesibil
- accesarea
- Cont
- Obține
- Realizeaza
- act
- acțiuni
- actori
- Acte
- adăugat
- plus
- Suplimentar
- adresa
- adrese
- admin
- avansat
- Avantaj
- publicitate
- consultativ
- AES
- care afectează
- După
- împotriva
- Propriul rol
- TOATE
- alocate
- alocări
- Permiterea
- permite
- deja
- Cu toate ca
- mereu
- AMD
- printre
- analiză
- analiza
- și
- Anime
- O alta
- api
- API-uri
- aplicaţia
- aplicabil
- aplicație
- aplicatii
- adecvat
- APT
- arhivă
- în jurul
- bunuri
- evaluare
- asociate
- Încercările
- atenţie
- August
- autor
- disponibil
- Backup
- backup-uri
- bazat
- de bază
- Noțiuni de bază
- far
- deoarece
- înainte
- Început
- în spatele
- fiind
- Bielorusia
- Crede
- de mai jos
- Mai bine
- între
- BleepingComputer
- Bloca
- Albastru
- Primă
- Cizme
- botnet
- Pauză
- Breaking
- descoperire
- aduce
- Aducere
- in linii mari
- adus
- tampon
- construi
- construit
- construit-in
- apel
- apel
- apeluri
- capacități
- capabil
- pasă
- atent
- caz
- cazuri
- ocazional
- Captură
- cauzată
- cauze
- provocând
- Centru
- certificat
- lanţ
- șansă
- Schimbare
- Canal
- control
- Verificări
- cifru
- creanțe
- clar
- client
- Închide
- închis
- mai aproape
- închidere
- cod
- colegii
- Columbia
- combinaţie
- combinate
- cum
- a comentat
- Comun
- în mod obișnuit
- comunica
- comunicarea
- Comunicare
- comparație
- comparație
- compatibilitate
- complet
- complex
- complexitate
- component
- componente
- compromis
- compromis
- concept
- îngrijorat
- încredere
- Configuraţie
- CONFIRMAT
- conexiune
- luand in considerare
- consumator
- conţine
- conține
- conţinut
- continua
- continuă
- continuu
- Control
- controlul
- cooperare
- Nucleu
- Corespunzător
- ar putea
- Curs
- acoperire
- crea
- a creat
- creează
- Crearea
- CREDENTIALĂ
- critic
- Curent
- În prezent
- personalizat
- Periculos
- de date
- Data Center
- Baza de date
- Data
- dezactivare
- abuzive
- Moarte
- decriptaţi
- adânc
- Mai adânc
- Mod implicit
- definit
- categoric
- depinde de
- implementa
- dislocate
- Implementarea
- desfășurarea
- implementează
- Derivat
- descrie
- descris
- dorit
- În ciuda
- destinație
- detaliu
- detaliat
- detalii
- detectat
- Detectare
- Determina
- determinarea
- dezvoltat
- Dezvoltator
- Dezvoltatorii
- dispozitiv
- Dispozitive
- FĂCUT
- diferenţă
- diferit
- SĂPA
- direcționa
- direct
- directoare
- invalid
- dezvăluire
- descoperi
- a descoperit
- descoperire
- distribuite
- distribuire
- distribuții
- face
- domenii
- Dont
- Descarca
- conduce
- şofer
- drivere
- Picătură
- scăzut
- scăparea
- duplicate
- în timpul
- dinamic
- fiecare
- Devreme
- mai ușor
- cu ușurință
- ecosistem
- ediţie
- în mod eficient
- efort
- element
- ELEVATE
- elevat
- încorporat
- angajează
- activat
- criptate
- criptare
- Inginerie
- suficient de
- înscris
- asigura
- intrare
- Mediu inconjurator
- medii
- esenţial
- stabilirea
- etc
- evaluat
- Chiar
- eveniment
- evenimente
- Fiecare
- dovadă
- exemplu
- exemple
- exclusiv
- a executa
- Executa
- executând
- execuție
- existent
- Ieşire
- Explica
- explicație
- Exploata
- exploatare
- exploatat
- exploit
- explora
- extensie
- extern
- realizabil
- Caracteristică
- Recomandate
- DESCRIERE
- membru
- puțini
- Domenii
- Figura
- Fișier
- Fişiere
- filtru
- final
- Găsi
- descoperire
- First
- fixată
- bliț
- debit
- urma
- următor
- urmează
- pentru totdeauna
- formă
- format
- Fost
- forumuri
- Înainte
- găsit
- din
- Complet
- complet
- funcţie
- funcțional
- funcționalitate
- funcții
- mai mult
- Jocuri
- poartă
- generată
- obține
- dat
- oferă
- scop
- GPU
- Verde
- Grupului
- Pază
- hacking
- Mânere
- mâini
- întâmpla
- se întâmplă
- Piese metalice
- având în
- anteturile
- aici
- Ascunde
- Înalt
- hit-uri
- cârlige
- gazdă
- Cum
- Totuși
- HTTPS
- sute
- identificat
- identificator
- identifica
- imagine
- imagini
- imediat
- Impactul
- implementat
- Punere în aplicare a
- importurile
- imposibil
- in
- inclus
- Inclusiv
- individ
- informații
- informativ
- inițială
- instala
- instalat
- in schimb
- integrate
- integritate
- Intel
- Inteligență
- interacţiune
- Internet
- conexiune internet
- Introducere
- investigaţie
- implicat
- IP
- problema
- IT
- în sine
- ianuarie
- Loc de munca
- salturi
- Kaspersky
- Kazahstan
- păstrare
- Cheie
- chei
- cunoscut
- Nume
- Anul trecut
- Târziu
- Ultimele
- lansa
- strat
- conduce
- Conduce
- lăsând
- Lenovo
- Li
- Bibliotecă
- Probabil
- LIMITĂ
- linux
- Listă
- listat
- liste
- mic
- încărca
- încărcător
- încărcare
- loturile
- local
- situat
- locaţie
- Lung
- perioadă lungă de timp
- Uite
- pierde
- Jos
- mac
- maşină
- Masini
- făcut
- magie
- Principal
- major
- face
- FACE
- Efectuarea
- malware
- gestionate
- manager
- Manipulare
- manual
- multe
- Meci
- materie
- max-width
- sens
- mecanism
- Memorie
- menționat
- pur și simplu
- mesaj
- mesaje
- metodă
- Microsoft
- ar putea
- minim
- minut
- atenuare
- mod
- modificată
- modifica
- Module
- moment
- monitorizate
- monitoare
- luni
- mai mult
- cele mai multe
- motivații
- muta
- multiplu
- nume
- Numit
- nume
- nativ
- necesar
- Nevoie
- Inutil
- nevoilor
- reţea
- Nou
- următor
- în mod normal
- număr
- numere
- obiecte
- obține
- octombrie
- promoții
- Offline
- Vechi
- ONE
- on-line
- deschide
- funcionar
- de operare
- operaţie
- operator
- Opțiune
- Opţiuni
- comandă
- original
- OS
- Altele
- in caz contrar
- Învinge
- Prezentare generală
- propriu
- deţinute
- proprietar
- parametru
- parametrii
- parte
- piese
- Plasture
- Patch-uri
- patching
- cale
- Model
- modele
- Perfect
- Efectua
- efectuarea
- persistență
- fizic
- bucată
- platformă
- Plato
- Informații despre date Platon
- PlatoData
- PoC
- Punct
- puncte
- Politica
- posibil
- Post
- postări
- potenţial
- puternic
- prezenţă
- prezenta
- împiedica
- precedent
- în prealabil
- Principiile
- privat
- cheie privată
- privilegii
- Problemă
- probleme
- venituri
- proces
- Procesat
- procese
- Produs
- Program
- proeminent
- dovadă
- dovada de concept
- cum se cuvine
- proteja
- protejat
- protectoare
- protecţie
- protocol
- prevăzut
- furnizarea
- public
- Cheia publică
- Publicații
- public
- publicat
- scop
- ridica
- RAM
- aleator
- repede
- atins
- Citeste
- Cititor
- Citind
- real
- Realitate
- realiza
- motiv
- rezonabil
- primit
- recent
- Recupera
- recuperare
- referințe
- menționat
- Fără deosebire
- registre
- registru
- regulat
- legate de
- rămâne
- îndepărtare
- scoate
- îndepărtat
- eliminarea
- înlocui
- înlocuiește
- Rapoarte
- depozit
- solicita
- necesar
- cercetare
- cercetător
- cercetători
- Rezoluţie
- hotărât
- resursă
- răspuns
- responsabil
- REST
- restabilirea
- rezultat
- reveni
- inversa
- Rol
- rădăcină
- rsa
- rsaconferință
- Alerga
- funcţionare
- Rusia
- cel mai sigur
- acelaşi
- nisip
- Înșelătorie
- scanare
- schemă
- Ecran
- căutare
- Al doilea
- secunde
- Secțiune
- secțiuni
- sigur
- securitate
- pare
- trimitere
- sens
- de serie
- serie
- serviciu
- Servicii
- sesiune
- set
- Seturi
- instalare
- câteva
- Distribuie
- Pantaloni scurți
- să
- indicat
- Emisiuni
- semna
- semnalele
- semnat
- semnare
- Semne
- asemănător
- simplu
- simplificată
- pur şi simplu
- întrucât
- SIX
- Mărimea
- So
- până acum
- Moale
- Software
- vândut
- soluţie
- unele
- Cineva
- ceva
- Surse
- Spaţiu
- specific
- specificație
- specificată
- răspândire
- Etapă
- Stadiile
- standalone
- standard
- Standuri
- Începe
- început
- începe
- lansare
- Stare
- şedere
- Pas
- paşi
- Încă
- oprit
- stoca
- stocate
- simplu
- structura
- supunere
- ulterior
- de succes
- Reușit
- astfel de
- sugerează
- rezuma
- REZUMAT
- a sustine
- Suportat
- De sprijin
- Sprijină
- a presupus
- suspendată
- simbol
- sintaxă
- sistem
- sisteme
- tabel
- Lua
- ia
- luare
- vorbesc
- Ţintă
- sarcini
- echipă
- Tehnic
- tehnici de
- temporar
- Noțiuni de bază
- informațiile
- lor
- prin urmare
- lucru
- lucruri
- mii
- amenințare
- actori amenințători
- amenințări
- trei
- Prin
- timp
- cronologie
- sfat
- la
- astăzi
- împreună
- semn
- de asemenea
- Unelte
- subiect
- a declanșat
- de încredere
- ÎNTORCĂ
- transformat
- Cotitură
- tipic
- Ucraina
- în
- înţelegere
- up-to-data
- Actualizează
- actualizat
- actualizări
- us
- Folosire
- utilizare
- Utilizator
- obișnuit
- utilitate
- valoare
- Valori
- diverse
- Verificare
- verificat
- verifica
- versiune
- de
- Victimă
- victime
- ÎNCĂLCARE
- încălcări
- vizibilitate
- volum
- volume
- Vulnerabilitățile
- vulnerabilitate
- vulnerabil
- Aşteptare
- modalități de
- web
- bine cunoscut
- Ce
- Ce este
- dacă
- care
- în timp ce
- întreg
- larg
- Wikipedia
- Sălbatic
- voi
- ferestre
- ferestre 11
- în
- fără
- Apartamente
- fabrică
- Mini rulouri de absorbție
- ar
- scris
- scris
- an
- ani
- Tu
- Ta
- zephyrnet
- zero