Fałszywe reklamy i złośliwe aplikacje - analiza operacji toll fraud

14 września 2026 roku trafiliśmy na dwie reklamy na Facebooku, które ostrzegały polskich użytkowników, iż ich aplikacja do obsługi plików PDF straciła ważność. Obie prowadziły jednak do Messenger Pro w Google Play, czyli niezwiązanego z plikami PDF komunikatora. Po instalacji aplikacja uruchamiała czterowarstwowy łańcuch prowadzący do modułu realizującego toll fraud.

Dalsza analiza ujawniła znacznie większą operację. Zabezpieczyliśmy 1235 reklam Meta wyświetlanych pod 74 zidentyfikowanymi nazwami profili. Z tej grupy 852 reklamy, publikowane pod 60 nazwami, promowały 17 aplikacji z Google Play powiązanych wspólnym kodem lub infrastrukturą.

Potwierdzone aplikacje maskowały się zarówno jako komunikatory, jak i narzędzia użytkowe. Reguły wyboru kraju mogły kierować polskie urządzenia do różnych wariantów kodu. Dla polskiego kodu kraju sieci komórkowej (MCC) 260 aplikacja Messenger Pro wybierała domyślny payload realizujący toll fraud. W przypadku później przeanalizowanej aplikacji Phone Cleaner Master reguły zawierały natomiast wartość PL260, która kierowała polskie urządzenia do gałęzi z payloadem AqMu.

Głównym punktem odniesienia w analizie technicznej jest Messenger Pro. Aplikacja rzeczywiście działała jako komunikator, mogła więc wiarygodnie prosić o ustawienie jej jako domyślnej aplikacji do obsługi wiadomości SMS. Jednocześnie bazowy plik APK odtwarzał zaszyfrowany plik DEX. Uruchomiony w ten sposób moduł pobierał dane z serwera i odszyfrowywał kolejny plik DEX, który stosował reguły wyboru kraju i pobierał adekwatny payload. Łańcuch wykonania obejmował cztery warstwy: moduł ładujący w bazowym pliku APK, mechanizm kontroli kraju, mechanizm wyboru payloadu oraz wybrany payload.

Toll fraud polega na nadużyciu mechanizmów płatności mobilnych w celu uruchomienia płatnej usługi bez wiedzy i świadomej zgody abonenta. W odróżnieniu od prostego wysyłania wiadomości SMS Premium lub wykonywania połączeń o podwyższonej opłacie, wariant wykorzystujący przeglądarkę zwykle wymaga kilku kroków. Złośliwe oprogramowanie rozpoznaje obsługiwanego operatora, przełącza ruch na sieć komórkową, otwiera stronę płatności, podaje numer telefonu, przechwytuje kod weryfikacyjny z wiadomości SMS i potwierdza zakup. Użytkownik może w ogóle nie zobaczyć strony ani wiadomości weryfikacyjnej.

Dokładny przebieg zależy od dostawcy. W przypadku części ofert wystarczy wysłać słowo najważniejsze w wiadomości SMS, inne wymagają podania numeru telefonu i kodu weryfikacyjnego. Dzięki temu toll fraud można dostosować do wielu mechanizmów rozliczeń. Serwer może wybierać oferty dla określonego kraju lub operatora, natomiast pobierany kod i skrypty JavaScript pozwalają pozostawić logikę adekwatną dla danego dostawcy poza wersją aplikacji przekazaną do weryfikacji w sklepie. W naszej wcześniejszej analizie Jokera opisaliśmy rodzinę złośliwego systemu na system Android, która nadużywała płatności przez operatora. Nie przypisujemy opisywanej tutaj próbki do kampanii Joker, ale wpisuje się ona w ten sam szerszy kierunek rozwoju: od prostych nadużyć wiadomości SMS do zdalnie sterowanej automatyzacji subskrypcji.

Rysunek 1. Typowe ścieżki toll fraud wykorzystujące SMS Premium i płatności przez operatora.

W zaobserwowanych regułach Messenger Pro polski MCC 260 otrzymywał domyślny payload. Aktywny serwer C2 przydzielał zadania dotyczące zarówno wiadomości SMS Premium, jak i płatności przez operatora realizowanych w przeglądarce. Ten drugi mechanizm, określany jako Direct Carrier Billing (DCB), pozwala obciążyć rachunek abonamentowy albo saldo usługi przedpłaconej za pośrednictwem operatora komórkowego. Podczas kontrolowanego uruchomienia JavaScript przekazany przez C2 aktywował odnośnik sms: bez działania użytkownika i przekazał numer docelowy oraz słowo najważniejsze do interfejsu korzystającego z systemowego API SMS. Wartości 92505, 92512 i 92513 były numerami skróconymi SMS używanymi przez strony subskrypcji. Wysłanie wygenerowanego słowa kluczowego na jeden z tych numerów mogło zamówić lub potwierdzić płatną usługę i obciążyć abonenta. Na jednej z przechwyconych stron All4You numer 92513 wiązał się z jednorazową opłatą 30,75 zł. Kolejne zadanie prowadziło do strony Teleaudio, która oferowała usługę za 17 zł co siedem dni.

Usługi SMS Premium w rejestrze UKE

Serwer C2 aplikacji Messenger Pro zwrócił trzy numery skrócone, które sprawdziliśmy w publicznym rejestrze usług o podwyższonej opłacie UKE. Numery 92505, 92512 i 92513 figurowały w rejestrze jako aktywne usługi SMS Premium. Wysłanie wiadomości na każdy z nich kosztowało 30,75 zł brutto. Wszystkie były zarejestrowane w czterech głównych polskich sieciach komórkowych: Orange, T-Mobile, Play i Polkomtel. Operatorem usługi o numerze 92505 jest GoMobee LTD z Malty, 92512 należy do Telefuture Nederland B.V. z Holandii, a 92513 do RedLeads B.V. z Holandii. Nazwa usługi zarejestrowanej dla 92505 zawiera Loovafit i Loovaplay, co odpowiada słowom kluczowym wysyłanym przez złośliwe oprogramowanie. Dla 92513 widnieje nazwa Usluga ALL na numerze 92513, odpowiadająca słowu kluczowemu ALL 64913 zarejestrowanemu podczas kontrolowanego uruchomienia. Kwota 30,75 zł zgadza się też z informacją na stronie All4You przechwyconej w czasie wykonania. Firmy te obsługują agregację usług SMS Premium, których numery zostały wykorzystane. Są dostawcami rozliczeń, a nie operatorami kampanii złośliwego oprogramowania. Oferta Teleaudio za 17 zł co siedem dni korzystała z płatności przez operatora za pośrednictwem epayment.teleaudio.pl, a nie z numeru skróconego SMS Premium, dlatego nie figuruje w tym rejestrze.

Dystrybucja i skala kampanii

Analizę rozpoczęliśmy od dwóch polskich reklam w Bibliotece reklam Meta. Wyświetlano je pod nazwami Britney Harris i Kenneth Williams, a obie wykorzystywały ten sam fałszywy motyw aktualizacji aplikacji do plików PDF. Zawierały następujący tekst:

Aplikacja PDF straciła ważność. jeżeli nie zaktualizujesz teraz, nie będziesz mógł otworzyć plików PDF. Jesteś o krok od utraty dostępu. Nie ryzykuj. Zaktualizuj do najnowszej wersji już teraz.

Obie reklamy były aktywne w Bibliotece reklam Meta, gdy zarejestrowaliśmy je 14 września 2026 roku. Miały identyfikatory 1101937705505412 i 4635863290017072. W chwili rejestracji druga z nich miała mniej niż 100 wyświetleń, ale liczba ta dotyczyła tylko jednej reklamy w znacznie większym zbiorze.

Kliknięcie dowolnej z nich przekierowywało bezpośrednio do strony Messenger Pro w Google Play. Reklamowany pakiet to:

Google Play przedstawiał pakiet jako Messenger Pro w wersji 9.0, opublikowany przez dewelopera Noah Isaiah Shortland. Zrzuty ekranu reklamowały blokadę hasłem, możliwość zmiany wyglądu i obsługę emoji. Nic w opisie nie łączyło aplikacji z plikami PDF ani ich aktualizacją.

CERT Polska zgłosił Messenger Pro firmie Google 15 września 2026 roku. Następnie Google usunęło aplikację ze sklepu. Zatrzymało to nowe instalacje z jej karty w Google Play, ale nie wpłynęło na kopie znajdujące się już na urządzeniach użytkowników. Podczas naszej analizy, także po usunięciu aplikacji ze sklepu, C2 i infrastruktura pomocnicza przez cały czas działały. Przyjmowały kontrolowane rejestracje z Polski i przydzielały zadania.

Skala kampanii w Meta i Google Play

Początkowy zakres analizy był wąski: dwie reklamy prowadzące do jednej aplikacji. Po zbadaniu Messenger Pro sprawdziliśmy, czy istnieje więcej reklam tej aplikacji. Systematyczne zbieranie danych powiększyło zbiór do 1235 unikalnych reklam Meta wyświetlanych pod 74 zidentyfikowanymi nazwami profili. Reklamy promowały 29 aplikacji w Google Play, a w przypadku 90 usuniętych rekordów nie można było już odtworzyć adresu docelowego. Kod i infrastruktura połączyły 17 aplikacji z operacją. To, co początkowo wyglądało na pojedynczy złośliwy plik APK promowany kilkoma reklamami, było częścią skoordynowanej i ciągłej dystrybucji.

