Elementrica
03Realizacje04Referencje05Firma06Aktualności07Kontakt
PLENDE

Nasłuch, jedno konto i cała domena

Testy penetracyjne
Nasłuch, jedno konto i cała domena

Klient poprosił nas o jedno: sprawdźcie sieć wewnętrzną tak, jak zrobiłby to ktoś, kto już siedzi w środku. Zwykły pracownik, zwykłe gniazdko, zero specjalnych uprawnień na start.

Nie użyliśmy żadnego świeżego exploita ani luki zero-day. Wystarczyło słuchać, co sieć sama rozgłasza, i grzecznie odpowiadać.

W dwa tygodnie mieliśmy w rękach konto administratora domeny, pełną bazę haseł z kontrolera i jedno hasło, które logowało nas na prawie sto sześćdziesiąt kont naraz. Poniżej cała ścieżka, technika po technice, z mapą na MITRE ATT&CK.

Kontekst

Zacznijmy od rzeczy, która powinna działać na korzyść klienta. Polityka haseł w domenie wymagała czternastu znaków. To więcej niż w większości firm, które odwiedzamy, i na papierze wygląda odpowiedzialnie.

Problem w tym, że ta reguła żyła w ustawieniach domeny, ale nie w rzeczywistości. Kiedy ktoś podniósł wymaganą długość, nikt nie wymusił zmiany istniejących haseł. Nowe konta łapały nowy wymóg, stare zostały przy swoim. W bazie, którą później wyciągnęliśmy z kontrolera, spokojnie siedziały hasła krótsze niż dziewięć znaków, mimo że system twierdził, że minimum to czternaście. Nawet hasło administratora domeny miało jedenaście.

Sam test był prosty w założeniu: pentest sieci wewnętrznej z perspektywy kogoś, kto ma już dostęp do sieci biurowej. Wewnętrzny użytkownik: stażysta z laptopem, ktoś podłączony do gniazdka w sali konferencyjnej, przejęta stacja robocza. Zakres to kilka segmentów sieci i jedno pytanie: jak daleko taki ktoś zajdzie.

Wyzwanie

Środowisko nie było budowane bez namysłu. Była domena Active Directory, była segmentacja na kilka podsieci, była polityka haseł ostrzejsza niż przeciętna. Gdyby oceniać je z listy kontrolnej do audytu, sporo pól dałoby się odhaczyć na zielono. Uczciwie to przyznajemy, bo wiarygodność testu bierze się z pokazywania obu stron, a nie tylko tych złych rzeczy.

Słaby punkt był gdzie indziej, w elementach które nie krzyczą z raportu zgodności. W tym, jak Windows domyślnie rozwiązuje nazwy, kiedy zawiedzie DNS. W tym, że część hostów nie wymuszała podpisywania komunikacji SMB. I w jednym koncie, które robiło stanowczo za dużo naraz.

Co zrobiliśmy

Zaczęliśmy od nasłuchu. Kiedy maszyna w sieci Windows nie znajdzie jakiejś nazwy w DNS, nie poddaje się. Rozgłasza do całego lokalnego segmentu pytanie w stylu „hej, czy ktoś wie, kto to jest?”. To zaproszenie dla każdego, kto akurat słucha. My słuchaliśmy. Odpowiadaliśmy „tak, to ja”, a maszyna z zaufaniem próbowała się do nas uwierzytelnić, oddając nam po drodze swoją próbę logowania w formie skrótu NetNTLMv2. Do tej samej puli dorzuciliśmy drugi mechanizm: w środowisku Windows protokół IPv6 jest domyślnie włączony i ma pierwszeństwo, a nikt nie skonfigurował dla niego serwera adresacji. Weszliśmy w tę pustkę, przedstawiliśmy się jako serwer konfiguracji i jako serwer nazw, i przechwyciliśmy kolejne próby uwierzytelnienia.

Potem przyszła kolej na przekazanie sesji. Ponieważ część hostów nie wymuszała podpisywania SMB, nie musieliśmy nawet łamać przechwyconych poświadczeń. Przekazaliśmy je w locie do innych maszyn i działaliśmy w imieniu tego użytkownika. Tu zadziałał efekt kuli śnieżnej: jeden z użytkowników, który wpadł w naszą pułapkę, miał uprawnienia lokalnego administratora na osiemnastu maszynach. Z każdej z nich zgarnęliśmy lokalną bazę kont ze skrótami haseł.

To samo konto okazało się administratorem domeny, używanym do codziennej pracy. Złamaliśmy jego hasło offline na naszej crack-maszynie. Jedenaście znaków, poniżej ich własnego progu czternastu, więc poszło szybko. Na poziomie domeny to był koniec.

Z uprawnieniami administratora domeny zrzuciliśmy z kontrolera całą bazę haseł Active Directory. Ponad trzy tysiące zestawów poświadczeń. Następnie łamaliśmy je offline, spokojnie, bez presji blokad kont. Co piąty skrót padł, dokładnie 22 procent. A na koniec puenta, po którą przyszliśmy: jedno hasło powtarzało się na 158 kontach.

Cała ścieżka w języku MITRE ATT&CK wygląda tak:

