Skanowanie AV-EDR poza kernelem Windows. Microsoft pracuje nad API

avlab.pl 13 godzin temu
Zdjęcie: Skanowanie AV-EDR poza kernelem Windows. Microsoft pracuje nad API


„Resilience is not optional – resilience is essential”. Microsoft doskonale rozumie i stara się wszystkich przekonać, iż w obliczu dzisiejszych zagrożeń bezpieczeństwa, odporność nie może być realizowana ad hoc — musi być fundamentem, rdzeniem systemów IT. Dlatego w ramach inicjatywny Windows Resiliency Initiative (zobacz więcej w PDF), o której szerzej pisaliśmy tutaj, Microsoft zamierza przebudować ochronę Windows 11 i Windows 12 w celu:

  1. Zapobieżenia incydentom bezpieczeństwa poprzez przedefiniowanie architektury Windows (secure by default, secure by design).
  2. Reagowania i zarządzania już w momencie wystąpienia problemów.
  3. Szybkiej odbudowy systemów i usług po awariach lub atakach.

Przypomnę, iż we wrześniu 2024 odbyło się spotkanie Windows Endpoint Security Ecosystem Summit, gdzie Microsoft zapowiedział współpracę z producentami zabezpieczeń i instytucjami (m.in. CISA) nad podniesieniem standardów ów odporności. Dodatkowo w ramach projektu Microsoft Virus Initiative, którego AVLab jest członkiem (zobacz szczegóły), dostawcy rozwiązań zabezpieczających muszą stosować się do wytycznych Microsoftu i potwierdzać swoją skuteczność, odporność na błędy, poprzez regularne testy swojego oprogramowania.

Skanowanie anty-malware poza kernelem Windows – kiedy?

Tradycyjnie oprogramowanie antywirusowe w Windows działa bardzo blisko kernela systemu operacyjnego. Wynika to z faktu, iż skuteczne wykrywanie złośliwego systemu często wymaga dostępu do niskopoziomowych zasobów systemowych — sterowników, plików systemowych, procesów w pamięci. Ten model ma jednak istotną wadę: mianowicie jeżeli coś pójdzie nie tak (np. błąd w module sterownika antywirusa), może spowodować awarię całego systemu. Zdarza się to niezwykle rzadko, ale ma ogromne skutki — wystarczy przypomnieć incydent z lipca 2024, gdy wadliwa aktualizacja sterownika CrowdStrike spowodowała globalne przestoje w firmach.

Nowy model będzie rozwijany na Windows 11 i jego następcę — czyli prawdopodobnie Windows 12 (jeśli tak się będzie nazywał nowy system). Pojawi się specjalne API dla deweloperów rozwiązań bezpieczeństwa (AV, EDR, SIEM itp.), by wynieść skanowanie poza jądro systemu, do trybu użytkownika i jednocześnie uzyskiwać dostęp do niskopoziomowych informacji z kernela. Może to być najważniejszy krok, aby zwiększyć przede wszystkim stabilność, zapobiec globalnym awariom, by jeden wadliwy moduł systemu nie wpłynął na bezpieczeństwo tysięcy, milionów urządzeń.

Nowy model skanowania poza jądrem (user-mode) będzie testowany w ramach Private Preview w Windows 11 — czyli najpierw w wersjach Insider lub dedykowanych buildach dla partnerów.

Jak to ma działać w praktyce?

Zamiast instalowania sterownika (np. minifilter driver) bezpośrednio w kernelu, silnik AV będzie działał w izolowanym kontenerze w przestrzeni użytkownika, z minimalnym dostępem do jądra. Komunikacja z systemem plików i procesami będzie realizowana przez udokumentowane API Windows, z dodatkowymi mechanizmami sandboxingu i telemetrii. Dzięki temu hakerom trudniej będzie wywołać eskalację uprawnień poprzez lukę w krytycznym oprogramowaniu, jakim jest antywirus. Co więcej deweloperzy będą mogli szybciej wypuszczać poprawki, bo nie będą musieli przechodzić skomplikowanej walidacji kodu kernelowego. Finalnie system operacyjny będzie bardziej odporny na awarie sterowników firm trzecich.

