Password spraying i credential stuffing objawiają się jako stos nieudanych logowań, ale kształt tego stosu jest inny i inne jest remedium. Jeśli Twoim jedynym alertem jest "pięć niepowodzeń na jednym koncie", przeoczysz oba ataki.
Trzy ataki, trzy wzorce
OWASP Credential Stuffing Prevention Cheat Sheet rozróżnia je w następujący sposób:
| Atak | Co robi atakujący |
|---|---|
| Brute force | Testuje wiele haseł ze słownika na jednym koncie |
| Credential stuffing | Testuje pary login/hasło pochodzące z wycieku z innego serwisu |
| Password spraying | Testuje jedno słabe hasło na dużej liczbie różnych kont |
OWASP zaznacza, że w wielu przypadkach obrona jest taka sama i działa też przeciwko brute force.
Czego szukać w logach
Strategia detekcji MITRE dla password spraying to duża liczba nieudanych uwierzytelnień z użyciem jednego hasła lub niewielkiego zestawu haseł na wielu kontach użytkowników w danym oknie czasowym. W przypadku credential stuffing są to liczne niepowodzenia z różnymi parami login/hasło z jednego adresu IP lub jednej sesji w krótkim oknie czasowym.
Atakujący dostosowują się do oczywistych zabezpieczeń:
- Spraying z ograniczoną częstotliwością. MITRE opisuje narzędzia APT28, które wykonywały mniej więcej cztery próby na godzinę na każde atakowane konto, przez dni lub tygodnie. Aktywność Quad7 polegała na jednej próbie logowania w ciągu 24 godzin, co omijało progi wykrywania brute force. Liczniki per konto tego nie wychwycą.
- Spraying rozproszony. MITRE zauważa również, że APT28 użyło klastra Kubernetes do rozproszonych, szeroko zakrojonych sprayów. Sam licznik per źródłowy IP to przeoczy, bo żaden pojedynczy adres nie generuje wielu niepowodzeń. Licz więc także unikalne konta z nieudanymi logowaniami w oknie czasowym, we wszystkich źródłach łącznie, a te same dane rozbijaj dodatkowo według ASN i user agenta.
- Cichsze protokoły. Atakujący mogą używać prób przez LDAP i Kerberos, które rzadziej wywołują zdarzenia o wysokiej widoczności, takie jak "logon failure" w Windows z identyfikatorem 4625, najczęściej generowane przez nieudane połączenia SMB. Zbieraj błędy LDAP i Kerberos, a nie tylko 4625.
Atakujący zwykle celują w usługi zarządzania na typowych portach: SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) oraz webowe interfejsy zarządzania na portach 80 i 443. Atakują też SSO, aplikacje chmurowe z uwierzytelnianiem federacyjnym i wystawioną na zewnątrz pocztę, taką jak Office 365 i OWA.
Microsoft 365: wykorzystaj smart lockout poprawnie
Microsoft Entra smart lockout jest zawsze włączony. Domyślnie blokuje konto po 10 nieudanych próbach w tenantach Azure Public lub po trzech w tenantach Azure US Government. Pierwsza blokada trwa jedną minutę, a przy kolejnych niepowodzeniach się wydłuża. Microsoft nie ujawnia tempa tego wzrostu.
- Śledzi hashe ostatnich trzech błędnych haseł, więc powtarzanie tego samego błędnego hasła nie zwiększa licznika. Dzięki temu powtarzająca się literówka użytkownika nie zablokuje mu konta. Przeciwko sprayowi, gdzie każde konto widzi dane hasło tylko raz, daje to niewiele.
- Znane i nieznane lokalizacje mają osobne liczniki blokad, więc atakujący z nowej lokalizacji może zostać zablokowany, podczas gdy prawdziwy użytkownik pracuje dalej.
- Własne wartości wymagają Microsoft Entra ID P1 lub wyższego. Zaloguj się do Microsoft Entra admin center jako co najmniej Authentication Policy Administrator i przejdź do Entra ID > Authentication methods > Password protection. Tam ustawisz Lockout threshold oraz Lockout duration w sekundach (domyślnie 60).
- Entra domyślnie blokuje też niektóre logowania na podstawie sygnałów dotyczących ruchu IP i zachowania, i zwraca
AADSTS50053 - IdsLocked, niezależnie od tego, czy hasło było poprawne. Traktuj konta, na których pojawia się ten kod, jako atakowane, ale nie odczytuj go jako dowodu, że hasło było błędne lub poprawne.
Smart lockout nie gwarantuje, że prawdziwy użytkownik nigdy nie zostanie zablokowany. MITRE dodaje drugą stronę medalu: zbyt restrykcyjna polityka może doprowadzić do denial of service, w którym zablokowane zostają wszystkie konta objęte atakiem.
Środowiska hybrydowe
Przy pass-through authentication próg w Entra musi być niższy niż próg w lokalnym AD DS, a próg AD DS powinien być co najmniej dwa lub trzy razy wyższy. Czas blokady w Entra musi być dłuższy niż w AD DS. Przykład Microsoftu to próg 10 wobec 20 oraz 120 sekund wobec 60. Czas blokady w Entra podaje się w sekundach, a w AD DS w minutach, więc sprawdź jednostki.
Śledzenie hashy nie jest dostępne przy pass-through authentication. Aby odczytać wartości z AD DS, otwórz Group Policy Management, edytuj politykę zawierającą ustawienia blokady i przejdź do Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
Własna strona logowania i wystawione usługi
Lockout to mechanizm działający per konto. Naszym zdaniem run credential stuffing, który próbuje każde konto raz lub dwa razy, często w ogóle nie osiągnie progu, więc nie traktuj blokady jako głównej obrony. MITRE ostrzega, że stuffing może powodować liczne niepowodzenia i blokady, ale zależy to od Twojej polityki. Jego zalecenia dla obu technik obejmują dodatkowo:
- Multi-factor authentication, włączone tam, gdzie to możliwe, w usługach wystawionych na zewnątrz.
- Polityki conditional access blokujące logowania z urządzeń niezgodnych z wymaganiami lub spoza zdefiniowanych zakresów IP organizacji.
- Blokowanie ryzykownych żądań, np. pochodzących z usług anonimizujących lub proxy.
- Polityki haseł oparte na wytycznych NIST.
- W przypadku stuffingu: proaktywny reset kont, o których wiadomo, że występują w wyciekach danych uwierzytelniających, od razu albo po wykryciu prób brute force.
Dla własnej aplikacji OWASP Authentication Cheat Sheet zawiera sekcje o ochronie przed atakami automatycznymi, o CAPTCHA oraz o logowaniu i monitorowaniu.
Od czego zacząć
- Wypisz każde logowanie dostępne z internetu: Microsoft 365 lub OWA, VPN, RDP, SSH, SSO i własne formularze webowe. Zamknij każdy port zarządzania, który nie musi być otwarty.
- Sprawdź próg i czas trwania smart lockout w Entra ID > Authentication methods > Password protection. Przy pass-through authentication porównaj je z polityką blokady w AD DS według reguł opisanych powyżej.
- Zbuduj dwa zapytania na logach logowań. Pierwsze liczy unikalne konta z nieudanymi logowaniami na źródłowy IP na godzinę. Drugie ignoruje źródło: liczy unikalne konta z niepowodzeniami w oknie czasowym łącznie, a następnie dzieli wynik według ASN i user agenta. Ustaw alert na oba, a
AADSTS50053zachowaj jako osobny widok. - Włącz MFA dla każdej usługi wystawionej na zewnątrz, a potem dodaj reguły conditional access dla urządzeń niezarządzanych i usług anonimizujących.
- Porównaj konta pracowników ze znanymi wyciekami, na przykład naszym sprawdzaniem haseł w wyciekach, i zresetuj te, które się pokrywają. Jeśli brakuje Ci ludzi do codziennego przeglądania logów, zarządzany monitoring wypełni tę lukę.
