- W systemie Windows GDI kumulują się luki w zabezpieczeniach umożliwiające ujawnienie informacji, odmowę usługi i zdalne wykonywanie kodu. Podatności te dotyczą wielu wersji systemu Windows i Windows Server.
- Wiele z tych luk jest wykorzystywanych za pośrednictwem plików EMF/WMF lub nieprawidłowo sformatowanej zawartości graficznej przetwarzanej przez gdi32.dll i win32k.sys, co może powodować niebieskie ekrany śmierci (BSOD) lub wycieki pamięci.
- Firma Microsoft udostępnia poprawki w pakietach zbiorczych, które wprowadzają zmiany w plikach binarnych, np. gdi32.dll, oraz udostępnia wartości skrótu i informacje o plikach w celu weryfikacji prawidłowej instalacji.
- Połączenie sprawnego wdrażania poprawek, segmentacji sieci, ograniczenia niebezpiecznych formatów graficznych i monitorowania przy użyciu EDR jest kluczem do ograniczenia ryzyka związanego z GDI.
Graficzny interfejs użytkownika systemu Windows (GDI) od dziesięcioleci renderuje okna, tekst, ikony i obrazy, a większość użytkowników nawet o tym nie wie. Jednak ten fundamentalny komponent systemu był również źródłem kilku poważnych luk w zabezpieczeniach, w tym luk typu zero-day i luk naprawionych w ramach masowych aktualizacji oprogramowania firmy Microsoft. Awaria GDI nie ogranicza się tylko do aplikacji: w niektórych przypadkach może prowadzić do wycieków danych, zdalnego wykonania kodu lub wyświetlania niebieskich ekranów śmierci (BSOD), które powodują awarię całych serwerów.
Poniżej opisano szczegółowo, jak działa GDI, jakie konkretne luki w zabezpieczeniach udokumentowano w ostatnich latach (takie jak CVE-2017-11816, CVE-2020-1435 lub CVE-2023-36884 ), w jaki sposób są one wykorzystywane , jaki mają rzeczywisty wpływ na środowiska domowe i korporacyjne oraz jakie praktyczne środki mogą zastosować administratorzy i specjaliści ds. cyberbezpieczeństwa, aby chronić swoje systemy Windows, od starszych wersji, takich jak Windows Vista SP2, po nowsze edycje systemów Windows 11 i Windows Server.
Czym jest Windows GDI i dlaczego jest tak wrażliwy pod względem bezpieczeństwa?
Graphics Device Interface (GDI) to starsze API systemu Windows odpowiedzialne za zarządzanie wszystkim, co wiąże się z renderowaniem grafiki: od rysowania linii i prostokątów po wyświetlanie czcionek, map bitowych i obrazów na ekranie lub drukarce. Aplikacje wywołują funkcje z bibliotek takich jak gdi32.dll, aby tworzyć konteksty urządzeń (HDC), pędzle, pióra, regiony i inne obiekty graficzne, którymi zarządzają „od podszewki” struktury danych kontrolowane przez jądro.
Architektura GDI jest podzielona na tryb użytkownika i tryb jądra . W trybie użytkownika biblioteka DLL gdi32.dll i inne powiązane biblioteki odbierają żądania rysowania od aplikacji. Wywołania te są przekazywane do podsystemu okienkowego systemu Windows, który działa w trybie jądra za pośrednictwem pliku win32k.sys. Ta część jądra faktycznie manipuluje pamięcią systemową, weryfikuje obiekty graficzne i wysyła je do sprzętu. Niedostateczna weryfikacja wskaźników, rozmiarów lub indeksów na tym etapie otwiera drogę do katastrofalnych błędów.
Aby śledzić i ponownie wykorzystywać zasoby, system utrzymuje tabele obiektów GDI . Każdy proces ma własną tabelę, ale istnieje również globalna tabela dla obiektów współdzielonych, co zwiększa ryzyko uszkodzenia w przypadku przepełnienia bufora, podwójnego zwolnienia pamięci lub nieprawidłowego odwołania do pamięci. Tego typu awarie mogą prowadzić do uszkodzenia pamięci jądra, sytuacji wyścigu, awarii systemu, a nawet wykonania dowolnego kodu w najbardziej uprzywilejowanym kontekście systemu.
Wraz z pojawieniem się nowocześniejszych interfejsów API (GDI+, Direct2D, DirectWrite, a nawet DirectComposition), Microsoft ograniczył wykorzystanie GDI w nowych aplikacjach, ale ekosystem starszego oprogramowania , który nadal na nim polega, jest ogromny. To dziedzictwo sprawia, że GDI stanowi bardzo atrakcyjną powierzchnię ataku dla badaczy i atakujących.
Historyczne luki w zabezpieczeniach: od ujawnienia informacji do dnia zerowego
Jedną z najstarszych luk w zabezpieczeniach powiązanych z GDI jest udokumentowana luka umożliwiająca ujawnienie informacji, CVE-2017-11816 . W tym przypadku problem leżał w sposobie, w jaki GDI obsługiwał określone obiekty w pamięci, umożliwiając złośliwemu użytkownikowi pobranie z systemu docelowego danych, które nie powinny być dostępne. Nie było to wykonanie kodu, ale poważne naruszenie poufności.
Ta luka w zabezpieczeniach dotyczyła różnych wersji systemu Windows i zmusiła firmę Microsoft do wydania specjalnej aktualizacji zabezpieczeń. Luka tkwiła w wewnętrznym przetwarzaniu struktur graficznych, gdzie podsystem nie mógł prawidłowo wyczyścić lub zweryfikować niektórych obszarów pamięci przed ich ponownym użyciem, co umożliwiało odczytanie szczątkowych informacji należących do innych procesów lub samego systemu operacyjnego.
Poprawka została wprowadzona w ramach aktualizacji zabezpieczeń w ramach regularnego cyklu „Patch Tuesday” w październiku 2017 roku. Wraz z opisem luki w zabezpieczeniach, firma Microsoft udostępniła obszerne tabele z listą zagrożonych plików i ich nowszych wersji: na przykład różne kompilacje pliku gdi32.dll dla platform x86, x64 i IA-64, z datami takimi jak 8 września 2017 roku, oraz wersjami pliku, takimi jak 6.0.6002.24200. Te szczegółowe informacje pozwoliły administratorom potwierdzić, że poprawka została zastosowana prawidłowo.
Później badacze z Project Zero (Google) ujawnili kolejną lukę typu zero-day związaną z plikiem gdi32.dll w trybie użytkownika . Tym razem luka dotyczyła obsługi plików DIB (Device Independent Bitmaps) osadzonych w rejestrach EMF (Enhanced Metafile). Nieprawidłowa manipulacja tymi mapami bitowymi w metaplikach umożliwiała wydobycie informacji z pamięci procesu, co miało bezpośredni wpływ na prywatność danych.
Tę lukę typu zero-day można było odtworzyć lokalnie za pośrednictwem przeglądarki Internet Explorer oraz zdalnie za pośrednictwem usługi Office Online, otwierając dokument DOCX za pomocą specjalnie spreparowanego pliku EMF. Lista zagrożonych wersji była długa, od systemu Windows Vista z dodatkiem Service Pack 2 do systemu Windows 10 , a także obejmowała wersje systemu Windows Server, takie jak 2012 R2 i 2016. Problem ujrzał światło dzienne po upływie standardowego 90-dniowego okresu Project Zero bez wydania poprawki, co oficjalnie uczyniło tę lukę luką typu zero-day.
Tymczasem Microsoft doświadczył znaczącego incydentu: przez miesiąc nie wydał zaplanowanej aktualizacji Patch Tuesday z powodu problemu wewnętrznego, co opóźniło wdrożenie poprawek do kolejnego cyklu. Tego typu opóźnienia wydłużają czas ujawnienia luk w zabezpieczeniach, które są już znane społeczności badawczej.
Ostatnie krytyczne błędy: BSOD, zdalne wykonywanie i duże partie poprawek
Z biegiem czasu luki w zabezpieczeniach GDI ewoluowały, prowadząc do poważniejszych scenariuszy. Szczególnie uderzającym przykładem jest luka typu „odmowa usługi” (Denial-of-Service) oznaczona jako CVE-2023-36884 , która dotyczy wersji systemu Windows 10 (od wersji 1607), Windows 11 oraz Windows Server 2016, 2019 i 2022. Chociaż identyfikator ten był powiązany z różnymi komponentami w zależności od biuletynu, analiza techniczna opisuje krytyczną wadę w podsystemie graficznym, która może powodować niebieskie ekrany śmierci (BSOD) podczas przetwarzania nieprawidłowo sformatowanych obiektów graficznych.
Problem dotyczy funkcji NtGdiDdDeleteDeviceBitmap w pliku win32k.sys . Podczas obsługi nieprawidłowej mapy bitowej lub urządzenia graficznego, podatny na atak kod nie przeprowadza dokładnej kontroli granic bufora podczas kopiowania danych ze struktury urządzenia (np. typu DD_DEVICE_OEM). To zaniedbanie powoduje nadpisanie sąsiedniej pamięci w jądrze, generując wyjątek dostępu do pamięci (PAGE_FAULT_IN_NONPAGED_AREA, kod 0x00000050) i wywołując niebieski ekran śmierci (BSOD) z kodami takimi jak IRQL_NOT_LESS_OR_EQUAL lub podobnymi.
Typowy schemat działania exploita rozpoczyna się od danych graficznych osadzonych w protokołach sieciowych, takich jak SMB lub RDP, a nawet za pośrednictwem WebDAV lub usług drukowania. Nieprawidłowo sformatowany plik EMF jest przesyłany jako część zdalnego dokumentu lub strumienia, a gdy aplikacja, taka jak Office, Edge, przeglądarka obrazów, a nawet sam Eksplorator plików, próbuje zinterpretować jego zawartość, wywoływany jest podsystem GDI w celu jego przetworzenia. Procedura analizy składniowej nie sprawdza prawidłowo poprawności niektórych rejestrów obiektów, co pozwala na dereferencję wskaźnika spoza zakresu i destabilizację pamięci jądra (zwłaszcza puli niestronicowanej).
Chociaż w oficjalnych biuletynach raportowano głównie o możliwości odmowy usługi (DoS) , różni badacze wskazali, że dzięki bardziej zaawansowanym technikom wykorzystywania uszkodzeń pamięci (na przykład poprzez atakowanie stosu) możliwe będzie zbudowanie łańcuchów prowadzących do wykonania kodu w trybie jądra, podobnie jak miało to miejsce w przypadku luk w zabezpieczeniach innych komponentów, takich jak MSHTML (przypadek CVE-2021-40444).
Krytyczność GDI znalazła również odzwierciedlenie w licznych poprawkach. W lipcu 2020 roku Microsoft wydał obszerną aktualizację, która naprawiła 123 luki w zabezpieczeniach swoich produktów, z czego 18 zostało sklasyfikowanych jako krytyczne. Wśród nich znalazła się luka CVE-2020-1435, bezpośrednio związana ze sposobem, w jaki GDI manipuluje obiektami w pamięci. Jeśli atakującemu udałoby się nakłonić ofiarę do otwarcia specjalnie spreparowanej zawartości (na przykład poprzez odwiedzenie złośliwej witryny), mogłoby to spowodować zdalne wykonanie kodu z takimi samymi uprawnieniami jak użytkownik.
W tej samej partii pojawił się błąd CVE-2020-1436, związany z obsługą specjalnie spreparowanych czcionek, oraz szczególnie głośny błąd CVE-2020-1350 , krytyczna luka w zabezpieczeniach serwera DNS systemu Windows, która działa jak robak i może rozprzestrzeniać złośliwe oprogramowanie bez interakcji użytkownika. Chociaż ten ostatni nie ma wpływu na GDI, ilustruje kontekst: pojedynczy pakiet poprawek zawierał luki w zabezpieczeniach usług sieciowych, hiperwizorów (kilka luk umożliwiających zdalne wykonywanie kodu w Hyper-V) oraz samego interfejsu graficznego.
CVE-2020-1435 dotyczy w szczególności sposobu, w jaki GDI obsługuje obiekty graficzne w pamięci . Skuteczne wykorzystanie luki umożliwiłoby atakującemu instalowanie programów, przeglądanie, modyfikowanie lub usuwanie danych oraz tworzenie kont użytkowników z pełnymi uprawnieniami. Typowy wektor ataku polega na nakłonieniu użytkownika do odwiedzenia złośliwej witryny lub otwarcia pliku zawierającego zasoby graficzne, których celem jest wykorzystanie luki. Jest to zgodne z historycznym wzorcem GDI: każda treść wizualna oparta na jego silniku renderującym może stanowić lukę w zabezpieczeniach, jeśli system nie jest zaktualizowany.
W tym samym cyklu poprawek z lipca 2020 r. ogłoszono również kilka krytycznych luk w zabezpieczeniach Hyper-V (CVE-2020-1041, -1040, -1032, -1036, -1042 i -1043) , co pokazuje, w jaki sposób różne komponenty systemu Windows (sieć, wirtualizacja, grafika) mogą stać się ogniwami w tym samym łańcuchu ataków, jeśli organizacja nie utrzymuje rygorystycznego programu zarządzania poprawkami.
Rzeczywisty wpływ na systemy Windows, wersje dotknięte problemem i wektory
Zakres wersji dotkniętych lukami GDI jest szeroki. W przypadkach zero-day udokumentowanych przez Project Zero, luka w pliku gdi32.dll dotyczyła systemów Windows Vista SP2, Windows 7, Windows 8.1, Windows 10 oraz kilku edycji systemu Windows Server (2012 R2, 2016 itd.). Oznacza to, że ogromna liczba komputerów, zarówno domowych, jak i firmowych, może paść ofiarą wycieków pamięci poprzez samo otwarcie dokumentu, przeglądanie Internetu za pomocą przeglądarki Internet Explorer lub korzystanie z pakietu Office Online.
W najnowszym scenariuszu skoncentrowanym na BSOD firma Microsoft potwierdziła, że analizowana luka dotyczy systemów Windows 10 od wersji 1607, Windows 11 oraz Windows Server 2016/2019/2022 , w tym edycji Enterprise, Education i LTSC. Wersje, które nie są już objęte rozszerzonym wsparciem technicznym, takie jak Windows 7 lub 8.1, nie są objęte oficjalną poprawką, ale nie oznacza to, że są wolne od problemów z GDI; oznacza to po prostu, że nie otrzymują regularnych poprawek.
Na poziomie operacyjnym wpływ można podsumować w trzech kategoriach: ujawnienie informacji (odczyt pamięci, która powinna być prywatna), odmowa usługi (powtarzające się BSOD) oraz zdalne wykonywanie kodu . W środowiskach korporacyjnych BSOD na serwerze pełniącym kluczowe role (na przykład współdzielonym serwerze wydruku lub hoście Hyper-V) może wywołać reakcję łańcuchową awarii: przerwanie usług wydruku, nieoczekiwane wyłączenie maszyn wirtualnych, utratę danych w sesjach zdalnych i długi czas odzyskiwania.
Z perspektywy sieciowej, GDI może zostać wykorzystane za pośrednictwem protokołów takich jak SMB (port 445), RDP lub WebDAV, jeśli dowolna usługa automatycznie przetwarza otrzymane obrazy lub metapliki EMF/WMF. Lokalnie wystarczy, że użytkownik otworzy złośliwy plik w aplikacjach korzystających z GDI, takich jak Paint, WordPad, starsze przeglądarki obrazów, a nawet procesy związane z podglądem ikon i miniatur w Eksploratorze plików . Najczęstsze łańcuchy ataków łączą wiadomość phishingową z dokumentem DOCX lub PDF zawierającym uszkodzony plik EMF.
W organizacjach regulowanych (finanse, opieka zdrowotna, administracja publiczna) incydenty spowodowane niezałatanymi lukami w zabezpieczeniach mogą mieć konsekwencje prawne i regulacyjne. Niebieski ekran śmierci (BSOD), który powoduje awarię krytycznego systemu, może zostać uznany za zdarzenie bezpieczeństwa zagrażające ciągłości usług, co z kolei może skutkować audytami i karami wynikającymi z przepisów takich jak RODO lub HIPAA. Co więcej, różne raporty dotyczące zagrożeń przypisują wykorzystywanie luk w podsystemach graficznych grupom APT atakującym ważne cele w Azji i Europie.
Warto pamiętać, że według powszechnych danych branżowych (na przykład tych uwzględnionych w corocznych raportach o naruszeniach danych), znaczny odsetek urządzeń z systemem Windows pozostaje bez aktualizacji przez ponad 90 dni po wydaniu krytycznych aktualizacji. Daje to atakującym szerokie pole manewru w automatyzacji ataków i integracji ich z platformami takimi jak Metasploit czy Cobalt Strike, które potrafią skanować całe pasma sieciowe w poszukiwaniu podatnych hostów.
Jak Microsoft dystrybuuje poprawki i który plik jest modyfikowany
Po wykryciu luki w zabezpieczeniach GDI firma Microsoft publikuje aktualizację zabezpieczeń, zazwyczaj w postaci comiesięcznych pakietów zbiorczych. Aktualizacje te są zazwyczaj dostarczane za pośrednictwem usługi Windows Update , katalogu usługi Microsoft Update lub narzędzi do zarządzania, takich jak Windows Server Update Services (WSUS) i Microsoft Endpoint Configuration Manager (MECM). W przypadku luki CVE-2017-11816, odpowiednią aktualizację (na przykład KB4042121 dla systemu Windows Server 2008) można pobrać z usługi Windows Update lub katalogu, jako samodzielny plik .msu.
Jedną z osobliwości, na którą zwraca uwagę Microsoft, jest to, że jeśli po zainstalowaniu aktualizacji zostaną zainstalowane pakiety językowe , łatka bezpieczeństwa musi zostać ponownie zainstalowana. Dlatego zawsze zaleca się najpierw wdrożenie niezbędnych języków, a dopiero potem aktualizacje. Ten szczegół, który może wydawać się mało istotny, doprowadził do niejednego przypadku, w którym system został błędnie uznany za zaktualizowany, podczas gdy w rzeczywistości niektóre pliki binarne GDI nie zawierały poprawionej wersji.
W dokumentacji związanej z tymi biuletynami firma Microsoft udostępnia obszerne tabele z informacjami o plikach : nazwa (na przykład gdi32.dll), konkretna wersja, rozmiar, data, godzina i platforma (x86, x64, IA-64). Tabele te umożliwiają administratorom i audytorom weryfikację poprawności zainstalowanego pliku binarnego. Podobny proces jest stosowany w przypadku pakietów .msu i .exe różnych edycji systemu Windows i pakietu Office, gdzie wyszczególnione są skróty SHA1 i SHA256 każdego pliku, co umożliwia zespołom weryfikację ich integralności.
Lista plików i skrótów jest przytłaczająca: od Windows6.0-KB2834886-x86.msu i jego wariantów x64 i ia64, przez Windows6.1-KB2835364-x64.msu, Windows8-RT-KB2835361-x86.msu, dziesiątki instalatorów dla systemów Windows Server 2003 i Windows XP w najróżniejszych językach (CHS, CHT, DEU, ESN, FRA, ITA, JPN, KOR, PTB, PTG, RUS itd.), aż po poprawki dla składników pakietu Office i programu Lync, takich jak AttendeeAdmin.msp, ogl2007-kb2687309-fullfile-x86-glb.exe lub lyncloc2013-kb2817465-fullfile-x64-glb.exe. Każdy z nich zawiera własne skróty SHA1 i SHA256, aby ułatwić weryfikację.
We wszystkich tych przypadkach ostateczny cel jest ten sam: aktualizacja pliku gdi32.dll (lub powiązanych plików binarnych podsystemu graficznego) do wersji bezpiecznej. Na platformach takich jak Windows Server 2008, na przykład, plik gdi32.dll jest oznaczony jako wersja 6.0.6002.24200, a jego rozmiar różni się w zależności od architektury (około 299 520 bajtów w architekturze x86, 391 680 bajtów w architekturze x64 i 955 392 bajtów w architekturze IA-64). Wartości te, wraz z datą kompilacji, stanowią podstawowe odniesienie do ustalenia, czy w systemie zastosowano poprawkę.
Oficjalna dokumentacja odwołuje się także do artykułów w Bazie wiedzy, które zawierają szczegółowe informacje na temat implementacji i wdrażania tych aktualizacji, a także łącza do zasobów pomocy technicznej: stron pomocy usługi Windows Update, portali poświęconych bezpieczeństwu dla specjalistów IT (takich jak TechNet Security), międzynarodowych witryn pomocy technicznej i konkretnych usług zwalczających złośliwe oprogramowanie pod marką Microsoft Secure.
Dobre praktyki w zakresie łagodzenia, monitorowania i reagowania
Oprócz instalowania poprawek natychmiast po ich udostępnieniu istnieje szereg środków zapobiegawczych i środków obrony , które pomagają ograniczyć ryzyko związane z awariami GDI, szczególnie w środowiskach korporacyjnych składających się z setek lub tysięcy komputerów.
Po pierwsze, zaleca się ograniczenie powierzchni ataku poprzez wyłączenie lub ograniczenie automatycznego przetwarzania niektórych formatów graficznych w aplikacjach i przeglądarkach. Na przykład w przeglądarce Microsoft Edge można skonfigurować zasady grupy, aby blokować lub kontrolować pobieranie i obsługę metaplików EMF/WMF za pomocą kluczy rejestru w HKLM\SOFTWARE\Policies\Microsoft\Edge, związanych z ograniczeniami pobierania. W innych aplikacjach można użyć opcji konfiguracji, aby uniemożliwić automatyczne podglądanie dokumentów z niezaufanych lokalizacji i zastosować przewodniki rozwiązywania problemów, aby rozwiązać problem braku reakcji Eksploratora plików.
Kolejną istotną warstwą jest segmentacja sieci zgodna z zasadami Zero Trust . Obejmuje to ograniczenie ruchu SMB, RDP i innych potencjalnie podatnych na ataki protokołów tylko do ściśle niezbędnych podsieci, wdrożenie zapór sieciowych nowej generacji z głęboką inspekcją pakietów oraz egzekwowanie reguł opartych na tożsamości i kontekście. Ograniczając liczbę urządzeń mogących komunikować się z poszczególnymi usługami, drastycznie zmniejsza się wpływ ataku próbującego rozprzestrzeniać się bocznie.
W obszarze wykrywania, wdrożenie rozwiązań Endpoint Detection and Response (EDR), takich jak Microsoft Defender for Endpoint, pomaga monitorować nietypowe zachowania związane z plikami win32k.sys, gdi32.dll i zdarzeniami BSOD . Skonfigurowanie alertów dotyczących nagłych wzrostów liczby błędów niebieskiego ekranu (na przykład rozpoczynających się od zdarzenia o identyfikatorze 1001 w Podglądzie zdarzeń) oraz nietypowego dostępu do podsystemu graficznego może pomóc w identyfikacji prób wykorzystania luk w zabezpieczeniach lub niestabilności spowodowanych przez złośliwe oprogramowanie.
W przypadku zarządzania poprawkami zdecydowanie zaleca się automatyzację wdrażania za pomocą usługi Windows Update for Business, WSUS lub MECM, ale zawsze należy uwzględnić fazę testowania w środowiskach testowych w celu wykrycia potencjalnych regresji przed uruchomieniem. W infrastrukturach odizolowanych od sieci zaleca się audyt wszystkich plików przychodzących za pomocą narzędzi takich jak reguły YARA, które służą do rozpoznawania podejrzanych wzorców w formatach EMF/WMF i innych formatach graficznych.
W bardziej zaawansowanych scenariuszach niektóre organizacje rozważają migrację swoich aplikacji wewnętrznych do nowocześniejszych interfejsów API, takich jak Direct2D, DirectWrite lub wieloplatformowe silniki graficzne (Cairo, Skia), które oferują lepszą izolację i mniejsze uzależnienie od starszego GDI. W perspektywie średnioterminowej Microsoft może wycofać znaczące elementy GDI w przyszłych wersjach systemu Windows, aby zmniejszyć powierzchnię ataku, choć kompatybilność ze starszym oprogramowaniem nadal będzie stanowić wyzwanie.
Z perspektywy kryminalistyki i inżynierii wstecznej, narzędzia takie jak WinDbg, KD i Volatility umożliwiają analizę zrzutów pamięci po wystąpieniu BSOD (niebieskiego ekranu śmierci) oraz obserwację uszkodzeń pamięci oznaczonych jako „Gdi” w puli pamięci jądra. Exploity typu proof-of-concept, opublikowane w celach badawczych, pokazują, jak plik EMF (Engine Memory File) z pewnymi nieprawidłowo sformatowanymi rejestrami (np. w EMR_HEADER) może wymusić wyścig i spowodować awarię. Ta wiedza jest kluczowa dla zespołów reagowania na incydenty, aby zrekonstruować przebieg rzeczywistego ataku.
W przypadku incydentu zaleca się stosowanie ram działania, takich jak NIST (Identify, Contain, Eradicate, Recover). Obejmuje to izolację zainfekowanych systemów , zachowanie dowodów (zrzutów pamięci, logów, próbek podejrzanych plików), wdrażanie oczekujących poprawek, skanowanie systemów za pomocą zaktualizowanych narzędzi antywirusowych oraz przywracanie danych z zweryfikowanych kopii zapasowych lub powrót do poprzedniego stanu . Ponadto zaleca się okresowy przegląd zdobytych doświadczeń w celu usprawnienia procesów łatania i wzmacniania systemów.
Cała historia awarii i poprawek związanych z Windows GDI pokazuje, jak kruche mogą być starsze komponenty, gdy nie ma solidnej, wielowarstwowej strategii zabezpieczeń i aktualizacji. Zrozumienie, w jaki sposób wykorzystywane są te luki, które wersje są zagrożone i jakie dodatkowe środki kontroli można zastosować, pozwala administratorom i specjalistom ds. cyberbezpieczeństwa wzmocnić swoje systemy i zapobiec awarii prostego obrazu lub specjalnie spreparowanego metapliku albo całkowitemu naruszeniu infrastruktury Windows.