Operacja wykorzystywała jednocześnie obie platformy. Publikacja na platformie Meta służyła do pozyskiwania polskich użytkowników dzięki płatnych reklam. Reklamy wyświetlane w znanym użytkownikowi strumieniu aktualności czerpią wiarygodność z samej platformy, dlatego fałszywe ostrzeżenia o plikach PDF wyglądały jak zwykła promocja produktu. Google Play zapewniał natomiast sposób instalacji, który użytkownicy uznają za sprawdzony i godny zaufania. Poniższe kategorie są celowo rozdzielone. Wspólny profil reklamodawcy lub podobny motyw graficzny nie wystarcza, aby stwierdzić, iż dwa pliki APK zawierają to samo złośliwe oprogramowanie.

Messenger Pro posłużył jako punkt odniesienia do mapowania kampanii. Inne reklamy i aplikacje łączyliśmy z nią wyłącznie na podstawie możliwych do zweryfikowania dowodów: dokładnych adresów docelowych reklam, identycznych skrótów materiałów reklamowych, wspólnego kodu modułu ładującego albo konkretnych powiązań DNS, TLS i hostingu. Podobne nazwy lub podobne motywy reklamowe nie były wystarczające.

Nazwy profili są etykietami wyświetlanymi przy reklamach, a nie zweryfikowanymi tożsamościami. Niedostępnych aplikacji i usuniętych adresów docelowych nie wliczamy do liczby potwierdzonej na podstawie kodu. Oddzielamy też aplikacje promowane dzięki identycznych materiałów kampanii, gdy ich odzyskany APK nie zawierał modułu ładującego. 98 reklam aplikacji Quick Show i BlushToon pochodziło z profili, które promowały także potwierdzone oprogramowanie należące do operacji. Oba pliki APK były jednak czytnikami komiksów o innym kodzie i infrastrukturze. Ich obecność świadczy o ponownym użyciu kont reklamodawców, nie o związku z opisywaną operacją toll fraud.

W sześciu aplikacjach odzyskaliśmy komponenty toll fraud lub potwierdziliśmy bezpośrednie powiązania z payloadami. Jedenaście kolejnych plików APK zawierało złośliwe moduły ładujące powiązane z tą samą operacją przez adresy docelowe reklam, ukryte komponenty Androida, logikę aktywacji i infrastrukturę. Nie odzyskaliśmy ich końcowych modułów realizujących oszustwo, dlatego traktujemy ten poziom dowodów oddzielnie. Łącznie te 17 aplikacji było promowanych w 852 reklamach wyświetlanych pod 60 nazwami profili.

Colorful Message korzystał z dokładnie tych samych obrazów reklamowych co pozostała część kampanii i był promowany przez 94 reklamy Meta. Osobne poszukiwania w serwisie TikTok wykazały dziewięć reklam tego samego pakietu. Jego ukryta, natywna ścieżka wykonania różniła się od potwierdzonych modułów ładujących, dlatego uznajemy go za część tej samej kampanii reklamowej, ale nie twierdzimy, iż używał tej samej implementacji złośliwego oprogramowania. Light SMS, Easy Messages i pięć nowo zidentyfikowanych usuniętych pakietów pozostają dowodami pomocniczymi, ponieważ ich pliki APK były niedostępne. Easy Messages Pro i Comic Reader były bezpośrednimi adresami docelowymi reklam korzystających z identycznych materiałów kampanii, ale odzyskane wersje APK nie zawierały rozpoznanego modułu ładującego operacji.

Do adresów docelowych powiązanych z operacją prowadziły reklamy wyświetlane pod następującymi 60 nazwami profili:

Pod nazwą Britney Harris wyświetlano także 12 reklam Easy Messages, a pod nazwą Kenneth Williams 21 reklam Light SMS. Zebraliśmy dodatkowo 898 plików reklamowych i podzieliliśmy je na 45 grup o identycznych skrótach SHA-256. 23 grupy odpowiadały plikom z wcześniejszego zbioru. Jeden niezmieniony plik o SHA-256 90b87d8b4dda273ef64853a9997bba0844f0bc02071ae5101d1be2693be1b861 pojawił się w 55 nowych reklamach obejmujących 20 pakietów i 39 zidentyfikowanych profili, oprócz jednego wcześniejszego rekordu. Liczba reklam z wcześniej najczęściej obserwowanym plikiem o SHA-256 7299f7de6acf366fc7f32f7c3873a09e11a08d9493aaa508cd2b2ee816c5d284 wzrosła z 26 do 50. Ponowne użycie tych materiałów przemawia za wspólnym przygotowaniem kampanii, a wspólny kod i infrastruktura stanowią niezależne dowody techniczne.

Wszystkie aplikacje odkryte podczas analizy zgłosiliśmy firmie Google, a Google usunęło je ze sklepu. Reklamy zgłosiliśmy również firmie Meta, i to właśnie te zgłoszenia doprowadziły do ich usunięcia. Usunięcie objęło wyłącznie reklamy, które zidentyfikowaliśmy. Inne reklamy w ramach tej samej operacji mogły pozostać aktywne bez naszej wiedzy, choć reklamy mają ograniczony czas trwania i część z nich mogła wygasnąć samoistnie. Usunięcia nie zatrzymały jednak dystrybucji w pełni: pojawiały się nowe pakiety, infrastruktura C2 przez cały czas działała, a kopie zainstalowane wcześniej mogły się z nią komunikować.

Kampania jest aktualnym przykładem problemu opisanego w naszej ewaluacji z marca 2025 roku. Stwierdziliśmy w niej, iż Meta nie wdrożyła odpowiednio kilku proponowanych zabezpieczeń, w tym skuteczniejszej obsługi zgłoszeń zwykłych użytkowników, proaktywnego blokowania powracających reklamodawców i integracji z Listą Ostrzeżeń CERT Polska. W sierpniu 2026 roku, po opublikowaniu przez Ministerstwo Cyfryzacji korespondencji z Meta, wicepremier Krzysztof Gawkowski poinformował o formalnym wystąpieniu do Komisji Europejskiej z wnioskiem o nałożenie kary w wysokości co najmniej 250 mln euro w związku ze sposobem reagowania firmy Meta na oszukańcze reklamy w Polsce.

Wspólne moduły ładujące i infrastruktura

Materiały reklamowe pozwoliły ustalić skalę kampanii, natomiast kod i infrastruktura połączyły aplikacje z tą samą operacją. Porównaliśmy 22 wersje aplikacji na system Android odzyskane podczas analizy i znaleźliśmy powtarzającą się architekturę dostarczania payloadów.

W typowej ścieżce działająca aplikacja, pierwsza warstwa łańcucha, odtwarzała w czasie wykonania zaszyfrowany plik DEX. Moduł ładujący weryfikował nazwę pakietu i MCC urządzenia, odpytywał niewielki serwer reguł, odszyfrowywał drugi plik DEX odpowiedzialny za wybór payloadu i pobierał końcowy payload z usługi Alibaba Cloud Object Storage Service (OSS). Cool Wallpaper realizował część tego łańcucha w kodzie natywnym. Max Messenger używał zaszyfrowanego mechanizmu kontroli kraju napisanego w Javie, ale przenosił kolejny etap wyboru ścieżki do kodu ARM64.

Późniejsze wersje zachowały pierwszą warstwę aplikacji, ukryte komponenty aplikacji bazowej i zdalny mechanizm aktywacji, ale różniły się sposobem przekazania sterowania do ostatniego etapu. Text Messages, Short Messages, Seed Text Messages i Instant Messages przekazywały zweryfikowaną lub przekształconą odpowiedź serwera do biblioteki natywnej. Quick Chat Message odszyfrowywał odpowiedź serwera i ładował ją bezpośrednio dzięki InMemoryDexClassLoader. Sześć aplikacji odzyskanych podczas analizy stosowało te same dwa rozwiązania. PDF Scanner Pro, Text Magic Messages, Go Cleaner Pro i Text Message Pro przekazywały zweryfikowane odpowiedzi z regułami do kodu natywnego. Quick Message Pro i Lite PDF Scanner odtwarzały uwierzytelnione kontenery DEX i ładowały je z pamięci. Wstrzyknięte wywołania startowe i ukryte komponenty odpowiadały operacji, choć nie odzyskaliśmy końcowych modułów realizujących oszustwo.

Historyczne dane WHOIS pokazują, iż wszystkie 20 domen nadrzędnych zarejestrowano za pośrednictwem Amazon Registrar między 10 lipca a 17 września 2026 roku. Pasywne dane DNS powiązały 16 pierwotnych hostów api z odrębnymi balancerami Aliyun w regionie US East. Dwie wcześniejsze pary domen zarejestrowano w odstępach odpowiednio 29 i 38 sekund, co jest zgodne z automatycznym procesem rejestracji domen. Cztery nowe domeny nadrzędne używały tego samego szablonu serwerów nazw AWS co 16 pierwotnych domen, a ich hosty api wskazywały na pary adresów Alibaba. Osiem odzyskanych obiektów OSS miało wspólny prefiks aqmu oraz identyfikatory od 2115 do 2155.

Cztery nowo odzyskane domeny nadrzędne miały dokładnie te same historyczne skróty wartości pól WHOIS dotyczących organizacji rejestrującego, numeru telefonu i adresu co piaagt.click, tehsnb.link i hsbdbv.link. Jest to bardziej szczegółowe powiązanie niż korzystanie z tego samego rejestratora lub dostawcy chmury. PDF Scanner Pro zapewnił kolejny bezpośredni łącznik: jego podstawowy adres API korzystał z hosta api.piaagt.click, który występował już w Colorful Message i Short Messages, choć każda wersja używała innej ścieżki, znacznika i biblioteki natywnej. Dane rejestracyjne, struktura DNS, nazewnictwo obiektów i konstrukcja kodu łącznie przemawiają za wspólnym przygotowaniem infrastruktury.

