Odpowiedź na to pytanie zaciekawi na pewno niejedną osobę zajmującą się bezpieczeństwem IT. Podczas naszej wieloletniej pracy z systemami bezpieczeństwa i z logami zaobserwowaliśmy kilka ciekawych przypadków, które chcielibyśmy opisać i podzielić się nimi w tym artykule. Chcielibyśmy także pokazać, jak nieodpowiednio zabezpieczone logi mogą posłużyć w pozyskaniu interesujących informacji o infrastrukturze klienta.

Czasami, aby wykonać zwiad w środowisku i dowiedzieć się o kontach lub ich hasłach nie potrzebujemy wysokich uprawnień w systemie. Wystarczy odpytać bazę danych katalogu Active Directory o jego obiekty. Może to wykonać każdy użytkownik ze swojej stacji roboczej (patrz artykuł rozpoznanie). Również nie musimy wykonywać metodami brute force dodatkowego łamania haseł innych użytkowników lub kont uprzywilejowanych, ponieważ najczęściej taka aktywność pozostawia w mniejszym lub większym stopniu po sobie ślady i może zostać wykryta przez niektóre współczesne systemy bezpieczeństwa (pisaliśmy o tym w artykułach kampanii KILLCHAIN) – tego na pewno byśmy nie chcieli, a bynajmniej twórcy złośliwego oprogramowania.


Jak zatem pozostać niewykrywalnym w środowisku i pozyskać odpowiednie informacje?


Jak się okazuje nawet najbardziej wyrafinowane złośliwe oprogramowanie nie musi skanować sieci w celu pozyskania informacji o hasłach i loginach użytkowników. Może to sprawdzić lokalnie w systemie wykorzystując błędy(nierozwagę) użytkowników podczas logowania do systemu, a także wykorzystując informacje przechowywane w logach uwierzytelnienia Microsoft. Co więcej, w przeciwieństwie do metody rozpoznania obiektów w AD wymienionej powyżej, może utworzyć kompletny i trafny zbiór loginów użytkowników wykorzystywanych do bieżącego logowania z informacją o ich godzinach logowania na lokalnym komputerze (lub zdalnym – pobierając jego IP) i wykorzystać je później do inteligentnego ataku na system. Taki atak może być niezauważony przez większość rozwiązań do bezpieczeństwa, ponieważ odbywa się lokalnie na stacji i wykorzystuje konta, które już wcześniej logowały się do systemu w podobnych przedziałach czasowych jak zazwyczaj odbywa się logowanie użytkownika. Tak więc wszelkie systemy z zaszczepionymi mechanizmami uczenia maszynowego mogą się nie sprawdzić do wykrywania tego typu ataku. Mamy zatem idealną sytuację dla atakującego.


Gdzie szukać i czy mogę znaleźć informacje o loginach i hasłach?


Microsoft oferuje nam za darmo wspaniałą i aktualna bazę loginów w postaci dziennika logów Microsoft (ang. Event Log) 🙂 Zawiera ona kilka ciekawych miejsc, w których możemy się dowiedzieć np. o uruchamianych aplikacjach, ich instalacji, czasem nawet ich wersjach, adresach IP, logowaniach innych kont itp. W przypadku tej ostatniej informacji możemy zebrać np. loginy użytkowników uprzywilejowanych przeglądając log Security, bez potrzeby zaglądania w Active Directory i odpytywania o członkostwo użytkownika w grupach. Wystarczy odpowiednio przygotowane zapytanie/skrypt i malware może dalej wykonywać kroki ataku.

Dostęp do logów Microsoft gwarantuje nam jedno z poniższych uprawnień w systemie:

  • Członkostwo w lokalnej grupie Administratorzy (ang. Administrators). Może być ciężko z pozyskaniem tego uprawnienia, ale jeśli użytkownik jest zalogowany na koncie posiadającym takie uprawnienia można wykonać odpowiednie skrypty i zdobyć właściwe informacje.
  • Członkostwo w lokalnej grupie „Czytelnicy Logów Zdarzeń”(ang. Event Log Readers). Najczęściej nie zaglądamy do zawartości tej grupy i w wielu firmach występuje brak świadomości o tym uprawnieniu.
    Lokalna grupa Event Log Readers
  • Uprawnienie lokalne “Manage auditing and security log”. Bardzo krytyczne uprawnienie, o którym wie wciąż mało osób. Uprawnienie te jest niskopoziomowe i ustawiane w lokalnej polisie GPO. Nie widać go bezpośrednio w systemie, dlatego ważne jest, aby monitorować kto posiada takie uprawnienie, ponieważ jak je zdobędzie może z logami zrobić dosłownie wszystko (włącznie z zdefiniowaniem audytu, czyli jakie logi mają się pojawiać w log).
    Uprawnienie niskopoziomowe do zarządzania logami

