Phishing w chmurze, czyli stare techniki w nowej odsłonie

Od ubiegłego roku CERT Orange Polska regularnie odnotowuje próby wykorzystania możliwości stwarzanych przez usługi chmurowe w kampaniach phishingowych i malspamowych. W ostatnich dniach trafił do nas ciekawy przykład, na podstawie którego przedstawimy część wykorzystywanych obecnie technik w phishingowych kampaniach, wyłudzających dane logowania do skrzynek pocztowych w usłudze Microsoft Office 365.

Malspam

Zaczyna się jak zawsze od wiadomości. I choć coraz częściej eksploatowanym kanałem bywają SMS-y, elektroniczna dystrybucja wiadomości pocztowych nie pozostaje w tyle.

Wiadomość sama w sobie nie wygląda się zbyt profesjonalnie, choć zdarzają się i takie, które designem graficznym nie odbiegają od oryginału, a ich temat i częściowo również treść ulega zmianie w celu oszukania operujących na schematach szablonów identyfikacji spamu i podejrzanych wiadomości.

Inaczej sprawa ma się z samymi metodami wysyłki. Klasyczną techniką jest posłużenie się serwerami pocztowymi bez aktywnej funkcji autoryzacji do wysyłki spamu. Często jest to połączone z technikami spoofingu, bądź wykorzystaniem przejętego już wcześniej konta do wysyłania kolejnych wiadomości. Chętnie wykorzystywane są zwłaszcza konta w usługach chmurowych, jako że dziedziczą domenę po usługodawcy, a to zdecydowanie obniża czujność (i scoring) większości systemów automatycznego wykrywania podejrzanych wiadomości.

Złośliwy link, czyli łańcuch przekierowań w tle

Jeśli przyjrzymy się strukturze następujących po sobie przekierowań, nietrudno o znalezienie elementów wspólnych. Powyższy link również wpisuje się w obserwowany trend utylizacji serwisów do zarzadzania kampaniami marketingowo-reklamowymi w internecie przez cyberprzestępców. Serwisy takie jak Partnerize (domena prf.hn) zapewniają wygodę w monitorowaniu dystrybucji i śledzenia aktywności rozsyłanych linkow, a możliwość wplecenia w łańcuch przekierowań legalnej, wiarygodnej domeny, zwiększa szanse uniknięcia natychmiastowej detekcji.

Pierwszy landing page, czyli złośliwa captcha

Po kliknięciu w link z wiadomości mailowej, użytkownik ląduje na stronie gdzie, jedynym aktywnym elementem jest mechanizm wykrywania automatów zapożyczony całkowicie z serwisów Google:

Nim przejdziemy do tego co dzieje się pod spodem, zweryfikujmy na szybko kłódkę certyfikatu:

Kolejny klient Let’s Encrypt i kolejny certyfikat z trzymiesięcznym okresem ważności… Data wystawienia certyfikatu to 3.3.2020, co w połączeniu ze wzmożoną liczbą połączeń do serwisu stanowi cechę charakterystyczną podczas wykrywania kampanii phishingowych.

Wracając do samej strony. Funkcja CAPTCHA, choć wizualnie to ona dzieli użytkownika od finalnego URL-a, uzbrojona jest w krótki skrypt warunkujący przekierowanie na właściwą stronę phishingową od poprawnego formatu e-mail (kodowanego potem w base64 i doklejanego do linka końcowego).

Drugi landing page, czyli man-in-the-middle w nowym wydaniu

Tym razem trafiamy na subdomenę w domenie Microsoftu (windows.net) z absolutnie zgodnymi certyfikatami giganta z Redmond. Przestępcy postarali się nawet, by w wyświetlanej domenowej nazwie pojawiło się słowo kluczowe „o365” w celu zapewnienia jak największej zgodności z oryginałem.

Najistotniejszej zmianie w porównaniu do obserwowanych już wcześniej phishingów ulegla technika wystawiania formularza logowania. Zwykle przygotowujący phishing starają się dokładnie odwzorować wygląd strony w budowanej przez siebie kopii. Tym razem, zamiast kopiować elementy ze spoofowanych witryn przy pomocy komponentu man-in-the-middle, byli w stanie podstawiać w czasie rzeczywistym niezbędne elementy graficzne dublowanych stron.

Bazując na domenie mailowej adresu zawartego w przekierowującym linku, skrypt budował relacje i wyświetlał ofierze komponenty graficzne wyciągnięte wprost z rzeczywistej usługi pocztowej, od banneru z logiem firmy począwszy, na obrazku w tle kończąc.

Sam formularz logowania wymagał z kolei podania właściwego maila mieszczącego się w bazie adresatów do których trafiła wiadomość phishingowa, by aktywować krok drugi i umożliwić ofierze wpisanie swojego hasła. Weryfikacja odbywała się za pomocą prostego kodu w PHP-ie (valid_email.php) znajdującego się na… japońskojęzycznym WordPressie (hehepress.com) do którego przekierowywane były wszystkie operacje wykonywane na formularzu autoryzacyjnym.

Gdy adres e-mail został zidentyfikowany poprawnie, po każdej próbie wpisania hasła, serwis każdorazowo zwracał informacje o niepoprawności wprowadzonych danych. W tym czasie w tle nawiązywane było kolejne połączenie z hostem hehepress.com, w celu uruchomienia funkcji, która w locie wykonywała logowanie po protokole IMAP z użyciem wprowadzonych poświadczeń. W sytuacji, gdy hasło wprowadzone zostało błednie, funkcja kończyła się poniższym błędem.

Co działo się w przypadku gdy hasło było poprawne, możemy się tylko domyślić…