Phone Cleaner Master pozwolił na najdokładniejsze porównanie późniejszej wersji z punktem odniesienia Messenger Pro. 16 września jego serwer reguł zwrócił:

Znacznik aktywował wbudowany etap wyboru ścieżki, a sufiks wskazywał MCC 260, 621 i 232 dla gałęzi AqMu. Polskie urządzenia pobierały zatem aqmu2150 i ładowały com.dzyna.mytsx.AqMu.land(). Powstały plik DEX zawierał 112 klas, tyle samo co payload AqMu odzyskany z Messenger Pro, i miał taki sam rozkład rozmiarów pakietów.

Obie wersje AqMu miały odrębne konfiguracje C2. Wersja z Messenger Pro używała 47.84.194.202/asnvoycs z hasłem u18r3ze2, a wersja z Phone Cleaner Master używała 47.84.193.174/j26j8vf7 z hasłem trd6rgu5. Obie zachowywały adres zapasowy 129.226.172.250, adres raportowania zdarzeń api.appbhwljk.com/api/v3/wkev i ten sam osadzony token zdarzeń. Zgodność kodu i konfiguracji wiąże payloady mocniej niż samo korzystanie ze wspólnego hostingu chmurowego.

Messenger Pro był punktem wyjścia do analizy infrastruktury sieciowej. Jego końcowy payload komunikował się z 47.84.77.127 przez nieszyfrowany protokół HTTP. Zbadaliśmy historię usług obserwowanych na tym adresie IP, szukając identyfikatorów wspólnych z adresami odzyskanymi z powiązanych wersji. VirusTotal zarejestrował na porcie 443 usługę TLS, która 10 września 2026 roku prezentowała wygasły certyfikat Let's Encrypt wystawiony dla ablefee.wiki:

Ta obserwacja TLS spowodowała, iż włączyliśmy ablefee.wiki do analizy. Domena nie występuje w kodzie Messenger Pro ani jego żądaniach sieciowych, a pasywne dane DNS nie łączą jej z 47.84.77.127. Istotny jest skrót SHA-256 certyfikatu, który VirusTotal zaobserwował także na pięciu adresach IP odzyskanych niezależnie z powiązanych próbek modułu ładującego:

Ten sam wygasły certyfikat prezentowało zatem sześć niezależnie powiązanych serwerów. Użycie identycznego certyfikatu podczas negocjacji TLS zwykle wymaga dostępu do odpowiadającego mu klucza prywatnego, dlatego jego ponowne wykorzystanie przemawia za wspólnym zarządzaniem infrastrukturą.

Ocena zebranych dowodów

Zebrane dowody łączą 17 aplikacji z Google Play i 852 reklamy Meta ze skoordynowaną operacją toll fraud wymierzoną w polskich użytkowników Androida. W sześciu aplikacjach odzyskaliśmy komponenty toll fraud albo bezpośrednie powiązania z payloadami. Jedenaście kolejnych zawierało powiązane złośliwe moduły ładujące, choć nie udało się odzyskać ich końcowych modułów realizujących oszustwo. Ponowne użycie materiałów reklamowych łączy profile Meta ze stronami Google Play, natomiast konstrukcja modułu ładującego, ukryte komponenty aplikacji bazowych, dane WHOIS, nazwy obiektów OSS i wzorce rejestracji domen łączą przeanalizowane wersje. C2 aplikacji Messenger Pro przekazał aktywne zadania dotyczące wiadomości SMS Premium i cyklicznych płatności przez operatora, a późniejsze reguły Phone Cleaner Master zawierały polski MCC 260 w gałęzi AqMu. Ponowne użycie certyfikatu jest dodatkowym powiązaniem infrastruktury, ale nie dowodzi, iż wszystkie historyczne serwery kontrolował ten sam podmiot. Nie przypisujemy więc operatorowi żadnej tożsamości, narodowości ani lokalizacji.

Analiza techniczna

Pełny łańcuch wykonania odtworzyliśmy dzięki analizy statycznej, badania ruchu sieciowego i kontrolowanego uruchomienia na urządzeniu z systemem Android 15, skonfigurowanym z profilem polskiego operatora komórkowego. Wyniki analizy statycznej porównaliśmy z odszyfrowaną komunikacją z C2, logami aplikacji i aktywnością WebView. W tym artykule określenie zaobserwowane oznacza zachowanie zarejestrowane podczas działania aplikacji. Funkcjonalność oznacza natomiast zaimplementowany kod, który nie został aktywowany w naszych testach.

Jeśli nie zaznaczono inaczej, poniższy opis wykonania dotyczy wybranej aplikacji kampanii, czyli Messenger Pro. Powiązane próbki zachowywały ten sam ogólny model dostarczania kodu, ale różniły się widoczną warstwą aplikacji, znacznikami reguł, implementacją wyboru ścieżki, obiektami z payloadami i konfiguracją C2.

Widoczna aplikacja i uprawnienia do SMS

Messenger Pro nie była pustą atrapą. W środowisku testowym aplikacja przechodziła konfigurację i wyświetlała działającą skrzynkę odbiorczą z kategoriami wiadomości, prywatnymi rozmowami, blokowaniem spamu i archiwum. Na ekranie uprawnień widniał komunikat: Your privacy comes first. No unnecessary permissions.

Po wybraniu jej jako domyślnej aplikacji do obsługi wiadomości SMS w zwykłym interfejsie Androida system przyznał uprawnienia READ_SMS, RECEIVE_SMS, RECEIVE_MMS i SEND_SMS z flagą GRANTED_BY_ROLE. Przyznano również dostęp do stanu telefonu, połączeń, kontaktów i publikowania powiadomień. Osobno zezwoliliśmy na wyświetlanie nad innymi aplikacjami.

To najważniejszy element kamuflażu uprawnień. Google Play zezwala aplikacji pełniącej rolę domyślnej aplikacji do obsługi SMS na żądanie ograniczonych uprawnień do wiadomości SMS, z zastrzeżeniem weryfikacji. Widoczna część aplikacji używa ich do obsługi wiadomości, a pobrany kod wykorzystuje te same uprawnienia do nadużyć związanych z płatnościami.

Operacja nie wymagała, by widoczna warstwa każdej aplikacji żądała takich samych uprawnień. Phone Cleaner Master udawał narzędzie użytkowe i nie żądał READ_SMS, RECEIVE_SMS ani SEND_SMS. Pobrany payload AqMu przez cały czas zawierał ogólną procedurę obsługi wiadomości SMS, ale aplikacja bez tych uprawnień zwykle nie mogłaby ich wysyłać. przez cały czas dostępne były płatności w przeglądarce, wiązanie procesu z siecią komórkową i funkcje obsługi powiadomień. Wiadomości SMS Premium i Direct Carrier Billing stanowią odrębne ścieżki toll fraud. Pierwsza polega na wysłaniu słowa kluczowego na numer skrócony i wymaga SEND_SMS. Druga otwiera stronę płatności w ukrytym WebView i obciąża użytkownika na podstawie identyfikacji abonenta przez sieć komórkową, bez konieczności samodzielnego wysłania wiadomości SMS przez aplikację. Komunikatory mogły korzystać z obu ścieżek, natomiast narzędzie użytkowe było ograniczone do płatności przez operatora. Pokazuje to, iż operator kampanii mógł ponownie wykorzystywać ten sam szkielet payloadu, aktywując wyłącznie funkcje obsługiwane przez widoczną warstwę danej aplikacji.

Google Play dostarczał Messenger Pro jako instalację split APK, składającą się z bazowego APK i wymaganego pakietu konfiguracyjnego ARM64. W wyniku analizy odzyskaliśmy mechanizm kontroli kraju, mechanizm wyboru payloadu i dwa alternatywne payloady, wszystkie w postaci plików DEX. Każda ścieżka wykonania korzystała z czterech warstw: bazowego APK, mechanizmu kontroli kraju, mechanizmu wyboru payloadu i jednego wybranego payloadu.

Bazowy APK pełnił funkcję modułu ładującego i zawierał zaszyfrowany etap 1. Po odszyfrowaniu etap 1 sprawdzał nazwę pakietu i MCC karty SIM, po czym pobierał zdalny znacznik aktywujący odszyfrowanie osadzonego w nim kolejnego etapu, który stosował zdalne reguły wyboru kraju i pobierał odpowiedni payload. W tej wersji Messenger Pro polski MCC 260 trafiał do domyślnej gałęzi. Poniższy diagram przedstawia cały przepływ wykonania.

Rysunek 2. Przepływ wykonania Messenger Pro. Kolorem czerwonym oznaczono ścieżkę wybraną dla polskiego MCC 260 przez reguły zaobserwowane 15 września 2026 roku.

Bazowy APK zawierał 39 990 208 bajtów kodu DEX w dziewięciu plikach. Moduł ładujący i zaszyfrowany etap 1 znajdowały się w classes9.dex, który stanowił 0,552% łącznej wielkości. Jedno wstrzyknięte wywołanie ukryto w dużej metodzie Application.onCreate(), a nagłówek pierwszego pliku DEX zapisano jako tablice liczb całkowitych.

