Operation ASTERIX: phishing, vishing i AI w jednym oszustwie

TL;DR

Operation ASTERIX pokazuje phishing jako spójny proces socjotechniczny, a nie pojedynczą wiadomość. W odsłoniętej infrastrukturze badacze Rapid7 znaleźli zestawy numerów telefonów, narzędzia do sprawdzania kont, wzbogacone leady, panele phishingowe, skrypty do obsługi połączeń, fałszywe aplikacje portfeli kryptowalutowych oraz kod służący do wysyłania wykradzionych danych przez Telegram.

Najciekawszy element z perspektywy security awareness nie dotyczy jednak kryptowalut. Dotyczy zaufania pomiędzy kanałami. Wiadomość e-mail tworzyła fałszywe zgłoszenie i kod, a późniejszy rozmówca znał te same dane. Ofiara mogła więc uznać: skoro osoba po drugiej stronie telefonu zna numer sprawy z wiadomości, kontakt musi być prawdziwy.

To błędne założenie. Jeżeli oba kanały są częścią jednego scenariusza napastnika, nie potwierdzają się niezależnie. Bezpieczna weryfikacja zaczyna się dopiero wtedy, gdy użytkownik sam wybiera trzeci, zaufany kanał kontaktu.

Co Rapid7 znalazł w odsłoniętej infrastrukturze

Rapid7 Labs trafił na odsłonięty katalog sieciowy w infrastrukturze wspierającej operację oszustwa kryptowalutowego. W przeciwieństwie do analizy pojedynczej wiadomości phishingowej badacze mogli zobaczyć dużą część zaplecza operatora: dane wejściowe, narzędzia do selekcji celów, panele, skrypty telefoniczne, fałszywe aplikacje i historię pracy z asystentami AI.

Nazwa Operation ASTERIX pochodzi od Asterisk, otwartego systemu telefonii IP odnalezionego w tym środowisku. Rapid7 opisał również obecność 3CX. Oba są legalnymi rozwiązaniami telefonicznymi. W tej operacji zostały wykorzystane jako element infrastruktury do obsługi połączeń i vishingu.

To rozróżnienie jest istotne: samo użycie popularnego, legalnego narzędzia nie świadczy o ataku. Problemem jest sposób, w jaki operator połączył wiele normalnie wyglądających elementów w jeden proces oszustwa.

Selekcja celu: od bazy numerów do zweryfikowanego leada

Atak nie musiał zaczynać się od losowego telefonu. Odzyskane artefakty wskazują na etap selekcji i wzbogacania danych. Operator wykorzystywał narzędzia do sprawdzania, które numery mogą być powiązane z kontami na platformach kryptowalutowych, a następnie budował bardziej wartościową listę celów.

Rapid7 opisał między innymi plik obejmujący ponad 100 tysięcy polskich numerów telefonów, który pojawiał się w procesie walidacji. To nie oznacza, że ponad 100 tysięcy osób zostało skutecznie oszukanych. Lista była materiałem wejściowym do dalszego filtrowania.

eSecurity Planet zwraca uwagę na większy zbiór numerów odnaleziony w infrastrukturze i na stopniowe zawężanie puli do bardziej obiecujących celów. Z perspektywy obrony ważniejszy od samej liczby jest mechanizm: rozmówca może wiedzieć o ofierze więcej niż tylko imię i numer telefonu.

Dane dopasowane do konkretnego użytkownika zmieniają odbiór rozmowy. Jeżeli osoba dzwoniąca zna nazwę usługi, z której korzystamy, lokalizację, podstawowe dane i numer rzekomego zgłoszenia, łatwiej pomylić wiedzę napastnika z dowodem jego tożsamości.

E-mail i telefon potwierdzają się nawzajem

W odzyskanych panelach phishingowych Rapid7 znalazł mechanizmy generujące wiadomości podszywające się pod znane firmy z rynku kryptowalut. Wiadomość mogła zawierać numer sprawy lub kod weryfikacyjny. Następnie te same dane były dostępne dla osoby prowadzącej rozmowę telefoniczną.

Powstaje wówczas bardzo skuteczna konstrukcja psychologiczna:

