Wykrywanie Pass-the-Hash za pomocą honeypotów

Dlatego właśnie zaczęto stosować inny, sprytniejszy i bardziej przyjazny dla pracowników cyberbezpieczeństwa sposób. Wprowadzone przez Mark’a Baggett’a honeypoty przeznaczone specjalnie do wykrywania próby Pass-the-Hash. Jest to nic innego jak „przynęta” na hakera pozwalająca wykryć próbę tego rodzaju ataku. Polega na wprowadzeniu przygotowanych, fałszywych hashy (honeyhash) do pamięci lokalnej komputera (dokładnie do pamięci procesu LSASS) i czekanie, aż atakujący pozyska je i spróbuje użyć. Przy próbie użycia fałszywego hasha poświadczenia zostaną odrzucone, a zdarzenie to wygeneruje alarm.

Honeyhash można w prosty sposób ustawić za pomocą komendy „runas” z przełącznikiem „/netonly”. Na screenie poniżej widzimy wprowadzenie do pamięci nieistniejącego konta użytkownika o nazwie admin392. NTLM hash zostanie wygenerowany dla tego konta automatycznie po wprowadzeniu losowego hasła.

Po zatwiedzeniu komendy i wprowadzeniu dowolnego hasła otwiera się nowy wiersz poleceń, ale już w kontekśćie konta admin392. Dopóki okno to zostanie otwarte, czyli proces pozostanie uruchomiony, to w pamięci lokalnej widoczny jest hash oraz nazwa domeny i usera.

Tak więc, nasz honeyhash został przygotowany poprawnie, co widać na poniższym obrazku, gdzie cyberprzestępca używa mimikatza do wyświetlenia wszystkich informacji o kontach na danej maszynie.

Co więcej, atakujący jest w stanie wykonać komendę Pass-the-Hash, jednak po próbie użycia skradzionych poświadczeń dostanie informację, że hasło sieciowe nie jest poprawne. Aby uniknąć otwartego okna z procesem cmd.exe moża użyć skryptu Powershella o nazwie New-HonetHash napisanego przez Matthew’a Graeber’a. Okno procesu jest wtedy ukrywane i niewidoczne z poziomu zwykłego usera.

Z samego faktu nieudanej próby uwierzytelnienia przez atakującego jest niewiele korzyści. Dopiero wykrycie przez zespół bezpieczeństwa zdarzenia oraz inwestygacja tego zdarzenia pozwala wykryć luki w zabezpieczeniach, a może nawet znaleźć sprawce. Zdarzenie nieudanego zalogowania się z pewnością odłoży się w event logu jako event id 4625, czyli nieudana autentykacja. Jednak oprócz nazwy naszego fałszywego konta oraz czasu zdarzenia nie otrzymamy więcej informacji. Z perspektywy dalszego dochodzenia dobrze by było znać takie informacje jak:

• adres lub nazwa stacji z której skradziono honeyhash
• konto które zostało przejęte i wykorzystane do skradzenia honeyhash
• moment kiedy honeyhash został skradziony (nie użyty!)
• w jaki sposób został skradziony (np. mimikatz)

Narzędzie umożliwiające szczegółowe monitorowanie procesu LSASS, czyli pozyskanie wyżej wymienionych informacji to na przykład Sysmon. Dodaje to nowe zdarzenia do event loga zapewniając takie informacje jak nazwa konta, nazwa użytego procesu oraz czas kiedy zajrzano do pamięci procesu LSASS. Jednym z wyzwań dla organizacji z pewnością może być konfiguracja dużej ilości honeypotów na stacjach roboczych i zarządzanie nimi. Istnieją już skrypty (SCCM, remote PowerShell) pozwalające zdalnie generować losowe nazwy i hashe na stacjach roboczych i aplikować je jako honeypoty dla ataków Pass-the-Hash.