Nie możemy ustalić, co wykazała wewnętrzna weryfikacja Google ani czy wcześniejsze wydanie aplikacji było niezłośliwe. Odzyskaliśmy wyłącznie wersję 9.0. Dokumentacja Androida wskazuje, iż wiele form zdalnego, dynamicznego ładowania kodu narusza zasady Google Play. Moduł ładujący odtwarzał etap 1 jako tablicę bajtów i ładował go dzięki InMemoryDexClassLoader. Etap 1 w ten sam sposób odszyfrowywał etap 2, który pobierał końcowy plik DEX z magazynu obiektowego. Etap 1, etap 2 i końcowy DEX były uruchamiane dzięki InMemoryDexClassLoader.

Łańcuch wykonania

Bazowy APK: ukryty moduł ładujący

Uruchomienie nie wymagało otwarcia aplikacji przez użytkownika. Package Manager zarejestrował instalację o 12:54:02. O 12:54:03 proces kontaktów Android wysłał żądanie do eksportowanego dostawcy treści Bluetooth Message Access Profile (MAP) aplikacji, który deklarował możliwość synchronizacji. ActivityManager uruchomił proces aplikacji, aby obsłużyć to żądanie:

Sam dostawca treści nie realizował faktycznej synchronizacji. Istotne jest to, iż żądanie uruchomiło proces aplikacji bez otwierania interfejsu. Android inicjalizuje dostawców treści przed Application.onCreate(). Wykonanie dotarło następnie do MyApplication.onCreate(), gdzie pojedyncze wstrzyknięte wywołanie uruchamiało moduł ładujący przed zwykłą inicjalizacją komunikatora. Kod ograniczony do istotnych instrukcji wygląda następująco:

Manifest deklaruje również komponenty aplikacji bazowej używane przez późniejsze etapy: wyłączony alias launchera, usługę zadań WorkJobService, przezroczystą aktywność z etykietą 6002 oraz usługę nasłuchującą powiadomień.

Moduł ładujący buduje tablicę 80 433 bajtów dzięki 73 wygenerowanych metod. Po jej odtworzeniu otrzymaliśmy następujący uwierzytelniony kontener:

Klucz główny jest odtwarzany z tablic liczb całkowitych. Niestandardowa procedura wyprowadza dwa klucze SHA-256, weryfikuje HMAC, a następnie wykonuje XOR każdego bloku szyfrogramu ze strumieniem SHA-256:

Zweryfikowany tekst jawny zaczynał się od dex\n038\0, co potwierdza, iż odszyfrowano poprawny plik DEX. Wartość 038 oznacza tutaj wersję formatu DEX, nie wersję aplikacji ani złośliwego oprogramowania. Moduł ładujący przekazał odzyskane bajty etapu 1 bezpośrednio do InMemoryDexClassLoader:

Wywołanie refleksyjne Gate.a(context) kończy działanie modułu ładującego w bazowym APK i rozpoczyna etap 1.

Etap 1: kontrola pakietu i kraju

Etap 1 włącza alias launchera, weryfikuje nazwę pakietu i kontynuuje działanie tylko dla dozwolonego MCC karty SIM. Przepływ sterowania, z ujednoliconymi nazwami, wygląda następująco:

Odkodowana lista obejmuje Tajlandię, Indonezję, Malezję, Turcję, Arabię Saudyjską, Zjednoczone Emiraty Arabskie, Polskę, Austrię, Grecję, Niemcy, Nigerię, Francję, Rumunię, Szwajcarię i Chiny:

Środowisko testowe początkowo zgłaszało domyślny MCC 310, którego nie ma na liście. Użyliśmy tej konfiguracji do potwierdzenia ścieżki odrzucenia, choć etap 1 zdążył już włączyć alias launchera, zanim pojawił się pierwszy ekran. Następnie skonfigurowaliśmy środowisko testowe tak, aby zgłaszało MCC karty SIM 260, i przeszliśmy ścieżkę przeznaczoną dla polskich urządzeń. Etap 1 zaakceptował tę wartość i wysłał żądanie do stałego adresu reguł hxxps://api.tehsnb[.]link/sabd/mckd. 15 września 2026 roku serwer zwrócił następującą wspólną odpowiedź sterującą aktywacją i wyborem ścieżki:

Odpowiedź nie klasyfikowała urządzenia testowego jako francuskiego. Był to wspólny zestaw reguł i nie zawierał kodu wykonywalnego ani klucza deszyfrującego. Znacznik cbhedbgegevdd nakazywał etapowi 1 kontynuować. Sufiks _GUOJIA=460_FR208 wymieniał wartości MCC przypisane do gałęzi przeznaczonej dla wybranych krajów: 460 dla Chin i 208 dla Francji. Nie było w nim polskiego MCC 260, dlatego etap 2 wybrał gałąź domyślną. Etap 1 zawierał już zaszyfrowany kontener etapu 2 i drugi klucz główny zapisany na stałe. Po znalezieniu znacznika weryfikował HMAC kontenera, odszyfrowywał plik DEX o rozmiarze 21 860 bajtów dzięki tej samej konstrukcji opartej na SHA-256 i ładował go przez InMemoryDexClassLoader.

Następnie etap 1 wywoływał paint.august.Osmanthus.flower(policyBody), przekazując całą odpowiedź HTTP jako ciąg znaków. To wywołanie kończy etap 1 i rozpoczyna etap 2.

Znacznik i wartości reguł były charakterystyczne dla tej wersji. Phone Cleaner Master używał znacznika poirjfirenhrhfg i tej samej konwencji _GUOJIA. Jego odpowiedź wybierała PL260, NG621 i AT232, a następnie aktywowała DEX wyboru ścieżki o rozmiarze 39 264 bajtów, który był już zaszyfrowany w etapie 1. W obu aplikacjach odpowiedź serwera zezwalała na kontynuację i przekazywała reguły wyboru kraju, natomiast zaszyfrowany plik wykonywalny i klucz deszyfrujący były już zapisane lokalnie.

Etap 2: wybór i pobranie payloadu

Etap 2 otrzymuje pełną odpowiedź z regułami w funkcji Osmanthus.flower(). Wyodrębnia tekst po _GUOJIA=, odczytuje pierwsze trzy cyfry operatora karty SIM i wybiera jeden z dwóch payloadów przechowywanych zdalnie. Istotna logika wyboru, z ujednoliconymi nazwami, wygląda następująco:

Każda konfiguracja zawiera adres URL payloadu, nazwę pliku w pamięci podręcznej, prefiks telemetrii, klasę i metodę wejściową oraz flagę gałęzi. Argument 47.84.77.127 staje się adresem C2 tylko dla domyślnego payloadu. W gałęzi przeznaczonej dla wybranych państw etap 2 zastępuje dwa argumenty wejściowe nazwami LpMsdqActivity i NotificationTool. Ten payload zawiera własny adres C2, 47.84.194.202.

Wewnętrzna diagnostyka nazywa te ścieżki new i old, ale etykiety te nie opisują ich stanu operacyjnego. Używamy określeń dla wybranych krajów i domyślna, zgodnie z logiką ich wyboru.

Domyślny payload Messenger Pro nie był przeznaczony wyłącznie dla Polski. Etap 2 wybierał go dla wszystkich dozwolonego MCC z wyjątkiem 208 i 460. Podczas rejestracji w C2 payload zgłaszał pełną wartość MCC/MNC, dzięki czemu serwer mógł przydzielać zadania adekwatne dla kraju lub operatora. W naszym kontrolowanym uruchomieniu MCC/MNC 26001 został sklasyfikowany jako PL i otrzymał polskie zadania dotyczące wiadomości SMS Premium oraz płatności przez operatora.

Decyzja o wyborze ścieżki nie była stała w całej operacji. Aktywne reguły Phone Cleaner Master zawierały PL260, dlatego ten sam MCC wybierał gałąź AqMu. Ta wersja pobierała aqmu2150, wywoływała com.dzyna.mytsx.AqMu.land() i używała 47.84.193.174/j26j8vf7 jako podstawowego adresu C2. Porównanie pokazuje, iż określenia „domyślna” i „dla wybranych krajów” opisują decyzję w obrębie jednej wersji, a nie stałe przypisanie krajów.

Przed pobraniem wybranego payloadu etap 2 rejestruje trwałe zadanie w JobScheduler dla WorkJobService, inicjalizuje AppsFlyer i odczytuje dane o źródle instalacji z Google Play. Uruchamia też przezroczystą aktywność LpMsdqActivity dzięki pośredniego łańcucha uruchamiania aktywności. W Androidzie 10 i nowszych umieszcza intencję aktywności w PendingIntent typu broadcast, ustawia tę intencję jako odbiorcę przycisku multimedialnego tymczasowej sesji MediaSession i wysyła zdarzenie przycisku multimedialnego. Zarejestrowany odbiorca wyodrębnia pierwotną intencję i uruchamia aktywność. Towarzyszące temu wirtualny ekran i Presentation należą do mechanizmu uruchamiania, nie do WebView obsługującego płatność.

Wybrany obiekt ma postać tekstu zakodowanego Base64. Po zdekodowaniu otrzymujemy dane skompresowane gzipem, a po dekompresji końcowy DEX. Dla domyślnego obiektu wybranego podczas polskiego uruchomienia:

Etap 2 zapisuje zakodowaną treść HTTP jako oyoangon dla ścieżki domyślnej albo dewqq_rsp dla ścieżki przeznaczonej dla wybranych państw w prywatnym katalogu plików aplikacji. Przy kolejnych uruchomieniach może użyć tej kopii z pamięci podręcznej zamiast ponownie pobierać obiekt. Następnie etap 2 dekoduje, dekompresuje i ładuje końcowy DEX dzięki kolejnego InMemoryDexClassLoader:

