UEFI Bootkit: dari laboratorium ke kenyataan, dengan fokus pada Bootkitty dan BlackLotus

Los Bootkit UEFI Hanya dalam beberapa tahun, mereka telah berubah dari konsep laboratorium menjadi masalah besar bagi para pembela HAM dan produsen. Dalam hal ini, batas antara bukti konsep dan ancaman operasional menjadi kabur, dan kasus-kasus seperti Teratai Hitam atau penemuan baru-baru ini Bootkitty di Linux Mereka membuktikannya dengan jelas.

Artikel ini menyatukan dan menjelaskan, dengan bahasa yang jelas dan detail teknis ketika mereka menambahkan nilai, yang paling relevan diterbitkan oleh para peneliti dan perusahaan di sektor ini: dari PoC pertama pada tahun 2012 hingga kampanye modern, termasuk kerentanan seperti CVE-2024-7344 yang memungkinkan Anda melewati Secure Boot, teknik penghindaran, IoC, serta tindakan deteksi dan mitigasi yang benar-benar berfungsi di dunia nyata.

Apa itu bootkit UEFI dan mengapa begitu bermasalah?

Bootkit UEFI adalah implan yang berjalan sebelum sistem operasi, dengan kemampuan untuk mengendalikan aliran boot, nonaktifkan pemeriksaan, dan muat komponen dengan hak istimewa tinggi. Dengan beroperasi pada tingkat yang begitu rendah, Anda dapat menghindari antivirus tradisional dan bahkan tertentu "tindakan awal yang aman" jika mengeksploitasi kelemahan atau konfigurasi yang permisif.

Di dunia nyata, implan dan teknik UEFI yang persisten telah diamati, seperti LoJax, MosaikRegressor o BulanBounce, tonggak sejarah yang menunjukkan bagaimana seorang aktor bisa menempati firmware dan menguasai fase kritis boot, yang mempersulit analisis forensik dan remediasi.

Mempertahankan WindowsMicrosoft merantai beberapa lapisan: Secure Boot (UEFI memvalidasi loader dengan sertifikat tepercaya), Boot Tepercaya (kernel memvalidasi komponen lainnya), ELAM (Early Launch Antimalware, yang memeriksa driver boot) dan Boot Terukur (Pengukuran TPM dan pengesahan jarak jauh). Ini merupakan hambatan yang berguna, namun tidak sempurna, untuk kerentanan ekosistem itu sendiri UEFI atau pengaturan kepercayaan yang terlalu luas. Selain itu, ada kemungkinan jendela perisai dengan Credential Guard, BitLocker, dan WDAC untuk mengurangi risiko persistensi jangka panjang.

Dari PoC ke Kehidupan Nyata: Garis Waktu dan Pemain Kunci

Perjalanan dimulai pada tahun 2012 dengan PoC Andrea Allievi untuk Windows di UEFI, diikuti oleh proyek-proyek seperti EfiGuard, Boot Backdoor, atau UEFI-bootkit. Butuh waktu bertahun-tahun hingga kasus-kasus yang terjadi di luar kendali terdokumentasikan, seperti ESPeter (ESET, 2021) atau Perangkat lunak FinSpy (Kaspersky, 2021), dan pada tahun 2023 muncul ke permukaan Teratai Hitam, bootkit UEFI pertama yang mampu Lewati Boot Aman pada sistem yang diperbarui sepenuhnyaDi lingkungan laboratorium, hal ini umum terjadi menguji malware pada mesin virtual untuk mengevaluasi PoC dan deteksi tanpa membahayakan infrastruktur produktif.

Ada sesuatu yang konstan sampai sekarang: targetnya adalah khusus komputer WindowsAsumsi itu hancur ketika aplikasi UEFI bernama VirusTotal muncul di VirusTotal pada November 2024. bootkit.efiAnalisis tersebut mengungkap sebuah bootkit, yang dijuluki oleh penulisnya sebagai Bootkitty, dirancang untuk Linux (Ubuntu)Berdasarkan telemetri, tidak ada konfirmasi penempatan sebenarnya; dan penulisnya sendiri, yang terhubung dengan program pelatihan Korea Terbaik dari yang Terbaik (BoB), mereka mengklarifikasi bahwa itu adalah bukti dari konsep dengan tujuan meningkatkan kesadaran.