Jak szukać loginów i haseł w logach?


Jeśli zdobędziemy wymagane uprawnienia opisane powyżej lub będziemy mieli szczęście pracować na koncie użytkownika z uprawneniami lokalnego administratora możemy przystąpić do fazy rozpoznania informacji w systemie lokalnym. W celu pobrania listy użytkowników logujących się poprawnie na stacji roboczej(dowolnym komputerze Windows) wystarczy, że przefiltrujemy log Security po zdarzeniach o identyfikatorze 4624. Kluczowy jest tutaj numer zdarzenia, ponieważ Microsoft dla każdego zdarzenia posiada osobny identyfikator.

Udane zalogowanie konta Appeal do domeny

W opisie zdarzenia logowania 4624 w polu LogonType zawarta jest interesującą nas wartość – jest to typ logowania, którego wartości oznaczają odpowiednio:

  • 2 – logowanie interaktywne (za pomocą klawiatury i ekranu system)
  • 3 – logowanie sieciowe (np. zdalne połączenie do udziału dyskowego na tym komputerze z innego miejsca w sieci)
  • 4 – logowanie Batch (np. zaplanowane zadanie) – konto uprzywilejowane
  • 5 – logowanie konta w usłudze – konto uprzywilejowane
  • 7 – Odblokowanie pulpitu (np. podczas uspienia lub wygaszacza ekranu)
  • 8 – logowanie sieciowe NetworkCleartext z użyciem podstawowego uwierzytelniania, gdzie hasło można podsłuchać w sieci
  • 9 – przydzielenie nowych uprawnień na innym koncie (przelogowanie na inne konto)
  • 10 – Logowanie przez pulpit zdalny (Terminal Services, Remote Desktop lub Remote Assistance)
  • 11 – buforowane logowanie (np jak computer był poza siecią)

W celu odpytania lokalny system o zdarzenia znajdujące w dzienniku zdarzeń najlepiej użyć jednej z trzech poniższych komend.

  • Komenda: wevtutil
  • Komenda Powershell: Get-EventLog
  • Komenda Powershell: Get-WinEvent

Wszystkie powyższe komendy są dostępne standardowo w systemie Windows.

Przykładowo poniższej zaprezentowaliśmy polecenie Powershell, które zwróci nam z logu Security loginy kont serwisowych z odfiltrowaniem wbudowanych kont systemowych (działa od Windows 2008, nazwy kont mogą być zmieniane w parametrze FilteredAccounts):

PS c:\>$FilteredAccounts = @(‘SYSTEM’,’NETWORK SERVICE’,’LOCAL SERVICE’)
PS c:\>Get-winevent -FilterHashtable @{logname=’security’; id=4624} | where {$_.properties[8].value -eq 5 -and $_.properties[5].value -and $_.properties[5].value -notin $FilteredAccounts} | select {$_.properties[5].value}

Zapytanie zwracające loginy kont serwisowych z logów Security

Widać, że na usługach pracują 4 konta z czego jedno jest kontem Administratora.

Poniższe polecenie zwróci nam z kolei loginy użytkowników logujących się do komputera poprzez zdalny pulpit (działa od Windows 2008):

PS c:\>Get-winevent -FilterHashtable @{logname=’security’; id=4624} | where {$_.properties[8].value -eq 10} | select {$_.properties[5].value}

Zapytanie zwracające loginy użytkowników logujących się poprzez zdalny pulpit

W tym przypadku otrzymaliśmy dwa wpisy konta Administrator.

Oczywiście w niektórych wynikach trzeba pamiętać, aby odfiltrować odpowiednie loginy kont systemowych takich jak np. SYSTEM, LOCAL SYSTEM, LOCAL SERVICE itp.

Dodatkowo możemy wzbogacić nasz wynik wyszukiwania o adres IP, z którego nastąpiło logowanie. Będziemy wtedy mieli pewność, że konkretny użytkownik loguje się z określonej końcówki lub na lokalnym komputerze.

PS c:\> Get-winevent -FilterHashtable @{logname=’security’; id=4624} | where {$_.properties[8].value -eq 10} | select {$_.properties[5].value, $_.properties[18].value}

Wzbogacenie zapytania o adres IP urządzenia

W tym wyniku widzimy, że konto Administrator loguje się zdalnie z IP 192.168.1.4 oraz lokalnie.

Innym źródłem informacji o loginach użytkowników mogą być logowania typu Kerberos. W tym wypadku należałoby ich szukać w logach Security – ID 4768. Zapytania będą analogiczne do powyższych, lecz będą posiadać inne parametry.