Dla polskiego MCC 260 etap 2 wywołał com.jk.MainEntry.init("47.84.77.127", installReferrer). Argumentami są adres C2 domyślnego payloadu i dane o źródle instalacji z Google Play. Wywołanie kończy etap 2 i rozpoczyna działanie domyślnego payloadu.

Dostępne były oba obiekty z payloadami:

Znaczniki czasu odnoszą się do zapisanych plików, nie do stanu operacyjnego ścieżek. Oba obiekty przez cały czas były dostępne, a domyślny C2 przydzielał podczas analizy aktualne zadania dla Polski.

Domyślny payload Messenger Pro: zachowanie zaobserwowane dla Polski

Domyślny payload przeszukuje manifest aplikacji bazowej w poszukiwaniu komponentu Activity z etykietą składającą się wyłącznie z cyfr. W tej próbce etykieta 6002 wskazuje LpMsdqActivity, który etap 2 otworzył już dzięki opisanego wcześniej mechanizmu uruchamiania. Podczas kontrolowanego wykonania z profilem polskiego operatora komponent wyświetlał formularz Register, używany później do zebrania polskiego numeru telefonu.

Protokół i kryptografia C2

com.jk.MainEntry.init(host, referrer) otrzymuje adres C2 47.84.77.127. Domyślny payload buduje na jego podstawie adresy URL korzystające z nieszyfrowanego protokołu HTTP. Podczas inicjalizacji zastępuje też domyślny menedżer zaufania całego procesu oraz mechanizm weryfikacji nazw hostów używany przez HttpsURLConnection. Nowe implementacje akceptują każdy certyfikat i każdą nazwę hosta. Osłabia to weryfikację żądań HTTPS wykonywanych przez kod Javy w procesie aplikacji, ale nie zmienia konfiguracji stosu TLS Chromium używanego przez WebView.

Przy pierwszym załadowaniu klasa protokołu generuje sześć pozornie losowych ścieżek, po jednej dla każdej operacji. Dla operacji i wybiera losową liczbę całkowitą r od 0 do 998 i oblicza:

Przed każdą cyfrą dziesiętną n albo po niej umieszcza losową literę ASCII, a następnie dodaje litery, aż ścieżka ma co najmniej osiem znaków. Usunięcie liter i obliczenie reszty z dzielenia pozostałej liczby całkowitej przez 31 pozwala odzyskać numer operacji:

Każda operacja używa tej samej wygenerowanej ścieżki przez cały czas życia procesu. Nowy proces generuje inny zestaw. Mechanizm zaciemnia znaczenie operacji i adresu, ale nie zapewnia istotnej ochrony.

Na poziomie aplikacji treści żądań i odpowiedzi, po usunięciu kodowania warstwy HTTP, stanowią surowy szyfrogram AES. Zarejestrowane odpowiedzi dodatkowo używały podczas transmisji Content-Encoding: gzip. Po zdekompresowaniu treści HTTP payload odszyfrowywał otrzymany szyfrogram. Materiałem do wyprowadzenia klucza jest pełny adres URL, łącznie z parametrami zapytania używanymi przez operację 5:

Pierwsze 16 znaków szesnastkowych ASCII tworzy klucz o długości 16 bajtów. Nie są one dekodowane do ośmiu bajtów. Wektor IV jest równy kluczowi. Ponieważ adres URL jest przesyłany przez sieć jawnym tekstem i jednoznacznie wyznacza obie wartości, szyfrowanie ukrywa ruch, ale nie zapewnia tajnego klucza ani uwierzytelniania wiadomości.

Rysunek 3. Sposób szyfrowania ruchu C2 przez Messenger Pro.

Podczas kontrolowanego wykonania aplikacja wygenerowała ścieżkę /A2W80jUc. Jej cyfry tworzą 280, a 280 mod 31 = 1, co wskazuje żądanie rejestracyjne. Zarejestrowany URL i wyprowadzony klucz to:

Po odszyfrowaniu treści żądania o rozmiarze 176 bajtów otrzymaliśmy:

Pola zawierają nazwę pakietu, MCC/MNC, czas instalacji w milisekundach czasu uniksowego, poziom SDK Androida, stały znacznik payloadu, markę urządzenia i dane o źródle instalacji z Google Play. Serwer zwrócił treść skompresowaną gzipem o rozmiarze 103 bajtów. Dekompresja treści HTTP dała 80 bajtów szyfrogramu AES. Po odszyfrowaniu otrzymaliśmy 64-bajtowy dokument JSON:

Serwer C2 przypisał urządzeniu zdalny identyfikator 60727718 i kod kraju PL. Zarejestrowaną wymianę przedstawia rysunek 3.

Aby zaobserwować przydzielanie zadań urządzeniu zgłaszającemu połączenie komórkowe oraz możliwość odbierania i wysyłania wiadomości SMS, zarejestrowaliśmy odrębny kontrolowany profil. Serwer C2 przypisał mu zdalny identyfikator 60723698. Odpytanie operacji 2 korzystało z innego adresu URL, a więc także z innego klucza:

Odszyfrowane żądanie:

Operacja 2 nie jest jedynie sygnałem podtrzymania połączenia. Informuje serwer C2, które ścieżki oszustwa obsługuje urządzenie. eymbmw zgłasza łączność komórkową, rktfht możliwość odbierania wiadomości SMS, a segdip możliwość ich wysyłania. Dzięki tym wartościom serwer może rozróżnić urządzenia zdolne do otwierania stron płatności przez operatora, przechwytywania wiadomości weryfikacyjnych lub wysyłania wiadomości SMS Premium. Odpowiedź o rozmiarze 6 928 bajtów szyfrogramu po odszyfrowaniu zawierała następujący pakiet zadań:

Odpowiedź ponownie wykorzystywała część nazw pól w innym znaczeniu. W żądaniu eymbmw zgłaszało dostępność połączenia komórkowego. W zwróconym zadaniu eymbmw: true wymagało, aby payload uzyskał takie połączenie i powiązał z nim proces. Niepowodzenie kończyło zadanie kodem 203. Podobnie podczas rejestracji hyszxc zawierało kod kraju PL, ale hyszxc: true w zadaniu wybierało tryb, w którym payload pobierał zawartość strony klientem HTTP działającym po stronie aplikacji, a następnie ładował ją do WebView.

lybfta zawierało zadanie przeglądarkowe. Choć miało postać tablicy, payload odczytywał tylko pierwszy element. ejqgpk było identyfikatorem zadania 863176325, który klient umieszczał później w wyniku. gooycf zawierało początkowy afiliacyjny adres URL. gkreil składało się z siedmiu reguł dopasowania adresów i odpowiadających im fragmentów JavaScript. Pozwalało to C2 sterować zachowaniem payloadu po kolejnych przekierowaniach do różnych stron płatności. inbzrz wybierało tryb wykonania 200. Wartości 300 i większe włączały dodatkowe mechanizmy śledzenia i rejestrowania stron.

Nadrzędny obiekt jxdkqb był przetwarzany niezależnie, przed zadaniem przeglądarkowym. Wartość segdip miała format destination---body i nakazywała mechanizmowi korzystającemu z systemowego API SMS wysłać rch59419069 na +447752070662. W innym miejscu payloadu wiadomość przychodząca zaczynająca się od rch wywołuje żądanie do /op/pair zawierające sufiks i numer telefonu nadawcy. Oba zachowania są zgodne z mechanizmem parowania numeru telefonu. Zaobserwowaliśmy polecenie wysłania wiadomości, ale nie obsługę po stronie odbiorczej, dlatego dokładna rola brytyjskiego numeru pozostaje niepotwierdzona.

Zdalne zadania i interfejs WebView

Pokazana wyżej odszyfrowana odpowiedź operacji 2 zawierała zadanie przeglądarkowe w lybfta. Tablicę gkreil zastąpiono w przykładzie tekstem <7 rule objects omitted>. Po jej rozwinięciu znaleźliśmy siedem reguł przekazanych przez C2. Każda łączyła wyrażenie URL z kodem JavaScript, który payload wykonywał, gdy WebView docierał do pasującej strony. Sprawdziliśmy pełny zestaw reguł bez otwierania przydzielonego początkowego adresu URL:

Kod 905 jest wynikiem końcowym przypisywanym przez C2 ścieżkom, których nie można było kontynuować, na przykład z powodu niedostępnej usługi, niepożądanego przekierowania afiliacyjnego lub zablokowanej domeny. Payload natychmiast kończył takie zadanie bez dalszej interakcji ze stroną.

Zadanie wymagało łączności komórkowej i zaczynało się od hxxps://nmx4e6qj[.]com/bV1p5aXg?campaign=10375&sub_aff=5063176325&sub_aff3=EZ. Główne gałęzie reguły Teleaudio, z ujednoliconymi nazwami zmiennych, pokazano poniżej. Pominięto logowanie, obsługę błędów i funkcję pomocniczą opóźnionego ponowienia:

C2 przekazywał NNNNBBBB jako symbol zastępczy numeru telefonu powiązanego dzięki operacji 4. W naszych zadaniach symbol nie został zastąpiony numerem, ponieważ nie podaliśmy użytecznej wartości. Pominięta funkcja nextThings() planuje zwrot wyniku 302 po 20 sekundach i ponawia próbę pobrania kodu PIN. Reguła służy więc do automatycznego wpisania numeru, wyodrębnienia kodu PIN, zaznaczenia zgody i wysłania formularza. Jej wyrażenie regularne jawnie rozpoznaje polskie słowo kod.

