TrustSink: gdy zewnętrzny dostawca MFA staje się pułapką na hasło

W demonstracji dla Microsoft Entra napastnik rejestruje złośliwego dostawcę External MFA. Użytkownik rozpoczyna logowanie na prawdziwej stronie Microsoft, podaje pierwszy składnik uwierzytelnienia, a następnie zostaje skierowany do zewnętrznego dostawcy. Tam może zobaczyć fałszywe pole proszące ponownie o hasło. Hasło trafia do napastnika, mimo że początek procesu był legalny.

To nie jest opis masowej kampanii ani dowód, że każde zewnętrzne MFA jest niebezpieczne. TrustSink wymaga wcześniejszego przejęcia uprzywilejowanego dostępu do konfiguracji uwierzytelniania. Dla firm wniosek jest jednak praktyczny: kontrola MFA musi obejmować nie tylko użytkowników i ich metody logowania, ale też dostawców, aplikacje, zgody administracyjne i zmiany w polityce uwierzytelniania.

Czym jest TrustSink

Nazwa TrustSink została nadana przez Varonis Threat Labs technice, w której zaufanie do legalnego procesu logowania zostaje wykorzystane do skierowania użytkownika do złośliwego zewnętrznego dostawcy MFA. Badacze zademonstrowali ten scenariusz w Microsoft Entra, ale wskazują, że problem wynika z modelu zewnętrznego uwierzytelniania, a nie z wyglądu pojedynczej strony phishingowej.

External MFA, czyli zewnętrzna metoda uwierzytelniania wieloskładnikowego, pozwala organizacji korzystać z dostawcy innego niż Microsoft do wykonania dodatkowego składnika logowania. Microsoft Entra nadal ocenia polityki i decyduje o dostępie, ale w odpowiednim momencie przekierowuje użytkownika do skonfigurowanego dostawcy.

Integracja opiera się na OpenID Connect, w skrócie OIDC. Jest to standard używany do wymiany informacji o uwierzytelnieniu między systemami. Administrator konfiguruje między innymi identyfikatory aplikacji i adres discovery, z którego Entra pobiera informacje potrzebne do komunikacji z dostawcą.

W prawidłowym wdrożeniu zewnętrzny dostawca jest częścią architektury bezpieczeństwa organizacji. W TrustSink napastnik próbuje sprawić, aby tę rolę pełniła infrastruktura pod jego kontrolą.

Jak działa External MFA w Microsoft Entra

Microsoft opisuje External MFA jako metodę, która może spełnić wymaganie dodatkowego składnika podczas logowania do konta służbowego lub szkolnego. Po wykonaniu pierwszego składnika Microsoft Entra może skierować użytkownika do zewnętrznego dostawcy. Po prawidłowym zakończeniu tego etapu dostawca zwraca podpisaną informację, którą Entra weryfikuje przed dalszym dostępem.

Taki model oznacza, że użytkownik może przechodzić między domeną Microsoft a domeną dostawcy i nadal uczestniczyć w prawidłowym procesie logowania. Sam fakt przekierowania poza Microsoft nie musi więc oznaczać phishingu.

Jednocześnie dostawca External MFA jest elementem o wysokim poziomie zaufania. Microsoft wymaga odpowiednich uprawnień do jego konfiguracji, a udzielenie zgody administracyjnej dla aplikacji dostawcy wymaga roli o wysokich uprawnieniach. To ważne ograniczenie scenariusza TrustSink: napastnik nie może po prostu wysłać użytkownikowi linku i samodzielnie dodać złośliwego dostawcy do cudzego środowiska.

Jak działa TrustSink krok po kroku

Według Varonis scenariusz zaczyna się przed kontaktem z użytkownikiem. Napastnik musi najpierw uzyskać uprzywilejowany dostęp, który pozwala zmienić konfigurację metod uwierzytelniania i podłączyć kontrolowanego przez siebie dostawcę.

Następnie złośliwy dostawca zostaje włączony dla wybranych użytkowników lub grup. Gdy użytkownik loguje się do zasobu objętego wymaganiem MFA, początek procesu może wyglądać całkowicie normalnie. Użytkownik znajduje się na stronie Microsoft i wykonuje pierwszy składnik uwierzytelnienia.

Kolejny etap odbywa się u zewnętrznego dostawcy. To właśnie tam TrustSink wprowadza fałszywy element. Kontrolowana przez napastnika strona może wyświetlić komunikat sugerujący, że do kontynuowania potrzebne jest ponowne podanie hasła.

