Pracownicy to najczęstszy i jednocześnie najprostszy/najłatwiejszy wektor ataku na naszą firmę. W celu ich ochrony często stosujemy multi-factor authentication (MFA) jako dodatkowe zabezpieczenie. Utrudnia to życie zarówno osobom o złych zamiarach, jak i samym użytkownikom, którzy narzekają na uciążliwe alerty i kody SMS. Skupmy się jednak na potencjalnych atakujących. Aby dostać się do naszych systemów, nie wystarczy już wysłać phishingowego e-maila, aby poznać login i hasło pracownika. Dodatkowo konieczne jest autoryzowanie nowego logowania, co wymaga interakcji naszego pracownika. Możesz teraz pomyśleć, że nikt nie potwierdzi takiego nietypowego logowania… życie potrafi jednak nas zaskoczyć 🙂
Wpadka Ubera
Dawno temu, bo w 2022 firma Uber (to ci od taksówek) miała włam. Atakujący kupił poświadczenia do konta jednego z kontraktorów firmy przez dark web. Jednak same dane nie były wystarczające, ponieważ konto było zabezpieczone przez MFA, a urządzenie cyberzbója nie zostało dodane do zaufanych. Co więc zrobił nasz haker? Próbował do skutku, aż osiągnął swój cel.
Przez godzinę pracownik był bombardowany powiadomieniami, aż w końcu uległ i potwierdził jedno z nich. To było wystarczające, by wszystko posypało się jak domek z kart.
Ciekawostka
Atakujący, który dokonał włamania do Ubera, miał zaledwie 18 lat. Jak widać, nie trzeba mieć doktoratu z cybersecurity, aby włamywać się do dużych firm 🙂
Po więcej szczegółów odsyłam do strony Sekuraka.
Co robić? Jak żyć?
Historia Ubera uczy nas, że warto regularnie szkolić i edukować naszych pracowników na tematy cyberzagrożeń. Przypadkowe lub odruchowe potwierdzenie komunikatu MFA może mieć opłakane konsekwencje, dlatego zbyt wiele szkoleń z zakresu bezpieczeństwa IT. Warto również zastanowić się, czy nasz dostawca tożsamości (IdP) nie udostępnia jakiegoś mechanizmu do zgłaszania podejrzanych prób logowania.
Zgłaszanie fałszywych prób MFA w Microsoft 365
W ramach Entra ID mamy dostępne dwa mechanizmy zgłaszania podejrzanych prób logowania - Fraud Alert oraz Report Suspicious Activity.
Czym jest Fraud Alert?
MFA Fraud alert jak nazwa wskazuje służy do zgłaszania przez użytkowników podejrzanych próśb potwierdzenia logowania (w aplikacji Microsoft Authenticator lub od fotowoltaiki Microsoftu - automat telefoniczny), które nie pochodzą od nich, a od złodzieja 🙂
Po takim zgłoszeniu konto pracownika może zostać automatycznie zablokowane do wyjaśnienia przez administratora. Niestety nie ma tu żadnej automatyzacji i wszystko wykonywane jest ręcznie.
Czym jest opcja Report Suspicious Activity?
To ulepszona opcja MFA Fraud Alert, która integruje się z Entra ID Protection. W skrócie Fraud Alert zazwyczaj blokuje konta pracowników do wyjaśnienia przez IT. Jeśli korzystamy z Entra ID P2 i Identity Protection, nasze konto po zgłoszeniu ciągle ma możliwość odblokowania przez użytkownika, po wykonaniu określonych działań naprawczych np. zmiany hasła na nowe.
Więcej o Entra ID Protection przeczytasz w tym wpisie.
Co wybrać?
Wybór jest dość prosty:
- Jeśli posiadasz Entra ID P2, skorzystaj z Report Suspicious Activity i wyłącz Fraud Alert.
- Jeśli posiadasz Entra ID P1, skorzystaj z Fraud Alert.
- Jeśli nie posiadasz ani Entra ID P1, ani Entra ID P2 to nie konfiguruj żadnego z ustawień, bo nie masz na nie licencji 🙂
Ważne: Możesz korzystać z obu tych ustawień jednocześnie. Choć osobiście polecam zdecydowac się na jedno z nich.
Konfiguracja
W tym rozdziale znajdziesz opis konfiguracji opcji Fraud Alert oraz Report Suspicious Activity.
Jak włączyć MFA Fraud alert?
Przechodzimy do: Entra admin center -> Protection -> Multifactor authentication -> Fraud alert
Następnie ustaw opcję Allow users to submit fraud alerts na On.
Gotowe! Opcja MFA Fraud Alert jest teraz aktywna! Zanim prześlesz swoje pierwsze zgłoszenie, warto również skonfigurować alerty w zakładce Notifications.
Jak włączyć Report Suspicious Activity?
Przechodzimy do: Entra admin center -> Protection -> Authentication Methods -> Settings
Następnie w sekcji Report suspicious activity dla opcji State ustaw wartość Enabled i zapisz zmiany, klikając przycisk Save. Gotowe!
Testy
W tym rozdziale znajdziesz testy ustawień Fraud Alert oraz Report Suspicious Activity.
Fraud alert
Logujemy się do dowolnej usługi Microsoft 365 / Entra ID i czekamy na prośbę o potwierdzenie MFA. Gdy zobaczymy nowe powiadomienie, klikamy opcję NIE, TO NIE JA, która otworzy nam możliwość zgłoszenia fałszywej próby logowania - klikamy ZGŁOŚ.
Zgłoszenie wylądowało u administratora, a konto zostało zablokowa… zabezpieczone!
Co się dzieje dalej z takim zgłoszeniem?
Administrator otrzymuje powiadomienie e-mail z informacją o nowym zgłoszeniu.
Jeśli ma akurat chwilę wolnego czasu, może przejść do Entra admin center i odblokować nasze konto w zakładce Block/unblock users. Oczywiście, wcześniej musi przeanalizować, co się wydarzyło, zaparzyć kawę i zgłosić incydent, więc może to trochę potrwać :beaming_face_with_smiling_eyes:
Nie brzmi zbyt dobrze? Zawsze możesz rozważyć dopłatę do Entra ID P2 i skonfigurować Identity Protection wraz z opcją Report Suspicious Activity!
Report Suspicious Activity
Nowa, ulepszona wersja Fraud Alert, czyli Report Suspicious Activity, nie różni się zbytnio w kontekście zgłaszania fałszywych prób MFA.
Ponownie logujemy się do dowolnej usługi Microsoft 365 / Entra ID i czekamy na prośbę o potwierdzenie MFA. Gdy zobaczymy nowe powiadomienie, klikamy opcję NIE, TO NIE JA, która otworzy nam możliwość zgłoszenia fałszywej próby logowania - klikamy ZGŁOŚ.
Zwróć uwagę na treść komunikatu. Wcześniej użytkownik widział informację, że takie zgłoszenie może zablokować dostęp do konta, ale teraz niczego takiego tu nie ma. Dlaczego? Report Suspicious Activity domyślnie nie blokuje kont użytkowników. Blokady realizowane są przez Conditional Access i Identity Protection. Jeśli nie skonfigurujemy tych zależności, to z perspektywy użytkownika nic specjalnego się nie wydarzy, a konto nie zostanie zablokowane.
Co się dzieje dalej z takim zgłoszeniem?
Zgłoszenie odnotowywane jest w Entra ID, gdzie ryzyko konta użytkownika zostaje podwyższone do poziomu High. Jeśli mamy wdrożone polityki Risk-Based Conditional Access, pracownik podczas kolejnej próby logowania, tuż po potwierdzeniu MFA, zostanie poproszony o zmianę hasła do konta.
Psst: Więcej o tym, jak skonfigurować Self-service Password Reset (SSPR) tutaj.
Co widzi administrator?
Podobnie jak w przypadku Fraud Alert, administrator otrzyma e-mail od Identity Protection z informacją o wykryciu nowego ryzykownego użytkownika.
Po kliknięciu w odnośnik w e-mailu, w zakładce Risk history pracownika, który zgłosił podejrzaną próbę MFA, możemy zobaczyć samo zgłoszenie oraz inne zdarzenia, które wykryło Identity Protection i mogą być z nim powiązane.
Oczywiście po zresetowaniu hasła zdarzenie nadal będzie widoczne, ale otrzymamy nowy wpis informujący o tym, że ryzyko zostało zażegnane poprzez reset hasła.
Podsumowanie
Teraz już wiesz, jak zapobiegać atakom typu Multi-Factor Authentication Request Generation w Entra ID. Pamiętaj, że po wdrożeniu środków technicznych zawsze należy zaktualizować dokumentację oraz materiały szkoleniowe dla pracowników 🙂
Do następnego razu.