Zmiana hasła w Active Directory to za mało. Jak skutecznie usunąć intruza z sieci
Samo zresetowanie skompromitowanego hasła w Active Directory nie gwarantuje usunięcia atakującego. Cached credentials, bilety Kerberos i zmodyfikowane uprawnienia mogą pozwolić mu na dalsze działanie. Wyjaśniamy, jakie kroki podjąć, by faktycznie odciąć dostęp intruzowi.
Resetowanie hasła to pierwsza, intuicyjna reakcja na podejrzenie włamania. Jednak w środowiskach Active Directory (AD) i hybrydowych z Entra ID sama zmiana hasła nie odcina atakującemu dostępu. Jak wyjaśniają eksperci Specops Software w analizie opublikowanej na łamach BleepingComputer, „password resets are often the first response to a suspected compromise. It makes sense; resetting credentials is a quick way to cut off an attacker’s most obvious path back in. However, that doesn’t always completely solve the issue.” Dla administratorów i architektów bezpieczeństwa oznacza konieczność szerszego spojrzenia na proces reagowania.
Luki po resecie – trzy stany przejściowe
Po zmianie hasła w AD mogą wystąpić trzy sytuacje. Po pierwsze, jeśli użytkownik zalogował się już z nowym hasłem na danym urządzeniu, pamięć podręczna aktualizuje się i stary hash przestaje działać. Po drugie, jeśli urządzenie nie połączyło się z domeną od czasu resetu, wciąż przechowuje stary hash – atakujący może go wykorzystać np. w ataku pass-the-hash. Po trzecie, w środowiskach hybrydowych nowe hasło musi zsynchronizować się z Entra ID, co trwa od kilku do kilkunastu minut. W tym oknie stare hasło może być nadal akceptowane.
Bilety Kerberos i uprawnienia – ukryte furtki
AD opiera się na protokole Kerberos, który przyznaje bilety dostępu na określony czas. Jeśli atakujący zdobył ważny bilet przed resetem hasła, może go używać aż do wygaśnięcia – chyba że sesje zostaną jawnie zakończone. Co gorsza, w przypadku kompromitacji konta KRBTGT możliwe jest wygenerowanie Golden Ticket – fałszywego biletu dla dowolnego użytkownika. Zmiana hasła użytkownika nie unieważnia takiego biletu. Podobnie działa Silver Ticket dla konkretnych usług. Równie groźne są zmiany w Access Control Lists (ACL). Atakujący, który dodał sobie uprawnienia do resetowania haseł innych kont lub zmodyfikował obiekt AdminSDHolder, może odzyskać dostęp nawet po resecie oryginalnego hasła.
„Resetting user passwords won’t invalidate forged tickets, and access can continue until the underlying issue is addressed.” – Specops Software
Jak skutecznie usunąć intruza?
Eksperci zalecają zestaw działań wykraczających poza samą zmianę haseł. Najpierw należy zakończyć wszystkie aktywne sesje – wymusić wylogowanie lub restart systemów, a także wyczyścić bilety Kerberos. Przy poważniejszej kompromitacji konieczne jest dwukrotne zresetowanie konta KRBTGT, co unieważni wszystkie fałszywe bilety. Kolejno trzeba zadbać o higienę kont serwisowych – ich hasła są rzadko zmieniane, a często mają podwyższone uprawnienia. Wreszcie niezbędny jest audyt zmian w katalogu: przegląd członkostw w grupach, delegowanych praw i ACL. Jak podkreślają autorzy analizy, „for serious breaches, there isn’t a single step that guarantees eviction. It’s a combination of cutting off sessions, rotating the right credentials, and verifying that no hidden access paths remain.”
Więcej szczegółów na temat mechanizmów i praktycznych zaleceń można znaleźć w oryginalnym artykule Specops Software na BleepingComputer. Dla administratorów w Polsce ważne przypomnienie, że procedury reagowania na incydenty powinny uwzględniać nie tylko reset haseł, ale też pełne czyszczenie śladów dostępu w AD.
