Stare narzędzia, nowe problemy, czyli jak WerFaultSecure.exe pozwala wykraść hasła z pamięci LSASS w Windows 11

kapitanhack.pl 2 godzin temu

W ostatnich tygodniach badacze przypomnieli, iż czasem najprostsze i najstarsze narzędzia potrafią obejść nowoczesne zabezpieczenia. Omówiony we wpisie Zero Salarium sposób użycia starego pliku WerFaultSecure.exe (pochodzącego z Windows 8.1) do zrzutu pamięci procesu LSASS na Windows 11 24H2 pokazuje, iż kompatybilność wsteczna bywa bronią obosieczną oraz iż przez cały czas warto rozumieć, czym jest LSASS i dlaczego jego pamięć zawiera dane, których nie chcemy ujawnić.

Czym jest LSASS i dlaczego przyciąga uwagę atakujących

LSASS (Local Security Authority Subsystem Service) to krytyczny proces Windows odpowiedzialny za egzekwowanie zasad bezpieczeństwa systemu: obsługę logowań, wyliczanie tokenów dostępu, zmianę haseł i inne zadania związane z uwierzytelnianiem. To właśnie w pamięci LSASS bardzo często występują (czasowo) poświadczenia – od hashy NTLM po jawne hasła – które narzędzia takie jak Mimikatz potrafią odzyskać po zrzucie pamięci procesu. Na Kapitanie opisywaliśmy metody zrzutu pamięci LSASS i ryzyko związane z jej ujawnieniem – warto zapoznać się ze zbiorem materiałów na ten temat, w tym z artykułem o metodach zrzutu LSASS.

Na czym polega technika z użyciem WerFaultSecure.exe?

Badacze z Zero Salarium pokazują, iż jeżeli na nowoczesnym Windows 11 uruchomi się starszą, podatną wersję WerFaultSecure.exe (narzędzie WER — Windows Error Reporting), to proces ten, posiadając wysoki poziom PPL (Protected Process Light — np. WinTCB), może zostać wykorzystany do wygenerowania zrzutu pamięci LSASS bez wbudowanego szyfrowania.

Atak wymaga:

  1. Użycia specjalnego loadera (w opisywanym materiale to „WSASS”), aby uruchomić WerFaultSecure.exe w kontekście PPL i zapisania do pliku zrzutu pamięci, a następnie „naprawienia” nagłówka pliku tak, by wyglądał na legalny minidump, co ułatwia ominięcie wykrywania. Po uruchomieniu odszukujemy plik „proc.png” znajdujący się w tym samym folderze co WSASS.exe i przywracamy pierwsze 4 bajty do wartości {0x4D, 0x44, 0x4D, 0x50} („MDMP”). Następnie można go używać jako zwykłego pliku MINIDUMP.
  2. Po otrzymaniu takiego surowego zrzutu jesteśmy w stanie użyć narzędzi typu pypykatz czy Mimikatz do wydobycia hashy NTLM i (czasem) haseł wprost z pamięci. Opis tej sekwencji i parametrów (np. nieudokumentowane przełączniki /h, /pid, /file itp.) znajduje się w analizie Zero Salarium – tutaj.
Źródło: Zero Salarium

Dlaczego to działa mimo ochrony PPL i współczesnych łatek?

Mechanizm PPL miał ograniczyć możliwość czytania pamięci chronionych procesów bez uprzywilejowanego kodu. Jednak tutaj atak nie polega na prostym „odczycie” pamięci przez zwykły proces – wykorzystuje funkcjonalność WER i jej uprawnienia do tworzenia crash dumpów chronionych procesów. Starsze wersje WerFaultSecure.exe zawierały błąd powodujący zapis niezaszyfrowanego zrzutu; uruchomione w odpowiedni sposób na nowszym systemie – przy pomocy loadera, który dziedziczy uchwyty – mogą wyprodukować surowy zrzut LSASS. To przykład, gdy kompatybilność wsteczna + nieudokumentowane parametry + spryt loadera tworzą „ślepy punkt” w ochronie.

Konsekwencje: od hashów po lateral movement

Z uzyskanych zrzutów zwykle wyciąga się hashe NTLM lub bezpośrednie hasła, które następnie służą do eskalacji uprawnień i ruchu bocznego (lateral movement) w sieci. Techniki typu Pass-the-Hash, DCSync czy bezpośrednie loginy na podstawie odzyskanych haseł są standardem w arsenale atakującego – o tych technikach pisaliśmy na Kapitanie wielokrotnie (np. o technice Pass-the-Hash). Dlatego każda droga prowadząca do „wycieku” pamięci LSASS jest krytyczna z punktu widzenia bezpieczeństwa domeny/organizacji.

Co mogą zrobić obrońcy – praktyczne kroki

  1. Monitoruj i weryfikuj WerFaultSecure.exe – wykrywanie kopii WerFaultSecure.exe poza oczekiwanymi lokalizacjami (System32) i niespodziewane uruchomienia z parametrami są sygnałem alarmowym.
  2. Ogranicz możliwość kopiowania systemowych binariów i uruchamiania procesów z uprawnieniami PPL – polityki EDR, kontrola integralności plików, AppLocker/WDAC mogą pomóc (zobacz opis różnych wektorów ładowania kodu do LSASS i metod obrony).
  3. Wzmocnij wykrywanie użycia narzędzi do zrzutów pamięci – reguły SIEM/EDR na nietypowe operacje CreateProcessAsPPL, nietypowe uchwyty do plików czy operacje zapisu dużych dumpów.
  4. Segmentacja i ograniczenie uprawnień – minimalne uprawnienia administracyjne, separacja ról i silne uwierzytelnianie wieloskładnikowe ograniczają skutki potencjalnego wykradzenia poświadczeń.

Podsumowanie

Atak z użyciem starego WerFaultSecure.exe to przypomnienie, iż obrona musi brać pod uwagę nie tylko nowe luki, ale także to, jak historyczne binaria i mechanizmy kompatybilności mogą zostać zestawione w nowy łańcuch ataku. Dla osób odpowiedzialnych za bezpieczeństwo: priorytetem są monitorowanie anomalii wokół narzędzi WER, kontrola integralności plików systemowych oraz wzmocnienie wykrywania operacji zrzutu pamięci LSASS. Pełne techniczne omówienie metody przygotował Zero Salarium, a szersze tło i praktyczne metody ataku/obrony znajdziecie też w naszych archiwach (LSASS i ataki na hasła).

Idź do oryginalnego materiału