ReliaQuest: phishing zadziałał, device trust ograniczył skutki

Na tym jednak dostęp praktycznie się zatrzymał. Według ReliaQuest, firmy zajmującej się cyberbezpieczeństwem, sesja pozwalała tylko na podgląd panelu. Próby wejścia do aplikacji były blokowane, ponieważ połączenie pochodziło z urządzenia, które nie spełniało wymagań kontroli zaufania do urządzenia (device trust). Firma zakończyła sesję, wygasiła hasło i zresetowała metody uwierzytelniania. ReliaQuest podał, że nie doszło do dostępu do aplikacji, systemów ani danych klientów.

Ten przypadek dobrze rozdziela dwie rzeczy, które w dyskusjach o phishingu często wrzuca się do jednego worka. Phishing rzeczywiście zadziałał na człowieka, ale błąd człowieka nie przełożył się automatycznie na pełny dostęp do środowiska. Program edukacji bezpieczeństwa (security awareness) ma zmniejszać prawdopodobieństwo błędu i przyspieszać zgłoszenie. Kontrole tożsamości, urządzenia i sesji mają ograniczać skutki, gdy mimo szkolenia ktoś da się przekonać.

Co wydarzyło się 22 sierpnia

ReliaQuest opublikował własny opis incydentu dzień po ataku. Według firmy napastnik zarejestrował domenę podobną do nazwy organizacji i przygotował fałszywą stronę logowania SSO za siecią CDN (siecią dostarczania treści). Następnie zadzwonił do kilku pracowników.

Nie przedstawiał się jako przypadkowy konsultant. Podszywał się pod prawdziwego pracownika zespołu bezpieczeństwa, podając jego nazwisko. To zwiększa wiarygodność rozmowy: użytkownik nie słyszy tylko „dzwoni dział IT”, lecz nazwę osoby, która rzeczywiście może pracować w firmie.

Jedna z zaatakowanych osób weszła na fałszywą stronę, podała hasło, a później zaakceptowała powiadomienie MFA na telefonie. Napastnik uzyskał dzięki temu aktywną sesję w panelu dostawcy tożsamości.

Vishing, czyli phishing prowadzony przez rozmowę telefoniczną, jest dokładnie tym rodzajem sytuacji, przed którym ostrzegamy w materiale o vishingu w firmie. Rozmowa w czasie rzeczywistym pozwala napastnikowi prowadzić użytkownika przez kolejne kroki, tłumaczyć pojawiające się komunikaty i utrzymywać presję. Sam fakt, że pojawia się prawdziwe powiadomienie MFA, może dodatkowo uwiarygodnić fałszywą historię.

Phishing zadziałał, ale zakres dostępu był ograniczony

W opisie tego incydentu łatwo o dwa przeciwstawne uproszczenia. Pierwsze brzmi: skoro pracownik podał hasło i zatwierdził MFA, firma została całkowicie przejęta. Drugie: skoro nie wykradziono danych klientów, atak się nie udał.

Oba pomijają istotny etap pośrodku.

Napastnik uzyskał ważną sesję użytkownika. To jest realne naruszenie warstwy tożsamości i trzeba je traktować poważnie. Jednocześnie ReliaQuest podał, że sesja była ograniczona do podglądu panelu tożsamości. Próby uruchomienia aplikacji były odrzucane. Firma nie stwierdziła dostępu do swoich aplikacji ani systemów, dostępu do danych klientów, przejęcia kolejnych tożsamości ani utrzymania dalszego dostępu.

Dlaczego MFA nie wystarczyło

W tym scenariuszu hasło nie było jedynym celem. Po jego zdobyciu napastnik potrzebował drugiego elementu. Użytkownik dostał powiadomienie MFA i je zatwierdził.

Nie oznacza to, że MFA jest zbędne. Oznacza, że różne metody MFA mają różną odporność na phishing.

Proste powiadomienie push nadal wymaga decyzji użytkownika. Jeśli ta decyzja jest podejmowana w czasie rozmowy z osobą podszywającą się pod pracownika zespołu bezpieczeństwa, użytkownik może uznać powiadomienie za normalny element procedury. Właśnie dlatego amerykańska agencja CISA rekomenduje przechodzenie na metody odporne na phishing, oparte m.in. na FIDO/WebAuthn — standardach, które wiążą uwierzytelnianie z właściwą usługą za pomocą kryptografii klucza publicznego.