1. użytkownik dostaje wiarygodnie wyglądający e-mail o problemie z kontem;
2. po chwili dzwoni rzekome wsparcie;
3. rozmówca zna numer sprawy lub kod widoczny w wiadomości;
4. zgodność danych wygląda jak potwierdzenie autentyczności obu kontaktów;
5. użytkownik zaczyna wykonywać kolejne instrukcje.

Rapid7 zaznacza, że nie odzyskano pełnych logów połączeń pozwalających odtworzyć każdą interakcję z ofiarą. Można natomiast potwierdzić, że infrastruktura była przygotowana do takiego współdziałania e-maila i telefonu.

Ten model jest szczególnie istotny dla firm. W organizacji identycznie może wyglądać fałszywe zgłoszenie z helpdesku: e-mail z numerem ticketu, a potem telefon od osoby, która ten numer zna. Samo powtórzenie informacji z wcześniejszej wiadomości nie jest niezależną weryfikacją.

Fałszywa aplikacja jako kolejny etap

Kontakt nie kończył się na zdobyciu zaufania. Rapid7 odzyskał fałszywe aplikacje podszywające się między innymi pod Trezor Suite, Ledger Live i Exodus w wersjach dla macOS i Windows. Ich zadaniem było doprowadzenie użytkownika do ujawnienia danych pozwalających przejąć portfel, w szczególności recovery phrase.

To pokazuje, dlaczego pytanie „czy wiadomość wygląda poprawnie?” jest zbyt wąskie. Użytkownik może przejść przez kilka etapów, z których każdy osobno wygląda wiarygodnie: e-mail, rozmowa ze wsparciem, strona, instalator i ekran aplikacji.

Oficjalne zalecenia producentów są jednoznaczne. Ledger przypomina, że recovery phrase nie należy przekazywać nikomu ani wpisywać jej poza urządzeniem Ledger. Trezor zaleca zakończenie rozmowy z osobą podającą się za wsparcie i rozpoczęcie kontaktu samodzielnie przez oficjalny kanał.

To dobra reguła także poza światem kryptowalut: jeżeli przychodzący kontakt prowadzi do instalacji programu, przekazania sekretu, zatwierdzenia operacji albo zmiany ustawień bezpieczeństwa, proces powinien zostać zatrzymany do czasu niezależnego potwierdzenia.

Gdzie naprawdę pojawia się AI

Operation ASTERIX jest interesująca również dlatego, że Rapid7 odzyskał historię pracy operatora z asystentami AI. Nie chodziło wyłącznie o wygenerowanie treści wiadomości phishingowej.

Materiały wskazują na używanie AI do:

• porządkowania i przygotowywania zbiorów danych;
• pracy nad skryptami do sprawdzania numerów i kont;
• rozwiązywania problemów z kompilacją aplikacji Electron;
• modyfikowania kodu i infrastruktury phishingowej;
• utrudniania analizy przygotowanych aplikacji;
• przygotowywania kolejnych wersji plików dla Windows i macOS.

Gdy jeden z modeli odmówił części działań związanych z przygotowaniem złośliwego oprogramowania, operator zmienił dostawcę i próbował obejść zabezpieczenia kolejnego modelu za pomocą instrukcji typu jailbreak.

Nie ma jednak podstaw, aby przedstawiać AI jako autonomicznego sprawcę operacji. Odzyskane materiały pokazują człowieka wykorzystującego kolejne modele jako narzędzia wspierające pracę. To istotna różnica względem scenariuszy opartych na agentach głosowych AI, gdzie sztuczna inteligencja może bezpośrednio uczestniczyć w rozmowie z ofiarą.

W Operation ASTERIX najciekawsze jest przyspieszenie pracy operatora: jeden człowiek może łatwiej łączyć przygotowanie danych, kod, fałszywe aplikacje i infrastrukturę w jeden spójny proces.

Dlaczego drugi kanał nie zawsze jest niezależnym potwierdzeniem

W szkoleniach często powtarza się dobrą zasadę: potwierdź nietypową prośbę drugim kanałem. Problem pojawia się wtedy, gdy użytkownik rozumie ją zbyt dosłownie.

Telefon po e-mailu nie jest automatycznie drugim, niezależnym kanałem. SMS wysłany podczas rozmowy też nim nie jest. Link przesłany przez osobę dzwoniącą również nie daje niezależności.

