W dzisiejszym artykule opiszemy nietypowy atak, przy pomocy którego będziemy mogli przeprowadzić sabotaż na koncie Administratora w organizacji. Skradniemy jego poświadczenia logowania (bilet Kerberos) i zapiszemy je do pliku. Następnie tak zdobyty bilet użyjemy na serwerze Linux (Kali) do uwierzytelnienia się do kontrolera domeny w Active Directory i uzyskamy dostęp do jego zasobów. Dzięki temu będziemy mogli przeprowadzić dalszy atak.
Uważaj Adminie, gdzie się logujesz!
Jeśli jesteś administratorem IT w firmie i jesteś odpowiedzialny za systemy Microsoft, pewnie myślisz, że straszymy lub piszemy niestworzone rzeczy. Przecież zabezpieczenia Windows dbają o to, żeby logowanie było bezpieczne. Jeśli dodatkowo do logowania używasz MFA to tym bardziej jesteś przekonany, że wszystko jest ok. Otóż nic bardziej mylnego. Twoje poświadczenia (zarówno bilet Kerberos jak i NTLM hash) można łatwo skraść podczas sesji i wykorzystać na innym komputerze (z systemem Windows lub Linux/Unix/MacOs) do przeprowadzenia ataku z wykorzystaniem Twojego konta.
Na Kapitanie Hack’u dużo piszemy o bezpieczeństwie Microsoft. W przypadku atakowania systemów Microsoft utworzyliśmy nawet osobną kampanię CYBER KILLCHAIN, w której opisujemy różne sposoby ataku. Atak, który dzisiaj zgłębiamy wykorzystuje słabość protokołu Kerberos, a raczej sposób w jaki można zapisać bilet Kerberos, który został przydzielony użytkownikowi podczas logowania do komputera w sieci. Użyjemy narzędzia kekeo, za pomocą którego wyeksportujemy bilet do pliku, a następnie użyjemy go na innym komputerze (Linux).
Czy bezpieczeństwo firmy uzależnione jest od higieny pracy administratora?
Notoryczną przypadłością i przyzwyczajeniem wielu administratorów IT w firmach jest użycie do logowania na serwery członkowskie domeny Active Directory lub, nie daj Boże, na stacje robocze użytkownika posiadającego wysoko uprzywilejowane uprawnienia, często z uprawnieniami administratora domeny! Tak wiemy, że na adminie robi się wszystko szybciej i wygodniej, ale nie w tym rzecz. Posiadając nawet wdrożony system PAM, zabezpieczenia logowania MFA możemy i tak paść ofiarą sabotażu. Uwaga także dotyczy zwykłych kont logujących się do Windows! Dlaczego nie powinniśmy tego robić? Ponieważ jak się poniżej przekonasz z łatwością można przejąć poświadczenia twojego konta i je wykorzystać na innym komputerze. Dotyczy to głownie biletów Kerberos, ponieważ to one pozostają dostępne w systemie w momencie logowania sesji użytkownika. Jeśli więc cyberprzestępca zdobędzie dostęp do takiego komputera, może zastawić na nim pułapkę. Wszystko zależy oczywiście od poziomu zabezpieczeń jakie posiadasz w firmie, ale w większości przypadków taki atak można wykonać z dużym powodzeniem. Należy również pamiętać, że „udostępniając” w ten sposób swoje poświadczenia cyberprzestępcy, sami stajemy się ofiarą z tą drobną różnicą – na koncie zwykłego użytkownika można zrobić niewiele, za to na koncie admina już bardzo dużo. W taki sposób powstawały słynne ataki np. malware NotPetya czy WannaCry, które oprócz podatności w protokołach do uwierzytelniania wykorzystywały przejęte hash’e NTML kont użytkowników do logowania się na inne komputery. Opisywany atak z przejęciem biletu Kerberos nazywa się Pass-the-Ticket.
Diabeł tkwi w szczegółach
Załóżmy, że do logowania do systemu Windows używamy najbezpieczniejszego mechanizmu uwierzytelniania jaki oferuje Microsoft – czyli protokołu Kerberos. W przeciwieństwie do NTLM, Kerberos oferuje większe bezpieczeństwo, ponieważ nigdy nie przesyła haseł przez sieć w sposób jawny. Jest unikalny w użyciu biletów, które potwierdzają tożsamość użytkownika na danym serwerze/komputerze bez wysyłania haseł przez sieć lub buforowania haseł na dysku twardym komputera lokalnego, na który zalogował się użytkownik. Uwierzytelnianie Kerberos to najlepsza metoda dla wewnętrznych instalacji aplikacji w firmie, które mogą wspierać ten protokół (np. strony na IIS używane tylko przez klientów domeny). Ale czy do końca jest taki bezpieczny? W Internecie można znaleźć kilka programów/skryptów umożliwiających przechwycenie biletu Kerberos. Jednym z nich jest program kekeo.
Uwaga! Program kekeo jest wykrywany przez większość oprogramowania antywirusowego, niemniej jednak jego twórca udostępnia kody źródłowe, które można wykorzystać do napisania własnego programu. Jak ominąć antywirusa pisaliśmy w artykule tutaj na przykładzie narzędzia mimikatz.
Za pomocą wbudowanego modułu „tgt” w kekeo, możemy przejąć sesję Kerberos i zapisać bilet na dysku twardym komputera. Taki bilet możemy następnie użyć i wykorzystać na innym komputerze. Poniżej prezentujemy wykonanie trzech komend w kekeo:
1) Pierwsza komenda pozwoli wyświetlić bilet Kerberos i pokaże okres jego ważności:
kerberos::list
Widzimy, że bilet jest ważny 10 godzin. Okres na jaki jest wystawiany (okres ważności) odpowiada poniższe ustawienie GPO na kontrolerach domeny.
Należy pamiętać, że mamy 10 godzin (domyślnie), abyśmy mogli go użyć. Dlatego najczęściej, przy tego typu ataku cyberprzestępcy starają się utworzyć backdoor w środowisku IT umożliwiający im stały dostęp.
2) Druga komenda zapisze bilet Kerberos zalogowanego do Windows użytkownika (Administrator) do pliku na dysku lokalnym:
tgt::deleg
W naszym przypadku plik został zapisany pod nazwą:„[email protected][email protected]_delegate.kirbi”
3) Trzecia komenda pozwoli użyć zapisany bilet i podmienić aktualny bilet zalogowanego użytkownika np. na innym komputerze lub podczas sesji zwykłego użytkownika na tym samym komputerze, do którego zalogował się administrator – atak Pass-the-Ticket.
kerberos::ptt <ścieżka_z_nazwą_pliku_.kirbi>
Od tej pory jesteśmy Administratorem, a po tym kroku fantazja nie zna granic!
Scenariusz – przejęcie konta admina i wykorzystanie poświadczeń na Linux/Unix
W poniższym scenariuszu pokażemy jak za pomocą jednolinijkowej komendy możemy zapisać bilet Kerberos Administratora, a następnie przekopiować go na Linux (Kali) i użyć do zaatakowania kontrolera domeny.
Krok 1. Przechwycenie biletu Kerberos administratora – narzędzie Kekeo
Ten krok można wykonać w różny sposób. Wystarczy, że w jakiś sposób zachęcimy administratora logującego się na komputer do uruchomienia skryptu. Nie będziemy tutaj sugerować metody, lecz jest wiele pomysłów jak taki administrator może uruchomić poniższą komendę (one-liner).
cmd /c “c:\temp\kekeo.exe “cd c:\temp” “tgt::deleg” “exit”” && exit
W wyniku wykonania powyższej komendy powinniśmy na dysku w określonym katalogu (w naszym przypadku c:\temp) otrzymać plik o rozszerzeniu *.kirbi.
Abyśmy mogli użyć pliku na Linux musimy go jeszcze przekonwertować na format „ccaches”.
W kekeo służy do tego polecenie:
misc::convert ccache
Dlaczego zapisaliśmy plik do formatu ccachees? Ponieważ nasz scenariusz zakłada, że będziemy logować się z komutera Linux i musimy go wcześniej wyeksportować to innego formatu (ccaches) używając funkcji misc::convert. Ten format możemy użyć także na komputerach MacOS.
Krok 2. Kopiujemy plik ccaches na Linux
Dla ułatwienia przeprowadzenia całej operacji kopiowania na Linux, możemy uruchomić na nim usługę SMB, która udostępni katalog, do którego będziemy mogli przekopiować nasz bilet admina. Użyjemy do tego narzędzia impacket-smbserver. Wpisując komendę:
impacket-smbserver kapitan /root/kapitan -smb2support
utworzymy zasób sieciowy o nazwie “kapitan” na naszym Linux, do którego będziemy mogli się dostać z naszego komputera Windows i przekopiować wyeksportowany wcześniej bilet Kerberos Administratora.
Krok 3. Użycie biletu Kerberos na Linux
W celu użycia biletu Kerberos na serwerze Linux musimy mieć zainstalowany na nim klient Kerberos (KRB5-user) i odpowiednio go skonfigurować. Dopiero po tym kroku będziemy mogli się do zalogować do domeny przy użyciu biletu Kerberos naszego admina. W naszym przypadku konfiguracja klienta Kerberos na Linux pliku krb5.conf wygląda następująco.
Jeśli po konfiguracji poprawnie odpala się na Linux polecenie klist, wówczas będziemy mogli użyć naszego biletu Kerberos do zalogowania się do komputera w domenie.
W tym celu musimy jeszcze wykonać następujące polecenie:
export KRB5CCNAME=<ścieżka do pliku ccchaces>
Wykonując polecenie klist dowiadujemy się, że używamy aktualnie biletu Administratora domeny Kapitan.hack. Widzimy też czas przez jaki jest ważny. Podobnie jak to jest na biletach komunikacji miejskiej 🙂 Wykonajmy zatem dalsze kroki.
Krok 4. Połączenie się do kontrolera domeny przez SMB
Ten krok będzie najkrótszy. Ograniczyliśmy się do prostego zadania – podpięcia się po SMB do dysku „C” na kontrolerze domeny, ale równie dobrze moglibyśmy użyć innych narzędzi do wykonania poleceń na kontrolerze domeny w kontekście konta Administrator (domain admin).
Poniżej przedstawiamy zrzut ekranu z podpięcia się po SMB do kontrolera domeny o nazwie DC. Wykonaliśmy dodatkowo listing katalogów. Wszystko dostępne jest z poziomu serwera Linux, który jest spoza domeny!
Czy jest się czego bać?
Powyższy scenariusz utwierdził nas w przekonaniu, że w przypadku Kerberosów i środowiska Microsoft nic nie jest w 100% bezpieczne. Należy uważać na tego typu aktywności w sieci, odpowiednio monitorować infrastrukturę IT, ponieważ jeśli tego nie robimy możemy być narażeni na przejęcie poświadczeń i użycie ich nawet na komputerze Linux, który jest spoza domeny AD. Ostatecznym celem opisywanego wyżej ataku Pass-the-Ticket może być kradzież skrótu hasła konta KRBTGT na kontrolerze domeny. Konto to jest używane przez Kerberos do szyfrowania biletów. Informacje o tym koncie widzimy także w bilecie jaki zapisaliśmy. Po uzyskaniu tego skrótu hasła haker może stworzyć nieograniczoną liczbę biletów, zapewniając dowolny poziom dostępu i praktycznie nieograniczoną żywotność. Jest to tak zwany Złoty Bilet (Golden Ticket).
Jak sobie radzić z problemem?
Zasadniczo nie można blokować exploitów, które wykorzystują atak Pass-the-Ticket za pomocą standardowych mechanizmów obrony przed cyberprzestępcą. Wynika to z faktu, że zmiany haseł lokalnych i haseł domenowych nie unieważniają skompromitowanych biletów. Podczas gdy uwierzytelnianie wieloskładnikowe (MFA) jest zwykle praktyką weryfikacji tożsamości, Pass-the-Ticket całkowicie wykorzystuje obejście MFA!
W celu zniwelowania możliwości przeprowadzenia ataku Pass-The-Ticket w środowisku powinniśmy:
- Wprowadzić bezpieczny model zarządzania uprawnieniami – ataki typu Pass-the-Ticket wykorzystują domyślne uwierzytelnianie w domenach Windows. Umożliwia to hakerom podszywanie się pod użytkowników lub procesy w celu uzyskania bocznego ruchu w sieci. Aby przeciwdziałać temu atakowi, należy zmniejszyć powierzchnię takiego ataku w sieci. Obejmuje to wymuszanie częstych, automatycznych aktualizacji danych uwierzytelniających, aby utrudnić ruch boczny. Powinniśmy także usunąć w środowisku współużytkowane loginy lokalnego administratora i zastąpić je złożonymi kryptograficznie, unikalnymi i często zmieniającymi się danymi uwierzytelniającymi.
- Sprawdzić, kto ma dostęp do wysoko uprzywilejowanych kont i zarządzać nimi w sposób bezpieczny.
- Ograniczyć ilość kont uprzywilejowanych w środowisku.
- Deleguj uprawnienia tam gdzie możesz, a nie przydzielaj wysoko uprzywilejowane konta – nie do wszystkich czynności potrzebujesz konto z uprawnieniami administratora. Tak wiemy, czasem na adminie robi się wszystko szybciej i wygodniej, ale nie w tym rzecz. Rozważ uprzywilejowane rozwiązanie do zarządzania tożsamością i dostępem, które zapewnia większą kontrolę.
- Przydzielaj uprawnienia na czas – dotyczy to zarówno delegowanego uprzywilejowanego dostępu oraz tymczasowego członkostwa we wstępnie zdefiniowanych grupach z podwyższonymi uprawnieniami. Te środki ograniczają zdolność atakujących do uzyskiwania dostępu do dodatkowych zasobów sieciowych po tym, jak skompromitowali komputer lub podszyli się pod użytkownika za pośrednictwem Pass-the-Ticket.
- Zmieniaj dwa razy hasło na koncie KRBTGT w domenie – dwa resetowania hasła wymuszają natychmiastową replikację zmienionych danych uwierzytelniających w całej domenie, aby zablokować użycie zhakowanych biletów.
- Wdróż renomowane rozwiązanie do monitorowania bezpieczeństwa Microsoft oraz do zarządzania dostępem uprzywilejowanym – dobre praktyki zarządzania i monitorowania na pewno pomogą w zabezpieczeniu środowiska i pozbyciu się problemów z tego typu atakami. Czy zabezpieczą w 100%? – pewnie nie, bo system bezpieczeństwa też można zhakować. Za to zmniejszymy znacznie ryzyko przeprowadzenia ataku na środowisko przez hakera. Pisaliśmy o takich przykładach na Hack’u.
Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.