Biner Bootkitty ditandatangani dengan sertifikat yang ditandatangani sendiri. Ini berarti tidak akan berjalan dengan Secure Boot diaktifkan kecuali instal sertifikat penyerang. Namun, logikanya menggambarkan bagaimana seorang aktor dapat menambal, dalam memori, komponen-komponen pemuat (GRUB) y kernel linux untuk melewati pemeriksaan.

Bootkitty secara detail: artefak, kompatibilitas, dan apa yang dimodifikasinya

Bootkit berisi fungsi yang tidak digunakan yang mencetak seni ASCII dengan nama Bootkitty dan daftar kemungkinan penulis. Ini juga menampilkan rangkaian teks di setiap permulaan dan referensi ke kucing hitam dalam outputnya dan dalam modul kernel terkait, tidak terkait dengan ransomware ALPHV/BlackCat; sebagian karena Bootkitty ditulis dalam C, sementara ALPHV berkembang di Rust.

Kompatibilitasnya terbatas. Untuk menemukan fungsi mana yang harus disentuh, gunakan pola byte yang dikodekan (teknik bootkit klasik), tetapi pola yang dipilih tidak mencakup beberapa versi kernel atau GRUB dengan baik. Akibatnya, implan hanya berfungsi dalam konfigurasi yang sangat terbatas, dan lebih lanjut, patch memperbaiki offset setelah dekompresi kernel: jika offset tidak cocok dengan versinya, hal tersebut dapat menimpa data acak dan menyebabkan tutup telepon alih-alih komitmen.

Sepatu bot dimulai dengan shim menjalankan Bootkitty, yang pertama-tama menanyakan status SecureBoot dan menempatkan kait ke dalam dua protokol autentikasi UEFI: Otentikasi Berkas EFI_SECURITY2_ARCH_PROTOCOL y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState. Dalam kedua kasus, atur output untuk kembali EFI_SUKSES, yang secara efektif meniadakan pemeriksaan integritas gambar PE selama pra-OS.

Bootkitty kemudian memuat GRUB yang sah dari jalur hardcoded di ESP (/EFI/ubuntu/grubx64-real.efi), menambalnya di memori dan fungsi kunci kait sebelum dieksekusi.

Menghubungkan ke GRUB dan mengekstrak kernel Linux

Implan mengubah fungsi gambar_mulai dari modul peimage GRUB, bertanggung jawab untuk meluncurkan biner PE yang sudah dimuat (seperti Rintisan kernel EFI, vmlinuz.efi/vmlinuz). Manfaatkan fakta bahwa kernel sudah ada di memori dan tempatkan hook dalam rutin yang mendekompresi citra kernel yang sebenarnya (mungkin zstd_dekompresi_dctx tergantung pada build), jadi setelah dibuka ritsletingnya, Anda dapat tempelkan pada hot patch.

Ini juga memodifikasi fungsi grub_verifiers_terbuka, yang memutuskan apakah akan memverifikasi integritas setiap berkas yang dimuat (modul, kernel, konfigurasi, dll.). Hook akan segera kembali, dan dengan demikian, menghindari verifikasi tanda tangan apa pun. Sementara itu, penyesuaian dalam shim_lock_verifier_init Membingungkan: hal ini memaksa bendera verifikasi yang lebih ketat (GRUB_VERIFIKASI_BENDERA_CHUNK_TUNGGAL), tetapi fungsi ini bahkan tidak dipanggil oleh hook lainnya, meninggalkan Tidak relevan.

Setelah kernel didekompresi, kode Bootkitty menerapkan tiga modifikasi memori: menulis ulang string versi/spanduk dari kernel dengan teks "BoB13"; paksa itu modul_sig_check() kembalikan 0 agar kernel dimuat modul yang tidak ditandatangani; dan menggantikan variabel lingkungan pertama dari proses tersebut init untuk menyuntikkan LD_PRELOAD=/opt/injector.so /init di awal ruang pengguna.

