Sterownik Microsoft Defender BTR.sys może posłużyć do usuwania ochrony podczas rozruchu Windows

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali technikę nadużycia sterownika BTR.sys, będącego częścią Microsoft Defender, do wykonywania uprzywilejowanych operacji na plikach i rejestrze już na etapie uruchamiania systemu Windows. Nie jest to klasyczna podatność prowadząca do zdalnego wykonania kodu ani bezpośredniej eskalacji uprawnień, lecz scenariusz abuse-of-trust, w którym zaufany i podpisany komponent systemowy zostaje wykorzystany przeciwko samym mechanizmom ochronnym.

Znaczenie tej techniki wynika z faktu, że operacje są realizowane w kontekście jądra systemu i w bardzo wczesnym oknie rozruchowym. W praktyce daje to możliwość usuwania lub osłabiania zabezpieczeń jeszcze przed pełnym startem usług ochronnych, agentów EDR i mechanizmów samoobrony.

W skrócie

Technika dotyczy sterownika BTR.sys używanego przez Microsoft Defender do działań naprawczych po restarcie.
Atakujący z uprawnieniami administratora może przygotować poprawne transakcje dla sterownika i zlecić mu operacje na plikach oraz rejestrze.
Możliwe działania obejmują usuwanie plików, przenoszenie danych do chronionych lokalizacji i modyfikację kluczy rejestru.
Do nadużycia nie trzeba dostarczać zewnętrznego podatnego sterownika, jak w modelu BYOVD.
Warunkiem powodzenia ataku pozostaje posiadanie lokalnej administracji oraz uprawnienia SeLoadDriverPrivilege.

Kontekst / historia

BTR.sys jest związany z mechanizmem Boot Time Removal Tool, którego zadaniem jest usuwanie złośliwych artefaktów niemożliwych do skasowania podczas normalnej pracy systemu. Rozwiązanie to zaprojektowano po to, aby kończyć remediację po ponownym uruchomieniu Windows, gdy część plików i wpisów rejestru nie jest jeszcze zablokowana przez aktywne procesy.

Sam komponent nie jest nowy. W 2021 roku był już analizowany w kontekście podatności CVE-2021-24092, związanej z lokalnym podniesieniem uprawnień. Obecny przypadek ma jednak inny charakter. Zamiast błędu implementacyjnego, który można stosunkowo prosto załatać, problem dotyczy architektury zaufania wokół legalnego, podpisanego narzędzia bezpieczeństwa.

Analiza techniczna

Istota problemu sprowadza się do sposobu, w jaki BTR.sys przetwarza polecenia dostarczane do sterownika. Badacze odtworzyli nieudokumentowany protokół transakcyjny i ustalili, że konfiguracja przekazywana do komponentu jest szyfrowana RC4 przy użyciu stałego klucza osadzonego w binarium. To umożliwia wygenerowanie poprawnych pakietów akceptowanych przez sterownik.

Scenariusz ataku zakłada najpierw pozyskanie sterownika z biblioteki silnika Defendera, a następnie przygotowanie zaszyfrowanej konfiguracji zawierającej pożądane operacje. Kolejnym krokiem jest zarejestrowanie sterownika jako usługi startowej ładowanej na etapie boot. Co ważne, konfiguracja może zostać wdrożona także przez bezpośrednie modyfikacje rejestru, z pominięciem standardowych ścieżek zarządzania usługami, co utrudnia wykrycie.

Po załadowaniu BTR.sys wykonuje zadania w kontekście Ring 0. Obejmuje to operacje szczególnie niebezpieczne z punktu widzenia ochrony endpointów:

usuwanie zablokowanych plików i katalogów,
przenoszenie plików do dowolnych ścieżek, także systemowych,
usuwanie kluczy i wartości rejestru,
zapisywanie nowych wartości rejestru różnych typów.

