Atak AiTM i kradzież tokenu MFA

Atakujący nie musi budować fałszywej witryny: uruchamia serwer WWW, który przekazuje pakiety HTTP między ofiarą a atakowaną usługą, w obu kierunkach¹. Strona zawiera dwie osobne sesje TLS, jedną z ofiarą, drugą z prawdziwą witryną, dzięki czemu z żądań można wyciągnąć hasła i, co ważniejsze, cookie sesji¹.

Tę pracę można zautomatyzować za pomocą zestawów open source. Microsoft wymienia Evilginx2, Modlishka i Muraena¹. MITRE podaje, że Evilginx2 może służyć jako przekaźnik AiTM między legalną witryną a osobą złapaną na phishing, aby przechwycić dane logowania, tokeny uwierzytelniania i cookie sesji⁵. Po zdobyciu cookie atakujący wstrzykuje je do własnej przeglądarki, by pominąć uwierzytelnianie, nawet gdy MFA celu jest włączone¹.

Na początku jest wiadomość. MITRE opisuje e-mail z zainfekowanym linkiem, który służy m.in. do omijania zabezpieczeń sprawdzających załączniki⁶. W kampanii zbadanej przez Microsoft e-mail zawierał załącznik HTML i zapowiadał wiadomość głosową¹. Strona wyświetlała pasek pobierania wiadomości, ale pasek był wpisany na stałe w pliku: żaden plik audio nie był pobierany¹. Ofiarę przekierowywano następnie na stronę, która wstępnie wypełniała jej adres e-mail, co zwiększało wiarygodność pułapki¹.

Potem pojawia się strona logowania, kopia portalu Microsoft. Gdy dane logowania zostały wpisane, a uwierzytelnienie się powiodło, ofiara trafiała na prawdziwą stronę office.com¹. Nic nie sygnalizuje przechwycenia: w tle atakujący już przechwycił dane logowania i z kolei otworzył sesję¹.

Oto zneutralizowana ilustracja formy takiego adresu, pokazująca, że pułapkę zdradza tylko adres:

Illustration (adresse neutralisée, inventée pour l'exemple) :
hxxps://login[.]exemple-portail[.]invalid/[identifiant de la victime]
Page affichée : [copie du formulaire de connexion Microsoft]
Adresse attendue : [l'adresse officielle du service, saisie ou enregistrée par vous]

Usługa internetowa otwiera sesję po uwierzytelnieniu, aby nie pytać o tożsamość przy każdej stronie. Sesja opiera się na cookie dostarczonym przez usługę uwierzytelniania, które dowodzi serwerowi, że użytkownik jest zalogowany¹. MITRE zauważa, że takie cookie często pozostają ważne przez długi czas, nawet gdy aplikacja nie jest aktywnie używana⁷. Atakujący, który je posiada, może zaimportować je do przeglądarki pod swoją kontrolą i zalogować się do aplikacji².

W kampanii z 2022 roku cookie zawierały deklarację MFA: atakujący używał ich więc do wejścia na konto mimo polityki MFA organizacji¹. MITRE podaje też przypadek, w którym APT29 użyło skradzionych cookie do dostępu do zasobów w chmurze oraz sfałszowanego cookie duo-sid do ominięcia MFA na koncie pocztowym podczas włamania SolarWinds².

Po stronie obrony CISA porządkuje formy MFA od najsilniejszej do najsłabszej. Jednorazowe kody z aplikacji są podatne na phishing, tak samo jak SMS-y i połączenia głosowe³. Powiadomienia push z wpisywaniem liczby są odporne na „push bombing", ale nie na phishing³. Według CISA tylko FIDO/WebAuthn jest powszechnie dostępnym uwierzytelnianiem odpornym na phishing³. Brytyjskie NCSC poświęca przewodnik najsilniejszym metodom MFA⁸. Microsoft zaleca też polityki dostępu warunkowego, oceniane przy każdej próbie użycia skradzionego cookie (zgodne urządzenie, zaufany adres IP)¹.

Lipiec 2022: kampania wymierzona w ponad 10 000 organizacji

12 lipca 2022 roku Microsoft opublikował analizę szeroko zakrojonej kampanii phishingowej AiTM. Kampania kradła hasła, przejmowała sesje i omijała uwierzytelnianie, nawet gdy MFA było włączone. Według danych Microsoftu próbowała objąć ponad 10 000 organizacji od września 2021 roku¹. Atakujący naśladowali stronę uwierzytelniania online pakietu Office, używając zestawu Evilginx2¹.

Po kradzieży: oszustwa przelewowe

Atakujący używali następnie skradzionych danych logowania i cookie, aby wejść do skrzynek pocztowych i przeprowadzać oszustwa przelewowe (BEC) wobec innych celów¹. Microsoft zaobserwował, że między kradzieżą a początkiem oszustwa mogło wystarczyć pięć minut¹. W kolejnych dniach atakujący co kilka godzin przeglądał e-maile i załączniki finansowe, szukał trwających korespondencji, a potem usuwał pierwotny e-mail phishingowy¹.

Następnie tworzył regułę skrzynki odbiorczej, która przenosiła do „Archiwum”, oznaczone jako przeczytane, wiadomości z domeny celu oszustwa, aby właściciel konta niczego nie zauważył¹. Na koniec odpowiadał w wątkach o płatnościach i fakturach, po czym usuwał swoje odpowiedzi z elementów wysłanych¹. Raz prowadził kilka prób równolegle z tej samej skrzynki¹.