Skrypty C2 używają stałego wyrażenia window.JBridge.call(...), ale uruchomiony WebView udostępnia obiekt pod inną nazwą. Niestandardowy WebView tworzy losową czteroznakową nazwę zakończoną _. W poniższym kodzie ujednolicono nazwy zmiennych, ale ciągi zastępujące i nazwa metody moixxt są dokładne:

C2 może zatem używać stałej składni JBridge.call, a każda instancja WebView udostępnia interfejs do kodu aplikacji pod inną nazwą.

Dwa argumenty moixxt to polecenie i jego wartość. Przed wywołaniem implementacji po stronie aplikacji dyspozytor zapisuje każde wywołanie jako js-><command>:<value>:

headers, data, url, mainFrame, b64 i finalUrl są polami przyjmowanymi przez polecenie request, a nie odrębnymi poleceniami interfejsu. Rozróżnienie to widać w parserze JSON po stronie aplikacji.

WebView zadania włącza JavaScript i DOM Storage, zezwala na mieszaną zawartość oraz automatyczne otwieranie okien przez JavaScript. Reguły typu 100, w tym siedem opisanych wyżej, wykonują JavaScript, gdy adres głównej strony pasuje do wzorca. Reguły typu 300 przechwytują pasujące żądania zasobów, pobierają ich zawartość klientem HTTP działającym po stronie aplikacji, stosują zamiany przekazane przez C2 i zwracają zmodyfikowaną odpowiedź do Chromium. Jedna z opcji zadania może też blokować żądania do notify.clfldcbprotect.com, notify.dcbprotect.com i notify.eyewitness.evina.com. Żadne z badanych polskich zadań nie włączyło tej opcji, a podczas uruchomienia All4You przez cały czas widzieliśmy ruch powiadomień mechanizmu ochrony przed oszustwami. Modyfikowanie odpowiedzi i blokowanie żądań pozostają zatem zaimplementowanymi funkcjami, których nie zaobserwowaliśmy podczas działania aplikacji.

Pojedyncza odpowiedź nie pokazuje pełnego zakresu zadań. Dlatego z jednego kontrolowanego profilu PL odpytaliśmy operację 2 50 razy, nie otwierając zwróconych adresów URL. Serwer przekazał 41 unikalnych zadań, po których nastąpiło dziewięć pustych odpowiedzi. Zadania zawierały 324 wystąpienia reguł, 119 unikalnych wyrażeń URL i 75 unikalnych fragmentów JavaScript. Początkowe adresy URL odwoływały się do kampanii 10371, 10372, 10374 i 10375. Reguły obejmowały procesy Teleaudio i Dimoco, bezpośrednie wiadomości SMS Premium, formularze numeru telefonu i PIN, komunikaty powodzenia oraz obsługę błędów. Wielokrotne odpytywanie nie dostarczyło informacji o innych urządzeniach ani instalacjach i nie może służyć jako miara liczby ofiar.

Porównaliśmy również flagi możliwości urządzenia przesyłane w operacji 2:

Flagi stanowią dane wejściowe dla reguł przydzielania zadań. Dzięki nim jeden payload może obsługiwać zarówno płatności przeglądarkowe, jak i wiadomości SMS Premium, a serwer nie przydziela urządzeniu zadań, których nie może ono wykonać.

Zbieranie numeru i wysyłanie wiadomości SMS Premium

Podczas jednego kontrolowanego uruchomienia payload zarejestrował MCC/MNC 26001, otrzymał kod kraju PL i zadanie 864515147. Zadanie prowadziło przez następujący łańcuch:

Reguła z C2 przekazała do SmsManager obie formy numeru skróconego. Wywołania zostały przechwycone w środowisku analitycznym i nie dotarły do sieci komórkowej:

Złośliwe oprogramowanie wysłało obie wersje natychmiast, a po 60 sekundach ponowiło próbę. Do kolejki zadania nie trafiła żadna odpowiedź, dlatego operacja 3 zwróciła wynik 305, a operacja 5 przesłała ślad obejmujący przekierowanie, polecenia interfejsu i czasy. Kolejne zadania próbowały wysłać LOOVAPLAY F4J na ten sam numer skrócony.

Rysunek 4 łączy zapis ruchu w formacie PCAP, odszyfrowane treści, przesłany ślad i przechwycone wywołania SMS. Nieciągła skala czasu pozwala pokazać zarówno szybkie wymiany z C2, jak i 60 sekund oczekiwania na odpowiedź.

Rysunek 4. Zaobserwowana sekwencja komunikacji C2, WebView i wiadomości SMS Premium dla zadania 864515147.

Odpowiedź rejestracyjna C2 zapisała hyszxc: "PL" w globalnym polu kraju. Gdy aplikacja bazowa miała już uprawnienie RECEIVE_SMS, payload otworzył DialogFragment, którego nie można zamknąć. Cały ekran został utworzony w Javie, a reguły walidacji pobrano z tabeli krajów.

Dla Polski okno wyświetla prefiks +48 i przyjmuje dowolne dziewięć cyfr bez sprawdzania, czy numer jest przydzielony. choćby celowo niemożliwa wartość 000000000 aktywowała więc przycisk.

Odszyfrowanie ruchu zapisanego w formacie PCAP pozwoliło odtworzyć dokładną wymianę:

Okno zostało następnie zamknięte, ale późniejsze zadania przez cały czas zawierały NNNNBBBB. Zarejestrowana wymiana nie pokazuje więc, iż serwer C2 zaakceptował niemożliwą wartość jako dane abonenta.

Po lewej stronie widać formularz złośliwego systemu z prefiksem +48. Zrzut ekranu po prawej pochodzi z wcześniejszego uruchomienia i pokazuje, iż Android rozpoznał rzeczywiste ryzyko: Messenger Pro próbował wysłać wiadomość na 92505, co mogło spowodować naliczenie opłaty.

Podczas późniejszego uruchomienia trwającego 240 sekund zarejestrowaliśmy trzy pełne polskie zadania dotyczące wiadomości SMS Premium. Trzecie z nich, o identyfikatorze 865090137, prowadziło w ramach kampanii 10372 przez łańcuch afiliacyjny do aktywnej strony All4You. Jej DOM wskazywał Polskę, numer skrócony 92513, widoczne słowo najważniejsze ALL 64913 i dostawcę RedLeads B.V. Informacje prawne podawały jednorazową opłatę 30,75 zł z VAT za trzy miesiące dostępu.

Aktywna strona zawierała odnośnik SMS:

Pasująca reguła C2 zawierała jedną instrukcję:

Chrome DevTools Protocol zarejestrował następujący przebieg:

Nawigacji nie wywołało dotknięcie ekranu. Po tym, jak zdalna instrukcja kliknęła odnośnik, interfejs JavaScript payloadu zinterpretował URL sms: i wywołał systemowe API SMS dla obu form numeru skróconego:

Nie nadeszła pasująca odpowiedź DA ALL. Po 68 270 ms operacja 3 zwróciła wynik 305, a operacja 5 przesłała ślad zawierający nazwę strony, URI SMS, polecenia interfejsu i wyrażenie używane do wyszukania odpowiedzi. Widoczna skrzynka odbiorcza pozostawała na ekranie, podczas gdy osobny WebView zadania działał dalej w procesie aplikacji.

Obsługa SMS i wybór sieci komórkowej

Domyślny payload rejestruje odbiorcę SMS_RECEIVED, analizuje przychodzące wiadomości i dodaje ich treść do aktywnej kolejki zadania. Polecenie interfejsu popMsg przeszukuje kolejkę wyrażeniem regularnym przekazanym przez C2. Wiadomość zaczynająca się od rch wywołuje również osobne żądanie parowania, które wiąże sufiks i nadawcę z identyfikatorem urządzenia w C2.

Operacja 3 zgłasza identyfikator zadania, kod wyniku, czas wykonania, strony pasujące do reguł oraz opatrzone znacznikami czasu rekordy wiadomości SMS, powiadomień i błędów. Operacja 5 może dodatkowo przesłać ślad tekstowy i zachowany kod HTML. Dzięki tym informacjom serwer C2 może odróżnić brak wiadomości, zmianę selektorów na stronie i odrzucenie transakcji przez dostawcę. Wszystkie kontrolowane uruchomienia zwróciły wyniki oznaczające niepowodzenie.

DEX domyślnego payloadu zawiera też com.jk.NoteListener, który może wyodrębniać tekst powiadomień i wywoływać cancelAllNotifications(). Klasa nie występuje w zewnętrznym manifeście, a w DEX payloadu nie ma innych odwołań do niej. Manifest deklaruje tylko niepowiązaną, pustą usługę powiadomień. Nie przyznaliśmy dostępu do nasłuchiwania powiadomień, dlatego funkcja ta nie została aktywowana. Payload dla wybranych państw ma bardziej bezpośrednią ścieżkę wstrzykiwania opisaną dalej.

Payload żąda zestawienia połączenia z TRANSPORT_CELLULAR i NET_CAPABILITY_INTERNET, zapisuje otrzymany obiekt Network i może powiązać z nim proces aplikacji:

Płatności przez operatora często opierają się na identyfikacji abonenta przez sieć komórkową, dlatego jest to podstawowa funkcja, a nie mechanizm awaryjny. Zaobserwowane zadania używały WebView, który nie był osadzony w widocznym komponencie Activity aplikacji Messenger Pro. CDP rejestrował nawigację i JavaScript z C2, gdy na ekranie pozostawała skrzynka odbiorcza. Inne mechanizmy wykonawcze mogą korzystać z wirtualnego ekranu, ale nie zaobserwowaliśmy tego trybu i nie przypisujemy go uruchomieniom All4You ani Teleaudio.