Jeżeli użytkownik wpisze hasło, trafia ono do infrastruktury napastnika. Z perspektywy użytkownika podejrzany formularz nie pojawił się po kliknięciu przypadkowego linku w wiadomości, lecz wewnątrz procesu rozpoczętego na prawdziwej stronie Microsoft.

Varonis zwraca też uwagę na możliwość utrzymania ryzyka po samej zmianie hasła. Jeżeli złośliwy dostawca nadal pozostaje skonfigurowany, kolejne logowanie może ponownie skierować użytkownika do tej samej pułapki. Usunięcie skutków wymaga więc naprawy konfiguracji, a nie tylko resetu danych logowania.

Dlaczego prawdziwa strona Microsoft nie wystarcza jako sygnał bezpieczeństwa

W podstawowej edukacji antyphishingowej często uczymy sprawdzania domeny strony logowania. To nadal ma znaczenie, ale TrustSink pokazuje ograniczenie tej zasady. Legalny proces może celowo przekierowywać użytkownika do innego podmiotu, ponieważ organizacja rzeczywiście korzysta z zewnętrznego MFA.

Użytkownik potrzebuje więc dodatkowego punktu odniesienia: czy zna dostawcę, którego używa jego organizacja, i czy zachowanie tego dostawcy jest zgodne z firmową procedurą. Jeśli po podaniu hasła na stronie Microsoft zewnętrzny etap nagle prosi o to samo hasło ponownie, jest to powód do przerwania procesu i zgłoszenia sytuacji.

Nie oznacza to, że pracownik ma samodzielnie analizować OIDC, identyfikatory aplikacji albo konfigurację Entra. Jego zadaniem jest rozpoznać nietypową zmianę w znanym procesie i nie przekazywać ponownie danych logowania stronie, która zwykle ich nie wymaga.

Podobny problem z nadmiernym zaufaniem do legalnego elementu pojawia się w ConsentFix i phishingu OAuth. Tam użytkownik może przejść prawdziwe logowanie Microsoft, ale ryzyko dotyczy kodu autoryzacyjnego i tokenów. W phishingu AiTM omijającym MFA mechanizm jest jeszcze inny: pośrednik próbuje przejąć sesję. TrustSink dotyczy konfiguracji zaufanego zewnętrznego dostawcy.

Czego TrustSink wymaga od napastnika

Najważniejszą granicą faktów jest poziom dostępu potrzebny do przygotowania ataku. Varonis nie opisuje techniki, którą anonimowy nadawca może uruchomić wyłącznie za pomocą wiadomości phishingowej.

Napastnik musi mieć możliwość dokonania zmian w środowisku tożsamości organizacji. Microsoft dokumentuje, że zarządzanie External MFA i udzielanie zgód aplikacji dostawcy wymaga uprzywilejowanych ról oraz odpowiednich uprawnień do polityki metod uwierzytelniania.

To przesuwa część obrony z użytkownika na administratorów. Jeśli konto uprzywilejowane zostanie przejęte, organizacja powinna zakładać, że atakujący może próbować zmieniać mechanizmy zaufania, a nie tylko logować się do poczty czy pobierać pliki.

TrustSink należy więc traktować jako połączenie dwóch problemów: ochrony uprzywilejowanego dostępu oraz phishingu osadzonego w legalnym przepływie uwierzytelniania.

Co powinien zauważyć pracownik

Pracownik nie musi znać nazwy TrustSink. Powinien natomiast znać normalny przebieg logowania w swojej organizacji i wiedzieć, gdzie zgłosić odstępstwo.

Szczególną ostrożność powinny wzbudzić: nieznana nazwa dostawcy MFA, nowa domena pojawiająca się w znanym procesie bez wcześniejszej informacji, prośba o ponowne wpisanie hasła po poprawnym zalogowaniu do Microsoft oraz nagła zmiana wyglądu lub kolejności kroków.

Jeżeli coś się nie zgadza, bezpiecznym działaniem jest zamknięcie procesu i kontakt z pomocą IT przez znany kanał. Nie należy korzystać z numeru telefonu, czatu ani danych kontaktowych pokazanych na podejrzanym ekranie.

