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:
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ł?
Umów rozmowę z konsultantem, wspólnie omówimy zakres, ryzyka i to, jak taki test mógłby wyglądać u Ciebie.
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.