Płatności przez operatora w usłudze Teleaudio

Aktywny C2 przesłał reguły automatyzujące obsługę dcb.teleaudio.pl, ale payload nie polegał wyłącznie na zdalnym kodzie JavaScript. Zawierał też dedykowaną maszynę stanów, aktywowaną, gdy adres URL zadania miał znacznik pl_protocol, a nawigacja zaczynała się od https://epayment.teleaudio.pl/api2/.

Ciągi znaków były chronione dzięki StringFog XOR z powtarzającym się kluczem. Po ich odszyfrowaniu odzyskaliśmy pełną sekwencję żądań przedstawioną poniżej. Symbole zastępcze oznaczają wartości wyodrębnione z pierwotnego adresu URL lub odpowiedzi:

Treść dwóch obiektów JSON można odtworzyć następująco:

Żądanie informacji o transakcji i kolejne wywołania API ustawiają Authorization: Bearer <sid>, a żądania POST dodatkowo Content-Type: application/json. Maszyna stanów zgłasza kod 901, gdy nie może odzyskać MSISDN, 902, gdy odpowiedź z /direct/proceed zawiera ERROR, 305, gdy nie nadejdzie PIN, i 903, gdy na końcowej stronie stanu brakuje tekstu Transakcja zakończona pomyślnie. Tylko odpowiedź zawierająca to zdanie daje kod powodzenia 100.

Logika protokołu zaszyta w kodzie pokazuje, iż obsługa polskich płatności nie zależała wyłącznie od zdalnych reguł. Pobrany DEX zawierał strukturę API dostawcy, pola JSON, obsługę tokena bearer, wzorce polskich wiadomości SMS i tekst powodzenia.

Następnie porównaliśmy maszynę stanów odnalezioną w kodzie z zachowaniem zaobserwowanym podczas działania. Nowa instalacja z wirtualnym połączeniem komórkowym otrzymała zadanie 865195912 dla kampanii 10371. Reguła C2 pasowała do consulate.teleaudio.pl/dcbev/ta2.* i próbowała wyodrębnić numer z #pin-label-id. Numer się nie pojawił, dlatego operacja 4 nie została wywołana. Ślady payloadu i CDP pozwalają odtworzyć ścieżkę:

Końcowa strona Direct Billing AoC zawierała puste pole numeru telefonu, wyłączony przycisk Dalej i następujący polski tekst:

Formularz nigdy nie pojawił się w widocznym komponencie Activity. Podczas rzeczywistego wykonania payload ładował i obsługiwał tę stronę w WebView działającym w tle. Użytkownik jej nie widział, a na ekranie pozostawała skrzynka odbiorcza. Na potrzeby dokumentacji otworzyliśmy zarejestrowany adres URL kampanii w Chrome na urządzeniu testowym, aby pokazać tę samą stronę w zwykłym widoku mobilnym.

Aktywna strona subskrypcji Teleaudio otwarta w Chrome na urządzeniu testowym dzięki zarejestrowanego adresu URL kampanii. Złośliwe oprogramowanie dotarło do tego samego formularza w WebView poza widocznym interfejsem komunikatora.

CDP i operacja 5 zarejestrowały żądanie GET do punktu API sprawdzającego transakcję wifi_nmd. Po 73 641 ms operacja 3 zwróciła wynik 302. Zarówno przejście do strony docelowej, jak i odpytanie o transakcję zaobserwowaliśmy podczas działania aplikacji. Późniejsze żądania kontynuacji, potwierdzenia kodu PIN i sprawdzenia stanu pozostają funkcjami wykrytymi statycznie.

W tym samym procesie ukończono zadania Games2day, Mind+ i Bitegames oraz rozpoczęto zadanie Learn English. Games2day próbował wysłać GRAM 23844 na 92512 i +92512, a niezależne polecenie żądało wysłania rch59424826 na +447752070662. Żadna z tych wiadomości nie dotarła do sieci komórkowej.

Poza zaobserwowanymi zadaniami odkodowane klasy i szablony obsługiwały punkty API tajskich operatorów AIS, DTAC, True i Mobilelife oraz procesy zakupu usług u indonezyjskiego Telkomsel, kenijskiego Safaricom i południowoafrykańskiego MTN Secure-D. Ogólne zadania mogły łączyć żądania HTTP, wyodrębniać wartości i czekać na wiadomości SMS. Integracje z 2Captcha i Anti-Captcha wskazują, iż operator spodziewał się zabezpieczeń przed botami w procesach aktywacji usług. Pomijamy osadzone dane dostępowe do usługi CAPTCHA.

Payload Messenger Pro dla MCC 208 i 460

Podczas naszej obserwacji ta gałąź Messenger Pro nie była wybierana dla Polski, ponieważ reguły wymieniały tylko MCC 208 i 460. Późniejsze reguły Phone Cleaner Master pokazują, iż operator mógł przypisać polskie urządzenia do tej samej rodziny payloadów AqMu w innej wersji aplikacji.

Protokół C2 i przydzielanie zadań

Dla MCC 208 i 460 w zaobserwowanych regułach Messenger Pro etap 2 wybiera inny DEX i protokół C2. Payload używa stałego adresu http://47.84.194.202/asnvoycs, identyfikuje pakiet w każdym żądaniu i przenosi parametry w obiekcie akcji. Ponownie używa AES-CBC z wektorem IV równym kluczowi, ale obie wartości wyprowadza z osadzonego hasła u18r3ze2:

Rozpoznawane akcje obejmują rejestrację rrss, odpytywanie lub wynik zadania dkco oraz akcje raportujące gxns, ykty i hchs. Serwer może odpowiedzieć jawnym tekstem JSON albo szyfrogramem AES.

Ścieżka dla wybranych państw odrzuciła rejestrację zawierającą polski MCC kodem HTTP 500, zgodnie z regułami modułu ładującego. Następnie użyliśmy kontrolowanego profilu francuskiego (20801) i wykonaliśmy jedną rejestrację oraz jedno odpytanie.

W żądaniu rejestracyjnym przesłano identyfikator instalacji, MCC/MNC 20801, identyfikator subskrypcji, wersje Androida i dane o źródle instalacji. W odpowiedzi serwer przypisał identyfikator 245651 i zwrócił stronę docelową dla FR:

W kolejnym żądaniu klient zgłosił dostęp do wiadomości SMS i wybraną subskrypcję. Serwer odpowiedział adresem strony płatności, zdalnym kodem JavaScript i niezależnym poleceniem wysłania wiadomości SMS:

Nie wykonaliśmy żadnej instrukcji. Oba serwery C2 zwróciły numer docelowy SMS +447752070662. Protokoły, adresy IP C2 i treści poleceń różnią się, ale numer jest wspólnym elementem operacyjnym obu gałęzi. W połączeniu ze wspólnym modułem ładującym i regułami wyboru ścieżki stanowi to mocny dowód, iż oba payloady należą do jednej operacji.

DEX AqMu z Phone Cleaner Master jest odrębną, zaciemnioną wersją tego samego szkieletu payloadu dla wybranych krajów. Oba zawierają 112 klas z takim samym rozkładem rozmiarów pakietów i zachowują tę samą konfigurację adresu zapasowego oraz raportowania zdarzeń. Ich podstawowe adresy C2 i hasła różnią się, co wskazuje na konfigurację adekwatną dla danej wersji, a nie jeden wspólny punkt komunikacji. Nie odpytywaliśmy C2 Phone Cleaner Master, dlatego opisane poniżej francuskie zadania są wyłącznie dowodem pochodzącym z serwera AqMu aplikacji Messenger Pro.

Zadanie dla wybranych państw odwoływało się do main.v2.js. Pobraliśmy ten plik jako materiał dowodowy i nie wykonywaliśmy go: 33 663 bajty, 1 045 wierszy, SHA-256 a2f292da1eb6da3bcd1b2bf2340478c2f02a4844bfaa85f00d6e4820bbbe597a.

Skrypt zawiera 43 reguły dyspozytora i jawne procedury obsługi 10 francuskich numerów skróconych SMS Premium:

Jedna funkcja pomocnicza wysyła obie formy numeru skróconego:

Procedury analizują adresy URL sms:, wysyłają ich treść i wywołują popMsg do 12 razy, czekając na OK albo odpowiedź zawierającą od 3 do 6 cyfr. Następnie wysyłają potwierdzenie, na przykład DA, DA KROX, DA GBT, OK albo pierwotną treść. Ogólna procedura awaryjna obsługuje nieznane wcześniej odnośniki sms:. Inne reguły wstawiają MSISDN poprzedzony francuskim kodem kraju, klikają elementy sterujące i zgłaszają aplikacji kod końcowy.

Taki podział funkcji ma praktyczne znaczenie operacyjne. APK zawiera stały zestaw funkcji, a zdalny skrypt można zaktualizować, gdy dostawca usługi zmieni stronę lub składnię wiadomości SMS.

Dodatkowe możliwości payloadu dla wybranych krajów

DEX dla wybranych państw zawiera trzy istotne funkcje, których nie aktywowano podczas naszych testów:

Żadna z aktywnych odpowiedzi nie włączyła tych funkcji, a my nie kontaktowaliśmy się z adresami przekaźnika. Po aktywacji mechanizm mógłby wykorzystać połączenie komórkowe ofiary jako wyjście do internetu, niezależnie od oszustwa subskrypcyjnego.

Podsumowanie