To rozszerza klasyczną zasadę z artykułu co to jest phishing: sprawdzamy nie tylko pojedynczy link, ale też kontekst całego procesu i to, czy kolejny krok ma sens.

Co powinno sprawdzić IT i zespół bezpieczeństwa

Pierwszy obszar to kontrola zmian konfiguracji External MFA. Organizacja powinna wiedzieć, którzy dostawcy są zatwierdzeni, kto może ich dodawać, jakie grupy są nimi objęte i kiedy konfiguracja była zmieniana.

Drugi obszar to uprzywilejowane role. Dostęp do zmiany polityki metod uwierzytelniania oraz udzielania zgód administracyjnych powinien być ograniczony do osób, które rzeczywiście go potrzebują. Konta uprzywilejowane wymagają osobnego monitorowania, silnych metod uwierzytelniania i kontroli zmian.

Trzeci obszar to aplikacje i zgody. Nowy dostawca External MFA nie powinien pojawiać się jako zwykła, niezauważona zmiana administracyjna. Warto alarmować o nowych konfiguracjach, zmianach zakresu użytkowników i zgodach dla aplikacji związanych z uwierzytelnianiem.

Czwarty obszar to logi. Varonis wskazuje na potrzebę obserwowania zmian konfiguracji oraz zdarzeń związanych z zewnętrznymi metodami uwierzytelniania. Konkretne reguły detekcji trzeba dopasować do używanego systemu SIEM, licencji i architektury organizacji.

Co zrobić po podejrzeniu TrustSink

Jeżeli użytkownik wpisał hasło na nieoczekiwanym ekranie zewnętrznego MFA, powinien od razu zgłosić zdarzenie. Dla zespołu technicznego nie jest to zwykły przypadek resetu hasła.

Najpierw trzeba sprawdzić, czy w konfiguracji istnieje nieautoryzowany dostawca External MFA i kto go dodał. Jeżeli zostanie potwierdzony, należy go wyłączyć lub usunąć zgodnie z procedurą organizacji oraz zabezpieczyć konto, które umożliwiło zmianę.

Następnie trzeba potraktować hasło jako przejęte: zmienić je, unieważnić aktywne sesje i przeanalizować logowania oraz działania wykonane z konta. Zakres analizy powinien objąć także inne konta i grupy przypisane do złośliwej metody.

Ważne jest ustalenie początku incydentu. Sam moment wpisania hasła przez użytkownika może być późniejszym etapem. Pierwotnym zdarzeniem mogło być wcześniejsze przejęcie konta administratora lub nadużycie uprawnień pozwalających zmienić politykę uwierzytelniania.

Jak ćwiczyć ten scenariusz w security awareness

TrustSink nie nadaje się do ćwiczenia jako zwykła wiadomość z fałszywym formularzem. Warto trenować decyzję użytkownika przy zmianie znanego procesu logowania: nieoczekiwanym dostawcy, ponownej prośbie o hasło albo nowej domenie pojawiającej się po prawidłowym logowaniu.

W testach phishingowych dla firm można odtworzyć bezpieczny wariant takiej sytuacji bez używania prawdziwych danych logowania. Mierzyć należy nie tylko kliknięcie, ale też to, czy użytkownik zatrzymał się przed przekazaniem danych i czy zgłosił nietypowy proces.

Po stronie administratorów ćwiczenie powinno być inne. Tu liczy się wykrycie nieautoryzowanej zmiany w metodach uwierzytelniania, identyfikacja konta, które ją wykonało, usunięcie złośliwej konfiguracji oraz ocena, którzy użytkownicy mogli zostać nią objęci.

Wniosek

TrustSink pokazuje, że bezpieczeństwo MFA zależy również od tego, komu organizacja ufa jako dostawcy i kto może to zaufanie konfigurować. Prawdziwa strona Microsoft na początku procesu nie gwarantuje, że każdy późniejszy ekran jest bezpieczny.

Dla pracownika praktyczna zasada jest prosta: jeśli znany proces logowania nagle kieruje do nieznanego dostawcy albo ponownie prosi o hasło, przerwij działanie i zgłoś zmianę przez firmowy kanał.

Dla organizacji kluczowe jest kontrolowanie uprzywilejowanych ról, dostawców External MFA, zgód aplikacji i zmian polityki uwierzytelniania. Reset hasła po incydencie nie zastąpi usunięcia złośliwej konfiguracji, która może ponownie skierować użytkownika do tej samej pułapki.