Pierwszy dostępny bootkit UEFI omijający funkcję UEFI Secure Boot we w pełni zaktualizowanych systemach UEFI jest już rzeczywistością
Liczba luk UEFI wykrytych w ostatnich latach oraz niepowodzenia w ich naprawianiu lub usuwaniu wrażliwych plików binarnych w rozsądnym przedziale czasowym nie pozostały niezauważone przez cyberprzestępców. W rezultacie pierwszy publicznie znany bootkit UEFI omijający podstawową funkcję bezpieczeństwa platformy – UEFI Secure Boot – stał się rzeczywistością. W tym wpisie na blogu przedstawiamy pierwszą publiczną analizę tego bootkita UEFI, który może działać nawet na w pełni aktualnych systemach Windows 11 z włączonym UEFI Secure Boot. Funkcjonalność bootkita i jego poszczególne cechy pozwalają sądzić, że mamy do czynienia z bootkitem znanym jako Czarny Lotos, bootkit UEFI jest sprzedawany na forach hakerskich za 5,000 USD od co najmniej października 2022 r.
Bootkity UEFI to bardzo potężne zagrożenia, mające pełną kontrolę nad procesem uruchamiania systemu operacyjnego, a tym samym zdolne do wyłączania różnych mechanizmów bezpieczeństwa systemu operacyjnego i wdrażania własnych ładunków trybu jądra lub trybu użytkownika na wczesnych etapach uruchamiania systemu operacyjnego. To pozwala im działać bardzo potajemnie iz wysokimi uprawnieniami. Jak dotąd tylko kilka z nich zostało odkrytych na wolności i opisanych publicznie (np złośliwe próbki EFI które odkryliśmy w 2020 r., lub w pełni funkcjonalne bootkity UEFI, takie jak nasze odkrycie w zeszłym roku — the Bootkit ESPecter - lub bootkita FinSpy odkryte przez badaczy z firmy Kaspersky).
Bootkity UEFI mogą stracić na ukryciu w porównaniu z implantami oprogramowania układowego – np LoJax; pierwszy na wolności implant oprogramowania układowego UEFI, odkryty przez nasz zespół w 2018 r. – ponieważ bootkity znajdują się na łatwo dostępnej partycji dysku FAT32. Jednak uruchomienie jako bootloader daje im prawie takie same możliwości jak implanty oprogramowania układowego, ale bez konieczności pokonywania wielopoziomowych zabezpieczeń flash SPI, takich jak bity zabezpieczające BWE, BLE i PRx, lub zabezpieczeń zapewnianych przez sprzęt (takich jak Intel Boot Guard ). Jasne, UEFI Secure Boot stoi na przeszkodzie bootkitom UEFI, ale istnieje znaczna liczba znanych luk, które pozwalają ominąć ten niezbędny mechanizm bezpieczeństwa. Najgorsze jest to, że nawet w chwili pisania tego tekstu niektóre z nich można łatwo wykorzystać w aktualnych systemach – w tym w systemie wykorzystywanym przez BlackLotus.
Nasze dochodzenie rozpoczęło się od kilku trafień w coś, co okazało się być komponentem trybu użytkownika BlackLotus – narzędziem do pobierania HTTP – w naszej telemetrii pod koniec 2022 roku. Po wstępnej ocenie wzorce kodu znalezione w próbkach doprowadziły nas do odkrycia sześciu BlackLotus instalatorów (zarówno w VirusTotal, jak i w naszej własnej telemetrii). To pozwoliło nam zbadać cały łańcuch wykonywania i uświadomić sobie, że mamy tu do czynienia nie tylko ze zwykłym złośliwym oprogramowaniem.
Poniżej znajdują się kluczowe punkty dotyczące BlackLotus i oś czasu podsumowująca serię wydarzeń z nim związanych:
- Może działać na najnowszych, w pełni załatanych systemach Windows 11 z włączoną funkcją UEFI Secure Boot.
- Wykorzystuje lukę istniejącą ponad rok (CVE-2022-21894), aby ominąć UEFI Secure Boot i skonfigurować trwałość dla bootkita. Jest to pierwsze publicznie znane nadużycie tej luki w zabezpieczeniach.
- Chociaż luka została naprawiona w aktualizacji Microsoftu ze stycznia 2022 r., jej wykorzystanie jest nadal możliwe, ponieważ dotyczy, prawidłowo podpisany pliki binarne nadal nie zostały dodane do Lista odwołań UEFI. BlackLotus wykorzystuje to, wprowadzając do systemu własne kopie legalnych – ale wrażliwych – plików binarnych w celu wykorzystania luki.
- Jest w stanie wyłączyć mechanizmy bezpieczeństwa systemu operacyjnego, takie jak BitLocker, HVCI i Windows Defender.
- Po zainstalowaniu głównym celem bootkita jest wdrożenie sterownika jądra (który m.in. .
- BlackLotus był reklamowany i sprzedawany na podziemnych forach co najmniej od 6 październikath, 2022. W tym wpisie na blogu przedstawiamy dowody na to, że bootkit jest prawdziwy, a reklama nie jest zwykłym oszustwem.
- Co ciekawe, niektóre z przeanalizowanych przez nas instalatorów BlackLotus nie przeprowadzają instalacji bootkitów, jeśli zaatakowany host używa jednej z następujących lokalizacji:
- rumuński (Mołdawia), ro-MD
- rosyjski (Mołdawia), ru-MD
- Rosyjski (Rosja), ru-RU
- ukraiński (Ukraina), uk-UA
- białoruski (Białoruś), be-BY
- ormiański (Armenia), hy-AM
- kazachski (Kazachstan), kk-KZ
Kalendarium poszczególnych wydarzeń związanych z BlackLotus pokazano na rysunku 1.
Jak już wspomniano, bootkit jest sprzedawany na podziemnych forach co najmniej od 6 październikath, 2022. W tym momencie nie byliśmy w stanie zidentyfikować na podstawie naszych danych telemetrycznych dokładnego kanału dystrybucji używanego do wdrażania bootkita u ofiar. Niewielka liczba próbek BlackLotus, które udało nam się uzyskać, zarówno ze źródeł publicznych, jak iz naszych danych telemetrycznych, pozwala sądzić, że niewielu cyberprzestępców zaczęło jeszcze z niego korzystać. Ale dopóki nie nastąpi wycofanie wrażliwych programów ładujących, od których zależy BlackLotus, obawiamy się, że sytuacja ulegnie szybkiej zmianie, jeśli ten bootkit dostanie się w ręce dobrze znanych grup przestępczych, w oparciu o łatwość wdrażania bootkita i możliwości rozprzestrzeniania się grup przestępczych złośliwe oprogramowanie wykorzystujące ich botnety.
Czy to naprawdę BlackLotus?
Istnieje kilka artykułów lub postów podsumowujących informacje o BlackLotus (tutaj, tutaj i tutaj i wiele innych…), wszystko w oparciu o informacje dostarczone przez twórcę bootkita na podziemnych forach hakerskich. Jak dotąd nikt nie potwierdził ani nie obalił tych twierdzeń.
Oto nasze podsumowanie twierdzeń z dostępnych publikacji w porównaniu z tym, co odkryliśmy podczas inżynierii wstecznej próbek bootkitów:
- Reklama BlackLotus na forach hakerskich twierdzi, że ma zintegrowane obejście Bezpiecznego rozruchu. Dodanie wrażliwych sterowników do listy odwołań UEFI jest obecnie niemożliwe, ponieważ luka dotyczy setek programów ładujących, które są nadal używane. ✅
- Prawda: wykorzystuje CVE-2022-21894 w celu przerwania Bezpiecznego rozruchu i osiągnięcia trwałości w systemach obsługujących UEFI-Secure-Boot. Wrażliwe sterowniki, których używa, nadal nie są cofane w najnowszej wersji dbx, w momencie pisania.
- Reklama BlackLotus na forach hakerskich twierdzi, że bootkit ma wbudowaną ochronę Ring0/Kernel przed usunięciem. ✅
- Prawda: jego sterownik jądra chroni uchwyty należące do jego plików na partycji systemowej EFI (ESP) przed zamknięciem. Jako dodatkową warstwę ochrony, te uchwyty są stale monitorowane, a niebieski ekran śmierci (BSOD) uruchamia się, jeśli którykolwiek z tych uchwytów jest zamknięty, jak opisano w Ochrona plików bootkitów na ESP przed usunięciem
- Reklama BlackLotus na forach hakerskich twierdzi, że jest wyposażony w funkcje anty-maszyny wirtualnej (anty-VM), anty-debug i zaciemnianie kodu, aby blokować próby analizy złośliwego oprogramowania. ✅
- Prawda: Zawiera różne techniki anty-VM, anty-debug i zaciemniania, aby utrudnić replikację lub analizę. Jednak zdecydowanie nie mówimy tutaj o żadnych przełomowych lub zaawansowanych technikach antyanalizy, ponieważ można je łatwo pokonać przy niewielkim wysiłku.
- Reklama BlackLotus na forach hakerskich twierdzi, że jej celem jest działanie jako downloader HTTP. ✅
- Prawda: jego końcowy składnik działa jako narzędzie do pobierania HTTP, jak opisano w sekcji Narzędzie do pobierania HTTP Sekcja
- Reklama BlackLotus na forach hakerskich twierdzi, że downloader HTTP działa na koncie SYSTEM w ramach legalnego procesu. ✅
- Prawda: jego narzędzie do pobierania HTTP działa w ramach winlogon.exe kontekst procesu.
- Reklama BlackLotus na forach hakerskich twierdzi, że tak mały bootkit o rozmiarze na dysku wynoszącym zaledwie 80 kB. ✅
- Prawda: Próbki, które udało nam się uzyskać, naprawdę mają około 80 kB.
- Reklama BlackLotus na forach hakerskich twierdzi, że może wyłącz wbudowane zabezpieczenia systemu Windows, takie jak HVCI, Bitlocker, Windows Defender i omiń kontrolę konta użytkownika (UAC). ✅
Na podstawie tych faktów jesteśmy przekonani, że odkryty przez nas bootkit to bootkit BlackLotus UEFI.
Przegląd ataków
Uproszczony schemat łańcucha kompromisów BlackLotus pokazano na rysunku 2. Składa się on z trzech głównych części:
- Zaczyna się od uruchomienia instalatora (krok 1 na rysunku 2), który jest odpowiedzialny za rozmieszczenie plików bootkita na partycji EFI System, wyłączenie HVCI i BitLockera, a następnie ponowne uruchomienie komputera.
- Po pierwszym ponownym uruchomieniu, wykorzystanie luki CVE-2022-21894 i późniejsza rejestracja atakujących Klucz właściciela maszyny (MOK), aby osiągnąć trwałość nawet w systemach z włączonym UEFI Secure Boot. Następnie maszyna jest ponownie uruchamiana (kroki 2–4 na rysunku 2).
- We wszystkich kolejnych rozruchach wykonywany jest samopodpisany bootkit UEFI, który wdraża zarówno sterownik jądra, jak i ładunek w trybie użytkownika, program do pobierania HTTP. Komponenty te razem mogą pobierać i uruchamiać dodatkowe komponenty trybu użytkownika i sterowników z serwera C&C oraz chronić bootkita przed usunięciem (kroki 5–9 na rysunku 2).
Ciekawe artefakty
Chociaż uważamy, że jest to bootkit BlackLotus UEFI, w przeanalizowanych przez nas próbkach nie znaleźliśmy żadnego odniesienia do tej nazwy. Zamiast tego kod jest pełen odniesień do Higurashi, kiedy płaczą serii anime, na przykład w nazwach poszczególnych komponentów, takich jak higurashi_installer_uac_module.dll i higurashi_kernel.sys, a także w samopodpisanym certyfikacie używanym do podpisania pliku binarnego bootkita (pokazany na rysunku 3).
Dodatkowo kod odszyfrowuje, ale nigdy nie używa różnych ciągów zawierających wiadomości od autora BlackLotus (jak pokazano na rysunku 4 – zauważ, że hasherezada jest dobrze znanym badaczem i autorem różnych narzędzi do analizy złośliwego oprogramowania), lub po prostu kilka przypadkowych cytatów z różnych piosenek, gier lub seriali.
Proces instalacji
Zaczynamy od analizy instalatorów BlackLotus. Wydaje się, że bootkit jest dystrybuowany w formie instalatorów, które występują w dwóch wersjach – offline i online. Różnica między tymi dwoma polega na sposobie, w jaki pozyskują legalne (ale podatne na ataki) pliki binarne systemu Windows, które później są używane do obejścia Bezpiecznego rozruchu.
- W wersjach offline pliki binarne systemu Windows są osadzone w instalatorze
- W wersjach online pliki binarne systemu Windows są pobierane bezpośrednio z magazynu symboli firmy Microsoft. Jak dotąd zaobserwowaliśmy, że bootkit BlackLotus nadużywał następujących plików binarnych systemu Windows:
- 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
Cel instalatora jest jasny – odpowiada za wyłączenie funkcji bezpieczeństwa systemu Windows, takich jak szyfrowanie dysku BitLocker i HVCI, oraz za wdrożenie wielu plików, w tym złośliwego bootkita, do ESP. Po zakończeniu ponownie uruchamia skompromitowaną maszynę, aby upuszczone pliki wykonały swoją pracę – aby mieć pewność, że samopodpisany bootkit UEFI będzie po cichu uruchamiany przy każdym uruchomieniu systemu, niezależnie od stanu ochrony UEFI Secure Boot.
Krok 0 – Inicjalizacja i (potencjalne) podniesienie uprawnień
Po uruchomieniu instalator sprawdza, czy ma wystarczające uprawnienia (przynajmniej wymagane uprawnienia administratora), aby wdrożyć resztę plików na ESP i wykonać inne czynności wymagające podwyższonego poziomu procesu – takie jak wyłączenie HVCI lub wyłączenie funkcji BitLocker. Jeśli tak nie jest, próbuje podnieść uprawnienia, ponownie uruchamiając instalator, korzystając z metody obejścia UAC opisanej szczegółowo tutaj: Obejście UAC za pomocą asystenta zgodności programów.
Kontynuuje, mając niezbędne uprawnienia, sprawdzając stan UEFI Secure Boot, odczytując wartość zmiennej SecureBoot UEFI za pomocą dostępnej funkcji Windows API i określając wersję systemu Windows, uzyskując bezpośredni dostęp do KUSER_SHARED_DATA pola strukturalne Wersja NtMajor i Wersja NtMinor w pamięci. Robi to, aby zdecydować, czy obejście UEFI Secure Boot jest konieczne do wdrożenia bootkita w systemie ofiary (ponieważ obsługa bezpiecznego rozruchu została po raz pierwszy dodana w systemie Windows 8 i może nie być włączona na danym komputerze).
Przed przejściem do następnych kroków zmienia nazwę legalnego Menedżera rozruchu systemu Windows (bootmgfw.efi) plik binarny znajdujący się w ESP: EFIMicrosoftBoot katalog do winload.efi. To zmieniono nazwę bootmgfw.efi kopia zapasowa jest później używana przez bootkita do uruchamiania systemu operacyjnego lub odzyskiwania oryginalnego łańcucha rozruchowego, jeśli z serwera C&C odebrane zostanie polecenie „odinstaluj” – więcej w Komunikacja C&C
Krok 1 – Wdrażanie plików
Jeśli funkcja UEFI Secure Boot jest włączona, instalator kontynuuje umieszczanie wielu plików w folderze ESP:/EFI/Microsoft/Boot/ i ESP:/system32/ katalogi. Podczas gdy pierwszy to standardowy katalog używany przez system Windows, drugi to niestandardowy folder utworzony przez instalator.
Lista plików usuniętych przez instalator wraz z krótkim wyjaśnieniem roli każdego pliku w łańcuchu wykonywania znajduje się w Tabeli 1. Później wyjaśnimy szczegółowo, jak działa łańcuch wykonywania; teraz po prostu zauważ, że kilka legalnych plików podpisanych przez Microsoft jest usuwanych wraz ze złośliwymi.
Tabela 1. Pliki instalowane przez instalator BlackLotus w systemach z włączonym UEFI Secure Boot
Teczka | Nazwa pliku | Opis |
---|---|---|
ESP: EFIMicrosoftBoot | grubx64.efi | Bootkit BlackLotus, złośliwa samopodpisana aplikacja UEFI. |
bootload.efi | Legalne podpisane przez Microsoft shim binarny (nazwa tymczasowa, później zastępuje bootmgfw.efi po CVE-2022-21894 eksploatacja). | |
bootmgfw.efi | Uzasadnione, ale wrażliwe (CVE-2022-21894) Plik binarny Menedżera rozruchu systemu Windows, osadzony w instalatorze lub pobrany bezpośrednio z Microsoft Symbol Store. | |
BCD | Zwyczaj atakujących Boot Configuration Data (BCD) sklep używany w CVE-2022-21894 łańcuch eksploatacji. | |
BCDR | Kopia zapasowa oryginalnego sklepu BCD ofiary. | |
ESP:system32 | hvloader.efi | Uzasadnione, ale wrażliwe (CVE-2022-21894) Plik binarny Windows Hypervisor Loader, osadzony w instalatorze lub pobrany bezpośrednio z Microsoft Symbol Store. |
bootmgr.efi | Uzasadnione, ale wrażliwe (CVE-2022-21894) Plik binarny Menedżera rozruchu systemu Windows, osadzony w instalatorze lub pobrany bezpośrednio z Microsoft Symbol Store. | |
mcupdate_AuthenticAMD.dll | Złośliwy natywny plik binarny PE z podpisem własnym. Ten plik jest wykonywany przez hvloader.efi po pomyślnym wykorzystaniu luki CVE-2022-21894 (w systemach korzystających z procesora AMD). | |
mcupdate_GenuineIntel.dll | Złośliwy natywny plik binarny PE z podpisem własnym. Ten plik jest wykonywany przez hvloader.efi po sukcesie CVE-2022-21894 exploit (w systemach wykorzystujących procesor Intel). | |
BCD | Niestandardowy BCD atakujących używany w CVE-2022-21894 łańcuch eksploatacji. |
W przypadku, gdy ofiara korzysta z wersji systemu Windows, która nie obsługuje funkcji UEFI Secure Boot lub gdy ta funkcja jest wyłączona, wdrożenie jest dość proste. Jedyną rzeczą potrzebną do wdrożenia złośliwego bootkita jest zastąpienie istniejącego Menedżera rozruchu systemu Windows (bootmgfw.efi) binarny w ESP: EFIMicrosoftBoot katalog z samopodpisaną złośliwą aplikacją UEFI osoby atakującej. Ponieważ funkcja UEFI Secure Boot jest wyłączona (a zatem podczas rozruchu nie jest przeprowadzana weryfikacja integralności), wykorzystanie luki w zabezpieczeniach nie jest konieczne, a oprogramowanie układowe UEFI po prostu uruchamia złośliwego menedżera rozruchu bez powodowania jakichkolwiek naruszeń bezpieczeństwa.
Krok 2 — Wyłączanie integralności kodu chronionej przez hiperwizor (HVCI)
Aby móc później uruchomić niestandardowy niepodpisany kod jądra, instalator musi to zapewnić HVCI jest wyłączony w systemie. Jeden z naszych kolegów z firmy ESET napisał bardzo pouczający wpis na blogu na ten temat w 2022 r. (Podpisane sterowniki jądra — niestrzeżona brama do rdzenia systemu Windows):
Zabezpieczenia oparte na wirtualizacji (VBS) oferują kilka funkcji ochronnych, z których najważniejszą jest integralność kodu chronionego przez Hypervisor (HVCI), która jest również dostępna jako samodzielna funkcja. HVCI wymusza integralność kodu w jądrze i pozwala na wykonanie tylko podpisanego kodu. Skutecznie zapobiega wykorzystywaniu wrażliwych sterowników do wykonywania niepodpisanego kodu jądra lub ładowania złośliwych sterowników (niezależnie od zastosowanej metody wykorzystania). Wydaje się, że złośliwe oprogramowanie wykorzystujące podatne sterowniki do ładowania złośliwego kodu było jednym z główne motywacje stojące za wdrożeniem tej funkcji przez Microsoft.
Jak pokazano na rysunku 5, aby wyłączyć tę funkcję, instalator ustawia wartość rejestru Włączone w obszarze Integralność wymuszonego kodu funkcji hypervisor . klucz rejestru do zera.
Krok 3 – Wyłączanie funkcji BitLocker
Następną funkcją dezaktywowaną przez instalatora jest Szyfrowanie dysków funkcją BitLocker. Powodem tego jest to, że BitLocker może być używany w połączeniu z Trusted Platform Module (TPM) aby upewnić się, że różne pliki rozruchowe i konfiguracje, w tym Bezpieczny rozruch, nie zostały naruszone od czasu skonfigurowania szyfrowania dysków funkcją BitLocker w systemie. Biorąc pod uwagę, że instalator modyfikuje łańcuch rozruchowy systemu Windows na zaatakowanej maszynie, pozostawienie włączonej funkcji BitLocker w systemach z obsługą modułu TPM doprowadziłoby do wyświetlenia ekranu odzyskiwania funkcji BitLocker przy następnym uruchomieniu i dałoby wskazówkę ofierze, że system został naruszony.
Aby wyłączyć tę ochronę, instalator BlackLotus:
- przechodzi przez wszystkie tomy pod RootCIMV2SecurityMicrosoftVolumeEncryption przestrzeni nazw WMI i sprawdza stan ich ochrony, wywołując funkcję Uzyskaj stan ochrony metoda Win32_EncryptableVolume klasa WMI
- dla osób chronionych przez funkcję BitLocker wywołuje metodę Wyłącz zabezpieczenia klawiszy metoda z Wyłącz licznik parametr ustawiony na zero, co oznacza, że ochrona zostanie zawieszona do momentu jej ręcznego włączenia
Po wyłączeniu niezbędnych zabezpieczeń i wdrożeniu wszystkich plików instalator rejestruje się do usunięcia podczas następnego ponownego uruchomienia systemu i ponownie uruchamia komputer, aby przystąpić do wykorzystania luki CVE-2022-21894.
Omijanie bezpiecznego rozruchu i ustanawianie trwałości
W tej części przyjrzymy się bliżej, w jaki sposób BlackLotus osiąga trwałość w systemach z włączonym UEFI Secure Boot. Ponieważ łańcuch wykonania, który zamierzamy opisać, jest dość złożony, najpierw wyjaśnimy podstawowe zasady, a następnie zagłębimy się w szczegóły techniczne.
W skrócie proces ten składa się z dwóch kluczowych etapów:
- Wykorzystanie luki CVE-2022-21894 do ominięcia funkcji bezpiecznego rozruchu i zainstalowania bootkita. Pozwala to na wykonanie dowolnego kodu we wczesnych fazach rozruchu, gdy platforma jest nadal własnością oprogramowania układowego, a funkcje UEFI Boot Services są nadal dostępne. Dzięki temu atakujący mogą robić wiele rzeczy, których nie powinni robić na maszynie z włączonym UEFI Secure Boot bez fizycznego dostępu do niej, na przykład modyfikować zmienne NVRAM tylko dla usług rozruchowych. I właśnie to atakujący wykorzystują do skonfigurowania trwałości dla bootkita w następnym kroku. Więcej informacji na temat eksploatacji można znaleźć w Wykorzystując lukę CVE-2022-21894
- Ustawianie trwałości poprzez zapisanie własnego MOK do MokList, Zmienna NVRAM obsługująca tylko usługi rozruchowe. W ten sposób może używać legalnego podpisu Microsoft shim do załadowania jego podpisu własnego (podpisanego kluczem prywatnym należącym do klucza zapisanego MokList) UEFI bootkit zamiast wykorzystywać lukę przy każdym uruchomieniu. Więcej na ten temat w Trwałość bootkitów
Aby ułatwić szczegółową analizę w kolejnych dwóch sekcjach, wykonamy kroki pokazane na diagramie wykonania, rysunek 6.
Wykorzystując lukę CVE-2022-21894
Aby ominąć Bezpieczny rozruch, BlackLotus używa upuszczenie pałeczki (CVE-2022-21894): luka w zabezpieczeniach związana z obejściem funkcji zabezpieczeń bezpiecznego rozruchu. Pomimo dużego wpływu na bezpieczeństwo systemu luka ta nie przyciągnęła tak dużej uwagi opinii publicznej, na jaką zasługiwała. Chociaż luka została naprawiona w aktualizacji Microsoftu ze stycznia 2022 r., jej wykorzystanie jest nadal możliwe, ponieważ pliki binarne, których dotyczy luka, nadal nie zostały dodane do Lista odwołań UEFI. W rezultacie atakujący mogą przenosić własne kopie wrażliwych plików binarnych na maszyny swoich ofiar, aby wykorzystać tę lukę i ominąć Bezpieczny rozruch w aktualnych systemach UEFI.
Co więcej, exploit Proof of Concept (PoC) wykorzystujący tę lukę jest publicznie dostępny od sierpnia 2022 r. Biorąc pod uwagę datę pierwszego zgłoszenia BlackLotus VirusTotal (patrz rysunek 1), twórca szkodliwego oprogramowania prawdopodobnie właśnie dostosował dostępny PoC do swoich potrzeb bez jakakolwiek potrzeba głębokiego zrozumienia, jak działa ten exploit.
Zacznijmy od krótkiego wprowadzenia do luki, w większości podsumowującego kluczowe punkty z artykułu opublikowanego wraz z PoC na GitHubie:
- Zainfekowane aplikacje rozruchowe systemu Windows (takie jak bootmgr.efi, hvloader.efi, winload.efi…) umożliwiają usunięcie zserializowanej polityki Bezpiecznego rozruchu z pamięci – zanim zostanie ona załadowana przez aplikację – za pomocą obetnij pamięć Opcja rozruchu BCD.
- Pozwala to atakującym na użycie innych niebezpiecznych opcji BCD, takich jak bootdebug, testowanielub nointegritychecks, łamiąc w ten sposób Bezpieczny rozruch.
- Istnieją różne sposoby wykorzystania tej luki – trzy z nich są publikowane w repozytorium PoC.
- Jako przykład, jeden z PoC pokazuje, jak można go wykorzystać, aby uczynić legalnym hvloader.efi załadować dowolny, samopodpisany mcupdate_ .dll binarny (gdzie może być GenuineIntel or Autentyczne AMD, na podstawie procesora maszyny.).
Teraz kontynuujemy opisywanie, w jaki sposób BlackLotus wykorzystuje tę lukę (liczby na poniższej liście opisują odpowiednie kroki na rysunku 6):
- Po ponownym uruchomieniu komputera przez instalatora oprogramowanie układowe UEFI kontynuuje ładowanie opcji pierwszego rozruchu. W systemach Windows opcja pierwszego rozruchu jest domyślnie ustawiona bootmgfw.efi znajduje się w ESP:/EFI/Microsoft/Boot folder w ESP. Tym razem zamiast egzekucji pierwotnej ofiary bootmgfw.efi (której nazwa została wcześniej zmieniona winload.efi przez instalatora), oprogramowanie układowe wykonuje podatny na ataki – wdrażany przez instalatora.
- Po bootmgfw.efi jest wykonywany, ładuje opcje rozruchowe BCD, zmodyfikowane wcześniej przez instalator. Rysunek 7 przedstawia porównanie legalnego BCD i zmodyfikowanego.
- Jak widać na rysunku 7 (ścieżka podkreślona na zielono), legalny Menedżer rozruchu systemu Windows normalnie ładowałby program ładujący system operacyjny Windows (WINDOWSsystem32winload.efi) jako domyślną aplikację rozruchową. Ale tym razem, ze zmodyfikowanym BCD, kontynuuje ładowanie wrażliwych ESP:system32bootmgr.efiZ unikaj słabej pamięci Element BCD ustawiony na wartość 0x10000000 oraz niestandardowe: 22000023 Element BCD wskazujący na kod BCD innego atakującego przechowywany w ESP: system32bcd. Wyjaśnienie użycia tych elementów można znaleźć w opublikowanym PoC:
Osoba atakująca musi upewnić się, że serializowane zasady bezpiecznego rozruchu są przydzielane powyżej znanego adresu fizycznego.
[...]
Połączenia unikaj słabej pamięci element może być użyty do zapewnienia, że wszystkie alokacje pamięci fizycznej są powyżej określonego adresu fizycznego.
• Od systemu Windows 10 ten element jest niedozwolony, jeśli VBS jest włączony, ale ponieważ jest używany podczas inicjowania aplikacji rozruchowej, przed odczytaniem serializowanych zasad bezpiecznego rozruchu z pamięci, ładowanie Bootmgr i określając niestandardową ścieżkę BCD (za pomocą ścieżka pliku bcd pierwiastek tzw niestandardowe: 22000023) można użyć do obejścia tego.
- W kolejnym kroku wykonywany ESP:system32bootmgr.efi ładuje ten dodatkowy BCD znajdujący się w ESP: system32bcd. Przeanalizowana zawartość tego dodatkowego kodu BCD jest pokazana na rysunku 8.
- Ze względu na opcje załadowane z pliku BCD pokazanego na rysunku 8, bootmgr.efi kontynuuje ładowanie innej podatnej na ataki aplikacji rozruchowej systemu Windows wdrożonej przez instalator — ESP:system32hvloader.efi – czyli moduł ładujący Windows Hypervisor. Co ważniejsze, dodatkowe opcje BCD są określone w tym samym pliku BCD (patrz rysunek 8):
- obetnij pamięć z wartością ustawioną na 0x10000000
- nointegritychecks ustaw na Tak
- i testowanie, również ustaw na Tak
I tu dzieje się magia. Ponieważ serializowane zasady Bezpiecznego rozruchu powinny zostać załadowane na powyższe adresy fizyczne 0x10000000 (z powodu unikaj słabej pamięci użyty w poprzednich krokach), określając obetnij pamięć element skutecznie go usunie – w ten sposób złamie Bezpieczny rozruch i pozwoli na użycie niebezpiecznych opcji BCD, takich jak nointegritychecks or testowanie. Korzystając z tych opcji, osoby atakujące mogą dokonać hvloader.efi wykonać własny, samopodpisany kod.
- Aby to zrobić, ta sama sztuczka, jak opisano w PoC jest używany: podczas jego wykonywania, uzasadniony hvloader.efi ładuje i wykonuje mcupdate_{oryginalny Intel| AuthenticAMD}.dll natywny plik binarny z : system32 informator. Skomentowany kod funkcji zdekompilowany przez Hex-Rays hvloader.efi odpowiedzialny za załadowanie pliku binarnego mcupdate*.dll pokazano na rysunku 9. Zwróć na to uwagę hvloader.efi normalnie ładowałby ten prawidłowy mcupdate*.dll binarny z:System Windows32, ale tym razem złośliwi atakujący podpisali się sami mcupdate*.dll jest wykonywany z niestandardowego katalogu ESP utworzonego wcześniej przez instalator (ESP:system32). Jest to spowodowane opcjami BCD urządzenie i systemowy używany w BCD z rysunku 8 określający bieżące urządzenie jako bagażnik – co oznacza ESP – a także określenie SystemRoot jako root () na tym urządzeniu.
- Teraz, jako własnoręcznie podpisany przez atakujących mcupdate*.dll jest ładowany i wykonywany, kontynuuje wykonywanie ostatniego komponentu w tym łańcuchu – wbudowanego MokInstallera (aplikacja UEFI) – szczegółowe informacje o tym, jak to się robi, znajdują się na rysunku 10.
Trwałość bootkitów
Teraz MokInstaller może przystąpić do konfigurowania trwałości, rejestrując MOK atakujących w zmiennej NVRAM i konfigurując legalny, podpisany przez Microsoft shim binary jako domyślny program ładujący. Zanim przejdziemy do szczegółów, trochę teorii nt shim i MOK.
shim to bootloader UEFI pierwszego stopnia opracowany przez programistów Linuksa, aby różne dystrybucje Linuksa działały z UEFI Secure Boot. Jest to prosta aplikacja, której zadaniem jest ładowanie, weryfikacja i uruchamianie innej aplikacji – w przypadku systemów Linux najczęściej jest to bootloader GRUB. Działa w taki sposób, że Microsoft podpisuje tylko a shimi shim zajmuje się resztą – może zweryfikować integralność bootloadera drugiego etapu za pomocą kluczy z db UEFI, a także osadza własną listę „dozwolonych” lub „odwołanych” kluczy lub skrótów, aby upewnić się, że komponenty zaufane zarówno przez programistę platformy, jak i programistę (np. Canonical, RedHat itp.) – mogą zostać wykonane. Oprócz tych list, shim umożliwia również korzystanie z zarządzanej przez użytkownika zewnętrznej bazy kluczy, zwanej listą MOK. Rysunek 11 ładnie ilustruje sposób działania UEFI Secure Boot z MOK.
Ta baza danych MOK jest przechowywana w zmiennej NVRAM tylko do rozruchu o nazwie MokList. Bez wykorzystania luki, takiej jak opisana powyżej, wymagany jest dostęp fizyczny do jej modyfikacji w systemie z włączoną funkcją UEFI Secure Boot (jest ona dostępna tylko podczas rozruchu, zanim program ładujący system operacyjny wywoła funkcję UEFI Boot Services Wyjdź z usług BootServices). Jednak wykorzystując tę lukę, atakujący mogą ominąć UEFI Secure Boot i wykonać własny kod z podpisem własnym przed wywołaniem Wyjdź z usług BootServices, aby mogli łatwo zarejestrować własny klucz (modyfikując plik MokList NVRAM), aby podkładka wykonała dowolną aplikację – podpisaną tym zarejestrowanym kluczem – bez powodowania naruszenia bezpieczeństwa.
- Kontynuując opisywanie przepływu z rysunku 6 – krok 8… Aplikacja MokInstaller UEFI kontynuuje ustawianie trwałości dla bootkita BlackLotus UEFI i zacieranie śladów eksploatacji poprzez:
- Przywracanie pierwotnego magazynu BCD ofiary z kopii zapasowej utworzonej przez instalator i zastępowanie efi legalną podkładką podpisaną przez Microsoft, wcześniej zrzuconą do ESP:system32bootload.efi przez instalatora.
- Tworząc MokList Zmienna NVRAM zawierająca samopodpisany certyfikat klucza publicznego atakującego. Zwróć uwagę, że ta zmienna jest sformatowana w taki sam sposób, jak inne zmienne bazy danych sygnatur UEFI (takie jak db lub dbx) i może składać się z zera lub większej liczby list sygnatur typu EFI_SIGNATURE_LIST – zgodnie z definicją w Specyfikacji UEFI.
- Usunięcie wszystkich plików związanych z eksploatacją z atakujących ESP:system32 teczka.
- Na koniec ponownie uruchamia maszynę, aby wdrożona podkładka wykonała samopodpisany bootkit upuszczony do EFIMicrosoftBootgrubx64.efi przez instalatora (grubx64.efi jest zazwyczaj domyślnym bootloaderem drugiego etapu wykonywanym przez a shim na systemach x86-64).
Kod wykonujący akcje opisane w dwóch ostatnich krokach pokazano na rysunku 12.
Bootkit BlackLotus UEFI
Po skonfigurowaniu trwałości bootkit BlackLotus jest uruchamiany przy każdym uruchomieniu systemu. Celem bootkita jest wdrożenie sterownika jądra i końcowego komponentu trybu użytkownika – downloadera HTTP. Podczas wykonywania próbuje wyłączyć dodatkowe funkcje bezpieczeństwa systemu Windows – Virtualization-Based Security (VBS) i Windows Defender – aby zwiększyć szansę na pomyślne wdrożenie i ukradkowe działanie. Zanim przejdziemy do szczegółów, jak to się robi, podsumujmy podstawowe informacje o sterowniku jądra i downloaderze HTTP:
- Sterownik jądra jest odpowiedzialny za
- Wdrożenie kolejnego elementu łańcucha – downloadera HTTP.
- Utrzymanie ładowacza przy życiu w przypadku zakończenia.
- Ochrona plików bootkitów przed usunięciem z ESP.
- Wykonywanie dodatkowych ładunków jądra, jeśli tak poinstruuje program do pobierania HTTP.
- Odinstalowanie bootkita, jeśli tak poinstruuje program do pobierania HTTP.
- Downloader HTTP jest odpowiedzialny za:
- Komunikowanie się z C&C.
- Wykonywanie poleceń otrzymanych z C&C.
- Pobieranie i wykonywanie ładunków otrzymanych z C&C (obsługuje zarówno ładunki jądra, jak i ładunki trybu użytkownika).
Pełny przepływ wykonywania (uproszczony), od instalatora do downloadera HTTP, pokazano na rysunku 13. Bardziej szczegółowo opisujemy te poszczególne kroki w następnej sekcji.
Przebieg wykonania BlackLotus
Kroki wykonania są następujące (kroki te pokazano na rysunku 13):
- W pierwszym kroku oprogramowanie układowe UEFI wykonuje domyślną opcję rozruchu systemu Windows, czyli plik, w którym zwykle jest przechowywany EFIMicrosoftBootbootmgfw.efi. Jak opisaliśmy wcześniej (Sekcja trwałości bootkitów, 8 .a), plik binarny MokInstaller zastąpił ten plik prawidłowym podpisem shim.
- Podczas shim jest wykonywany, odczytuje MokList NVRAM i używa certyfikatu przechowywanego wcześniej przez atakujących do weryfikacji bootloadera drugiego etapu – samopodpisanego bootkitu BlackLotus UEFI znajdującego się w EFIMicrosoftBootgrubx64.efi.
- Po zweryfikowaniu, shim uruchamia bootkita.
- Bootkit rozpoczyna się od utworzenia Boot-only VbsPolicyWyłącz Zmienna NVRAM. Jak w opisie tutaj, ta zmienna jest oceniana przez moduł ładujący systemu operacyjnego Windows podczas rozruchu i jeśli jest zdefiniowana, podstawowe funkcje VBS, takie jak HVCI i Credential Guard, nie zostaną zainicjowane.
- W kolejnych krokach (5. a–e) bootkit kontynuuje wspólny wzorzec używany przez bootkity UEFI. Przechwytuje wykonanie komponentów zawartych w typowym przepływie rozruchowym systemu Windows, takich jak Menedżer rozruchu systemu Windows, program ładujący system operacyjny Windows i jądro systemu operacyjnego Windows, i przechwytuje niektóre z ich funkcji w pamięci. Jako bonus, próbuje również wyłączyć program Windows Defender, łatając niektóre ze swoich sterowników. Wszystko po to, aby osiągnąć wykonanie ładunku na wczesnych etapach procesu uruchamiania systemu operacyjnego i uniknąć wykrycia. Następujące funkcje są zaczepione lub załatane:
- Aplikacja ImgArchStartBoot in bootmgfw.efi or bootmgr.efi:
Ta funkcja jest często przechwytywana przez bootkity, aby uchwycić moment, w którym program ładujący system operacyjny Windows (winload.efi) jest załadowany do pamięci, ale nadal nie został wykonany – co jest właściwym momentem na wykonanie większej liczby poprawek w pamięci. - BlImgAllocateImageBuffer in winload.efi:
Używany do przydzielenia dodatkowego bufora pamięci dla złośliwego sterownika jądra. - OslArchTransferToKernel in winload.efi:
Zaczepiony, aby uchwycić moment, w którym jądro systemu operacyjnego i niektóre sterowniki systemowe są już załadowane do pamięci, ale nadal nie zostały uruchomione – co jest idealnym momentem na wykonanie większej liczby poprawek w pamięci. Sterowniki wymienione poniżej są załatane w tym haku. Kod z tego haka odpowiedzialny za znalezienie odpowiednich sterowników w pamięci pokazano na rysunku 14. - WdBoot.sys i WdFilter.sys:
BlackLotus łata punkt wejścia WdBoot.sys i WdFilter.sys – odpowiednio sterownik Windows Defender ELAM i sterownik filtru systemu plików Windows Defender – aby natychmiast powrócić. - dysk.sys:
Bootkit przechwytuje punkt wejścia dysk.sys sterownik do uruchamiania sterownika jądra BlackLotus we wczesnych etapach inicjalizacji systemu.
- Aplikacja ImgArchStartBoot in bootmgfw.efi or bootmgr.efi:
- Następnie, gdy jądro systemu operacyjnego wykona plik dysk.sys punktu wejścia sterownika, zainstalowany hak przeskakuje do punktu wejścia złośliwego sterownika jądra. Złośliwy kod z kolei przywraca oryginał dysk.sys aby umożliwić prawidłowe działanie systemu i czeka, aż winlogon.exe rozpoczyna się proces.
- Gdy złośliwy sterownik wykryje, że plik winlogon.exe proces się rozpoczął, wstrzykuje i uruchamia końcowy komponent trybu użytkownika – program do pobierania HTTP – do niego.
Sterownik jądra
Sterownik jądra jest odpowiedzialny za cztery główne zadania:
- Wstrzyknięcie downloadera HTTP do winlogon.exe i ponowne wstrzyknięcie go w przypadku zakończenia wątku.
- Ochrona plików bootkitów wdrożonych na ESP przed usunięciem.
- Rozbrajanie procesu Windows Defender w trybie użytkownika MsMpEngine.exe.
- Komunikowanie się z downloaderem HTTP iw razie potrzeby wykonywanie dowolnych poleceń.
Spójrzmy na nie jeden po drugim.
Trwałość downloadera HTTP
Sterownik jądra jest odpowiedzialny za wdrożenie downloadera HTTP. Po uruchomieniu sterownik czeka, aż proces o nazwie winlogon.exe rozpocznie się przed podjęciem jakichkolwiek innych działań. Po rozpoczęciu procesu sterownik odszyfrowuje plik binarny downloadera HTTP i wstrzykuje go do winlogon.exeprzestrzeni adresowej i wykonuje ją w nowym wątku. Następnie sterownik okresowo sprawdza, czy nić nadal się porusza i w razie potrzeby powtarza iniekcję. Narzędzie do pobierania HTTP nie zostanie wdrożone, jeśli sterownik wykryje debuger jądra.
Ochrona plików bootkitów na ESP przed usunięciem
Aby chronić pliki bootkita znajdujące się na ESP, sterownik jądra używa prostej sztuczki. Otwiera wszystkie pliki, które chce chronić, duplikuje i zapisuje ich uchwyty oraz używa rozszerzenia ObSetHandleAtrybuty funkcja jądra określająca Chroń przed zamknięciem flaga w środku UchwytFlags (OBJECT_HANDLE_FLAG_INFORMATION) parametru na 1 – zabezpieczając w ten sposób klamki przed zamknięciem przez jakiekolwiek inne procesy. Uniemożliwi to wszelkie próby usunięcia lub modyfikacji chronionych plików. Następujące pliki są chronione:
- ESP:EFIMicrosoftBootwinload.efi
- ESP:EFIMicrosoftBootbootmgfw.efi
- ESP: EFIMicrosoftBootgrubx64.efi
Jeśli użytkownik spróbuje usunąć te chronione pliki, nastąpi coś takiego, jak pokazano na rysunku 15.
Jako kolejna warstwa ochrony, na wypadek gdyby użytkownik lub oprogramowanie zabezpieczające mogło wyłączyć flagę ochrony i zamknąć uchwyty, sterownik jądra stale je monitoruje i powoduje BSOD, wywołując KeBugCheck(INVALID_KERNEL_HANDLE) funkcji, jeśli któryś z uchwytów już nie istnieje.
Rozbrojenie głównego procesu Windows Defender
Sterownik jądra próbuje również rozbroić główny proces Windows Defender – MsMpEng.exe. Robi to, usuwając wszystkie uprawnienia tokena procesu, ustawiając SE_PRIVILEGE_USUNIĘTO przypisać każdemu z nich. W rezultacie proces Defender nie powinien być w stanie prawidłowo wykonywać swoich zadań — takich jak skanowanie plików. Ponieważ jednak ta funkcja jest źle zaimplementowana, można ją zdezaktywować, ponownie uruchamiając program MsMpEng.exe proces.
Komunikacja z downloaderem HTTP
Sterownik jądra może komunikować się z programem do pobierania HTTP za pomocą nazwanego zdarzenia i sekcji. Nazwy używanych nazwanych obiektów są generowane na podstawie adresu MAC karty sieciowej (ethernet) ofiary. Jeśli wartość oktetu jest mniejsza niż 16, to dodaje się do niego 16. Format nazw generowanych obiektów może się różnić w różnych próbkach. Na przykład w jednej z analizowanych przez nas próbek dla adresu MAC 00-1c-0b-cd-ef-34, wygenerowane nazwy będą następujące:
- BaseNamedObjects101c1b: dla nazwanej sekcji (używane są tylko pierwsze trzy oktety MAC)
- Obiekty o nazwie bazowejZ01c1b: dla nazwanego zdarzenia – analogicznie jak dla Sekcji, ale pierwsza cyfra adresu MAC zostaje zastąpiona przez Z
W przypadku, gdy downloader HTTP chce przekazać jakieś polecenie do sterownika jądra, po prostu tworzy nazwaną sekcję, zapisuje w niej polecenie z powiązanymi danymi i czeka na przetworzenie polecenia przez sterownik, tworząc nazwane zdarzenie i czekając, aż polecenie zostanie przetworzone przez sterownik. kierowca go wyzwala (lub sygnalizuje).
Sterownik obsługuje następujące zrozumiałe polecenia:
- Zainstaluj sterownik jądra
- Odinstaluj BlackLotus
Uważny czytelnik może zauważyć tutaj słaby punkt BlackLotus – mimo że bootkit chroni swoje komponenty przed usunięciem, sterownik jądra można oszukać, aby całkowicie odinstalował bootkita, tworząc wyżej wymienione obiekty i wysyłając do niego polecenie odinstalowania.
Narzędzie do pobierania HTTP
Ostatni komponent odpowiada za komunikację z serwerem C&C i wykonywanie otrzymanych z niego poleceń C&C. Wszystkie ładunki, które udało nam się wykryć, zawierają trzy polecenia. Te polecenia są bardzo proste i jak sugeruje nazwa sekcji, polegają głównie na pobieraniu i wykonywaniu dodatkowych ładunków przy użyciu różnych technik.
Komunikacja C&C
Aby komunikować się z C&C, moduł ładujący HTTP używa protokołu HTTPS. Wszystkie informacje niezbędne do komunikacji są osadzone bezpośrednio w pliku binarnym downloadera – w tym domeny C&C oraz wykorzystywane ścieżki zasobów HTTP. Domyślny interwał komunikacji z serwerem C&C to jedna minuta, ale można go zmienić na podstawie danych z C&C. Każda sesja komunikacyjna z C&C rozpoczyna się od wysłania do niego beacona HTTP POST. W analizowanych przez nas próbkach w nagłówkach HTTP POST można określić następujące ścieżki zasobów HTTP:
- /network/API/hpb_gate[.]php
- /API/hpb_gate[.]php
- /brama[.]php
- /hpb_gate[.]php
Dane komunikatu nawigacyjnego są poprzedzone znakiem a checkin= string, zawierający podstawowe informacje o zaatakowanej maszynie – w tym niestandardowy identyfikator maszyny (określany jako HWID), status UEFI Secure Boot, różne informacje o sprzęcie i wartość, która wydaje się być numerem kompilacji BlackLotus. HWID jest generowany na podstawie adresu MAC komputera (ethernet) i numeru seryjnego woluminu systemowego. Format wiadomości przed zaszyfrowaniem jest taki, jak pokazano na rysunku 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” } |
Rysunek 16. Format komunikatu beacon
Przed wysłaniem wiadomości do C&C dane są najpierw szyfrowane za pomocą wbudowanego klucza RSA, a następnie szyfrowane w formacie base64 bezpiecznym dla adresów URL. Podczas analizy znaleźliśmy dwa różne klucze RSA używane w próbkach. Przykład takiego żądania HTTP beacon pokazano na rysunku 17.
Dane otrzymane z C&C jako odpowiedź na komunikat beacon powinny zaczynać się od dwubajtowej wartości magicznej HP; w przeciwnym razie odpowiedź nie jest dalej przetwarzana. Jeśli wartość magiczna jest poprawna, dane następujące po wartości magicznej są odszyfrowywane przy użyciu 256-bitowego algorytmu AES w trybie CBC z użyciem wspomnianego ciągu HWID jako klucza.
Po odszyfrowaniu wiadomość jest podobna do beacona, łańcucha znaków w formacie JSON i określa identyfikator polecenia (określany jako Rodzaj Nieruchomości) oraz różne dodatkowe parametry, takie jak:
- Interwał komunikacji C&C
- Metoda wykonania do użycia
- Nazwa pliku ładunku
- Typ ładunku na podstawie rozszerzenia pliku (sys, .exelub . Dll utrzymany)
- Token uwierzytelniania, który ma być używany do żądania pobrania danych ładunku
- Klucz AES używany do odszyfrowywania danych ładunku
Wszystkie obsługiwane polecenia i ich opisy są wymienione w tabeli 2.
Tabela 2. Komendy C&C
Typ polecenia | Opis polecenia |
---|---|
1 | Pobierz i uruchom sterownik jądra, bibliotekę DLL lub zwykły plik wykonywalny |
2 | Pobierz ładunek, odinstaluj bootkita i uruchom ładunek – prawdopodobnie używany do aktualizacji bootkita |
3 | Odinstaluj bootkita i wyjdź |
W tych poleceniach C&C może określić, czy ładunek powinien zostać najpierw zrzucony na dysk przed jego wykonaniem, czy też powinien zostać wykonany bezpośrednio w pamięci. W przypadkach wymagających upuszczenia pliku na dysk, plik ProgramData folder na woluminie systemu operacyjnego jest używany jako folder docelowy, a nazwa pliku i rozszerzenie są określane przez serwer C&C. W przypadku wykonywania plików bezpośrednio w pamięci, svchost.exe jest używany jako cel wstrzyknięcia. Kiedy C&C wysyła polecenie wymagające współpracy sterownika jądra lub operator chce wykonać kod w trybie jądra, mechanizm opisany w Komunikacja z downloaderem HTTP sekcja jest używana.
Sztuczki antyanalityczne
Aby utrudnić wykrywanie i analizę tego złośliwego oprogramowania, jego autor starał się ograniczyć do minimum widoczność standardowych artefaktów plików, takich jak ciągi tekstowe, importy lub inne niezaszyfrowane dane osadzone. Poniżej znajduje się podsumowanie zastosowanych technik.
- Szyfrowanie ciągów i danych
- Wszystkie ciągi użyte w próbkach są szyfrowane przy użyciu prostego szyfru.
- Wszystkie osadzone pliki są szyfrowane przy użyciu 256-bitowego algorytmu AES w trybie CBC.
- Klucze szyfrowania dla poszczególnych plików mogą różnić się w zależności od próbki.
- Oprócz szyfrowania AES niektóre pliki są również kompresowane przy użyciu LZMS.
- Rozwiązanie interfejsu API tylko w czasie wykonywania
- We wszystkich przykładach (jeśli ma to zastosowanie) interfejsy API systemu Windows są zawsze rozwiązywane wyłącznie w czasie wykonywania, a skróty funkcji zamiast nazw funkcji służą do znajdowania żądanych adresów funkcji interfejsu API w pamięci.
- W niektórych przypadkach bezpośredni wywoływanie systemowe, wywołanie instrukcji służy do wywołania żądanej funkcji systemowej.
- Komunikacja sieciowa
- Komunikuje się za pomocą protokołu HTTPS.
- Wszystkie wiadomości wysyłane do C&C przez downloader HTTP są szyfrowane przy użyciu wbudowanego klucza publicznego RSA.
- Wszystkie wiadomości wysyłane z C&C do downloadera HTTP są szyfrowane przy użyciu klucza pochodzącego ze środowiska maszyny ofiary lub przy użyciu klucza AES dostarczonego przez C&C.
- Triki zapobiegające debugowaniu i anty-VM – jeśli są używane, zwykle umieszczane na samym początku punktu wejścia. Stosowane są tylko przypadkowe sztuczki wykrywania piaskownicy lub debuggera.
Łagodzenia i środki zaradcze
- Po pierwsze, oczywiście aktualizowanie systemu i jego produktów zabezpieczających jest koniecznością — aby zwiększyć szansę na zatrzymanie zagrożenia na samym początku, zanim będzie ono w stanie osiągnąć trwałość sprzed systemu operacyjnego.
- Następnie kluczowym krokiem, który należy podjąć, aby zapobiec używaniu znanych wrażliwych plików binarnych UEFI do obejścia funkcji UEFI Secure Boot, jest ich odwołanie w bazie danych odwołań UEFI (dbx) – na systemach Windows, dbx aktualizacje powinny być dystrybuowane za pomocą Aktualizacji systemu Windows.
- Problem polega na tym, że wycofanie powszechnie używanych plików binarnych UEFI systemu Windows może spowodować, że tysiące przestarzałych systemów, obrazów przywracania lub kopii zapasowych stanie się niemożliwe do uruchomienia — a zatem unieważnienie często trwa zbyt długo.
- Należy zauważyć, że wycofanie aplikacji Windows używanych przez BlackLotus uniemożliwiłoby instalację bootkita, ale ponieważ instalator zastąpiłby program ładujący ofiary programem odwołanym, mogłoby to uniemożliwić uruchomienie systemu. Aby odzyskać w tym przypadku, ponowna instalacja systemu operacyjnego lub samo odzyskiwanie ESP rozwiązałoby problem.
- Jeśli odwołanie miałoby miejsce po ustawieniu trwałości BlackLotus, bootkit nadal działałby, ponieważ używa legalnej podkładki z niestandardowym kluczem MOK do trwałości. W takim przypadku najbezpieczniejszym rozwiązaniem byłoby ponowne zainstalowanie systemu Windows i usunięcie zarejestrowanego klucza MOK atakujących za pomocą mokutil (do wykonania tej operacji wymagana jest fizyczna obecność ze względu na niezbędną interakcję użytkownika z Menedżerem MOK podczas uruchamiania).
Takeaways
W ciągu ostatnich kilku lat odkryto wiele krytycznych luk w zabezpieczeniach systemów UEFI. Niestety, ze względu na złożoność całego ekosystemu UEFI i powiązane problemy z łańcuchem dostaw, wiele z tych luk sprawia, że wiele systemów jest podatnych na ataki nawet długo po naprawieniu luk – a przynajmniej po tym, jak powiedziano nam, że zostały naprawione. Aby uzyskać lepszy obraz, oto kilka przykładów niepowodzeń poprawek lub odwołań umożliwiających obejście UEFI Secure Boot tylko z ostatniego roku:
- Przede wszystkim oczywiście CVE-2022-21894 – luka wykorzystywana przez BlackLotus. Minął rok od usunięcia luki, wrażliwe pliki binarne UEFI nadal nie zostały odwołane, co pozwala zagrożeniom, takim jak BlackLotus, na ukradkowe działanie w systemach z włączonym UEFI Secure Boot, dając w ten sposób ofiarom fałszywe poczucie bezpieczeństwa.
- Na początku 2022 roku ujawniliśmy kilka luk UEFI, które umożliwiają między innymi wyłączenie funkcji UEFI Secure Boot. Wiele urządzeń, których dotyczy problem, nie jest już obsługiwanych przez producenta OEM, a zatem nie zostało naprawionych (mimo że te urządzenia nie były tak stare – na przykład 3-5 lat w momencie ujawnienia luki w zabezpieczeniach). Przeczytaj więcej w naszym poście na blogu: Gdy „bezpieczny” wcale nie jest bezpieczny: w laptopach konsumenckich Lenovo wykryto poważne luki w zabezpieczeniach UEFI
- Później w 2022 roku odkryliśmy a kilka innych luk UEFI, którego wykorzystanie pozwoliłoby również atakującym bardzo łatwo wyłączyć UEFI Secure Boot. Jak zauważyli koledzy badacze z Binarnie, kilka urządzeń wymienionych w doradczy pozostawiono niezałatane lub niepoprawnie załatane, nawet kilka miesięcy po opublikowaniu porady, narażając urządzenia na niebezpieczeństwo. Nie trzeba dodawać, że podobnie jak w poprzednim przypadku, niektóre urządzenia pozostaną podatne na ataki na zawsze, ponieważ osiągnęły datę zakończenia wsparcia.
To była tylko kwestia czasu, zanim ktoś wykorzysta te awarie i stworzy bootkit UEFI zdolny do działania na systemach z włączonym UEFI Secure Boot. Jak sugerowaliśmy w zeszłym roku w naszym Prezentacja RSA, wszystko to sprawia, że przejście na ESP jest bardziej wykonalne dla atakujących i możliwe rozwiązanie dla zagrożeń UEFI – istnienie BlackLotus to potwierdza.
IoC
Akta
SHA-1 | Nazwa pliku | Wykrywanie | Opis |
---|---|---|---|
05846D5B1D37EE2D716140DE4F4F984CF1E631D1 | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
A5A530A91100ED5F07A5D74698B15C646DD44E16 | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
D82539BFC2CC7CB504BE74AC74DF696B13DB486A | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
16B12CEA54360AA42E1120E82C1E9BC0371CB635 | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
45701A83DEC1DC71A48268C9D6D205F31D9E7FFB | N / A | Win64/BlackLotus.A | Instalator BlackLotus. |
2CE056AE323B0380B0E87225EA0AE087A33CD316 | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
5A0074203ABD5DEB464BA0A79E14B7541A033216 | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
5DC9CBD75ABD830E83641A0265BFFDDD2F602815 | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
97AEC21042DF47D39AC212761729C6BE484D064D | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
ADCEEC18FF009BED635D168E0B116E72096F18D2 | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
DBC064F757C69EC43517EFF496146B43CBA949D1 | N / A | EFI/BlackLotus.B | Bootkit BlackLotus UEFI. |
06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
0C0E78BF97116E781DDE0E00A1CD0C29E68D623D | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
74FF58FCE8F19083D16DF0109DC91D78C94342FA | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6 | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
111C4998F3264617A7A9D9BF662D4B1577445B20 | N / A | Win64/BlackLotus.B | Narzędzie do pobierania HTTP BlackLotus. |
17FA047C1F979B180644906FE9265F21AF5B0509 | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
1F3799FED3CF43254FE30DCDFDB8DC02D82E662B | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
4B882748FAF2C6C360884C6812DD5BCBCE75EBFF | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
91F832F46E4C38ECC9335460D46F6F71352CFFED | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
994DC79255AEB662A672A1814280DE73D405617A | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
FFF4F28287677CAABC60C8AB36786C370226588D | N / A | Win64/BlackLotus.C | Sterownik jądra BlackLotus. |
71559C3E2F3950D4EE016F24CA54DA17D28B9D82 | N / A | EFI/BlackLotus.C | Magazyn BlackLotus Boot Configuration Data (BCD) usunięty przez instalator BlackLotus. |
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 | N / A | EFI/BlackLotus.C | Magazyn BlackLotus Boot Configuration Data (BCD) usunięty przez instalator BlackLotus. |
547FAA2D64B85BF883955B723B07635C0A09326B | N / A | EFI/BlackLotus.A | Program ładujący ładunek eksploatacyjny BlackLotus CVE-2022-21894. |
D1BBAA3D408E944C70B3815471EED7FA9AEE6425 | N / A | EFI/BlackLotus.A | Program ładujący ładunek eksploatacyjny BlackLotus CVE-2022-21894. |
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB | N / A | EFI/BlackLotus.A | Ładunek eksploatacyjny BlackLotus CVE-2022-21894 – aplikacja MokInstaller EFI. |
D6BB89D8734B3E49725362DAE9A868AE681E8BD6 | N / A | EFI/BlackLotus.A | Ładunek eksploatacyjny BlackLotus CVE-2022-21894 – aplikacja MokInstaller EFI. |
164BB587109CFB20824303AD1609A65ABB36C3E9 | N / A | Win64/BlackLotus.D | Moduł obejściowy UAC instalatora BlackLotus. |
certyfikaty
Numer seryjny | 570B5D22B723B4A442CC6EEEBC2580E8 |
Odcisk kciuka | C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 |
Temat CN | Kiedy płaczą CA |
Temat O | N / A |
Temat L | N / A |
Temat S | N / A |
Temat C | N / A |
Ważne od | 2022-08-13 17:48:44 |
Ważne do | 2032-08-13 17:58:44 |
Sieć
IP | Domena | Dostawca usług hostingowych | Pierwszy widziany | Szczegóły |
---|---|---|---|---|
N / A | xrepozytoriumx[.]nazwa | 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 spółka z ograniczoną odpowiedzialnością | 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 | moje repozytorium[.]nazwa | SkyLink Data Center BV | 2022–10–14 | BlackLotus C&C. mojerepozytorium[.]nazwa/sieć/API/hpb_gate.php |
190.147.189[.]122 | egcorp[.]net | Telmex Kolumbia SA | 2022–08–24 | BlackLotus C&C. https://egscorp[.]net/API/hpb_gate.php |
Techniki SKOŚNE ATT&CK
Ten stół został zbudowany przy użyciu wersja 12 frameworku MITER ATT&CK.
Taktyka | ID | Imię | Opis |
---|---|---|---|
Rozwój zasobów | T1587.002 | Rozwijaj możliwości: Certyfikaty podpisywania kodu | Niektóre próbki BlackLotus są podpisane certyfikatem z podpisem własnym. |
T1588.005 | Zdobądź możliwości: Exploity | BlackLotus wykorzystał publicznie znany exploit do ominięcia funkcji UEFI Secure Boot. | |
Egzekucja | T1203 | Wykorzystywanie do realizacji klienta | Instalatorzy BlackLotus mogą wykorzystać lukę CVE-2022-21894 do wykonania dowolnego kodu w systemach z włączoną funkcją UEFI Secure Boot. |
T1559 | Komunikacja między procesami | Narzędzie do pobierania HTTP BlackLotus używa nazwanej sekcji do przekazywania poleceń do komponentu trybu jądra. | |
T1106 | Natywny interfejs API | Narzędzie do pobierania HTTP BlackLotus korzysta z różnych natywnych interfejsów API systemu Windows w celu wykonania kodu na zaatakowanej maszynie. | |
T1129 | Współdzielone moduły | BlackLotus HTTP downloader może ładować i uruchamiać biblioteki DLL otrzymane z serwera C&C. | |
Uporczywość | T1542.003 | Rozruch przed systemem operacyjnym: Bootkit | Bootkit BlackLotus jest wdrażany na partycji systemowej EFI i wykonywany podczas rozruchu. |
Eskalacja uprawnień | T1548.002 | Nadużycie mechanizmu kontroli podniesienia uprawnień: Obejście kontroli konta użytkownika | Instalator BlackLotus próbuje zwiększyć uprawnienia, omijając Kontrolę konta użytkownika. |
T1134.002 | Manipulacja tokenem dostępu: tworzenie procesu za pomocą tokena | Narzędzie do pobierania HTTP BlackLotus może używać WTSQueryUserToken i CreateProcessAsUserW do wykonywania pobranych ładunków w ramach nowego procesu z lokalnymi uprawnieniami systemowymi. | |
Unikanie obrony | T1622 | Unikanie debugera | Komponenty BlackLotus wykorzystują różne techniki do wykrywania, czy na ofierze działa debugger w trybie jądra lub w trybie użytkownika. |
T1574 | Przechwytywanie przepływu wykonywania | BlackLotus bootkit przejmuje różne komponenty zawarte we wczesnych etapach procesu rozruchu systemu Windows (Menedżer rozruchu systemu Windows, program ładujący system operacyjny Windows, jądro systemu Windows i określone sterowniki), aby uniknąć wykrycia poprzez dezaktywację różnych funkcji bezpieczeństwa systemu Windows (VBS, Windows Defender) i potajemnie uruchamia swój tryb jądra i komponenty trybu użytkownika | |
T1562 | Osłabiaj obronę | Komponenty BlackLotus mogą wyłączyć funkcję BitLocker i Windows Defender, aby uniknąć wykrycia. | |
T1070.004 | Usuwanie wskaźnika: usuwanie plików | Instalator BlackLotus usuwa się sam po pomyślnym wdrożeniu plików na partycji EFI System. Również po udanej eksploatacji CVE-2022-21894 BlackLotus usuwa ślady eksploatacji, usuwając wszystkie pliki zawarte w łańcuchu eksploatacji z partycji systemowej EFI. | |
T1070.009 | Usunięcie wskaźnika: wyczyść trwałość | BlackLotus może się sam odinstalować, usuwając wszystkie pliki bootkitów z ESP i przywracając oryginalnego Menedżera rozruchu systemu Windows ofiary. | |
T1036.005 | Maskarada: Dopasuj legalną nazwę lub lokalizację | BlackLotus próbuje ukryć swoje pliki wdrożone na ESP, używając legalnych nazw plików, takich jak grubx64.efi (jeśli UEFI Secure Boot jest włączony na zaatakowanej maszynie) lub bootmgfw.efi (jeśli UEFI Secure Boot jest wyłączony na zaatakowanej maszynie). | |
T1112 | Zmodyfikuj rejestr | Instalator BlackLotus modyfikuje rejestr systemu Windows, aby wyłączyć funkcję zabezpieczeń systemu Windows HVCI. | |
T1027 | Zaciemnione pliki lub informacje | Niemal wszystkie ciągi osadzone w komponentach BlackLotus są szyfrowane przy użyciu niestandardowego szyfru kombinowanego i odszyfrowywane tylko w razie potrzeby. | |
T1027.007 | Zaciemnione pliki lub informacje: dynamiczne rozpoznawanie interfejsu API | Komponenty BlackLotus używają dynamicznego rozpoznawania API, używając skrótów nazw API zamiast nazw. | |
T1027.009 | Zaciemnione pliki lub informacje: osadzone ładunki | Prawie wszystkie pliki osadzone w komponentach BlackLotus są szyfrowane przy użyciu algorytmu AES. | |
T1542.003 | Rozruch przed systemem operacyjnym: Bootkit | Bootkit BlackLotus jest instalowany na partycji systemowej EFI i uruchamiany podczas wczesnych etapów uruchamiania systemu operacyjnego, dzięki czemu jest w stanie kontrolować proces uruchamiania systemu operacyjnego i unikać wykrycia. | |
T1055.012 | Wstrzykiwanie procesu: wstrzykiwanie biblioteki z dynamicznym łączem | Narzędzie do pobierania HTTP BlackLotus może wstrzyknąć bibliotekę DLL do nowo utworzonego pliku svchost.exe proces wykorzystujący drążenie procesowe. | |
T1055.002 | Wstrzykiwanie procesu: Przenośne wstrzykiwanie pliku wykonywalnego | Sterownik BlackLotus wstrzykuje przenośny plik wykonywalny downloadera HTTP do pliku winlogon.exe proces. | |
T1014 | Rootkit | Sterownik jądra BlackLotus chroni pliki bootkitów na ESP przed usunięciem. | |
T1497.001 | Wirtualizacja/obejście piaskownicy: kontrole systemu | BlackLotus stosuje różne kontrole systemu, w tym sprawdzanie wartości rejestru specyficznych dla piaskownicy, w celu wykrywania i unikania środowisk wirtualizacji i analizy. | |
odkrycie | T1622 | Unikanie debugera | Komponenty BlackLotus wykorzystują różne techniki do wykrywania, czy na ofierze działa debugger w trybie jądra lub w trybie użytkownika. |
T1082 | Wykrywanie informacji o systemie | BlackLotus gromadzi informacje systemowe (IP, GPU, CPU, pamięć, wersja systemu operacyjnego) na zaatakowanym hoście. | |
T1614 | Wykrywanie lokalizacji systemu | BlackLotus może zakończyć działanie, jeśli na zaatakowanym hoście zostanie zidentyfikowana jedna z następujących lokalizacji systemowych: ro-MD, ru-MD, ru-RU, uk-UA, be-BY, hy-AM, kk-KZ. | |
T1016 | Wykrywanie konfiguracji sieci systemu | Narzędzie do pobierania HTTP BlackLotus może określić publiczny adres IP zaatakowanego hosta, wysyłając żądanie api.ipify[.]org service. | |
T1016.001 | Wykrywanie konfiguracji sieci systemowej: Wykrywanie połączenia internetowego | Narzędzie do pobierania HTTP BlackLotus sprawdza połączenie internetowe, wysyłając zapytanie do firmy Microsoft www.msftncsi[.]com/ncsi[.]txt | |
T1497.001 | Wirtualizacja/obejście piaskownicy: kontrole systemu | BlackLotus stosuje różne kontrole systemu, w tym sprawdzanie wartości rejestru specyficznych dla piaskownicy, w celu wykrywania i unikania środowisk wirtualizacji i analizy. | |
Dowodzenia i kontroli | T1071.001 | Protokół warstwy aplikacji: protokoły internetowe | BlackLotus używa protokołu HTTPS do komunikacji z C&C. |
T1132.001 | Kodowanie danych: kodowanie standardowe | BlackLotus koduje zaszyfrowane dane w komunikacji C&C z bezpiecznym dla adresów URL algorytmem base64. | |
T1573.001 | Szyfrowany kanał: kryptografia symetryczna | BlackLotus używa 256-bitowego algorytmu AES w trybie CBC do odszyfrowywania wiadomości otrzymanych ze swojej C&C. | |
T1573.002 | Szyfrowany kanał: kryptografia asymetryczna | BlackLotus używa wbudowanego klucza publicznego RSA do szyfrowania wiadomości wysyłanych do C&C. |
- Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
- Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. Dostęp tutaj.
- Źródło: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- 000
- 1
- 10
- 11
- 2018
- 2020
- 2022
- 7
- 9
- a
- Zdolny
- O nas
- powyżej
- nadużycie
- dostęp
- dostępny
- Dostęp
- Konto
- Osiągać
- Osiąga
- działać
- działania
- aktorzy
- Dzieje Apostolskie
- w dodatku
- dodatek
- Dodatkowy
- adres
- Adresy
- Admin
- zaawansowany
- Korzyść
- reklama
- doradczy
- AES
- wpływający
- Po
- przed
- aka
- Wszystkie kategorie
- przydzielony
- przydziały
- Pozwalać
- pozwala
- już
- Chociaż
- zawsze
- AMD
- wśród
- analiza
- w czasie rzeczywistym sprawiają,
- i
- Anime
- Inne
- api
- Pszczoła
- Aplikacja
- odpowiedni
- Zastosowanie
- aplikacje
- właściwy
- APT
- Archiwum
- na około
- towary
- oszacowanie
- powiązany
- Próby
- Uwaga
- Sierpnia
- autor
- dostępny
- backup
- Kopie zapasowe
- na podstawie
- podstawowy
- Podstawy
- oświetlać
- bo
- zanim
- Początek
- za
- jest
- Białoruś
- uwierzyć
- poniżej
- Ulepsz Swój
- pomiędzy
- BleepingComputer
- Blokować
- Niebieski
- Bonus
- Botki
- botnety
- przerwa
- Przełamując
- przełom
- przynieść
- Bringing
- szeroko
- przyniósł
- bufor
- budować
- wybudowany
- wbudowany
- wezwanie
- powołanie
- Połączenia
- możliwości
- zdolny
- który
- ostrożny
- walizka
- Etui
- casual
- zapasy
- powodowany
- Przyczyny
- spowodowanie
- Centrum
- świadectwo
- łańcuch
- szansa
- zmiana
- Kanał
- kontrola
- Wykrywanie urządzeń szpiegujących
- szyfr
- roszczenia
- jasny
- klient
- Zamknij
- zamknięte
- bliższy
- zamknięcie
- kod
- koledzy
- Kolumbia
- połączenie
- połączony
- jak
- skomentował
- wspólny
- powszechnie
- komunikować
- przyległy
- Komunikacja
- w porównaniu
- porównanie
- zgodność
- całkowicie
- kompleks
- kompleksowość
- składnik
- składniki
- kompromis
- Zagrożone
- pojęcie
- zaniepokojony
- pewność siebie
- systemu
- ZATWARDZIAŁY
- połączenie
- wobec
- konsument
- zawierać
- zawiera
- zawartość
- kontynuować
- ciągły
- bez przerwy
- kontrola
- kontrolowania
- współpraca
- rdzeń
- Odpowiedni
- mógłby
- Kurs
- pokrycie
- Stwórz
- stworzony
- tworzy
- Tworzenie
- POŚWIADCZENIE
- krytyczny
- Aktualny
- Obecnie
- zwyczaj
- Niebezpieczny
- dane
- Centrum danych
- Baza danych
- Data
- dezaktywacja
- czynienia
- Śmierć
- Odszyfruj
- głęboko
- głębiej
- Domyślnie
- zdefiniowane
- Zdecydowanie
- zależy
- rozwijać
- wdrażane
- wdrażanie
- Wdrożenie
- wdraża się
- Pochodny
- opisać
- opisane
- życzenia
- Mimo
- miejsce przeznaczenia
- detal
- szczegółowe
- detale
- wykryte
- Wykrywanie
- Ustalać
- określaniu
- rozwinięty
- Deweloper
- deweloperzy
- urządzenie
- urządzenia
- ZROBIŁ
- różnica
- różne
- KOPAĆ
- kierować
- bezpośrednio
- katalogi
- niepełnosprawny
- ujawnienie
- odkryj
- odkryty
- odkrycie
- dystrybuowane
- 分配
- Dystrybucje
- robi
- domeny
- nie
- pobieranie
- napęd
- kierowca
- sterowniki
- Spadek
- porzucone
- Rzut
- duplikaty
- podczas
- dynamiczny
- każdy
- Wcześnie
- łatwiej
- z łatwością
- Ekosystem
- edycja
- faktycznie
- wysiłek
- Elementy
- ELEWACJA
- podniesiony
- osadzone
- zatrudnia
- włączony
- szyfrowane
- szyfrowanie
- Inżynieria
- dość
- zapisany
- zapewnić
- wejście
- Środowisko
- środowiska
- niezbędny
- ustanowienie
- itp
- oceniane
- Parzyste
- wydarzenie
- wydarzenia
- Każdy
- dowód
- przykład
- przykłady
- wyłącznie
- wykonać
- Wykonuje
- wykonywania
- egzekucja
- Przede wszystkim system został opracowany
- Wyjście
- Wyjaśniać
- wyjaśnienie
- Wykorzystać
- eksploatacja
- eksploatowany
- exploity
- odkryj
- rozbudowa
- zewnętrzny
- wykonalny
- Cecha
- polecane
- Korzyści
- facet
- kilka
- Łąka
- Postać
- filet
- Akta
- filtrować
- finał
- Znajdź
- znalezieniu
- i terminów, a
- ustalony
- Migać
- pływ
- obserwuj
- następujący
- następujący sposób
- na zawsze
- Nasz formularz
- format
- Dawny
- Forum
- Naprzód
- znaleziono
- od
- pełny
- w pełni
- funkcjonować
- funkcjonalny
- Funkcjonalność
- Funkcje
- dalej
- Games
- Bramka
- wygenerowane
- otrzymać
- dany
- daje
- cel
- GPU
- Zielony
- Grupy
- osłona
- włamanie
- Uchwyty
- siła robocza
- zdarzyć
- dzieje
- sprzęt komputerowy
- mający
- headers
- tutaj
- Ukryj
- Wysoki
- Odsłon
- Haczyki
- gospodarz
- W jaki sposób
- Jednak
- HTTPS
- Setki
- zidentyfikowane
- identyfikator
- zidentyfikować
- obraz
- zdjęcia
- natychmiast
- Rezultat
- realizowane
- wykonawczych
- import
- niemożliwy
- in
- włączony
- Włącznie z
- indywidualny
- Informacja
- informacyjny
- początkowy
- zainstalować
- zainstalowany
- zamiast
- zintegrowany
- integralność
- Intel
- Inteligencja
- wzajemne oddziaływanie
- Internet
- połączenie internetowe
- Wprowadzenie
- śledztwo
- zaangażowany
- IP
- problem
- IT
- samo
- styczeń
- Praca
- skoki
- Kaspersky
- Kazachstan
- konserwacja
- Klawisz
- Klawisze
- znany
- Nazwisko
- Ostatni rok
- Późno
- firmy
- uruchomić
- warstwa
- prowadzić
- Wyprowadzenia
- pozostawiając
- Lenovo
- Li
- Biblioteka
- Prawdopodobnie
- LIMIT
- linux
- Lista
- Katalogowany
- wykazy
- mało
- załadować
- ładowarka
- załadunek
- masa
- miejscowy
- usytuowany
- lokalizacja
- długo
- długi czas
- Popatrz
- stracić
- niski
- mac
- maszyna
- maszyny
- zrobiony
- magia
- Główny
- poważny
- robić
- WYKONUJE
- Dokonywanie
- malware
- zarządzane
- kierownik
- Manipulacja
- ręcznie
- wiele
- Mecz
- Materia
- Maksymalna szerokość
- znaczenie
- mechanizm
- Pamięć
- wzmiankowany
- jedynie
- wiadomość
- wiadomości
- metoda
- Microsoft
- może
- minimum
- chwila
- łagodzenie
- Moda
- zmodyfikowano
- modyfikować
- Moduł
- moment
- monitorowane
- monitory
- miesięcy
- jeszcze
- większość
- motywacje
- ruch
- wielokrotność
- Nazwa
- O imieniu
- Nazwy
- rodzimy
- niezbędny
- Potrzebować
- Nieproduktywny
- wymagania
- sieć
- Nowości
- Następny
- normalnie
- numer
- z naszej
- obiekty
- uzyskać
- październik
- Oferty
- nieaktywny
- Stary
- ONE
- Online
- otwiera
- działać
- operacyjny
- działanie
- operator
- Option
- Opcje
- zamówienie
- oryginalny
- OS
- Inne
- Inaczej
- Przezwyciężać
- przegląd
- własny
- własność
- właściciel
- parametr
- parametry
- część
- strony
- Łata
- Łatki
- łatanie
- ścieżka
- Wzór
- wzory
- doskonały
- wykonać
- wykonywania
- uporczywość
- fizyczny
- kawałek
- Platforma
- plato
- Analiza danych Platona
- PlatoDane
- PoC
- punkt
- zwrotnica
- polityka
- możliwy
- Post
- Wiadomości
- potencjał
- mocny
- obecność
- teraźniejszość
- zapobiec
- poprzedni
- poprzednio
- Zasady
- prywatny
- Klucz prywatny
- przywileje
- Problem
- problemy
- dochód
- wygląda tak
- Obrobiony
- procesów
- Produkt
- Program
- wybitny
- dowód
- dowód koncepcji
- prawidłowo
- chronić
- chroniony
- ochrony
- ochrona
- protokół
- pod warunkiem,
- że
- publiczny
- Klucz publiczny
- publikacje
- publicznie
- opublikowany
- cel
- podnieść
- RAM
- przypadkowy
- szybko
- osiągnięty
- Czytaj
- Czytelnik
- Czytający
- real
- Rzeczywistość
- zrealizować
- powód
- rozsądny
- Odebrane
- niedawny
- Recover
- regeneracja
- referencje
- , o którym mowa
- Bez względu
- rejestry
- rejestr
- regularny
- związane z
- pozostawać
- usuwanie
- usunąć
- Usunięto
- usuwanie
- obsługi produkcji rolnej, która zastąpiła
- otrzymuje
- Raporty
- składnica
- zażądać
- wymagany
- Badania naukowe
- badacz
- Badacze
- Rozkład
- zdecydowany
- Zasób
- odpowiedź
- odpowiedzialny
- REST
- przywrócenie
- dalsze
- powrót
- rewers
- Rola
- korzeń
- RSA
- rsakonferencja
- run
- bieganie
- Rosja
- najbezpieczniejszym
- taki sam
- piaskownica
- oszustwo
- skanowanie
- schemat
- Ekran
- poszukiwania
- druga
- sekund
- Sekcja
- działy
- bezpieczne
- bezpieczeństwo
- wydaje
- wysyłanie
- rozsądek
- seryjny
- Serie
- usługa
- Usługi
- Sesja
- zestaw
- Zestawy
- ustawienie
- kilka
- Share
- Short
- powinien
- pokazane
- Targi
- znak
- Sygnały
- podpisana
- podpisywanie
- znaki
- podobny
- Prosty
- uproszczony
- po prostu
- ponieważ
- SIX
- Rozmiar
- So
- dotychczas
- Miękki
- Tworzenie
- sprzedany
- rozwiązanie
- kilka
- Ktoś
- coś
- Źródła
- Typ przestrzeni
- specyficzny
- specyfikacja
- określony
- Rozpościerający się
- STAGE
- etapy
- standalone
- standard
- stojaki
- początek
- rozpoczęty
- rozpocznie
- startup
- Rynek
- pobyt
- Ewolucja krok po kroku
- Cel
- Nadal
- zatrzymany
- sklep
- przechowywany
- bezpośredni
- Struktura
- uległość
- kolejny
- udany
- Z powodzeniem
- taki
- Wskazuje
- streszczać
- PODSUMOWANIE
- wsparcie
- Utrzymany
- Wspierający
- podpory
- domniemany
- zawieszony
- symbol
- składnia
- system
- systemy
- stół
- Brać
- trwa
- biorąc
- rozmawiać
- cel
- zadania
- zespół
- Techniczny
- Techniki
- tymczasowy
- Połączenia
- Podstawy
- Informacje
- ich
- w związku z tym
- rzecz
- rzeczy
- tysiące
- groźba
- podmioty grożące
- zagrożenia
- trzy
- Przez
- czas
- Oś czasu
- typ
- do
- już dziś
- razem
- żeton
- także
- narzędzia
- aktualny
- rozsierdzony
- zaufany
- SKRĘCAĆ
- Obrócony
- Obrócenie
- typowy
- Ukraina
- dla
- zrozumienie
- nowomodny
- Aktualizacja
- zaktualizowane
- Nowości
- us
- Stosowanie
- posługiwać się
- Użytkownik
- zazwyczaj
- użyteczność
- wartość
- Wartości
- różnorodny
- Weryfikacja
- zweryfikowana
- zweryfikować
- wersja
- przez
- Ofiara
- Ofiary
- NARUSZENIE
- Naruszenia
- widoczność
- Tom
- kłęby
- Luki w zabezpieczeniach
- wrażliwość
- Wrażliwy
- Czekanie
- sposoby
- sieć
- znane
- Co
- Co to jest
- czy
- który
- Podczas
- cały
- szeroki
- Wikipedia
- Dziki
- będzie
- okna
- Okna 11
- w ciągu
- bez
- Praca
- działa
- najgorszy
- by
- pisanie
- napisany
- rok
- lat
- You
- Twój
- zefirnet
- zero