bootkit
| Po angielsku | bootkit |
|---|---|
| Którą formą pisać | po angielsku Polski odpowiednik istnieje, ale w praktyce nikt tak nie pisze. Zostaw angielski, polski trzymaj jako synonim. |
| Inne formy | rootkit sektora rozruchowego · złośliwy kod ładowany przed systemem |
| Kategoria | Złośliwe oprogramowanie |
Bootkit to odmiana złośliwego oprogramowania (malware), która modyfikuje sektory rozruchowe dysku albo pliki programu rozruchowego, dzięki czemu jej kod wykonuje się, zanim załaduje się system operacyjny [1]. Jest bliskim krewnym rootkita: oba mają ukryć obecność intruza, ale bootkit robi to z poziomu, który system i jego zabezpieczenia widzą najsłabiej. NIST opisuje rootkit jako zestaw plików, który zmienia standardowe działanie hosta w złośliwy i ukryty sposób, przez co trudno ustalić, że w ogóle jest obecny [6].
Jak działa
Komputer przy starcie wykonuje łańcuch programów: oprogramowanie układowe płyty głównej, program rozruchowy, jądro systemu, a dopiero na końcu sterowniki i programy ochronne. Bootkit wstawia się w początek tego łańcucha. MITRE opisuje dwa warianty. W komputerach z klasycznym BIOS-em modyfikowany jest Master Boot Record (MBR) albo Volume Boot Record (VBR). W komputerach z UEFI atakujący tworzy lub zmienia pliki na partycji systemowej EFI, żeby uruchomić złośliwy kod jądra [1].
Kolejność uruchamiania ma znaczenie praktyczne. W opisie rozruchu Windows Microsoft podaje, że oprogramowanie antywirusowe ładuje się dopiero po menedżerze rozruchu i jądrze [4]. Kod, który wystartował wcześniej, może więc ukrywać pliki, wyłączać mechanizmy ochronne i fałszować to, co widzi program ochronny. Schemat poniżej pokazuje, w którym miejscu łańcucha działa bootkit.
Obroną na tym etapie jest bezpieczny rozruch (Secure Boot). Według Microsoftu przy starcie komputera firmware sprawdza podpis każdego elementu oprogramowania rozruchowego: sterowników UEFI, aplikacji EFI i systemu operacyjnego. Kontrolę przekazuje systemowi tylko wtedy, gdy podpisy są prawidłowe [4]. Dozwolone podpisy leżą w bazie db, a unieważnione w bazie dbx. Jeśli skrót obrazu jest w obu, wygrywa lista unieważnień [4].
Odmiany
| Odmiana | Co zmienia | Przykład ze źródeł |
|---|---|---|
| bootkit MBR/VBR | sektor rozruchowy dysku [1] | APT41 używał bootkitów MBR w Windows [1] |
| bootkit UEFI | pliki na partycji EFI [1] | BlackLotus, HybridPetya [2] [3] |
| implant w firmware | pamięć flash płyty głównej [5] | TrickBot potrafi wszczepić kod do firmware [1] |
Granica między bootkitem a złośliwym firmware jest płynna. NIST w wytycznych dotyczących BIOS-u ostrzega, że nieautoryzowana zmiana oprogramowania układowego może skończyć się trwałą awarią komputera albo trwałą instalacją złośliwego kodu [5]. Wytyczne obejmują klasyczny BIOS, EFI i UEFI przechowywane w pamięci flash [5], dlatego aktualizacja firmware powinna przyjmować tylko podpisane obrazy.
W WordPressie
Bootkit nie infekuje WordPressa. Działa poniżej systemu operacyjnego, a WordPress to aplikacja PHP uruchomiona dużo wyżej. Wtyczka bezpieczeństwa ani skaner złośliwego oprogramowania (malware scanner) działający w PHP nie widzi sektora rozruchowego ani partycji EFI serwera. Znaczenie bootkitów dla stron WordPress jest pośrednie.
- Komputer administratora. Bootkit może wyłączyć ochronę systemu, a potem wpuścić dowolne inne narzędzia. BlackLotus potrafi wyłączyć BitLocker, HVCI i Microsoft Defender [2]. Na takim komputerze keylogger albo infostealer przechwyci hasło do panelu i dane uwierzytelniające do serwera.
- Serwer. Na hostingu współdzielonym rozruch maszyny jest odpowiedzialnością dostawcy. Na własnym serwerze VPS lub fizycznym odpowiada za niego administrator, a obowiązuje go ta sama zasada co w przypadku każdego komputera: podpisany rozruch i aktualne oprogramowanie układowe [4].
- Sprzątanie po incydencie. Jeśli bootkit był na komputerze, z którego logowano się do WordPressa, samo czyszczenie przejętej strony nie wystarczy. Hasła trzeba zmienić z innego, czystego urządzenia.
Zagrożenia i skutki
Główną cechą bootkitu jest trwałość i niewidzialność. Kod startujący przed systemem przetrwa reinstalację aplikacji, a często także samego systemu, jeśli atakujący zmienił firmware [5]. MITRE wymienia jako przykłady grupę APT28, która użyła bootkitu razem z narzędziem Downdelph, oraz destrukcyjne WhisperGate, które nadpisywało MBR komponentem niszczącym dane [1]. Ten drugi przykład pokazuje, że bootkit może służyć nie tylko do ukrywania się, lecz także jako wiper.
Bootkit bywa też częścią ransomware. HybridPetya, opisany przez badaczy ESET, instaluje się na partycji systemowej EFI, przejmuje rozruch przed startem Windows i szyfruje tablicę MFT partycji NTFS algorytmem Salsa20 [3]. W czasie szyfrowania wyświetla użytkownikowi fałszywy komunikat programu CHKDSK [3].
Jak się bronić
MITRE zaleca dwie grupy zabezpieczeń: integralność rozruchu, czyli moduł TPM i bezpieczny lub zaufany proces rozruchu, oraz ograniczenie kont z uprawnieniami potrzebnymi do instalacji bootkitu [1]. Druga zasada to po prostu zasada najmniejszych uprawnień: kto nie pracuje na koncie administratora, ten nie zmieni sektora rozruchowego jednym kliknięciem. Do wykrywania MITRE proponuje obserwację bezpośredniego dostępu do dysków fizycznych, zmian rekordów MBR i VBR oraz podejrzanych plików na partycji EFI [1].
Sam Secure Boot nie wystarcza, jeśli lista unieważnień jest nieaktualna. Przypadek BlackLotus pokazał, że podatny, ale podpisany program rozruchowy pozostaje furtką, dopóki nie trafi do bazy dbx [2]. Dlatego obok aktualizacji systemu potrzebne są aktualizacje firmware i baz Secure Boot. Microsoft informuje, że certyfikaty Secure Boot wydane w 2011 roku zaczynają wygasać w czerwcu 2026 roku i trzeba je zaktualizować z wyprzedzeniem [4].
Po wykryciu bootkitu zwykłe usuwanie plików zawodzi. NIST wskazuje, że gdy na hoście zainstalowano rootkity lub tylne furtki (backdoor), najpewniejszym sposobem przywrócenia integralności jest odbudowa hosta, czyli ponowna instalacja systemu i odtworzenie danych ze sprawdzonej kopii zapasowej (backup) [6]. Przy bootkicie UEFI odbudowa obejmuje także partycję EFI, a przy implancie w firmware ponowne wgranie zaufanego obrazu oprogramowania układowego [5].
Historia i przykłady
- BlackLotus (2022–2023). ESET 1 marca 2023 roku opisał BlackLotus jako pierwszy publicznie znany bootkit UEFI, który omija Secure Boot i działa na w pełni zaktualizowanym Windows 11 z włączonym Secure Boot [2]. Wykorzystywał CVE-2022-21894, lukę załataną przez Microsoft w styczniu 2022 roku, której podatne pliki nie trafiły jeszcze na listę unieważnień [2]. Był oferowany na podziemnych forach co najmniej od 6 października 2022 roku za 5000 dolarów [2].
- HybridPetya (2025). Sekurak 23 września 2025 roku opisał odkryty przez ESET ransomware z bootkitem, który omija Secure Boot przez lukę CVE-2024-7344 [3]. Żądał okupu 1000 dolarów w bitcoinach [3].
Przypisy
6- [1] Pre-OS Boot: Bootkit (T1542.003) · MITRE ATT&CK
- [2] BlackLotus UEFI bootkit: Myth confirmed · ESET Research
- [3] HybridPetya – ransomware omijający zabezpieczenie UEFI Secure Boot · Sekurak
- [4] Secure boot · Microsoft Learn
- [5] SP 800-147: BIOS Protection Guidelines · NIST
- [6] SP 800-83 Rev. 1: Guide to Malware Incident Prevention and Handling for Desktops and Laptops · NIST
Hasła w tym artykule
17- złośliwe oprogramowanie
- rootkit
- bezpieczny rozruch
- aktualizacja firmware
- wtyczka bezpieczeństwa
- skaner złośliwego oprogramowania (malware scanner)
- keylogger
- infostealer
- dane uwierzytelniające
- hosting współdzielony
- czyszczenie przejętej strony
- wiper
- ransomware
- zasada najmniejszych uprawnień
- tylna furtka
- kopia zapasowa
- CVE