IDTechnikaJak jej użyliśmy
T1590.001Gather Victim Network Information: Domain Propertiesustaliliśmy właściwości domeny i mapę środowiska
T1557.001Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relaypodszyliśmy się pod rozwiązywanie nazw i przekazaliśmy przechwycone sesje
T1557.003Adversary-in-the-Middle: DHCP Spoofingweszliśmy w rolę serwera konfiguracji i nazw dla IPv6
T1110.002Brute Force: Password Crackingzłamaliśmy hasła offline na podstawie zrzuconych skrótów
T1003.003OS Credential Dumping: NTDSzrzuciliśmy bazę haseł z kontrolera domeny
T1201Password Policy Discoveryodczytaliśmy realną politykę haseł i skonfrontowaliśmy ją z danymi

Mechanikę pierwszego kroku najłatwiej pokazać na uproszczonym przebiegu. Dane są generyczne, żadnych prawdziwych nazw, adresów ani czasów:

# maszyna nie znajduje nazwy w DNS i pyta cały segment
[BROADCAST]  kto to jest "fileserv01"?
[NASZ HOST]  to ja, łącz się ze mną
[MASZYNA]    ok, uwierzytelniam się...  (NetNTLMv2)

# host docelowy nie wymusza podpisywania SMB,
# więc przechwyconą sesję przekazujemy dalej
[NASZ HOST] -> [inny host]   loguję się jako przechwycony użytkownik
[inny host]                  dostęp przyznany

Rezultat

Pełna kompromitacja domeny z pozycji zwykłego użytkownika, bez luki zero-day, w dwa tygodnie, przy ryzyku ocenionym jako krytyczne. Kiedy atakujący ma konto administratora domeny i całą bazę haseł z kontrolera, nie włamuje się już do pojedynczych systemów. Porusza się po organizacji jak zaufany użytkownik. Powielone hasła zamieniają jedno złamanie w dostęp do dziesiątek kont. Powtórzone hasło lokalnego administratora sprawia, że przejęcie jednej maszyny powoduje przejęcie kolejnych.

Obok tej warstwy tożsamościowej środowisko ciągnęło za sobą drugi dług. Trzy krytyczne i ponad sto poważnych podatności na przestarzałych wersjach serwerów WWW, bibliotek kryptograficznych i usług bazodanowych, plus słabe zestawy szyfrów TLS. Każda z nich to osobny wektor. Razem składają się na obraz środowiska, w którym łatanie przestało nadążać za rzeczywistością.

Co z tym zrobić, w formie do odhaczenia:

  • Wyłączyć LLMNR i NBT-NS przez GPO tam, gdzie nie są potrzebne, i zablokować ruch DHCPv6 oraz ogłoszenia routera, jeśli IPv6 nie jest używane. To odbiera atakującemu pierwszy krok, czyli darmowe poświadczenia z nasłuchu.
  • Wymusić podpisywanie SMB na wszystkich stacjach i serwerach. Bez tego przechwyconą sesję da się przekazać dalej i łamanie nie jest nawet potrzebne.
  • Rozdzielić konta administracyjne od kont do codziennej pracy i wdrożyć zarządzanie hasłami lokalnych administratorów, na przykład LAPS, żeby przejęcie jednej maszyny nie otwierało kolejnych.
  • Przy każdej zmianie polityki haseł wymusić reset istniejących haseł. Reguła, która nie obejmuje kont sprzed zmiany, chroni wyłącznie na papierze.
  • Wymusić unikalność haseł między systemami i podnieść realne minimum długości do co najmniej piętnastu znaków. Jedno hasło na wielu kontach to prezent dla atakującego.
  • Uporządkować łatanie: centralny proces aktualizacji systemów i aplikacji, wycofanie przestarzałych protokołów i słabych szyfrów.
  • Gdzie się da, dołożyć uwierzytelnianie wieloskładnikowe i segmentację, żeby ograniczyć zasięg ataku man-in-the-middle w obrębie segmentu.

Na koniec

Najciekawsze w tym teście jest to, że żaden krok nie był magią. Nasłuch, przekazanie sesji, jedno za bardzo uprzywilejowane konto, jedno hasło powielone setki razy. Każdy z tych elementów wygląda niewinnie, dopóki nie ustawią się w rządku.

Więc pytanie na koniec jest proste. Gdyby ktoś podłączył się dziś do gniazdka w twojej sali konferencyjnej i zaczął tylko słuchać, jak daleko by zaszedł?

Od zwykłego konta do całej domeny, bez jednego exploita. Twoja sieć wewnętrzna wytrzymałaby taki scenariusz?

Umów rozmowę z konsultantem, wspólnie omówimy zakres, ryzyka i to, jak taki test mógłby wyglądać u Ciebie.

Poprzedni
Faktura, karta podarunkowa i 22 komplety haseł
Następny
Cała załoga miała dostęp do magazynu z sekretami. Wystarczyła jedna reguła grupy

Wszystkie realizacje zanonimizowano sektorowo, bez nazw, dat i danych pozwalających zidentyfikować klienta, zgodnie z poufnością. Nie publikujemy żadnych prawdziwych podatności ani danych technicznych klienta.