Najbardziej krytyczne jest krótkie okno rozruchowe pomiędzy uzyskaniem dostępu do systemu plików a pełnym startem usług ochronnych. Właśnie wtedy sterownik może fizycznie usunąć binaria produktów AV, sterowniki filtrujące, elementy Defendera lub agentów EDR, zanim zdążą uruchomić mechanizmy samoobrony. Taki model działania pozwala skutecznie obejść część zabezpieczeń działających głównie po starcie systemu.

Z perspektywy detekcji potencjalnymi artefaktami są między innymi alternatywne strumienie danych powiązane z konfiguracją sterownika, nietypowe wpisy usług w rejestrze, krótkotrwałe tworzenie i usuwanie pliku BootClean.log oraz sekwencja zdarzeń obejmująca załadowanie drivera i natychmiastowe operacje kasowania wykonywane przez proces System.

Konsekwencje / ryzyko

Ryzyko tej techniki należy oceniać jako wysokie w środowiskach, w których przeciwnik uzyskał już lokalne uprawnienia administracyjne. Nie jest to wektor wejścia, ale bardzo skuteczne narzędzie post-exploitation, które może ułatwiać utrzymanie dostępu, sabotowanie telemetrii oraz przygotowanie gruntu pod kolejne etapy ataku.

osłabianie lub wyłączanie ochrony endpointów,
usuwanie agentów EDR i komponentów antywirusowych,
utrudnianie analizy powłamaniowej poprzez kasowanie artefaktów i telemetrii,
przygotowanie środowiska pod ransomware, rootkity i trwałość ataku,
ukrywanie działań za legalnym, podpisanym komponentem systemowym.

Dodatkowym wyzwaniem jest ograniczona skuteczność klasycznych blocklist sterowników. W odróżnieniu od typowych scenariuszy BYOVD nie chodzi tu o zewnętrzny podatny driver, lecz o natywny składnik Microsoft Defender. Oznacza to, że obrona musi koncentrować się na ograniczaniu przywilejów, hardeningu i detekcji zachowań, a nie tylko na prostym blokowaniu pliku.

Rekomendacje

Organizacje powinny potraktować ten przypadek jako ważny przykład nadużycia zaufanego komponentu bezpieczeństwa i dostosować do niego kontrole ochronne.

Ograniczyć liczbę kont posiadających uprawnienie SeLoadDriverPrivilege i objąć jego użycie ścisłym audytem.
Wzmocnić monitoring zdarzeń rozruchowych, ładowania sterowników oraz zmian w kluczach usług systemowych.
Wdrożyć detekcje dla tworzenia ADS powiązanych z plikami .sys, anomalii związanych z BootClean.log oraz operacji kasowania wykonywanych przez proces System po starcie.
Stosować tiering administracyjny i minimalizować liczbę systemów, na których użytkownicy lub operatorzy mają lokalną administrację.
Ująć ten wektor w playbookach SOC i DFIR, zwłaszcza przy incydentach obejmujących znikające komponenty ochronne i nietypowe restarty.
Regularnie prowadzić ćwiczenia purple team oraz testy odporności na ataki post-exploitation wymierzone w rozwiązania ochronne.

Podsumowanie

Przypadek BTR.sys pokazuje, że nowoczesne ataki coraz częściej nie polegają na wykorzystywaniu klasycznych luk, lecz na nadużywaniu legalnych i podpisanych komponentów systemowych. W tym scenariuszu atakujący dysponujący administracją może użyć natywnego sterownika Microsoft Defender do przeprowadzenia operacji jądrowych i osłabienia zabezpieczeń jeszcze przed pełnym uruchomieniem systemu.

Dla zespołów bezpieczeństwa kluczowy wniosek jest jednoznaczny: samo blokowanie znanych podatnych sterowników nie wystarcza. Skuteczna obrona wymaga połączenia ścisłej kontroli uprawnień, monitoringu działań boot-time oraz detekcji anomalii wokół legalnych komponentów ochronnych.