Podczas analizy zabezpieczyliśmy 1235 reklam Meta. Z 17 złośliwymi aplikacjami w Google Play powiązaliśmy 852 reklamy wyświetlane pod 60 zidentyfikowanymi nazwami profili. W sześciu aplikacjach odzyskaliśmy moduły toll fraud albo potwierdziliśmy bezpośrednie powiązania z payloadami. Jedenaście kolejnych zawierało powiązane moduły ładujące, ale nie odzyskaliśmy ich końcowych modułów realizujących oszustwo. Ponowne użycie identycznych obrazów reklamowych łączyło warstwę dystrybucji przez płatne reklamy. O powiązaniu samych aplikacji świadczyły architektura modułu ładującego, infrastruktura reguł, dane WHOIS, obiekty OSS i konfiguracje payloadów.

Analiza Messenger Pro pokazuje, iż dystrybucja przez Google Play nie przesądza o bezpieczeństwie aplikacji. Widoczny komunikator wiarygodnie uzasadniał uprawnienia do wiadomości SMS, natomiast cztery warstwy kodu wykonywalnego oddzielały oszukańcze wykorzystanie tych uprawnień od wersji aplikacji przekazanej do weryfikacji w sklepie.

Aktywne odpowiedzi C2 potwierdziły, iż zaimplementowane funkcje były przeznaczone także dla polskich użytkowników. Mechanizm kontroli zaakceptował MCC 260, reguły wybrały domyślny payload, a payload zarejestrował urządzenie jako PL i otrzymał reguły automatyzujące proces Teleaudio. Podczas jednego uruchomienia urządzenie załadowało aktywny formularz subskrypcji Teleaudio i wysłało żądanie do API sprawdzającego transakcję. Nie podano numeru telefonu ani kodu PIN, więc transakcja nie przeszła dalej. Odrębne zadania prowadziły do innych polskich stron subskrypcji i próbowały wysłać wiadomości SMS Premium na 92505, 92512 i 92513.

Phone Cleaner Master pokazał, iż przypisanie kraju może zmieniać się między wersjami. Jego reguły zawierały PL260, przez co polskie urządzenia wybierały payload AqMu skonfigurowany z innym adresem C2. Polska nie była więc na stałe przypisana do domyślnej ścieżki Messenger Pro. Operator mógł kierować urządzenia z tego samego kraju do różnych rodzin payloadów, zmieniając zdalne reguły i rozpowszechniając odpowiednio skonfigurowane wersje aplikacji.

Wszystkie aplikacje odkryte podczas analizy zgłosiliśmy firmie Google, a Google usunęło je ze sklepu. Meta usunęła również zgłoszone przez nas reklamy, choć inne reklamy w ramach tej samej operacji mogły pozostać aktywne bez naszej wiedzy albo wygasnąć samoistnie. Pojedyncze usunięcia przerywały określone ścieżki instalacji, ale pojawiały się nowe pakiety, infrastruktura C2 przez cały czas działała, a kopie zainstalowane wcześniej mogły się z nią komunikować.

Operator oddzielił stałe funkcje od zmiennej logiki biznesowej. Zaszyfrowane etapy DEX ukrywały cel modułu ładującego, magazyn obiektowy dostarczał wymienne payloady, reguły pozwalały przypisywać kraje do różnych gałęzi, a zdalny JavaScript dostosowywał implant do poszczególnych stron płatności. O sposobie działania operacji świadczy przede wszystkim ta architektura, a nie pojedyncza domena.

Wskaźniki kompromitacji

Wskaźniki zaobserwowano lub odzyskano między 14 a 21 września 2026 roku. Wartości sieciowe zneutralizowano (ang. defanged). Adresy docelowe rozliczeń i programów afiliacyjnych oddzielono od infrastruktury przypisanej do operacji modułu ładującego.

Messenger Pro

• Pakiet: com.messages.sms.messenger.textmessage.owyo
• SHA-256 bazowego APK: dfe8f46ab3cefa99382f9d2a4dab881cb9551497e9bc5d6a95fe4cf4b7c8df03
• SHA-256 pakietu konfiguracyjnego ARM64: ce6cd404fbf7f5ef42afebe04ecfb0d4349884cadfbe7e0ad92cf023f9df07ed
• SHA-256 certyfikatu podpisującego: 44e4971490a2b876a204ca1d9f5e87d0b4e7a8354258368267befa222a88d679
• SHA-256 certyfikatu Source Stamp: 3257d599a49d2c961a471ca9843f59d341a405884583fc087df4237b733bbd6d
• SHA-256 DEX etapu 1: 2f3093e9790e541c626b58c058c1098ca8ea25abab875771b285dcae04b1298e
• SHA-256 DEX etapu 2: c21361d183d7b649e6af869a911e210ff8a293fcb91695694992a1428fb5bf28
• SHA-256 DEX domyślnego payloadu: 8ffa31b8d6ba3ba217b4f658539b6c6894d75709842482c2248d056ee080a79c
• SHA-256 DEX payloadu AqMu: 79e3a8b1b19f1af6c80e728d32652e11a63c1d35517dd448760249fc42efceb7
• SHA-256 zdalnego main.v2.js: a2f292da1eb6da3bcd1b2bf2340478c2f02a4844bfaa85f00d6e4820bbbe597a
• Endpoint reguł: api.tehsnb[.]link/sabd/mckd
• C2 domyślnego payloadu: 47.84.77[.]127
• C2 payloadu AqMu: 47.84.194[.]202/asnvoycs
• Początkowe identyfikatory Biblioteki reklam Meta: 1101937705505412, 4635863290017072

Phone Cleaner Master

• Pakiet: com.ms.phonecleaner.clean.junk.pkoza
• SHA-256 bazowego APK: 6dafefa5a88dea6021028b4b58c58e60422af96296318c84cf898bd3aecc4ee9
• SHA-256 pakietu konfiguracyjnego ARM64: 6ff20ddfb5d3fda08aea05f70af1d907ed782b3e043a2ee98a98ef2361824f8b
• SHA-256 certyfikatu podpisującego: 71fd2453a6303058e193cef446fb796a59c6d0ab1f1c9cf9c887fec5b6a34089
• SHA-256 DEX etapu 1: eb51fea688ded3ae08fbde2130b859c70e90ce4730f9464120b2ffab087946de
• SHA-256 DEX etapu 2: 20e97d2717fca6cb4216f762d0c9cffe5b314e1331591d9800f827e988450711
• SHA-256 DEX payloadu AqMu: aa06f574b48b2ee071d6488616280be91a2854b38a702c3a2cc92cb2824413aa
• Endpoint reguł: api.hsbdbv[.]link/mkds/cneu
• C2 payloadu AqMu: 47.84.193[.]174/j26j8vf7
• C2 gałęzi domyślnej: 47.84.57[.]5

Inne reklamowane aplikacje należące do operacji

Powiązane próbki modułów ładujących użyte do analizy infrastruktury

Kampania reklamowa z inną implementacją

• Aplikacja: Colorful Message
• Pakiet: com.colorsms.poetry.messages
• SHA-256 bazowego APK: e624939f6a73e3bfce5587a2ba0c461363909dd31cf912b04f88a525aada71dd
• SHA-256 pakietu konfiguracyjnego ARM64: a6bb91620972efb5895291658d15e474428304d40421099efdd9b33072b5b57c
• Endpoint reguł: api.piaagt[.]click/view/colorful-messagee/home
• SHA-256 identycznego obrazu reklamowego: 7299f7de6acf366fc7f32f7c3873a09e11a08d9493aaa508cd2b2ee816c5d284
• SHA-256 najczęściej ponownie używanego pliku reklamowego: 90b87d8b4dda273ef64853a9997bba0844f0bc02071ae5101d1be2693be1b861

Aplikację Colorful Message łączą z operacją identyczny plik reklamowy oraz wspólny host api.piaagt[.]click, ale jej APK korzystał z innej ukrytej implementacji natywnej. Wskaźników tych nie należy interpretować jako dowodu, iż aplikacja zawierała ten sam kod modułu ładującego.

Pełny zbiór analityczny zawiera 1235 unikalnych identyfikatorów Biblioteki reklam Meta. Identyczne pliki reklamowe łączą z tym samym zbiorem dystrybucyjnym także poniższe pakiety. Odzyskane wersje APK nie ujawniły jednak modułu ładującego operacji:

Zidentyfikowaliśmy także następujące reklamowane pakiety już po tym, jak ich pliki APK stały się niedostępne, dlatego nie mogliśmy odzyskać ich skrótów:

Infrastruktura aktywacji modułów ładujących i reguł

Magazyn payloadów

Infrastruktura C2, adresów zapasowych i raportowania

Pasywne powiązania infrastruktury

Poniżej przedstawiamy powiązania TLS hostów API używanych przez nowo odzyskane aplikacje. Dla czterech nowych hostów dostępne nam dane pasywne nie zawierały nazwy balancera Aliyun:

• SHA-256 ponownie użytego certyfikatu TLS: 5848152508acc864869500c0dfff20723a087019eb717131dc6d7df51fbd75e6
• Podmiot certyfikatu: ablefee[.]wiki
• Inne endpointy prezentujące ten certyfikat: 43.98.201[.]44, 43.106.58[.]250, 8.219.222[.]81, 47.245.84[.]227, 47.84.66[.]120

ablefee[.]wiki jest pasywnym powiązaniem wynikającym z certyfikatu. Messenger Pro nie kontaktował się z tą domeną i nie występuje ona w jego kodzie.

Polska infrastruktura rozliczeń i programów afiliacyjnych

Domeny te zaobserwowano w zadaniach przydzielonych przez C2. Obecność na tej liście nie dowodzi, iż domenę kontroluje operator złośliwego oprogramowania.