Injeksi oleh LD_PRELOAD Ini adalah taktik klasik untuk memprioritaskan objek bersama ELF dan mengesampingkan fungsi. Di sini, rantai tersebut memiliki kekhasan (termasuk "/init" di samping LD_PRELOAD), sebuah detail yang memperkuat karakter PoC yang Belum Selesai alih-alih operasi yang dipoles. Biner yang seharusnya disuntikkan tidak diamati, meskipun tulisan pihak ketiga berikutnya menunjukkan bahwa mereka hanya digunakan untuk memuat tahap tambahan.

Indikator, gejala dan solusi sederhana

Jika Bootkitty ada, petunjuk yang terlihat dapat terlihat. Perintah nama pengguna -v akan menampilkan versi kernel dengan teks yang diubah dan di dmesg Spanduk tersebut mungkin juga tampak dimodifikasi. Selain itu, dapat dideteksi bahwa prosesnya ID 1 (init) dirilis dengan LD_PRELOAD memeriksa /proc/1/lingkungan, sinyal anomali dalam sistem yang sah.

Dalam pengujian laboratorium, kernel muncul tercemar setelah boot dengan Bootkitty, dan pemeriksaan empiris lainnya pada komputer dengan Secure Boot diaktifkan adalah mencoba memuat modul yang tidak ditandatangani:Jika pemuatan panas diizinkan, ini menunjukkan bahwa pemeriksaan_tanda_tangan_modul telah ditambal.

Jika bootkit telah diinstal dengan mengganti biner GRUB dengan perantara (perilaku yang diamati), cara mudah untuk memulihkannya adalah dengan memindahkan GRUB yang sah dari /EFI/ubuntu/grubx64-real.efi ke rute aslinya /EFI/ubuntu/grubx64.efi untuk shim jalankan dan rantai boot berlanjut tanpa mencangkok.

BCDropper dan BCObserver: Kesatuan yang Terhubung atau Hanya Kebetulan?

Modul kernel yang tidak ditandatangani yang dijuluki Bootkitty ditemukan bersama Bootkitty Penitis BC, yang berbagi petunjuk dengan bootkit: string Kucing Hitam/kucing hitam dalam metadata dan jalur debug, dan fungsi dari menyembunyikan file yang awalannya termasuk "injector" (sesuai dengan variabel LD_PRELOAD menunjuk ke /opt/injector.so).

Daun BCDropper masuk /opt/pengamat ELF tertanam (disebut Pengamat BCO) dan meluncurkannya melalui / bin / bashKomponen yang cukup sederhana ini menunggu gdm3 aktif dan kemudian memuat modul kernel dari /opt/rootkit_loader.ko menggunakan modul_hingga, pastikan untuk melakukannya setelah sistem selesai di-boot sepenuhnya.

Meskipun ada tanda-tanda hubungan, tidak mungkin untuk menjamin bahwa kedua elemen tersebut berasal dari pembuat yang sama atau bahwa keduanya dirancang untuk bekerja sama. Lebih parah lagi, versi kernel yang disebutkan dalam metadatanya (6.8.0-48-generik) bahkan tidak tercantum di antara yang didukung oleh bootkit.

IoC terkait

Artefak berikut telah dikaitkan dengan temuan yang dibahas. Nilainya terutama referensi dan laboratorium:

BlackLotus dan CVE-2022-21894: Tonggak sejarah yang membuka pintu air

BlackLotus telah ada di pasaran sejak tahun 2022 dengan harga sekitar 5.000 USD (ditambah tambahan per peningkatan) dan mencakup teknik untuk anti-VM/anti-penghindaran debug, geofencing untuk menghindari negara-negara tertentu (Armenia, Belarus, Kazakhstan, Moldova, Rumania, Rusia dan Ukraina) dan, yang paling penting, eksploitasi CVE-2022-21894 (Baton Drop) untuk melewati Boot Aman dan mencapai persistensi yang kuat pada mesin Windows 10/11 yang telah ditambal sepenuhnya.