KNF w materiale o vishingu opisuje podobny mechanizm uwiarygadniania rozmowy dodatkowymi wiadomościami i zaleca, aby w razie wątpliwości rozłączyć się oraz samodzielnie zadzwonić do instytucji.

To prowadzi do precyzyjniejszej reguły:

Nie potwierdzaj przychodzącego kontaktu kanałem wskazanym przez osobę, która ten kontakt rozpoczęła. Samodzielnie wybierz znany, oficjalny kanał i rozpocznij nową rozmowę.

W firmie może to oznaczać wejście do portalu helpdesk z zapisanej zakładki, użycie numeru z firmowego katalogu, kontakt z przełożonym przez znany wcześniej komunikator albo zgłoszenie do działu bezpieczeństwa zgodnie z wewnętrzną procedurą.

Jak organizacje powinny ćwiczyć taki scenariusz

Operation ASTERIX dobrze pokazuje ograniczenie klasycznych testów phishingowych. Jeżeli symulacja kończy się w chwili kliknięcia w link, nie sprawdza wielu decyzji, które pojawiają się w rzeczywistym ataku.

1. Ćwiczyć spójne scenariusze wielokanałowe

Pracownik powinien zetknąć się z sytuacją, w której e-mail i telefon zawierają te same informacje. Celem nie jest wprowadzenie go w pułapkę za wszelką cenę, ale sprawdzenie, czy rozumie różnicę pomiędzy zgodnością informacji a niezależnym potwierdzeniem tożsamości.

2. Mierzyć moment przerwania procesu

Samo kliknięcie nie daje pełnego obrazu. Warto mierzyć, czy użytkownik zatrzyma się przed instalacją programu, podaniem sekretu, zatwierdzeniem operacji albo zmianą ustawień bezpieczeństwa.

3. Uczyć samodzielnego wyboru kanału weryfikacji

Procedura powinna mówić konkretnie, skąd wziąć prawidłowy numer telefonu lub adres kontaktowy. Zasada „zadzwoń i potwierdź” jest niewystarczająca, jeżeli pracownik oddzwoni na numer z podejrzanej wiadomości.

4. Łączyć awareness z obsługą zgłoszeń

Pracownik musi wiedzieć, co zrobić po przerwaniu rozmowy. Jeżeli zgłoszenie podejrzanego telefonu jest skomplikowane albo nikt nie reaguje, organizacja traci informacje o tym, że inni pracownicy mogą być właśnie atakowani tym samym scenariuszem.

5. Nie ograniczać problemu do kryptowalut

Kryptowaluty były celem tej konkretnej operacji, ale mechanizm można łatwo przenieść na firmowy helpdesk, bank, Microsoft 365, dostawcę usług chmurowych, dział HR albo księgowość. To dlatego program security awareness powinien ćwiczyć decyzje w różnych kanałach, a nie wyłącznie rozpoznawanie podejrzanych wiadomości e-mail.

Szerszy kontekst takiego podejścia opisaliśmy też w materiale o industrializacji phishingu i modelu PhaaS. Operation ASTERIX jest konkretnym przykładem, jak wiele elementów można połączyć w jeden warsztat operatora.

Wniosek

Operation ASTERIX nie wymaga od obrońców nauczenia się zupełnie nowej techniki. Pokazuje coś bardziej praktycznego: znane techniki stają się znacznie skuteczniejsze, gdy są połączone w jeden spójny scenariusz.

E-mail może przygotować rozmowę. Rozmowa może potwierdzić dane z e-maila. Fałszywa aplikacja może wyglądać jak naturalne rozwiązanie problemu opisanego przez rzekome wsparcie. AI może przyspieszać przygotowanie kodu, danych i kolejnych wersji narzędzi.

Dlatego skuteczna obrona nie powinna opierać się na pojedynczym sygnale typu „dziwny link” albo „nieznany numer”. Użytkownik musi rozumieć, kto kontroluje cały kontekst rozmowy i w którym momencie trzeba wyjść z narzuconej ścieżki.

W praktyce najlepszym ruchem jest często przerwanie kontaktu i rozpoczęcie nowego procesu weryfikacji przez oficjalny kanał wybrany samodzielnie. Tę decyzję warto mierzyć w realistycznych testach phishingowych dla firm, szczególnie gdy scenariusz obejmuje więcej niż jeden kanał komunikacji.