LLMNR/NBT-NS Poisoning (T1557.001)

Dzisiaj lab z Cyberdefenders - analiza ruchu sieciowego ze zrzutu PCAP. Scenariusz jest następujący:

Your organization's security team has detected a surge in suspicious network activity. There are concerns that LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) poisoning attacks may be occurring within your network. These attacks are known for exploiting these protocols to intercept network traffic and potentially compromise user credentials. Your task is to investigate the network logs and examine captured network traffic.

Czym w ogóle są protokoły LLMNR (Link-Local Multicast Name Resolution) i starszy NBT-NS (NetBIOS Name Service)? Są to protokoły do rozwiązywania nazw hostów w sieci lokalnej LAN. Przykład: Host A, będący komputerem pracownika, chce uzyskać dostęp do współdzielonych zasobów np. SMB share. Używa do tego nazwy \\serwerplikow\finanse2026. Jeśli serwer DNS nie znajdzie adresu IP dla tego SMB to host A za pomocą protokołu LLMNR wysyła zapytanie (multicast, w przypadku NBT-NS to broadcast) “Kto ma adres IP \\serwerplikow\finanse2026 ?”. Pozostałe hosty w LAN nasłuchujące na porcie UDP 5355 (NBT-NS na UDP 137), jeśli mają ten adres, odpowiadają mu “Jestem \\serwerplikow\finanse2026 mam adres IP 192.168.50.120”.

Oba mają jednak istotne wady:

1. Ruch nie jest szyfrowany - atakujący mogą podsłuchać zapytania LLMNR oraz NBT-NS, jeśli są w sieci lokalnej.
2. Oba protokoły nie mają mechanizmu uwierzytelniania - nie sprawdzają od kogo pochodzi odpowiedź.
3. Ofiara po otrzymaniu odpowiedzi z poszukiwanym adresem IP np. serwera ftp, bądź innego zasobu, będzie próbowała się z nim połączyć. Jeśli ten serwer wymaga uwierzytelnienia (używa protokołu NTLM, używanego w Windows), to host ofiary wyśle hash NTLMv2 (lub v1).

I tu do akcji wkracza cyberzbój, który może przeprowadzić atak typu Adversary in the Middle, a konkretnie LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001). Atakujący mający dostęp do sieci LAN, w której znajduje się ofiara, nasłuchuje wszelkich zapytań LLMNR w sieci na porcie 5355 (lub 137). Jeśli takie zapytanie zostanie wysłane (a przypominam, że jest to broadcast lub multicast), to atakujący je przechwytuje i SZYBCIEJ NIŻ inne hosty wysyła odpowiedź to ja jestem SMB share, oto mój adres IP. Ofiara odbiera odpowiedź, nie weryfikując od kogo przyszła. Atakujący mogą do tego ataku użyć popularnego narzędzia Responder, które potrafi imitować m.in. SMB share i oprócz nasłuchiwania na porcie 5355 może też nasłuchiwać na 445. Ofiara znając już adres IP atakującego, myśląc że to zwykły SMB, próbuje nawiązać połączenie. Responder automatycznie wysyła NTLM Challange, niezbędny do uwierzytelnienia. Ofiara odsyła NTLM Response wraz z hashem NTLMv2. Responder przechwytuje hash. Za pomocą hashcata atakujący łamie hasło offline albo przekazuje hash dalej (relay). Game Over.

Pytanie 1

#

In the context of the incident described in the scenario, the attacker initiated their actions by taking advantage of benign network traffic from legitimate machines. Can you identify the specific mistyped query made by the machine with the IP address 192.168.232.162?

Z głównego opisu zadania wiemy, że prawdopodobnie mamy do czynienia z atakiem LLMNR/NBT-NS poisoning, ale musimy to oczywiście udowodnić i dać twarde dowody. Na początku przefiltrujmy pakiety i wyświetlmy tylko te związane z protokołem LLMNR i NBT-NS - bo to za pomocą ich wykonywany jest atak tego typu.

Jak widać host 192.168.232.162 zrobił literówkę tworząc zapytanie o adres zasobu “fileshaare” (dodatkowe “a”). Zapytanie wysyłane jest na specjalny adres multicast 224.0.0.252 używany przez LLMNR. Dlaczego to w ogóle jest istotne? Ponieważ protokół LLMNR jest wykorzystywany gdy DNS np. nie potrafi rozwiązać nazwy. Najpewniej poprawną nazwą jest “fileshare”. W tym momencie ofiara wysyła zapytania w sieci LAN, które może również trafić do atakującego.

Pytanie 2

#

We are investigating a network security incident. To conduct a thorough investigation, We need to determine the IP address of the rogue machine. What is the IP address of the machine acting as the rogue entity?