Alur yang dijelaskan oleh komunitas keamanan mencakup fase pertama dengan penonaktifan perlindungan sistem operasi, eksploitasi kerentanan lama di Secure Boot dan mendaftarkan kunci pemilik mesin dikendalikan oleh penyerang. Setelah reboot lebih lanjut, implan menyebarkan penggerak kernel dan tipe komponen mode pengguna downloader untuk mengelola komunikasi komando dan kontrol dan biaya tambahan.

Untuk pertahanan proaktif, komunitas telah menerbitkan aturan operasional. Misalnya, SOC Prime menawarkan deteksi Sigma yang mencari pembuatan file firmware yang mencurigakan di System32 oleh proses non-sistem atau Penonaktifan HVCI melalui pencatatan. Jenis sinyal ini, yang dipetakan ke MITRE ATT&CK (misalnya, T0857, T1562, T1112), membantu untuk perburuan aktivitas anomali yang biasanya disertakan dengan bootkit; ada juga panduan praktis untuk Deteksi proses berbahaya dengan Process Explorer di lingkungan Windows.

CVE-2024-7344: Memuat biner UEFI yang tidak tepercaya melalui "reloader.efi"

Kerentanan yang sangat sensitif ditemukan pada tahun 2024, CVE-2024-7344, yang memengaruhi beberapa rangkaian pemulihan yang ditandatangani oleh sertifikat Microsoft Corporation UEFI CA 2011Akar permasalahannya adalah penggunaan pemuat PE khusus di aplikasi UEFI reloader.efi, alih-alih API yang aman MuatGambar/GambarAwal. Biner mendekripsi dan mengeksekusi konten dari sebuah file cloak.dat tanpa memverifikasi tanda tangan sesuai dengan kebijakan Secure Boot.

Vektornya tidak terbatas pada komputer dengan perangkat lunak yang terpasang, karena penyerang dengan hak istimewa yang lebih tinggi dapat menyebarkannya biner rentan di ESP (partisi EFI) sistem apa pun yang mempercayai UEFI CA pihak ketiga Microsoft dan menyebabkan eksekusi UEFI tidak ditandatangani saat startup. Produk yang terdampak termasuk rangkaian produk dari Howyar, Greenware, Radix, SANFONG, Wasay, CES, dan Signal Computer, serta dikoreksi dan dicabut pada 14 Januari 2025.

Untuk memverifikasi perlindungan en PowerShell dengan hak istimewa yang lebih tinggi dan Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Kasus ini membuka kembali perdebatan mengenai rantai kepercayaan:Microsoft memelihara dua sertifikat yang banyak terdapat pada komputer UEFI konsumen dan perusahaan (Produksi Windows CA 2011 y UEFI CA 2011 untuk pihak ketiga). Rencana yang ada adalah migrasi ke sertifikat 2023, menyusul insiden seperti BlackLotus dan maraknya bootloader rentan yang ditandatangani bertahun-tahun lalu. Di komputer Inti amanUEFI CA pihak ketiga biasanya disertakan dinonaktifkan secara default.

Perlindungan praktis dan kustomisasi Secure Boot

Selain menerapkan Pencabutan UEFI dan selalu memperbarui firmware/OS (Windows Update dan LVFS), ada langkah-langkah yang mengurangi permukaan serangan: mengendalikan akses ke ESP dengan aturan keamanan, sesuaikan Secure Boot untuk membatasi kepercayaan pada apa yang diperlukan (mengikuti pedoman seperti yang ada di NSA) dan menyebarkan pengesahan dengan TPM untuk memvalidasi status boot dari jarak jauh terhadap nilai referensi.

Di Windows, kombinasi Boot Aman + Boot Tepercaya + ELAM + Boot Terukur Ini menawarkan penghalang berlapis: validasi loader, pengontrol boot diperiksa sebelum yang lain, dan catatan yang ditandatangani oleh TPM yang memungkinkan firewall untuk memisahkan komputer yang "bersih" dari komputer yang memiliki deviasi. Dalam lingkungan terkelola, hal ini mengurangi el tiempo de deteksi dan penahanan.

