Czas na kontynuację poprzedniego artykułu (ciekawy backdoor z kontem komputera umożliwiający trwały dostęp do Active Directory (część 1)), w którym wyjaśnialiśmy i pokazywaliśmy, jak można utworzyć backdoor’a w Active Directory korzystając z możliwości zalogowania się za pomocą obiektu konta komputera i specjalnej funkcji resetu konta.
Tym razem rozbudujemy ten przypadek w oparciu o specjalny skrypt wykonany na zwykłym koncie użytkownika w AD.
Powyższa możliwość jest dużym zagrożeniem dla każdej organizacji posiadającej Active Directory. Poniżej przedstawiamy jeszcze ciekawszy scenariusz, z fazą ataku, w którym konto komputera (nie mylić z kontem użytkownika w systemie) posłuży nam do zdobycia uprawnień administracyjnych i całkowitej kompromitacji domeny.
Eskalacja uprawnień za pomocą kont komputerów
Wspominaliśmy poprzednio, że w przypadku monitorowania bezpieczeństwa AD warto się skupić na podejrzanych aktywnościach jakie są wykonywane na kontach komputerów, a nie tylko na kontach użytkowników. Obiekty komputerów w AD (computer accounts objects) odgrywają również znaczącą rolę w operacjach zespołów RedTeam, ponieważ w wielu technikach ataku wykorzystuje się je do eskalacji uprawnień, ruchów bocznych i eskalacji uprawnień w domenie. Istnieją jednak również przypadki, w których konto komputera może być używane do ustanawiania trwałego dostępu do domeny (opisaliśmy to w poprzednim artykule).
Taki dostęp możemy wykorzystać w kontekście posiadanych na koncie komputera wysokich uprawnień. Wiąże się to albo z dodaniem dowolnego konta komputera do grupy o wysokim poziomie uprawnień, takiej jak administratorzy domeny, albo zmodyfikowaniem atrybutu „userAccountControl”, który przekształca konto komputera w konto kontrolera domeny! W obu scenariuszach atakujący może uwierzytelnić się jako konto komputera (ponieważ zna hasło) i wykonać operacje z podwyższonym poziomem uprawnień, takie jak DCSync, aby pobrać wszystkie skróty haseł użytkowników z domeny. Czy zatem w takiej sytuacji atak będzie rozpoznany przez systemy bezpieczeństwa w Twojej firmie? To zależy od podejścia i wiedzy na ten temat, ponieważ najczęściej skupiamy się tylko na kontach użytkowników. Poniżej pokażemy jak taki atak mógłby wyglądać w praktyce.
Utworzenie konta komputera w domenie
Jeśli masz w swojej domenie skonfigurowane domyślne ustawienia, jak to już wcześniej wyjaśnialiśmy i pokazywaliśmy, konto komputera (nawet 10 sztuk) może zostać domyślnie utworzone przez zwykłego użytkownika poprzez dodanie go ręcznie do domeny. Istnieją na to jeszcze inne metody, chociażby skrypty. Jednym z nich, który znaleźliśmy w Internecie, jest proste narzędzie, napisane w PowerShell, o nazwie PowerMAD. Jego twórcą jest Kevin Robertson.
Poniżej prezentujemy komendę dodania do domeny fikcyjnego konta komputera (z odpowiednimi wpisami DNS), które posłuży nam do dalszej fazy ataku na domenę. Polecenie to wykonujemy na zwykłym koncie użytkownika (w naszym przypadku kapitanhack.pl).
New-MachineAccount -MachineAccount NAZWA_KOMPUTERA -Domain NAZWA_DOMENY -DomainController NAZWA_KONTROLERA_DOMENY
Pierwsze co musimy zrobić, to pobrać narzędzie na naszą stację Windows i zaimportować moduł (narzędzie) „PowerMAD.psm1” do PowerShell. Dzięki temu będziemy mogli korzystać z wielu przydatnych funkcji takich jak dodanie komputera, wyłączenie go itp.
Na stacji Windows 10 jesteśmy zalogowani do domeny jako zwykły użytkownik „kapitanhack.pl”. Poniżej informacja o naszym użytkowniku w AD.
Dodajemy komputer do domeny za pomocą polecenia „New-MachineAccount” :
Narzędzie spyta się nas o hasło, jakie chcemy utworzyć dla obiektu konta komputera.
W naszym przypadku jest to „Fake123” (zamaskowane gwiazdkami na powyższym ekranie).
Od teraz nasz komputer pojawił się w AD w kontenerze „Computers” z utworzonymi poprawnie wszystkimi wymaganymi atrybutami (oraz będzie posiadał znane przez nas hasło).
Próba uwierzytelnienia się kontem komputera do domeny
Należy pamiętać, że domyślnie konta komputerów nie mają uprawnień do lokalnego logowania na komputerach w domenie – zabrania tego polityka bezpieczeństwa Windows. Jak pokazywaliśmy w poprzednim artykule, jest na to obejście – możemy użyć narzędzi/klientów, którzy akceptują poświadczenia sieciowe bezpośrednio lub za pomocą komendy „runas /netonly” lub użyć dołączonych funkcji „Invoke-UserImpersonation/Invoke-RevertToSelf” do narzędzia PowerView.
W naszym scenariuszu użyjemy wyżej utworzonego konta komputera KAPITANHACK$, do uwierzytelnienia się do AD oraz uruchomienia na jego poświadczeniach konsoli do zarządzania ADUC (Active Directory Users and Computers).
W tym celu posłużymy się następującym poleceniem:
runas /netonly /user:KAPITAN\KAPITANHACK$ “mmc.exe c:\windows\system32\dsa.msc”
Eskalacja uprawnień na koncie komputera
Tematem naszego artykułu jest przeprowadzenie ataku i kompromitacji AD przy użyciu konta komputera. Dobrym przykładem na to jest zdobycie uprawnień DCSync. Lecz aby móc zaatakować AD przy użyciu naszego konta komputera KAPITANHACK, musimy przydzielić mu najpierw odpowiednie uprawnienia w domenie. Standardowo uprawnienia DCSync posiadają cztery wbudowane grupy w AD: Administrators, Domain Admins, Enterprise Admins oraz Domain Controllers (grupa, do której dodane są konta kontrolerów domeny). Ewentualnie możemy je sprawdzić przy użyciu specjalnego skryptu lub dodać kontu komputera indywidualne uprawnienia (wymagane uprawnienia administracyjne): „Replicating Directory Changes All” na obiekcie domeny w AD.
Interesująca w tym przypadku dla nas jest grupa Domain Controllers oraz sposób dodania komputera do niej.
Zmiana wartości userAccountControl
Aby konto komputera pojawiło się jako kontroler domeny, atrybut userAccountControl musi mieć wartość 0x2000 = (SERVER_TRUST_ACCOUNT). 0x2000 to liczba szesnastkowa, która w systemie dziesiętnym jest liczbą 8192.
Sprawdziliśmy dokumentację protokołu MS-SAMR w Microsoft, aby dowiedzieć się jakie uprawnienie wymagane jest do zarządzania tym atrybutem. W sekcji 5 dokumentu możemy znaleźć informacje na temat atrybutu userAccountControl i dodatkowych uprawnień wymaganych do ustawienia niektórych bitów userAccountControl. Aby ustawić bit userAccountControl UF_SERVER_TRUST_ACCOUNT, użytkownik musi mieć przyznane uprawnienie DS-Install-Replica („Dodaj/usuń replikę w domenie”) dla obiektu domeny. Oprócz tego uprawnienia musimy jeszcze przydzielić uprawnieninie do zapisu (Write userAccountControl) dla tego atrybutu, ale ustawiamy to już tylko na konkretnym obiekcie komputera – w naszym przypadku KAPITANHACK$.
UWAGA! Jako alternatywa, uprawnienie „DS-Install-Replica” można przydzielić dla grupy „Authenticated Users” – wtedy będzie to mniej zauważalne w domenie.
W chwili obecnej nasz obiekt komputera KAPITANHACK posiada wartość 0x100 = (WORKSTATION_TRUST_ACCOUNT) i należy do grupy Domain Computers (zwykłych komputerów domeny).
Modyfikując wartość atrybut userAccountControl na 8192 uzyskamy pożądany efekt – zmiana typu konta i automatyczne przydzielenie go do grupy Domain Controllers. Poniżej zaprezentowaliśmy sposób modyfikacji tego atrybutu z perspektywy Powershell i wynik w AD. Możemy też zmianę wykonać z konsoli ADUC, jak pokazano powyżej (w lewym ekranie) ręcznie edytując i zmieniając wartość 4096 na 8192. Pamiętajmy tylko o wymaganych uprawnieniach.
Zmianę dokonujemy za pomocą funkcji Set-ADComputer w Powershell na zalogowanym zwykłym użytkowniku „kapitannhack.pl” do domeny z dodanymi powyższymi uprawnieniami wymienionymi powyżej:
Set-ADComputer KAPITANHACK -replace @{ “userAccountControl” = 8192 }
Oraz jako dowód prezentujemy zrzut z konsoli ADUC po wykonanych zmianach.
Na podstawie powyższego przykładu widzimy, jak zmiana wartości jednego atrybutu (userAccountControl) na obiekcie w AD wpływa na finalny skutek takiej zmiany (zmiana typu konta oraz dodanie go do uprzywilejowanej grupy).
Przeprowadzenie ataku na domenę i jej kompromitacja.
Mamy stworzonego backdoor’a w postaci konta komputera KAPITANHACK, którym możemy uwierzytelniać się do domeny oraz przypisaliśmy mu odpowiednie uprawnienia do domeny pozwalające na wykonanie ataku DCSYNC. To co moglibyśmy jeszcze zrobić dodatkowego, to ukryć nasze konto przed znalezieniem i widocznością dla innych w domenie używając do tego metody opisanej w tym artykule.
O ataku DcSync pisaliśmy dużo na naszym portalu. W naszym przykładzie dodanie komputera do grupy „Domain Controllers” dodatkowo zaciemnia lub nawet często omija reguły używane w rozwiązaniach do bezpieczeństwa, ponieważ podczas przeprowadzania ataku DCSync często pomijane są wszystkie konta należące do grupy Domain Controllers lub inne konta w uprawnionych do tego grupach, ponieważ traktowane są jako pełnoprawne. Coż…nie zawsze musi być kolorowo.
Ponieważ znamy hasło i login komputera KAPITANHACK, do ataku moglibyśmy się posłużyć narzędziem mimikatz. Lecz celowo tego nie pokażemy, ponieważ już taki atak demonstrowaliśmy w innym artykule. Pokażemy, jak przeprowadzić taki atak z zewnętrznego komputera, zupełnie niezwiązanego z domeną (komputer z Linux) i użyjemy na nim narzędzia z pakietu Impacket o nazwie „secretsdump.py”.
Secretsdump to skrypt w Python używany do wyodrębniania poświadczeń z systemu. Główne przypadki użycia tego są następujące:
- Wyciąganie skrótów NTLM haseł użytkowników lokalnych (wyciąganie danych z bazy SAM)
- Wyodrębnij poświadczeń z domeny za pomocą DCSync
W naszym przypadku polecenie na Linux będzie wyglądało następująco:
python3 secretsdump.py kapitan.hack/KAPITANHACK\$:[email protected] -just-dc-user krbtgt
Przełącznik “-just-dc-user” oznacza, że przeprowadzamy atak DCSync i pobieramy hash hasła dla wskazanego konta (krbtgt).
Poprosiliśmy o hash hasła konta krbtgt i go otrzymaliśmy. Pozwoli nam on do wykreowania Golden Ticket, lecz jak to wykonasz dowiesz się z innego artykułu tutaj.
W tym momencie kończy się nasz scenariusz, ponieważ domena AD została skompromitowana.
Jak sobie radzić z problemem?
Musisz pamiętać, że w celu monitorowania podejrzanych aktywności użytkowników jak i komputerów w domenie nie wystarczą zwykłe narzędzia do zbierania i monitorowania logów. Analiza logów może być trudna w tym przypadku, ponieważ musimy dobrze wiedzieć co system loguje, czy w ogóle loguje, w jakiej ilości i wreszcie jak znaleźć odpowiednie zdarzenia, a potem podjąć na jego podstawie odpowiednią akcję. Jako analogię do powyższego pozwolimy sobie przytoczyć pewien przykład (obraz bitwy– niestety nie znamy twórcy, wzięty z prezentacji Sean’a Metcalf’a), na którym każde zdarzenie (osoba) jest za coś odpowiedzialna.
Jak znaleźć w tym gąszczu informacji tą właściwą?
Musimy też pamiętać, że niektórych zdarzeń system może w ogóle nie odłożyć w logu i trzeba do tego zastosować dodatkowy audyt, technologię lub rozwiązanie firm trzecich.
Potrzebna jest też do tego odpowiednia wiedza, zaszyta logika oraz często technologia, która pozwoli na wykrycie i zablokowanie lub wręcz zabezpieczenie odpowiednio obiektów przez możliwością modyfikacji.
Wiemy już, że monitorowanie użytkowników to za mało, musimy skupić się na monitorowaniu kont komputerów, zmian ich atrybutów, nadawania „nietypowych” uprawnień w domenie, logowań oraz odpowiednim hardeningu systemów, czy nawet zastosowaniu logiki zarzadzania i separacji uprawnień Zero Trust, aby jak najbardziej ograniczyć przestrzeń ataku.
Odpowiednie zabezpieczenie AD jest szczególnie ważne w tych trudnych czasach, gdy polskie firmy są atakowane przez hackerów z innych państw. Zhackowanie Active Directory pozwala na zdobycie kluczy do „królestwa”, czyli praktycznie przejęcie prawie wszystkich zasobów w firmie.
Podsumowanie
Nadszedł czas na podsumowanie obu części artykułów. Powyższa metoda, jak i ta z poprzedniego artykułu (o resecie konta komputera) oraz inne jakie pokazujemy na Kapitanie pokazują tylko, że wymyślane są non stop nowe sposoby na obejście zabezpieczeń i systemów do monitorowania bezpieczeństwa. Czy Twój system i konfiguracja jest w stanie to wykryć? Staramy się, Drogi Czytelniku, abyś był na bieżąco w technikach ataku i zabezpieczał odpowiednio własne środowisko w firmie. Jeśli interesuje Ciebie zabezpieczenie Twojej domeny na wysokim poziomie oraz zabarykadowanie jej proponujemy bezpośredni kontakt z nami. O koncepcji zabarykadowania AD wspominaliśmy w osobnym artykule tutaj.
Zachęcamy także do zapoznania się z treścią naszej pierwszej części artykułu – Ciekawy backdoor z kontem komputera umożliwiający trwały dostęp do Active Directory (część 1)