To istotna różnica. Użytkownika można przekonać, aby nacisnął „zatwierdź”. Znacznie trudniej wykorzystać metodę, która kryptograficznie wiąże proces logowania z właściwą usługą i nie pozwala po prostu przekazać drugiego składnika stronie podszywającej się pod prawdziwy serwis.

W organizacji warto więc unikać myślenia: „mamy MFA, temat zamknięty”. Pytanie powinno brzmieć: jakiego rodzaju MFA używamy i co stanie się, jeśli użytkownik zatwierdzi niepożądane logowanie?

Device trust dodał drugi warunek dostępu

Najciekawszy element tego incydentu pojawił się po skutecznym uwierzytelnieniu.

Napastnik miał sesję użytkownika, ale nie korzystał z firmowego, zaufanego urządzenia. ReliaQuest opisuje, że kontrola device trust blokowała dostęp do aplikacji i systemów z urządzeń spoza środowiska organizacji.

W uproszczeniu można to przedstawić jako dwa osobne pytania:

1. Czy system rozpoznał tożsamość użytkownika? Po podaniu hasła i zaakceptowaniu MFA odpowiedź przez chwilę brzmiała „tak”.
2. Czy ta sesja może wejść do konkretnej aplikacji z tego urządzenia? Tutaj odpowiedź brzmiała „nie”.

To rozdzielenie uwierzytelnienia od decyzji o dostępie jest kluczowe dla ograniczania skutków przejęcia konta. Podobną zasadę można wdrażać w różnych platformach tożsamości. Przykładowo Microsoft Entra Conditional Access może wymagać, aby urządzenie było oznaczone jako zgodne z polityką organizacji, zanim dostęp do wskazanych zasobów zostanie przyznany.

Nie chodzi o jeden konkretny produkt. Chodzi o zasadę: prawidłowe hasło i prawidłowy drugi składnik nie muszą automatycznie oznaczać dostępu z dowolnego urządzenia i z dowolnego kontekstu.

Szkolenie nie powinno być jedyną barierą

Incydent jest szczególnie interesujący, bo dotknął firmę zajmującą się cyberbezpieczeństwem. Można byłoby potraktować to jako argument, że szkolenia nie działają. Taki wniosek byłby zbyt prosty.

Celem edukacji bezpieczeństwa nie jest stworzenie organizacji, w której przez wiele lat ani jedna osoba nigdy nie popełni błędu. Przy odpowiedniej liczbie prób, dobrym rozpoznaniu celu i wiarygodnej rozmowie część ataków może przejść przez warstwę ludzką.

Dojrzały model zakłada więc kilka warstw:

• użytkownik potrafi rozpoznać nietypową prośbę i przerwać rozmowę;
• organizacja ma prosty kanał do niezależnego potwierdzenia tożsamości pracownika IT lub zespołu bezpieczeństwa;
• MFA jest możliwie odporne na phishing;
• dostęp do aplikacji uwzględnia stan i zaufanie do urządzenia;
• nietypowe sesje i próby wejścia do wielu aplikacji są wykrywane;
• zespół może szybko unieważnić sesję, hasło i metody uwierzytelniania;
• po incydencie sprawdzany jest zakres dostępu, a nie tylko fakt, że ktoś podał hasło.

To praktyczne znaczenie obrony warstwowej (defense in depth). Warstwy nie są od siebie niezależnymi ozdobami. Każda ma przejąć część ryzyka, gdy poprzednia zawiedzie.

Co w tym przypadku zrobił człowiek, a co technologia

W edukacji bezpieczeństwa warto bardzo precyzyjnie rozdzielić momenty decyzyjne.

Człowiek:

• odebrał telefon;
• zaufał osobie podszywającej się pod pracownika zespołu bezpieczeństwa;
• wszedł na wskazaną stronę;
• podał hasło;
• zatwierdził MFA.

Technologia i procesy organizacji:

• nie potraktowały samej sesji w panelu tożsamości jako nieograniczonego prawa do aplikacji;
• wymagały zaufanego kontekstu urządzenia;
• blokowały kolejne próby dostępu;
• pozwoliły zakończyć sesję i zresetować elementy uwierzytelnienia;
• umożliwiły sprawdzenie, czy napastnik dotarł dalej.