Di Linux, selain pencabutan dan kontrol ESP, ada baiknya memperhatikan sinyal seperti LD_PRELOAD dalam proses init, negara tercemar dari kernel, dan menghubungkan peristiwa pemuatan modul (misalnya, modul_hingga) dengan rute yang tidak biasa (/opt/*.ko) untuk mendeteksi upaya untuk ketekunan lebih awal.

Alat, Cakupan, dan MITRE ATT&CK

Menurut ESET, ini adalah satu-satunya vendor di 20 titik akhir teratas berdasarkan pendapatan yang mengintegrasikan Pemindai firmware UEFI dalam solusi perlindungan peralatan mereka. Meskipun produsen lain menawarkan teknologi terkait UEFI, tujuan mereka tidak selalu sesuai dengan inspeksi firmware langsungKarena serangan UEFI, meskipun sporadis, memberikan kontrol dan ketekunan total hampir mutlak, berinvestasi pada lapisan ini dapat membuat perbedaan besar.

Dalam hal MITRE ATT&CK, perilaku yang diamati sesuai dengan beberapa teknik: Boot Pra-OS: Bootkit (T1542.003), Modul Bersama/LD_PRELOAD (T1129), pengembangan malware (NUMNUMX) dan penggunaan sertifikat (T1587.002), Plus Rootkit (T1014), Merusak Pertahanan (T1562) y Sembunyikan Artefak (T1564) dalam kasus modul kernel yang mereka bersembunyi diri.

• T1542.003: Bootkit pada ESP untuk persistensi pra-OS.
• T1129: Muat awal dengan LD_PRELOAD dalam proses init.
• T1014: Modul kernel dengan fungsionalitas rootkit.
• T1562 / T1564: Nonaktifkan pemeriksaan dan sembunyikan dari sistem.

Linux tidak kebal: kasus Bootkitty dan nama-nama baru di radar

Selama bertahun-tahun, narasi populer membandingkan peningkatan paparan Windows dengan apa yang disebut "ketidakmampuan untuk menembus" macOS atau LinuxRealitasnya lebih bernuansa: model dan pangsa pasar mereka menjadikan mereka target yang berbeda, tetapi tidak kebal. Munculnya Bootkitty di Linux menunjukkan bahwa pengetahuan untuk membuat bootkit juga ada untuk ekosistem ini, meskipun dalam kasus khusus ini kita berbicara tentang PoC Akademik dengan dukungan terbatas.

Bahkan ada yang menyebutkan varian ransomware, HybridPetya, yang akan mengintegrasikan kemampuan bootkit UEFI. Sampel yang diunggah ke VirusTotal pada tahun 2025 dari Polandia menunjukkan perkembangan terkini, meskipun harus diperlakukan dengan hati-hati. hati hati sampai ada analisis independen dan atribusi yang kuat.

Hal yang penting adalah menginternalisasi bahwa pertahanan harus mencakup seluruh rantai boot, meminimalkan kepercayaan default tanda tangan pihak ketiga yang tidak digunakan, memantau partisi EFI dan mengkonsolidasikan telemetri yang berguna (kernel yang terkontaminasi, kejadian modul, perubahan pada pemeriksa GRUB atau variabel UEFI yang sensitif) untuk dideteksi tepat waktu.

Gambaran risiko UEFI saat ini menggabungkan PoC untuk tujuan pendidikan, bootkit yang dipasarkan sebagai layanan dan kerentanan dalam komponen yang ditandatangani yang, jika tidak dicabut tepat waktu, akan membuka pintu bagi eksekusi pra-OS yang tidak tepercayaMempertahankan firmware terkini dan daftar pencabutan, mengurangi lingkaran kepercayaan, dan memantau ESP adalah tindakan yang, bersama-sama, menempatkan pembela dalam posisi yang jauh lebih kuat terhadap keluarga ancaman ini.

Artikel terkait:

Cara mengamankan Windows dengan Credential Guard, BitLocker, AppLocker, Device Guard, dan WDAC

Isaac

Penulis yang bersemangat tentang dunia byte dan teknologi secara umum. Saya suka berbagi ilmu melalui tulisan, dan itulah yang akan saya lakukan di blog ini, menunjukkan kepada Anda semua hal paling menarik tentang gadget, perangkat lunak, perangkat keras, tren teknologi, dan banyak lagi. Tujuan saya adalah membantu Anda menavigasi dunia digital dengan cara yang sederhana dan menghibur.