Jak wyszukać hasło użytkownika w logach?


Czasami może zaistnieć sytuacja, w której użytkownik omyłkowo zamiast loginu podczas logowanie wpisze hasło użytkownika i wciśnie ENTER. Spotkaliśmy ten problem w wielu organizacjach i naprawdę często się taka pomyłka zdarza nawet bardzo świadomym użytkownikom. Wówczas mechanizm logowania Windows potraktuje hasło użytkownika jako błędny login i zarejestruje próbę logowania na nieznanym loginie (de facto haśle) użytkownika w systemie. W logach Security takie zdarzenie można odszukać pod zdarzeniem o identyfikatorze 4625. Gdy taka sytuacja pojawi się w infrastrukturze, w takim przypadku najlepiej, aby użytkownik zmienił jak najszybciej hasło na nowe.

Poniższy przykład zawiera polecenie listujące hasła wpisane omyłkowo w loginy podczas logowania do systemu (działa od Windows 2008):

PS c:\> Get-winevent -FilterHashtable @{logname=’security’; id=4625} | where {$_.properties[10].value -eq 2} | select {$_.properties[5].value}

Zapytanie listujące błędnie wpisane loginy

Mamy wszystko potrzebne do ataku. Co dalej?


W tym momencie możemy próbować zalogować się zdobytymi hasłami na wybrane loginy z listy, którą zdobyliśmy poniżej używając do tego np. polecenia runas lub narzędzie psexec.exe (z pakietu sysinternals), w którym hasło możemy podać bezpośrednio w linii komend i oprogramować cały mechanizm logowania. Ale jaki właściwy login użytkownika użyć? Tutaj musimy posłużyć się lista wcześniej zdobytych logów i próbować logować się na nie hasłami, które znaleźliśmy w logach

Jeśli natomiast nie udało nam się znaleźć w logach hasła. Nie ma problemu, możemy próbować logować się co jakaś chwilę używając haseł np. z jakiegoś zewnętrznego słownika. Dobrze, aby pamiętać o logowaniach w takich porach, w których loguje się zwykle użytkownik (to też wyczytamy z logów). Ogłupimy wtedy systemy bezpieczeństwa i swobodnie będziemy mogli przejąć konto. W przypadku logowania na lokalne konta w systemie (np. lokalny administrator), kiedy firma nie monitoruje logów lokalnych sprawa jest jeszcze bardziej prostsza.

Poniżej posłużyliśmy się nazwą znalezionego konta Administrator i znalezionym wcześniej hasłem w logach. I jak się okazuje udało nam się uruchomić wiersz poleceń na tym użytkowniku:

Uruchomienie wiersza poleceń jako użytkownik Administrator

Co jeśli zdobędziemy dostęp do logu Security z kontrolera domeny(ów) w Active Directory?


W tym przypadku zdobędziemy kompletną informację o wszystkich aktywnych loginach użytkowników (baza loginów) w Active Directory i z odrobiną szczęścia możemy nawet pozyskać informacje o hasłach użytkowników – jeśli w procesie logowania użytkownik na stacji się pomylił i zamiast loginu wpisał swoje hasło. Skala problemu jak widać jest ogromna i większość firm nie jest świadoma jego skali. Najciekawsze w tym jest to, że nie musimy skanować bazy danych Active Directory, lecz logi Security Microsoft. Różnica pomiędzy wynikiem takiego skanowania jest taka, że w przypadku bazy loginów uzyskanej z logu Security, mamy pewność ciągłej używalności loginów – prawdziwe loginy. W przypadku skanowania AD, loginy mogą być już dawno nieużywane (konta wyłączone) i każda próba użycia takiego nieaktualnego loginu może zostać wyłapana przez system bezpieczeństwa.


Jak powinniśmy się chronić?


Powyższy problem przede wszystkim rozpoczyna się w 90% od końcówek, więc musimy monitorować użycie loginów kont na końcówkach oraz na serwerach (w szczególności kontrolerach domeny), gdzie jak się okazuje może znaleźć się o wiele więcej informacji niż na stacji roboczej. Powinniśmy także wykonywać regularne audyty środowiska, zabezpieczyć, monitorować i kontrolować dostęp do logów, w szczególności użycie kont uprzywilejowanych oraz monitorować polecenia Powershell oraz z linii komend wykonywane na komputerach.

Ciekawym sposobem na monitorowanie tego typu aktywności jest zastosowanie odrębnego mechanizmu logowania i rejestrowania zmian, niezależnego od audytu Microsoft, ponieważ logi aktywności odkładać się będą w innym źródle niż log Microsoft.