Takie rozdzielenie jest przydatne również po własnym incydencie. Zamiast kończyć analizę stwierdzeniem „użytkownik kliknął” albo „użytkownik podał hasło”, warto sprawdzić, które kolejne bariery zadziałały, a których zabrakło.

Co firmy mogą zmienić po tym incydencie

1. Ustalić procedurę dla telefonów od IT i zespołu bezpieczeństwa

Pracownik powinien wiedzieć, jak niezależnie potwierdzić, że dzwoni właściwa osoba. Numer wyświetlany na telefonie ani znajomość nazwiska kolegi nie są wystarczającym dowodem.

Jeżeli rozmówca prowadzi użytkownika do logowania, resetu hasła, MFA lub zmiany ustawień bezpieczeństwa, dobrym nawykiem jest przerwanie rozmowy i powrót przez znany kanał: firmowy komunikator, numer z katalogu albo zgłoszenie do wsparcia IT.

2. Ograniczać zależność od prostego push MFA

Tam, gdzie jest to możliwe, warto przechodzić na MFA odporne na phishing. Szczególną uwagę należy zwrócić na konta administratorów, pracowników wsparcia IT, zespołu bezpieczeństwa, działu finansowego, działu kadr oraz osób zarządzających.

3. Wymagać odpowiedniego kontekstu urządzenia

Dostęp do krytycznych aplikacji może zależeć nie tylko od tożsamości, ale również od tego, czy urządzenie jest zarządzane i spełnia politykę organizacji. Nie każda firma będzie mogła zastosować ten warunek wszędzie, ale dla najważniejszych usług jest to kontrola warta oceny.

4. Szybko unieważniać aktywne sesje

Po podejrzeniu wyłudzenia hasła sama zmiana hasła nie zawsze zamyka problem. Trzeba ocenić aktywne sesje, tokeny, metody MFA, nowe urządzenia i próby dostępu do aplikacji.

5. Monitorować domeny podobne do własnej marki

ReliaQuest wskazał wykorzystanie domeny podobnej do nazwy firmy. Organizacje mogą monitorować nowe rejestracje przypominające ich nazwę, szczególnie gdy są łączone z kopiami SSO lub fałszywym wsparciem IT.

Jak przełożyć ten przypadek na ćwiczenie bezpieczeństwa

Ten scenariusz nadaje się do szkolenia lepiej niż kolejny mail o paczce albo fakturze, bo sprawdza kilka decyzji naraz.

Bezpieczna symulacja może wyglądać następująco:

1. pracownik otrzymuje kontrolowany telefon lub wiadomość proszącą o kontakt z „zespołem bezpieczeństwa”;
2. rozmówca przedstawia wiarygodny pretekst dotyczący konta;
3. użytkownik trafia na kontrolowaną stronę szkoleniową imitującą moment przed logowaniem;
4. pojawia się prośba o wykonanie czynności związanej z MFA, ale bez używania prawdziwego konta i prawdziwych danych;
5. mierzone jest nie tylko wejście na stronę, lecz także przerwanie procesu, niezależna weryfikacja i zgłoszenie.

W testach phishingowych dla firm taki scenariusz ma sens szczególnie dla zespołów IT, wsparcia technicznego, administratorów, zespołów bezpieczeństwa i osób mających dostęp do wielu systemów. Nie chodzi o udowodnienie, że ktoś „dał się złapać”. Chodzi o sprawdzenie, w którym miejscu łańcucha organizacja potrafi go przerwać.

ReliaQuest pokazuje, jak projektować odporność na błąd

Najbardziej użyteczne w tym incydencie jest to, że można wskazać zarówno udaną część ataku, jak i skuteczne bariery po niej.

Napastnik przekonał człowieka. Zdobył hasło. Użytkownik zatwierdził MFA. Powstała aktywna sesja. Mimo tego dalszy dostęp do aplikacji został zablokowany, a sesja została szybko zakończona.

To model, do którego warto dążyć: szkolić ludzi tak, aby popełniali mniej błędów i szybciej je zgłaszali, ale jednocześnie budować środowisko, w którym pojedyncza pomyłka nie otwiera całej organizacji.

Jeżeli program bezpieczeństwa opiera się wyłącznie na przekonaniu, że „pracownik nie kliknie i nie zatwierdzi”, to pojedynczy skuteczny vishing może wystarczyć. Jeżeli edukacja bezpieczeństwa jest jedną z kilku warstw, organizacja ma kolejne szanse na zatrzymanie ataku.