Ataki dotyczą LLMNR oraz NBT-NS - dlatego zastosuję filtr llmnr i nbns, aby wyświetlić istotne informacje. Szybka obserwacja - host 192.168.232.215 odpowiada na wiele zapytań LLMNR hosta 192.168.232.162. Dodatkowo widzimy, że odpowiada swoim adresem IPv4 oraz IPv6 zarówno dla zapytań o hosta “fileshaare” oraz “prinetr” (kolejna literówka ofiary, prawdopodobnie miało być printer), co jest podejrzane, bo adresy IP w LAN muszą być unikalne. Dodatkowo hosty o nazwie “fileshaare” lub “prinetr” są nienaturalne i raczej nie powinny istnieć w sieci, a tu ofiara dostaje odpowiedź!

Podobnie w przypadku NBT-NS. Atakujący odpowiada swoim adresem IP 192.168.232.215 dla zapytań o CYBERCACTUS, PRINETR i FILESHAARE. Czyli znowu - różne nazwy hostów, a za każdym razem odpowiedź z tym samym IP 192.168.232.215.

Dodatkowo widzimy ciekawą sytuację. Udana odpowiedź na zapytanie o FILESHAARE jest wysyłana przez 192.168.232.215, natomiast w przypadku CYBERCACTUS na zapytanie odpowiada zarówno host 192.168.232.148 i 192.168.232.215 jednocześnie, na co pytający 192.168.232.176 odpowiada Name is in conflict. Czwarta próba jest jednak udana i odpowiedzią jest adres 192.168.232.215. Również na zapytanie o nazwę hosta PRINETR wysyłana jest odpowiedź 192.168.232.215.

• host 192.168.232.215 odpowiada na zapytania o różne nazwy hostów swoim jednym(!) adresem IP (zarówno IPv4 i IPv6)
• host 192.168.232.215 odpowiada na zapytania o hosty z literówkami
• host 192.168.232.215 odpowiada na zapytania, co wprowadza konflikt adresów IP

Możemy ponad wątpliwość stwierdzić, że 192.168.232.215 jest atakującym.

Pytanie 3

#

As part of our investigation, identifying all affected machines is essential. What is the IP address of the second machine that received poisoned responses from the rogue machine?

Zidentyfikowaliśmy już atakującego - 192.168.232.215. Ponownie przefiltrujmy ruch z użyciem protokołów LLMNR i NBT-NS. Analiza adresów IP pokazuje, że zarówno host 192.168.232.162 jak i 192.168.232.176 otrzymali od atakującego zatrute odpowiedzi.

Poniżej zatrute odpowiedzi kierowane do hosta 192.168.232.162.

Tutaj zatrute odpowiedzi do hosta 192.168.232.176.

Poniżej szczegóły zatrutej odpowiedzi wysłanej przez atakującego do ofiary próbującej uzyskać adres IP hosta o nazwie “fileshaare”.

Udane zatrucie hostów 192.168.232.176 i .162 następuje również przez protokół NBT-NS, oznaczony w Wireshark jako NBNS.

Poniżej szczegóły jednej z zatrutych odpowiedzi wysłanych do 192.168.232.176 przez atakującego. Odpowiada swoim adresem na zapytanie o nazwę “PRINETR”.

Szczegóły zatrutej odpowiedzi wysłanej do hosta 192.168.0.176 przez atakującego. Atakujący wysyła w odpowiedzi swój adres IP na pytanie o hosta “CYBERCACTUS”.

Co ciekawe poisoning ma również miejsce przez protokół mDNS - dla obu ofiar.

Ostatecznie widzimy, że ofiarami ataku są hosty 192.168.232.176 oraz 192.168.232.162.

Pytanie 4

#

We suspect that user accounts may have been compromised. To assess this, we must determine the username associated with the compromised account. What is the username of the account that the attacker compromised?

Z MITRE ATT&CK wiemy, że LLMNR poisoning służy do przejęcia hashu NTLMv2 ofiary, służącego do uwierzytelniania np. do SMB. Analizując przejęte pakiety możemy zobaczyć, że część ruchu odbywa się po protokole SMB w wersji 2 oraz 1. Pójdźmy zatem tym tropem i wyświetlmy ten ruch, ale z uwzględnieniem adresu IP atakującego. Możemy również zastosować bezpośrednio filtr ntlm, lecz ja wybrałem smb, ponieważ następne pytanie bezpośrednio go dotyczy.

Widzimy, że atakujący z sukcesem łączy się przez protokół SMB do współdzielonych zasobów hosta 192.168.232.176 (Pełna negocjacja wersji protokołu, sesji, a na koniec zaszyfrowana komunikacja).

