Windows atnaujintas, bet Secure Boot vis tiek apėjo: ką parodė BlackX atvejis

Kas yra „BlackX“?

„BlackX“ – įkrovos lygmens kenkėjas (*bootkit*), kuris veikia dar prieš pilnai pasileidžiant „Windows“. Kaspersky tyrėjai jį aptiko 2026 m. pradžios kampanijoje prieš diplomatines organizacijas Tadžikistane, Uzbekistane ir Turkmėnistane. Jie įvertino, kad įrankis panašus į anksčiau žinomą „BlackLotus“ ir gali būti modernizuota jo versija. Priskyrimą APT41 grupei Kaspersky pateikė su vidutiniu pasitikėjimo lygiu. Kaspersky Securelist techninė analizė ↗

Ši detalė svarbi: pagal Kaspersky analizę, užpuolikai „BlackX“ įdiegė jau įsibrovę į aukos tinklą ir gavę administratoriaus teises. Taigi aprašyta technika yra patvarumo ir apsaugų apėjimo etapas, o ne būdas iš niekur pirmą kartą patekti į kompiuterį. Apsauga turi apimti ir pirminę prieigą – paskyras, nuotolines paslaugas, tinklo segmentavimą bei galinių įrenginių stebėseną.

Kodėl „Windows“ atnaujinimas ne visada užbaigia darbą?

„BlackX“ naudojasi seniai žinoma „Baton Drop“ spraga (CVE-2022-21894), susijusia su „Secure Boot“ pasitikėjimo grandine. Kaspersky pranešė, kad analizuotų aukų kompiuteriai buvo atnaujinti, tačiau UEFI programinės aparatinės įrangos atšaukimo sąrašas dar nebuvo užblokavęs pažeidžiamų, sena „Windows Production PCA 2011“ pažyma pasirašytų įkrovos komponentų.

Čia svarbu atskirti du dalykus: pataisa gali būti įdiegta „Windows“ sistemoje, o jos numatytas atšaukimas – dar nepritaikytas UEFI aplinkoje. Kaspersky nurodo, kad jo tirtu atveju reikalingas atšaukimo etapas nebuvo automatiškai atliktas kartu su įprastu naujinimu. Vien tik žyma „Windows atnaujinta“ todėl nėra pakankamas įrodymas, kad konkretaus įrenginio įkrovos grandinė uždaryta.

„Windows Production PCA 2011“ pažymėjimo galiojimo pabaiga taip pat nėra tas pats, kas jo įtraukimas į UEFI draudžiamų parašų sąrašą. „Microsoft“ aiškina, kad 2011 m. pažymėjimo galiojimo pabaiga savaime netrukdo esamiems kompiuteriams paleisti „Windows“, o senasis įkrovos tvarkytuvas nebegaus naujų saugumo pataisų. „Microsoft“ 2026 m. spalio paaiškinimas apie PCA 2011 ↗

Ką įmonės administratoriams verta patikrinti?

1. Inventorizuokite įrenginius. Įtraukite fizines darbo vietas, serverius ir virtualias mašinas, kuriose įjungtas „Secure Boot“. Užfiksuokite gamintoją, modelį, UEFI programinės aparatinės įrangos versiją ir valdymo būdą.
2. Patikrinkite atšaukimo būseną. Vadovaukitės aktualia „Microsoft“ ir įrenginio gamintojo dokumentacija, kad patvirtintumėte, jog UEFI DBX sąrašo pakeitimas pritaikytas ir patikrinamas. Nespręskite vien pagal tai, ar mėnesinis „Windows“ naujinimas įdiegtas.
3. Diekite etapais. Pirmiausia išbandykite atnaujinimus ir atšaukimus reprezentatyviuose įrenginiuose. UEFI ar įkrovos grandinės pakeitimai gali paveikti paleidimą, atkūrimo laikmenas, dvigubą įkrovą ar virtualizacijos aplinkas.
4. Paruoškite atkūrimą. Prieš keisdami „Secure Boot“ būseną patikrinkite, kad saugiai turite „BitLocker“ atkūrimo raktus ir veikiančią, atnaujintą diegimo ar atkūrimo laikmeną. „Microsoft“ rekomenduoja rizikas įvertinti ir pakeitimus išbandyti prieš platesnį diegimą.
5. Įtariant įsilaužimą, vien pataisos neužtenka. Izoliuokite įrenginį, išsaugokite tyrimui reikalingus duomenis ir naudokite incidentų valdymo procedūrą. Prevencinis atšaukimas pašalina galimybę pasinaudoti sena įkrovos grandine, bet pats savaime neišvalo jau kompromituotos sistemos.

Detalius DBX keitimo veiksmus geriausia atlikti pagal konkrečios organizacijos įrenginiams taikomą „Microsoft“ ir gamintojo procesą. „Microsoft“ įspėja, kad įkrovos atšaukimų diegimas turi būti išbandytas, paruošus atkūrimo priemones ir apsaugojus „BitLocker“ raktus. Jos publikuotas diegimo vadovas skirtas susijusiems „Windows Boot Manager“ atšaukimams, todėl jo žingsnius reikia taikyti tik pagal aprašytą taikymo sritį, o ne aklai perkelti visiems įrenginiams. „Microsoft“ Secure Boot atšaukimų diegimo gairės ↗

Pamoka apie pataisų valdymą

„BlackX“ atvejis parodo, kodėl saugumo pataisų valdymas turėtų tikrinti ne vien diegimo rezultatą. Kai apsauga priklauso nuo UEFI ar aparatinės įrangos būsenos, reikia patvirtinti ir galutinę konfigūraciją: ar atšaukimo sąrašas tikrai atnaujintas, ar įrenginys vis dar saugiai pasileidžia ir ar atkūrimo planas veikia. Tai ypač svarbu organizacijoms, kurios valdo daug skirtingų kompiuterių modelių ar virtualizacijos platformų.