Jak to ma działać w praktyce?

Przeniesienie antywirusa (czy innego systemu wymagającego dostępu do jądra) do trybu użytkownika nie oznacza obniżenia skuteczności wykrywania, ponieważ najważniejsze funkcje (np. skanowanie w czasie rzeczywistym, heurystyka) będą działać z podobną prędkością, dzięki nowoczesnym mechanizmom w Windows 11 i Windows Server. Przykładowo Microsoft Defender już teraz częściowo działa w user-mode. W nowym modelu ochrony izolowany będzie silnik AV (minifilter diver), ale jednocześnie będzie uzyskiwał dostęp do skanowania plików na etapie otwierania i zapisu — czyli w czasie rzeczywistym. Co więcej kernel systemowy będzie tylko „sygnalizował” AV o zdarzeniu (np. próbie dostępu do pliku), zatem cała analiza ma dziać się poza jądrem.

Poniżej uproszczony przykład fragmentu MiniFiltera, który przechwytuje każde otwarcie pliku i loguje jego nazwę.

#include PFLT_FILTER gFilterHandle; // Callback: Pre-operation callback for IRP_MJ_CREATE (open file) FLT_PREOP_CALLBACK_STATUS PreCreateOperation( PFLT_CALLBACK_DATA Data, PCFLT_RELATED_OBJECTS FltObjects, PVOID *CompletionContext ) { PFLT_FILE_NAME_INFORMATION fileNameInfo; NTSTATUS status; // Get file name status = FltGetFileNameInformation(Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo); if (NT_SUCCESS(status)) { FltParseFileNameInformation(fileNameInfo); DbgPrint("File open intercepted: %wZ\n", &fileNameInfo->Name); FltReleaseFileNameInformation(fileNameInfo); } // Allow operation to continue return FLT_PREOP_SUCCESS_WITH_CALLBACK; } // Registration table CONST FLT_OPERATION_REGISTRATION Callbacks[] = { { IRP_MJ_CREATE, // File open 0, PreCreateOperation, NULL }, { IRP_MJ_OPERATION_END } }; CONST FLT_REGISTRATION FilterRegistration = { sizeof(FLT_REGISTRATION), // Size FLT_REGISTRATION_VERSION, 0, // Flags NULL, // Context Callbacks, // Operation callbacks DriverUnload, // Unload NULL, NULL, NULL, NULL, NULL, NULL, NULL }; // Driver entry point NTSTATUS DriverEntry( PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath ) { return FltRegisterFilter(DriverObject, &FilterRegistration, &gFilterHandle); }

Przykładowo teraz Windows Defender z usługą MsMpEng.sys działa w kernelu i używa tego MiniFiltera. Podobnie większość rozwiązań bezpieczeństwa, ponieważ tak skonstruowany jest Windows. Zasadniczo każde rozwiązanie ma swój MiniFilter lub choćby kilka.

Jak skanowanie działa teraz?

  • Silnik antywirusowy instaluje sterownik minifilter w kernel mode.
  • Sterownik monitoruje wszystkie operacje I/O (np. otwarcia, zapisy plików).
  • Jeśli wykryje podejrzane zachowanie – blokuje operację lub przekazuje dane do silnika AV.
  • Sterownik ma wysokie uprawnienia: błąd lub luka w kodzie sterownika = potencjalny BSOD lub wektor eskalacji uprawnień.


Jak to będzie w działać w user mode (przestrzeń użytkownika)?

  • Kernel nie załaduje sterownika AV, tylko udostępni API i wywołania do zdarzeń (np. otwarcie pliku, zmiana rejestru).
  • Silnik antywirusowy działać ma w procesie użytkownika, odseparowany od jądra.
  • Komunikacja odbywać się będzie przez bezpieczny interfejs API (coś w rodzaju sandbox).
  • Jeśli AV przestanie działać, ochrona przestanie działać, ale nie spowoduje do uszkodzenia systemu, BSOD
Idź do oryginalnego materiału