I w sumie zatrzymamy się tu na dłużej - jest to punkt nad którym mocno się głowiłem i w którym bardzo mi pomógł pewien członek polskiej społeczności cyber NTHW (dzięki Clone!). Otóż jak już mówiłem, głównym zadaniem LLMNR poisoning jest przejęcie hasha NTLMv2 (lub v1). Jak? Ano atakujący po zatruciu ofiary swoimi odpowiedziami może zacząć nasłuchiwać na porcie 445 i czekać na próbę połączenia od tej ofiary. Jeśli ofiara będzie próbowała się połączyć z fałszywym SMB atakującego, wyśle mu jednocześnie swój hash, ponieważ SMB może wymagać uwierzytelnienia za jego pomocą. Atakujący go przejmuje i np. łamie offline.

To co jednak widzimy poniżej to moment w którym atakujący już posiada ten hash i próbuje się nim uwierzytelnić do SMB na 192.168.232.176. To atakujący (klient) łączy się na port 445 i wysyła pakiety REQUEST, a ofiara (serwer) RESPONSE. Wiadomo, że hash NTLMv2 jest wysyłany tylko w Session Setup Request podczas uwierzytelniania do SMB. Stąd było moje początkowe zdziwienie - czy to nie powinno być na odwrót? Czy to host .176 nie powinien się łączyć do .215 na port 445? Kiedy atakujący wykradł ten hash?

Otóż timestampy przejętych pakietów mówią, że wystąpiły kilkunasto/kilkudziesięcio-sekundowe przerwy w rejestrowaniu ruchu.

Biorąc to pod uwagę istnieją 2 możliwe scenariusze:

• Proces przejęcia hasha przez atakującego miał miejsce w jednej z przerw i nie została zarejestrowana
• Proces przejęcia hasha jest w innym, nieznanym nam zrzucie PCAP.

W całym dostępnym zrzucie PCAP nie ma przypadku requestu od jakiegokolwiek hosta do atakującego .215 z hashem NTLM.

Wiemy natomiast, że atakujący ostatecznie wszedł w posiadanie hasha. Skompromitowane zostało konto “janesmith” w domenie cybercactus.local. Nazwa hosta 192.168.232.215 to WORKSTATION. Atakujący próbuje uwierzytelnić się do udostępnianych zasobów hosta 192.168.232.176.

Poniżej hash NTLMv2 w pakiecie nr. 242 Session Setup Request, NTLMSSP_AUTH wysłanego przez host .215.

Pytanie 5

#

As part of our investigation, we aim to understand the extent of the attacker's activities. What is the hostname of the machine that the attacker accessed via SMB?

Ponownie skupimy się na tym samym procesie logowania na SMB przez atakującego hosta .215. Pakiet nr. 241 Session Setup Response zawiera metadane - m.in. nazwę hosta maszyny, do której atakujący próbuje się dostać - ACCOUNTINGPC, który z nazwy może sugerować, że są na nim wrażliwe dane finansowe.

Atakujący uzyskał dostęp, co potwierdza rozpoczęcie szyfrowanej komunikacji z SMB.

Rekomendacje bezpieczeństwa

#

Ostatecznie atakującemu 192.168.232.215 udaje się zatruć odpowiedzi na zapytania LLMNR oraz NBT-NS. Moment przejęcia hasha NTLM przez atakującego nie został zapisany w zrzucie. Atakujący wykorzystał wykradziony hash do uzyskania dostępu do SMB. Krótki czas ataku (niecałe 6 minut), od momentu pierwszej zatrutej odpowiedzi do wykorzystania przejętego hasha sugeruje, że atakujący mógł wykorzystać atak NTLM relay, zamiast łamać go offline.

Jak zwiększyć odporność na tego typu ataki? Oparłem się tu ponownie o MITRE ATT&CK:

• Jeśli protokoły LLMR i NetBIOS nie są niezbędne do poprawnego działania organizacji i jej operacji, to należy je wyłączyć np. przez Group Policy
• Użyć narzędzi endpoint security (EDR, HIPS/HIDS) - wykryć oraz zablokować ruch LLMNR, czy NetBIOS
• Stosowanie SMB signing, czyli podpisów kryptograficznych pakietów, aby uniemożliwić atak NTLM relay. Serwer zobaczy, że hash NTLM pochodzi od atakującego, a nie oryginalnego hosta wysyłającego
• Detekcja modyfikacji klucza rejestru HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast
• IDS/IPS - detekcja wzorców i blokowanie ruchu LLMNR/NetBIOS

Incident Timeline

#