Wektorem ataku w przypadku opisywanego oszustwa na fałszywe kasyna jest wiadomość SMS. W polu „nadawca” oszuści wpisują różne nadpisy, które mogą – ale nie muszą – kojarzyć się z hazardem. Treść zapowiada, że czeka na nas nagroda – wystarczy kliknąć w link (znakami „x” zastąpiliśmy 6-cyfrowy kod alfanumeryczny):

Niesamowite nagrody (wcale nie) czekają!

Gdy przejdziemy na docelową stronę trzeba „rozpocząć zakręcanie” jak proponuje wyskakujące okienko. Nie podajemy adresu konkretnej strony, bowiem nie miałoby to sensu. Po internecie krążą tysiące podobnych, nierzadko identycznych witryn. Jedne znikają, drugie się pojawiają.

Warto zwrócić uwagę na dziwną formę wykrzykników. To styl charakterystyczny dla języka hiszpańskiego. Może to dowodzić, że sprawcy są Hiszpanami, bądź używają szablonu przygotowanego pod kątem ofiar z Półwyspu Iberyjskiego. Dowodzi tego też ekran, który pojawia się wraz z kołem fortuny:

Treść na powyższym ekranie to – w wolnym tłumaczeniu – „Zakręć by wygrać”. Kwotą podana jest ponownie w sposób charakterystyczny dla kultury hiszpańskojęzycznej (poprzedzona symbolem waluty). Warto zwrócić uwagę na prawy dolny róg i „Piotra”, który zarobił powitalne 850 PLN. Gdy sami zakręcimy – za pierwszy razem się nie udaje (to standard w tego typu oszustwach), za drugim razem „wzbogaciliśmy się” o 200 „Darmowe Obroty”

by w następnym kroku trafić wymarzonego jackpota. Kolejna uwaga – polskie znaki diakrytyczne są małe, a reszta wielka. A nam zaproponowano odbiór naszego pakietu powitalnego.

Teoretycznie powinno wystarczyć kliknięcie w żółty przycisk na dole. Po kliknięciu jednak…

Przez Telegram na fałszywe kasyna

…trafiamy na komunikator Telegram. Witryna telegrambonuses[.]com jest pośrednikiem, który ma nam pozwolić dołączyć do kanału Królestwo Jackpotów.

Opis kanału mógłby sugerować, że jesteśmy o krok od wielkich pieniędzy. Dołączmy zatem do kanału.

Kolejna rzecz na którą warto zwrócić uwagę. Na wcześniejszym ekranie kanał miał mieć 3278 subskrybentów, tymczasem po wejściu okazuje się, że jest ich jednak zaledwie 63.

Gdy klikniemy łącze na końcu wpisu z telegramowego kanału, trafiamy na docelową stronę WWW:

Wybieramy kraj, podajemy dane rejestracyjne. I oczywiście wybieramy dostępną metodę płatności, musimy bowiem mieć za co zagrać w kasynie.

Co się stało z zapowiadaną premią 1500 złotych? Gdy weszliśmy na kanał na Telegramie, okazało się, że dostaniemy nie 1500 PLN tylko „do 2000€”. I nie tak po prostu (co sugerowałaby sytuacja z początku tego tekstu) tylko jako pomnożenie o 100% naszej pierwszej wpłaty.

Nie tak miało być? Prawda. Ale od początku piszemy, że to fałszywe kasyna. Nie prawdziwe.

BLIK pozwala na kolejny krok

Jaką formę wpłaty wybrać? Zdecydowaliśmy się na BLIK, bowiem specyfika Polskiego Standardu Płatności pozwala sprawdzić, dokąd miałyby trafić pieniądze zanim potwierdzimy transakcję. W przypadku karty – zobaczylibyśmy dane kontrahenta na wyciągu. Pierwszy ekran to operator płatności (Payment Gateway),

kolejny to serwis docelowy (voucherek[.]pl)

co potwierdza monit BLIK w aplikacji bankowej:

Vaallis sp. z o.o. to właściciel usługi Voucherek. Na głównej stronie serwisu czytamy o nim:

Kody i Doładowania w 30 sekund! Voucher, karty podarunkowe i doładowania GSM. Błyskawiczna dostawa po płatności.

Jak to czyta sieciowy oszust?

Idealna metoda na wypranie pieniędzy. Kupię kody/karty, sprzedam od razu w sieci za nieco taniej. Easy money!

W opisywanym modus operandi przestępcy nie próbują się nawet maskować, podstawiając np. wyglądającą na pierwszy rzut oka rzetelnie nazwę sklepu. Tak jak w przypadku BLIK-a, tak przy użyciu karty płatniczej ofiara na wyciągu zobaczy, że nie wpłacała pieniędzy na kasyno „Magius 1234”. Ona po prostu kupiła oszustom karty podarunkowe.

Jak nie dać się oszukać na fałszywe kasyna?

Przede wszystkim miej świadomość, że na końcu kasyno zawsze wygrywa. Pamiętaj, że jedyne legalne kasyno online w rozumieniu prawa Rzeczypospolitej Polskiej prowadzi Totalizator Sportowy sp. z o.o. No i nie daj się złapać na SMS-a, że gdzieś czekają na Ciebie jakieś pieniądze! W miejscu, w którym nigdy Cię nie było, za linkiem, który wygląda jak losowy zlepek liter.

Orange Polska bierze udział w finansowanym przez Unię Europejską projekcie ThreatChase (ThreatChase – Open Platform for Protection against Phishing). Celem projektu jest stworzenie i wprowadzenie platformy wspomagającej strukturyzację danych w zakresie phishingowych adresów i domen oraz proaktywnie zapobiegającej skutkom ataków phishingowych. Obserwuj ThreatChase na LinkedIn.

The post Uważaj na fałszywe kasyna! Wyjaśniamy na czym polega oszustwo appeared first on CERT Orange.

Opracowanie obejmuje charakterystykę ekosystemu SpyNote, jego architekturę operacyjną, model dystrybucji oraz zaplecze operatorskie, ze szczególnym uwzględnieniem panelu administracyjnego i mechanizmu budowania spersonalizowanych plików APK.

Kontekst zagrożenia i ewolucja SpyNote

W ostatnich latach obserwuje się systematyczny wzrost zagrożeń wymierzonych w urządzenia mobilne, w szczególności w ekosystem Android. Smartfony, będące nośnikiem zarówno danych prywatnych, jak i służbowych, stały się atrakcyjnym celem dla cyberprzestępców oraz aktorów prowadzących operacje szpiegowskie. Jednym z przykładów długotrwałego i ewoluującego zagrożenia w tym obszarze jest malware SpyNote, znany również pod nazwami pochodnymi, takimi jak CypherRat czy SpyMax.

SpyNote jest rodziną złośliwego oprogramowania typu RAT, która od lat funkcjonuje w ekosystemie zagrożeń mobilnych. Pomimo publicznej dostępności kreatora oraz relatywnie długiej historii, SpyNote pozostaje aktywnie wykorzystywany w bieżących kampaniach, zarówno o charakterze masowym jak i ukierunkowanym. W ostatnim okresie zaobserwowano również jego użycie w operacjach przypisywanych grupom APT, co znacząco podnosi poziom ryzyka związanego z tą rodziną malware.

Celem niniejszego raportu jest przedstawienie ogólnej charakterystyki SpyNote, jego modelu operacyjnego oraz sposobów dystrybucji, a następnie przejście do analizy technicznej wybranych, najnowszych próbek wykorzystywanych w aktualnych kampaniach.

Charakterystyka SpyNote jako Android RAT

Złośliwe oprogramowanie klasy RAT stanowi jedno z najbardziej rozpowszechnionych i trwałych zagrożeń dla urządzeń mobilnych. W szczególności platforma Android – ze względu na swoją powszechność oraz otwartą architekturę dystrybucji aplikacji – jest celem licznych kampanii złośliwego oprogramowania, których celem jest kradzież danych, kontrola urządzeń końcowych oraz nadużycia finansowe. Wśród aktywnych rodzin złośliwego oprogramowania mobilnego szczególną pozycję zajmuje SpyNote – znany od kilku lat Android RAT, który stał się fundamentem dla kolejnych publicznie dostępnych narzędzi typu RAT oraz ich modyfikacji.

SpyNote (nazywany także w środowisku underground Spymax lub SpyNote/Spymax RAT) pojawił się pierwotnie jako komercyjny lub półkomercyjny Android RAT, oferujący pełną zdalną kontrolę nad zainfekowanym urządzeniem. Charakterystycznym momentem w historii tego oprogramowania był wyciek kodu źródłowego wersji 6.4 w 2020 roku, co spowodowało szerokie rozpowszechnienie narzędzia i umożliwiło tworzenie licznych pochodnych (tzw. forków) oraz wariantów przez różne grupy cyberprzestępcze i osoby trzecie. Dzięki temu kod SpyNote stał się punktem wyjścia dla szeregu nowszych narzędzi RAT budowanych przez społeczność hackerską, które następnie były dystrybuowane w modelu Malware-as-a-Service (MaaS) przez niezależnych operatorów.

W literaturze technicznej oraz raportach threat intelligence istnieją także odniesienia łączące SpyNote z innymi narzędziami o podobnym sposobie działania. Przykładem jest Craxs RAT, który w analizach branżowych [2], jest opisywany jako pochodna lub wariant SpyNote/SpyMax – wykorzystujący jego kod bazowy i rozbudowany o dodatkowe funkcje oraz mechanizmy sterowania. W tym przypadku kod SpyNote został użyty i rozbudowany przez autora o pseudonimie EVLF, który od 2022 roku rozwijał i dystrybuował Craxs RAT za pośrednictwem kanałów takich jak Telegram, reklamując funkcje rozbudowanego Android RAT o własnych możliwościach sterowania i kontroli urządzenia.

Z punktu widzenia zagrożeń SpyNote nie jest jednorodnym narzędziem o stałym zestawie możliwości. Znane są różne warianty tego RAT, oznaczane literowo i generacyjne (np. SpyNote.A, SpyNote.B, SpyNote.C), które w zależności od kampanii przyjmują odmienne taktyki działania i maskowania. Ich cechą wspólną jest szeroki zakres funkcji inwigilacyjnych i zdalnej kontroli, co czyni SpyNote poważnym narzędziem w arsenale operatorów malware.

Należy podkreślić, że użycie SpyNote i jego pochodnych nie ogranicza się wyłącznie do szeroko rozumianej cyberprzestępczości finansowej. Chociaż wiele kampanii związanych z tymi narzędziami ma charakter masowy i jest ukierunkowanych na kradzież danych, oszustwa finansowe lub phishing aplikacyjny, jego funkcjonalność pozwala na wykorzystywanie narzędzia do bardziej ukierunkowanych operacji inwigilacyjnych. Oznacza to, że zarówno grupy cyberprzestępcze, jak i potencjalnie threat aktorzy typu APT (Advanced Persistent Threat) lub inne grupy o motywacjach szpiegowskich mogą adaptować to oprogramowanie do własnych celów, rozszerzając jego moduły lub łącząc go z innymi komponentami malware w ramach bardziej złożonych kampanii. Z raportów threat intelligence wynika, że grupy takie jak OilRig (APT34), APT-C-37 (Pat-Bear) czy Kimsuky w swoim portfolio narzędziowym miały SpyNote w kampaniach przeciwko ważnym celom (tzw. High Value Asset).

Model dystrybucji i wykorzystanie operacyjne (MaaS)

Dystrybucja SpyNote oraz jego pochodnych (w tym Craxs RAT) opiera się w przeważającej mierze na modelu MaaS, który od lat stanowi jeden z kluczowych mechanizmów skalowania cyberprzestępczości. Model ten zakłada oddzielenie roli autora narzędzia od roli operatora kampanii – twórcy dostarczają gotowe oprogramowanie, buildery oraz infrastrukturę sterującą, natomiast użytkownicy końcowi odpowiadają za jego faktyczne wykorzystanie i dystrybucję.

Wspomniany już wcześniej wyciek kodów źródłowych umożliwił jego swobodną modyfikację, rozwój własnych forków oraz integrację z innymi komponentami złośliwego oprogramowania. W praktyce doprowadziło to do fragmentacji ekosystemu SpyNote, w którym funkcjonuje wiele wariantów różniących się detalami implementacyjnymi, lecz zachowujących wspólną architekturę i zestaw funkcji charakterystycznych dla tej rodziny RAT.

Narzędzie to było aktywnie promowane w zamkniętych i półotwartych kanałach komunikacyjnych, głównie w serwisach takich jak Telegram. Autorzy oferowali nie tylko sam malware ale również pełne zaplecze operatorskie, obejmujące kreator złośliwych aplikacji, panel administracyjny oraz instrukcje dotyczące omijania zabezpieczeń systemu Android. Takie podejście znacząco obniżało barierę wejścia dla nowych operatorów i umożliwiało szybkie uruchamianie kampanii infekcyjnych bez konieczności posiadania zaawansowanych kompetencji technicznych.

Z perspektywy technicznej dystrybucja złośliwych aplikacji opiera się głównie na trojanizowanych plikach APK (pakiet instalacyjny aplikacji dla systemu Android), które podszywają się pod legalne aplikacje mobilne. Najczęściej są to przeglądarki internetowe, aplikacje bankowe, kurierskie, komunikatory, narzędzia VPN lub aplikacje powiązane z aktualnymi wydarzeniami społecznymi i ekonomicznymi. Pliki te są rozpowszechniane poza oficjalnym sklepem Google Play, m.in. za pośrednictwem stron phishingowych, bezpośrednich linków do pobrania, fałszywych reklam oraz wiadomości SMS i e-mail zawierających odnośniki do instalatorów.

Istotnym elementem modelu dystrybucji jest wykorzystanie socjotechniki do nakłonienia użytkownika do ręcznego zainstalowania aplikacji oraz nadania jej szerokich uprawnień systemowych. Mechanizm ten jest kluczowy, ponieważ SpyNote nie posiada wektorów infekcji wykorzystujących exploity ani zdalne wykonanie kodu (RCE). Operatorzy kampanii często instruują ofiary, aby wyłączyły mechanizmy ochronne Androida, takie jak Google Play Protect, lub zezwoliły na instalację aplikacji z nieznanych źródeł. W niektórych kampaniach stosowane są również techniki bardziej zaawansowane, takie jak przekierowywanie do odpowiedniego pliku w zależności od typu urządzenia, ukrywanie linków z wykorzystaniem kodów QR czy wykorzystanie aplikacji-loaderów, które dopiero w drugim etapie pobierają lub odszyfrowują właściwy payload SpyNote.

Model MaaS sprzyja również decentralizacji infrastruktury sterującej. Każdy operator może wykorzystywać własne serwery C2, często hostowane u różnych dostawców lub ukryte za usługami dynamicznego DNS. Niektóre warianty wspierają również fallback C2 oraz dynamiczną zmianę adresów za pomocą DNS-over-HTTPS. W efekcie powstaje rozproszony ekosystem kampanii, które mogą wydawać się niezależne, mimo że korzystają z tego samego lub bardzo zbliżonego kodu malware. Taka fragmentacja znacząco utrudnia blokowanie zagrożenia na poziomie infrastruktury oraz przypisywanie aktywności do konkretnych aktorów.

Zaplecze operatorskie: panel administracyjny i builder

Integralnym elementem ekosystemu SpyNote jest publicznie dostępny panel administracyjny (C2 panel), oferowany za pośrednictwem oficjalnej strony projektu. Panel ten stanowi centralny punkt zarządzania zainfekowanymi urządzeniami i odgrywa kluczową rolę w operacyjnym wykorzystaniu tego narzędzia. Z perspektywy technicznej i funkcjonalnej jest to klasyczny interfejs C2, udostępniający operatorowi pełen wgląd w aktywność ofiar oraz możliwość wykonywania poleceń w czasie rzeczywistym.

Zacznijmy od witryny projektu. Panel administracyjny SpyNote prezentowany jest jako „zaawansowane narzędzie do zdalnej administracji Androida”, jednak zakres oferowanych funkcji jednoznacznie odpowiada charakterystyce złośliwego oprogramowania typu RAT. Deklarowanie narzędzia jako „remote admin tool” to standardowa technika marketingowa pomniejszająca potencjalne konsekwencje prawne dla autorów. Interfejs umożliwia operatorowi monitorowanie i kontrolę urządzeń z systemem Android w szerokim zakresie, obejmującym zarówno pasywne pozyskiwanie danych jak i aktywne oddziaływanie na system ofiary. Funkcje są dostępne z poziomu jednej konsoli zarządzającej i nie wymagają bezpośredniego dostępu fizycznego do urządzenia.

Rys. 1. Serwis „projektu SpyNote” – notka informacyjna.

Do kluczowych możliwości panelu administracyjnego należy zdalny podgląd ekranu urządzenia w czasie rzeczywistym, wraz z możliwością interakcji i sterowania interfejsem systemu. Funkcja ta pozwala operatorowi obserwować bieżącą aktywność użytkownika: w tym uruchamiane aplikacje, wprowadzane dane oraz wyświetlane treści. Panel umożliwia również zdalne odblokowanie ekranu urządzenia, co w praktyce pozwala na przejęcie kontroli nad telefonem nawet w sytuacji, gdy jest on zabezpieczony mechanizmami blokady (odblokowanie ekranu możliwe jest wyłącznie dzięki nadaniu uprawnień Accessibility Service, a nie przez przełamanie mechanizmu blokady).

Istotnym elementem funkcjonalnym jest zdalny dostęp do sensorów urządzenia, w tym mikrofonu i kamery. Panel umożliwia uruchamianie nagrywania dźwięku oraz obrazu bez wiedzy użytkownika, a także podgląd obrazu z kamery w czasie rzeczywistym. Funkcje te w połączeniu z mechanizmami ukrywania aktywności malware pozwalają na prowadzenie długotrwałej i dyskretnej inwigilacji.

Panel administracyjny oferuje również rozbudowane narzędzia do zarządzania danymi przechowywanymi na urządzeniu. Operator ma dostęp do eksploratora plików umożliwiającego przeglądanie, pobieranie oraz usuwanie danych, a także do modułów pozwalających na odczyt wiadomości SMS, historii połączeń, list kontaktów oraz zapisanych kont i haseł. Dodatkowo dostępny jest moduł keyloggera, umożliwiajcy przechwytywanie wprowadzanych danych, w tym potencjalnie danych uwierzytelniających do aplikacji bankowych i korporacyjnych.

Rys. 2. Serwis „projektu SpyNote” – funkcjonalności narzędzia

Jednym z bardziej zaawansowanych komponentów panelu administracyjnego jest moduł lokalizacji, oferujący śledzenie położenia urządzenia w czasie rzeczywistym z wykorzystaniem danych GPS. Funkcja ta prezentowana jest w formie interaktywnej mapy z trójwymiarową wizualizacją, umożliwiającą dokładne monitorowanie przemieszczania się ofiary. W połączeniu z innymi modułami pozwala to na korelację aktywności użytkownika z jego fizyczną lokalizacją. Stałe śledzenie urządzenia jest możliwe dzięki połączeniu uprawnień do lokalizacji oraz usługi działającej w tle, co oznacza, że użytkownik otrzymuje minimalne alerty systemowe lub nie otrzymuje żadnych.

Panel SpyNote zawiera również funkcje typowe dla narzędzi administracyjnych o charakterze ofensywnym, takie jak dostęp do terminala systemowego. Moduł ten umożliwia wykonywanie poleceń na zainfekowanym urządzeniu, uzyskiwanie informacji o konfiguracji systemu oraz potencjalne wdrażanie dodatkowych komponentów. Tego typu funkcjonalność znacząco zwiększa elastyczność operacyjną narzędzia i pozwala operatorowi na dynamiczne dostosowywanie działań do konkretnej ofiary.

Z punktu widzenia modelu biznesowego panel administracyjny SpyNote jest oferowany w ramach płatnych licencji czasowych oraz dożywotnich. Dostępne są pakiety obejmujące kilkumiesięczne licencje testowe, średnioterminowe oraz jednorazowy zakup zapewniający stały dostęp do narzędzia. Charakterystycznym elementem jest akceptowanie płatności wyłącznie w kryptowalutach, takich jak Bitcoin, Ethereum czy USDT, co jest typowym rozwiązaniem stosowanym w środowisku narzędzi o podwyższonym ryzyku prawnym i operacyjnym.

Rys. 3. Serwis „projektu SpyNote” – cennik

Operatorzy SpyNote deklarują możliwość sprzedaży niestandardowych wersji narzędzia, w tym modyfikacji kodu źródłowego oraz świadczenia „usług specjalnych” na żądanie klienta. Z perspektywy analitycznej wskazuje to na wysoki poziom elastyczności oraz gotowość do dostosowywania narzędzia do konkretnych scenariuszy użycia, w tym potencjalnie do operacji ukierunkowanych.

C2 oraz Builder

Opisany powyżej panel stanowi centralny element całego ekosystemu tego malware i odpowiada za zarządzanie cyklem życia infekcji, od generowania złośliwej aplikacji po bieżącą kontrolę nad zainfekowanymi urządzeniami. W zależności od wersji SpyNote oraz jego licznych forków interfejs panelu może różnić się wizualnie oraz funkcjonalnie. Jednak we wszystkich obserwowanych wariantach zachowany jest wspólny zestaw podstawowych mechanizmów operacyjnych. Różnice wynikają z faktu, iż narzędzie było wielokrotnie modyfikowane i adaptowane przez różne grupy hakerskie.

Rys. 4. Panel administracyjny SpyNote – zarządzanie infekcjami

Niezależnie od wariantu kluczowym komponentem panelu administracyjnego jest moduł buildera, który umożliwia generowanie dopasowanych i unikalnych próbek malware w postaci plików APK. Builder pozwala operatorowi zdefiniować podstawowe parametry złośliwej aplikacji, w tym nazwę wyświetlaną użytkownikowi, nazwę pakietu oraz identyfikatory komponentów, co umożliwia maskowanie malware jako legalnego oprogramowania. Na tym etapie określana jest również nazwa procesu oraz dane infrastruktury sterującej. W szczególności adres IP lub domena serwera C2 oraz port komunikacyjny, z którym aplikacja będzie się łączyć po uruchomieniu na urządzeniu ofiary. Niektóre wersje buildera wspierają generowanie wielu wariantów tej samej próbki (polimorfizm), co znacząco utrudnia klasyczne wykrywanie sygnaturowe.

Rys. 5. Panel administracyjny SpyNote – builder-konfiguracja

Istotnym elementem procesu budowania aplikacji jest możliwość wyboru funkcjonalności włączanych w wygenerowanej próbce. Panel udostępnia operatorowi zestaw przełączników odpowiadających poszczególnym modułom operacyjnym, takim jak dostęp do kamery, mikrofonu, lokalizacji, wiadomości SMS, kontaktów czy plików. Dodatkowo możliwe jest wymuszenie żądania uprawnień specjalnych, w tym uprawnień do wyświetlania nakładek ekranowych, ignorowania optymalizacji baterii oraz blokowania powiadomień systemowych. Szczególnie istotną opcją jest możliwość automatycznego uzyskiwania dodatkowych uprawnień po aktywacji usługi Accessibility, co w praktyce umożliwia dalszą eskalację kontroli nad systemem bez bezpośredniego udziału użytkownika.

Rys. 6. Panel administracyjny SpyNote – builder-konfiguracja

Z perspektywy technicznej panel administracyjny SpyNote jest aplikacją desktopową napisaną w technologii .NET. Do procesu budowy plików APK wykorzystywane są narzędzia zewnętrzne, w szczególności apktool, który służy do dekompilacji, modyfikacji oraz ponownej kompilacji pakietów Android. Integracja buildera z apktool pozwala operatorom generować nowe warianty bez znajomości programowania, automatyzując wstrzyknięcie konfiguracji oraz ukrycie kodu RAT.

Rys. 7. Panel administracyjny SpyNote – kompilacja pliku apk.

Po uruchomieniu panel administracyjny otwiera port nasłuchowy i oczekuje na połączenia przychodzące od zainfekowanych urządzeń. W momencie, gdy wygenerowana aplikacja zostanie zainstalowana na urządzeniu ofiary i uruchomiona, nawiązuje ona połączenie z serwerem C2 zdefiniowanym w procesie budowania. Po zestawieniu połączenia urządzenie jest rejestrowane w panelu jako nowa ofiara, a operator uzyskuje pełny wgląd w jej stan oraz możliwość zdalnego zarządzania jej funkcjonalnościami.

Panel umożliwia dynamiczne aktywowanie poszczególnych modułów malware w odpowiedzi na bieżące potrzeby operatora. Obejmuje to między innymi uruchamianie podglądu ekranu, przechwytywanie obrazu z kamery, nagrywanie dźwięku, śledzenie lokalizacji, przeglądanie plików oraz monitorowanie komunikacji. Funkcje te mogą być aktywowane w czasie rzeczywistym, co pozwala na elastyczne prowadzenie działań inwigilacyjnych oraz dostosowywanie ich do zachowania ofiary.

Analiza wygenerowanych aplikacji APK wskazuje, że proces budowania nie polega wyłącznie na prostym osadzeniu adresu C2. Obejmuje również selektywne włączanie lub wyłączanie komponentów manifestu oraz usług działających w tle. W rezultacie różne próbki SpyNote mogą znacząco różnić się zakresem żądanych uprawnień oraz zachowaniem w systemie, mimo że zostały wygenerowane z tego samego panelu administracyjnego. Mechanizm ten utrudnia detekcję sygnaturową oraz sprzyja powstawaniu dużej liczby wariantów tego samego malware.

Rys. 8. Panel administracyjny SpyNote – obsługa zainfekowanego urządzenia.

Z perspektywy operacyjnej panel administracyjny SpyNote pełni jednocześnie rolę narzędzia do generowania malware, serwera sterującego oraz konsoli operatorskiej. Taka konsolidacja funkcji w połączeniu z prostotą obsługi i szerokimi możliwościami konfiguracji czyni SpyNote narzędziem atrakcyjnym zarówno dla cyberprzestępców jak i dla aktorów prowadzących bardziej ukierunkowane operacje, w tym działania o charakterze szpiegowskim.

Analiza techniczna próbek SpyNote

Analiza techniczna została przeprowadzona na wybranych próbkach SpyNote pozyskanych w ramach bieżących kampanii oraz z publicznie dostępnych repozytoriów próbek złośliwego oprogramowania. Jej celem było określenie aktualnych mechanizmów infekcji, trwałości, komunikacji z infrastrukturą C2 oraz zakresu funkcji realizowanych na zainfekowanych urządzeniach z systemem Android.

Proces działania SpyNote rozpoczyna się na etapie instalacji aplikacji w postaci pakietu instalacyjnego APK. Już na tym etapie w pliku AndroidManifest.xml deklarowany jest szeroki zakres uprawnień, jednak ich faktyczne przyznanie i aktywacja następują stopniowo w trakcie dalszych faz infekcji, zgodnie z obowiązującym w systemie Android modelem runtime permissions.

Pierwsze uruchomienie aplikacji powoduje start głównej aktywności, odpowiedzialnej za przygotowanie środowiska operacyjnego malware. W ramach tego etapu inicjalizowane są komponenty zbierające kluczowe informacje o urządzeniu: wersja systemu Android, model sprzętu, identyfikatory systemowe oraz poziom zabezpieczeń. Informacje te stanowią podstawę doboru dalszych technik eskalacji uprawnień.

Rys. 9. Przykład ekranu – akceptacja Accessibility Service (na przykładzie aplikacji Roblox Modded.apk)

Kolejnym etapem działania malware jest stopniowa eskalacja uprawnień, realizowana poprzez sekwencję dedykowanych aktywności mających na celu skłonienie użytkownika do nadania aplikacji kolejnych uprawnień o krytycznym znaczeniu. Mechanizm ten opiera się na socjotechnice oraz wykorzystaniu systemowych okien typu overlay. W pierwszej kolejności użytkownik nakłaniany jest do przyznania dostępu do usług ułatwień dostępu (Accessibility Service), co stanowi punkt przełomowy w schemacie działania SpyNote. Uzyskanie tego uprawnienia umożliwia malware monitorowanie interakcji użytkownika z systemem oraz symulowanie zdarzeń wejścia, prowadząc do dalszej automatyzacji eskalacji uprawnień.

Posiadając już uprawnienia Accessibility Service SpyNote inicjuje kolejne etapy przejmowania kontroli nad systemem. W sposób półautomatyczny wymuszane jest nadanie uprawnień administratora urządzenia (Device Administrator), aktywacja własnej klawiatury systemowej (technika keyloggerów mobilnych) oraz zgoda na wykonywanie operacji w tle bez ograniczeń mechanizmów oszczędzania energii. W niektórych wariantach obserwuje się również próby uzyskania zgody na instalowanie oraz usuwanie pakietów aplikacji, co umożliwia dalszą rozbudowę funkcjonalności malware lub instalację dodatkowych komponentów.

Równolegle do procesu eskalacji uruchamiane są mechanizmy trwałości. SpyNote rejestruje komponenty typu BroadcastReceiver, skonfigurowane do obsługi wybranych zdarzeń systemowych: restart urządzenia (BOOT_COMPLETED), zmiana stanu ekranu, podłączenie zasilania oraz zdarzenie USER_PRESENT (sygnalizujące odblokowanie urządzenia przez użytkownika). Dzięki temu złośliwe usługi są automatycznie wznawiane po restarcie systemu lub aktywowane w momencie interakcji użytkownika z urządzeniem, co zwiększa niezawodność działania malware i ogranicza jego widoczność operacyjną.

Po uzyskaniu kluczowych uprawnień następuje inicjalizacja pełnego zestawu funkcji operacyjnych. Uruchamiane są usługi odpowiedzialne za monitorowanie lokalizacji, przechwytywanie dźwięku i obrazu, rejestrowanie wprowadzanych danych oraz zbieranie informacji o aktywności aplikacji. W zależności od konfiguracji malware część tych funkcji działa w trybie pasywnym, oczekując na polecenia z serwera sterującego, inne natomiast mogą być aktywowane automatycznie w odpowiedzi na określone zdarzenia systemowe.

Rys. 10. Zdekompilowana i zdekodowana klasa SpyNote – konfiguracja sieciowa

Ostatnim etapem schematu działania jest nawiązanie komunikacji z infrastrukturą C2 operatora kampanii. SpyNote inicjuje połączenie sieciowe z serwerem C2, przekazując wcześniej zgromadzone informacje identyfikujące urządzenie oraz potwierdzając gotowość do odbioru poleceń. Komunikacja realizowana jest cyklicznie lub zdarzeniowo, w zależności od konfiguracji, i służy zarówno do przesyłania danych wykradzionych z urządzenia jak i do odbierania instrukcji sterujących dalszym działaniem malware (wspólny kanał danych oraz zarządzania). W zaawansowanych wariantach komunikacja może być dodatkowo ukrywana poprzez mechanizmy szyfrowania lub wykorzystanie tunelu VPN, co utrudnia jej wykrywanie w warstwie sieciowej.

Całość schematu działania SpyNote wskazuje na przemyślaną, wieloetapową architekturę, której celem jest stopniowe przejmowanie kontroli nad urządzeniem ofiary przy jednoczesnym minimalizowaniu ryzyka wykrycia. Połączenie socjotechnik, nadużyć mechanizmów systemowych Androida oraz centralnego sterowania z poziomu C2 czyni SpyNote narzędziem zdolnym do długotrwałej i dyskretnej inwigilacji.

Komunikacja C2

Przeanalizowany komponent <package_name>.run.Socket odpowiada za pełną obsługę komunikacji sieciowej między zainfekowanym urządzeniem a serwerem sterującym SpyNote. Implementacja ta stanowi centralny element architektury komunikacji z C2 i została zaprojektowana w sposób umożliwiający stabilną, długotrwałą dwukierunkową komunikację przy jednoczesnym zachowaniu elastyczności w zakresie przesyłanych poleceń i danych. Długotrwałe utrzymywanie połączenia TCP odróżnia SpyNote od większości mobilnych RAT, które korzystają z krótkich połączeń typu “pull”.

Po stronie klienta komunikacja realizowana jest przy użyciu asynchronicznych kanałów sieciowych (AsyncChannel) opartych o Java NIO (Non-blocking IO), z wykorzystaniem gniazd TCP. Podczas inicjalizacji połączenia malware konfiguruje kluczowe opcje gniazd sieciowych, takie jak TCP_NODELAY oraz SO_KEEPALIVE, co wskazuje na dążenie do minimalizacji opóźnień oraz utrzymania sesji przez dłuższy czas. Adres serwera C2 oraz port pobierane są dynamicznie z klasy Support.SocketInfo, co potwierdza, że wartości te są wstrzykiwane na etapie budowania próbki przez panel administracyjny.

Proces zestawiania połączenia realizowany jest w klasie Client.Connect, która podejmuje wielokrotne próby połączenia, uwzględniając obsługę wyjątków sieciowych. W przypadku niepowodzenia malware wprowadza opóźnienie i podejmuje kolejne próby, co pozwala na przetrwanie czasowych problemów z dostępnością infrastruktury C2 lub sieci ofiary. Po pomyślnym zestawieniu połączenia zapisywany jest znacznik czasu, wykorzystywany następnie do monitorowania stanu sesji.

Bezpośrednio po połączeniu, klient wysyła do serwera pakiet inicjalizacyjny zawierający rozbudowany zestaw informacji identyfikacyjnych i telemetrycznych. Dane te obejmują unikalny identyfikator urządzenia, wersję malware, nazwę pakietu aplikacji, nazwy kluczowych klas, informacje o stanie baterii, lokalizacji, blokadzie ekranu oraz szczegóły dotyczące systemu operacyjnego i interfejsu producenta. Pakiet ten rejestruje nową ofiarę w panelu administracyjnym oraz umożliwia operatorowi natychmiastową ocenę wartości przejmowanego urządzenia.

Odbiór danych z serwera realizowany jest w klasie ReceiveData, która implementuje własny, niestandardowy protokół komunikacyjny. Dane przesyłane są w postaci strumienia bajtów, w którym długości poszczególnych segmentów oddzielane są bajtem zerowym. Po odebraniu pełnej ramki dane są dekodowane, opcjonalnie dekompresowane przy użyciu mechanizmu GZIP oraz przekazywane do dalszego przetwarzania. Zdekodowane pakiety trafiają do współdzielonej kolejki Socket.packets, co umożliwia ich asynchroniczną obsługę przez inne wątki. Przetwarzanie poleceń z serwera realizowane jest w klasie IncomingPackets, która cyklicznie pobiera pakiety z kolejki i przekazuje je do metody Client.Data. W tym miejscu następuje interpretacja poleceń na podstawie kluczy logicznych.

Istotnym elementem architektury jest obsługa operacji. SpyNote wykorzystuje równoległe zadania do przeszukiwania systemu plików, pobierania zawartości katalogów oraz wykonywania operacji na plikach multimedialnych, takich jak zrzuty ekranu o zadanych parametrach. Zastosowanie puli wątków umożliwia efektywne wykorzystanie zasobów urządzenia, a jednocześnie pozwala operatorowi na wykonywanie tych operacji w tle bez wyraźnych oznak aktywności dla użytkownika.

Komunikacja z serwerem C2 jest utrzymywana przez dedykowany mechanizm kontroli stanu połączenia zaimplementowany w klasie CheckConnection. Komponent ten cyklicznie wysyła pakiety typu „ping” oraz monitoruje czas bezczynności sesji. W przypadku braku odpowiedzi lub wykrycia problemów z dostępem do internetu malware samodzielnie inicjuje procedurę rozłączenia i ponownego zestawienia połączenia. Mechanizm ten umożliwia utrzymanie ciągłości kampanii nawet w warunkach niestabilnej sieci mobilnej. Dodatkowo okresowo przekazywane są aktualne informacje o stanie baterii, ładowaniu, lokalizacji oraz blokadzie ekranu, co umożliwia operatorowi bieżące monitorowanie kontekstu operacyjnego ofiary. Dane te mogą także służyć jako wyzwalacze operacyjne – np. aktywacja nagrywania po podłączeniu zasilania, co minimalizuje ryzyko wzrostu zużycia baterii i wykrycia przez użytkownika.

Całość logiki sterującej pracą poszczególnych komponentów komunikacyjnych została skupiona w klasie Controller, która koordynuje uruchamianie, zatrzymywanie oraz ponowne inicjalizowanie zadań odpowiedzialnych za połączenie, odbiór danych, przetwarzanie poleceń i kontrolę sesji. Mechanizm ten zapewnia wysoką odporność na błędy oraz pozwala na automatyczne odzyskiwanie połączenia w przypadku zakłóceń, co jest charakterystyczne dla dojrzałych rodzin złośliwego oprogramowania. W niektórych wariantach zaobserwowano dodatkowe mechanizmy ukrywania komunikacji, takie jak niestandardowe nagłówki, zaciemnione identyfikatory sesji lub wykorzystanie tunelowania przez HTTPS, co znacząco utrudnia monitoring ruchu sieciowego oraz korelację zdarzeń.

Analiza komponentu odpowiedzialnego za komunikację jednoznacznie wskazuje, że SpyNote wykorzystuje własny protokół C2 oparty o długotrwałe sesje TCP, z obsługą kompresji, dynamicznego kodu oraz wielowątkowego przetwarzania poleceń. Architektura ta została zaprojektowana z myślą o długotrwałej kontroli nad zainfekowanym urządzeniem, elastycznym rozszerzaniu funkcjonalności oraz minimalizowaniu ryzyka utraty sesji.

Techniki obfuskacji

SpyNote stosuje szereg wyrafinowanych technik obfuskacji i ochrony kodu, które ewoluowały od prostych metod do zaawansowanych mechanizmów mających na celu ominięcie nowoczesnych systemów zabezpieczeń. Podczas gdy najwcześniejsze wersje i publicznie dostępne kreatory (buildery) często nie posiadały żadnych zabezpieczeń, współczesne warianty (takie jak SpyNote.C czy V7) są wysoce skomplikowane.

Rys. 11. Konfiguracja widoczna w zdekompilowanym pliku (wersja kodowana)

Niektóre warianty działają jako droppery, gdzie pierwszy plik APK służy jedynie do zainstalowania drugiego payloadu ukrytego w pliku DEX wewnątrz zasobów aplikacji. Parametry połączenia z serwerem są często zaszyte wewnątrz plików DEX, co stanowi kolejną warstwę ukrycia. Przykładami stosowania takich technik są kampanie grup APT (np. grupy APT43), gdzie właściwy kod SpyNote ukryto w folderze /assets pod niepozornymi nazwami plików, jak security.dat czy search.db. Do jego odszyfrowania służy dedykowana biblioteka natywna SILENTKEY (np. libnative-lib.so), która zawiera funkcję decryptFile. Przejście z prostego szyfrowania XOR w języku Java na deszyfrowanie w bibliotece natywnej znacząco ogranicza skuteczność analizy statycznej z wykorzystaniem standardowych narzędzi do dekompilacji DEX.

Malware powszechnie wykorzystuje kodowanie do ukrywania kluczowych informacji konfiguracyjnych, w tym adresów IP serwerów C2, numerów portów oraz kluczy komunikacyjnych. Również dane wykradzione od ofiary (np. przechwycone znaki z klawiatury) są zapisywane i przesyłane w formie zakodowanej, a czasem zaszyfrowanej. W nowszych wariantach spotykane są wielopoziomowe łańcuchy dekodowania, gdzie stringi są deszyfrowane dopiero w momencie użycia. Utrudnia to statyczne mapowanie funkcji.

Najnowsze wersje SpyNote korzystają z komercyjnych pakerów oraz zaawansowanego zaciemniania ciągów znaków. Sprawia to, że kod aplikacji jest nieczytelny dla standardowych dekompilatorów, co utrudnia identyfikację złośliwych funkcji. Często używane są obfuskowane nazw klas i usług (np. klasy o nazwach C71 czy C38), by ukryć złośliwe procesy wśród legalnych usług systemowych. W wielu próbkach obserwuje się także sztuczne wypełniacze kodu (dead code), fałszywe klasy oraz zagnieżdżone bloki try/catch, które utrudniają analizę algorytmów.

Rys. 12. Drzewo klas i metod SpyNote – wersja bez obfuskacji

W zaawansowanych przypadkach kod malware jest deszyfrowany dopiero w momencie uruchomienia i ładowany bezpośrednio do pamięci urządzenia (in-memory execution). Dzięki temu złośliwe moduły nie są widoczne podczas zwykłego skanowania plików na dysku, co pozwala skutecznie omijać mechanizmy takie jak Google Play Protect. Tego typu technika jest stosowana głównie w wariantach wykorzystywanych w ukierunkowanych kampaniach lub tworzonych przez zaawansowanych operatorów – nie jest to funkcja standardowego buildera SpyNote dostępnego publicznie.

Zastosowanie powyższych technik znacząco utrudnia zarówno analizę statyczną, jak i detekcję behawioralną SpyNote.

Podsumowanie

SpyNote stanowi dojrzałe, wielokomponentowe złośliwe oprogramowanie klasy Android RAT. Zostało ono zaprojektowane jako spójny ekosystem obejmujący infrastrukturę C2, panel operatorski, mechanizm generowania spersonalizowanych próbek oraz modularną architekturę po stronie klienta. Taka konstrukcja umożliwia centralne zarządzanie kampaniami oraz precyzyjne dostosowanie zachowania poszczególnych instancji do założeń operacyjnych.

Z perspektywy funkcjonalnej SpyNote łączy mechanizmy pasywnej inwigilacji z aktywnym sterowaniem urządzeniem. Zakres jego możliwości obejmuje m.in. pozyskiwanie danych uwierzytelniających, monitorowanie aktywności użytkownika, dostęp do zasobów systemowych oraz wykonywanie zdalnych poleceń. Kluczowym elementem architektury jest systematyczne nadużywanie usług Accessibility, co umożliwia eskalację uprawnień logicznych oraz automatyzację interakcji z interfejsem systemu bez konieczności uzyskiwania uprawnień root. W praktyce czyni to SpyNote szczególnie efektywnym na współczesnych wersjach Androida, ponieważ omija on większość ograniczeń bezpieczeństwa dotyczących aplikacji bez dostępu do uprawnień systemowych. Cechą charakterystyczną jest również zdolność do utrzymywania stałych sesji TCP, co odróżnia SpyNote od większości mobilnych RAT i komplikuje analizę ruchu.

Model operacyjny SpyNote zakłada przeniesienie logiki konfiguracji na etap budowania próbki. Parametry komunikacji, zakres funkcjonalny oraz zachowanie aplikacji po instalacji definiowane są po stronie panelu operatorskiego, co skutkuje powstawaniem wariantów różniących się zachowaniem i artefaktami technicznymi. Takie podejście znacząco ogranicza skuteczność detekcji sygnaturowej i sprzyja długotrwałemu utrzymaniu dostępu do zainfekowanych urządzeń.

Z punktu widzenia detekcji i reagowania SpyNote reprezentuje klasę zagrożeń charakteryzującą się wysoką integracją z mechanizmami systemowymi Androida, odpornością na restart urządzenia oraz zdolnością do działania w tle w oparciu o zdarzenia systemowe. Zastosowanie własnego protokołu C2 oraz dynamicznego przetwarzania poleceń dodatkowo utrudnia identyfikację infrastruktury i blokowanie komunikacji na poziomie sieciowym.

W konsekwencji SpyNote należy traktować nie jako pojedynczą rodzinę malware w wąskim sensie, lecz elastyczne narzędzie operatorskie, zdolne do adaptacji i do zmian w modelu bezpieczeństwa platformy Android. Współcześnie termin SpyNote obejmuje de facto szeroką rodzinę forków i wariantów o różnym stopniu zaawansowania, z których część znacząco odbiega od oryginalnej wersji 6.4. Ma to istotne znaczenie dla analizy oraz atrybucji kampanii. Jego obecność w krajobrazie zagrożeń powinna być analizowana w kategoriach długofalowych, z naciskiem na detekcję behawioralną, korelację zdarzeń oraz monitorowanie nadużyć mechanizmów systemowych.

Indicators of Compromise (IoC)

Analizowane próbki

sonapk.apk
SHA256: 3cf8bd9828f8fe52867fcb09f3caa59f5ce0aa76ff20cf644807ae76b57c2c86
C2:          tcp://103.61.224[.]102:2323

Gmail.apk
SHA256: 8f09663836bef9fad23b34560dbcb0848e99d66e40787c37d498e7647792d5b6
C2         tcp://103.61.224[.]102:2323

inpost.apk
SHA56: 40d31617f45e8317e9d8fa6e42e67d587bdc546b50fd2197b26ac27b51d037de
C2:          tcp://103.61.224[.]102:3333

Roblox Modded.apk
SHA256: acf2d29c8c65ee2fe57445e672fbee01fa240b0039b66ea507f110468c6c8210
C2:          tcp://144.31.30[.]235:7771

Pozostałe (najnowsze) próbki
SHA256: 6fd37bbd31b52c6312a0c7972d7fe7242dade45f3d8faa2fc548bef2e3400ecd
C2:           tcp://20.82.176[.]195:7771

SHA256: 231b21251d16d17e564a2014765d1de553eb821abd92781b18c94889650a3bf7
C2:          tcp://91.92.251[.]105:12004

SHA256: b29b8bd2d47254de3d7bf21d7610209d3cc4db49cd3e7ba2fd1ea040f49cb6db
C2:          tcp://185.87.254[.]82:2305

SHA256: d9c47a7d7e42402c3ce2dd191ea09e9f7e29b1ee8d78d9aec0a47ed7b4bcdb80
C2:          tcp://mm-includes.gl.at.ply[.]gg:33004

SHA256: 5d4aa3800788f80d2a0b0460574ee3d3403c642b19e294941cd9e59b37aebae5
C2:          tcp://193.161.193[.]99:40920

SHA256: d14fb879a81e6c415146092d2aab8f8c69991828dbebc0ec27363248f9b260c0
C2:          tcp://83.217.209[.]142:1333

SHA256: e21f8722ab3d3557e7b0dda0faca39c517bbf0afd84bf4bbdc92687c9bd58aae
C2:          tcp://tcp.cloudpub[.]ru:48683

Źródła i materiały referencyjne:

1. https://www.mobile-hacker.com/2025/06/05/analysis-of-spyware-that-helped-to-compromise-a-syrian-army-from-within/
2. https://www.group-ib.com/blog/craxs-rat-malware/
3. https://malpedia.caad.fkie.fraunhofer.de/details/apk.spynote
4. https://hunt.io/malware-families/spynote
5. ThreatLabz 2025 Mobile, IoT & OT Threat Report
6. https://app.apkdetect.com/search/?malware=SpyNote

The post SpyNote: kompleksowa analiza złośliwego oprogramowania RAT dla systemu Android appeared first on CERT Orange.

Zastanawiasz się czasem jak to by było, gdyby ktoś mógł się pod Ciebie podszyć? Odbierać Twoje rozmowy i SMS, dostawać na swoje urządzenie Twoje wiadomości autoryzacyjne? Brzmi groźnie, więc jeśli ktoś Ci powie, że właśnie tak się dzieje – może to wywołać bardzo duży stres i spowodować, że dasz się złapać na socjotechniczną sztuczkę. To podstawa działania sieciowych oszustów. Chcą wywołać u nas nerwy tak wielkie, by nie przyszło nam do głowy zastanawiać się, czy to, co nam mówią, ma jakikolwiek sens.

Ostatnio wzrosła liczba zgłoszeń trafiających do CERT Orange Polska o sytuacjach, gdy oszuści „ostrzegają” o rzekomej próbie wymiany Twojej karty SIM. Co zrobić jeśli to do Ciebie trafi wiadomość, która budzi Twój niepokój/wydaje się podejrzana ? Możesz zgłosić ją bezpośrednio do nas, używając przycisku „Zgłoś zagrożenie” na stronie głównej. Poniżej pokażemy Wam schemat takiego przekrętu.

Zaczyna się od telefonu

Pani ze wschodnim akcentem, podając się za pracownika salonu Orange, poinformowała o próbie wymiany mojej karty SIM w salonie Orange

Przedstawiła się jako Anna Jakaś-tam z Orange. Dzwoniła, żeby zweryfikować podejrzaną transakcję na moim koncie polegającą na wydaniu duplikatu karty SIM w salonie Orange w Warszawie

Do klienta z numeru xxx xxx xxx dzwoniła osoba twierdząca, że jest pracownikiem Orange o nazwisku Xxxxxxx i informowała, że na numer klienta została zlecona wymiana karty SIM i teraz połączenia są przekierowania na ten duplikat

Z numeru +48 xxx xxx xxx dzwoni osoba która przedstawia się jako pracownik Orange i twierdzi że w salonie Orange został wydany duplikat karty SIM z wykorzystaniem e-dowodu

To tylko kilka przykładów zgłoszeń, które trafiły do CERT Orange Polska. Co je łączy?

• rozmowa telefoniczna przychodząca
• ostrzeżenie – z dużym naciskiem – o podejrzanej transakcji
• sprecyzowanie, że chodzi o duplikat karty
  • można założyć, że w kolejnym kroku następuje ostrzeżenie o konsekwencjach wpadnięcia Twojej karty SIM w ręce osób trzecich
• powołanie się na salon Orange

Umiejętna presja kluczem do sukcesu oszusta

Ten przekręt – podobnie jak podobne rozpoczynające się od rozmowy telefonicznej – ma niestety sporą szansę na sukces, jeśli oszust dobrze poprowadzi rozmowę. Dlaczego? Mamy tu bowiem:

• ostrzeżenie przed realnym zdarzeniem
• sytuację obiektywnie generującą wysokie ryzyko (przejęcie kontroli nad ruchem telefonicznym i SMS-owym)
• wsparcie się znaną marką (telekom, bank, dostawca prądu, etc.), a w efekcie uwiarygodnienie u ofiary
• często posługiwanie się prawdziwymi danymi ofiar, pozyskanymi z wycieków
• w opisywanym przypadku: powoływanie się na konkretny salon Orange (we analizowanych przypadkach oszuści podawali adres/nazwę nieistniejącego salonu, ale równie dobrze mogą podszyć się pod prawdziwy)

Zadaniem dla dobrze przygotowanego socjotechnika jest tylko poprowadzenie potencjalnej ofiary po ścieżce, odpowiednio dawkując emocje i nie przesadzając z presją. Oszust-specjalista potrafi nawet tak „zakręcić” ofiarą, że ta dojdzie do wniosku, że przestępcę uwiarygadnia nawet fakt, że… wie o jaki numer telefonu chodzi! No tak, wie – przecież właśnie na niego zadzwonił.

Czego chce oszust od Twojej karty SIM?

Twoja SIM-ka go nie interesuje. To tylko przynęta. W jednym ze zgłoszeń analizowanych przez CERT Orange Polska czytamy:

Następnie niby blokują ten duplikat. Twierdzą, że zostały wykradzione dane osobowe i pytają jakie instytucje w związku tym mają poinformować. Następnie z nr +48 xx xxx xx xx dzwoni osoba podająca się za przedstawiciela banku i próbuje wymusić instalację oprogramowania rzekomo do obsługi 2FA. Nie udało się ustalić o jaki program chodzi. Po zapowiedzi zgłoszenia sprawy na policję, dzwoniący stwierdził, że zadzwoni później i rozłączył się.

W innej sytuacji zorientowany klient zapowiedział, że nie zgadza się na wymianę. Od rozmówcy usłyszał, że sytuacja zostanie zgłoszona na policję, a dalsze informacje otrzyma mailem. Generalnie rozmówcy dopytywani o co chodzi, regularnie powtarzali, że to kwestia podejrzanej aktywności/transakcji. Naciskali też na werbalne potwierdzenie, że nie robiły tego ofiary.

Co mogłoby się dziać w kolejnych krokach? W potwierdzonym wariancie mamy próbę przekonania do instalacji nieznanej aplikacji po telefonie „z banku”. W innych, podobnych atakach, często pojawiają się próby wykradzenia poświadczeń logowania do systemu bankowości elektronicznej. Tutaj mogłoby być podobnie. Być może e-mail, którego przyjście oszust zapowiadał, kierowałby do fałszywej strony banku, korzystając z tego, że wcześniejsze aktywności uwiarygodniły przestępcę w oczach ofiary.

Jak wygląda wymiana Twojej karty SIM w Orange

Kartę SIM w Orange najlepiej wymienić samemu. Jeśli dotychczasowa jest aktywna i masz do niej dostęp, zrobisz to przez SMS lub w Mój Orange.

W przypadku gdyby ktoś faktycznie chciał uzyskać nieautoryzowany dostęp do treści związanych z Twoją kartą, zakładamy, że nie będzie miał do niej dostępu (nie będzie mógł np. otrzymać kodu autoryzacyjnego). Wtedy wymiana możliwa jest wyłącznie w salonie Orange. W celu jej wykonania musisz wylegitymować się ważnym dowodem osobistym bądź paszportem.

Ważna wiadomość to fakt, że w procesie wymagana jest weryfikacja PESEL. Dlatego:

• nie możesz wyrobić duplikatu Twojej karty SIM jeśli Twój PESEL jest zastrzeżony
• jeśli ktoś dzwoni do Ciebie i ostrzega, że ktoś taki duplikat właśnie wyrobił – kłamie
• nie zablokowałaś/eś jeszcze PESEL-u – to dobry moment, by zrobić to teraz

Jeśli ktoś do Ciebie dzwoni w takiej sprawie – najlepiej po prostu się rozłączyć. Tym bardziej, jeśli nie masz telefonu w Orange – oszuści mogą dzwonić na losowo wybrane numery. Co robić dalej?

• zadzwoń na nr *100 lub 510 100 100, przedstaw sprawę i poproś konsultanta o sprawdzenie, czy są zanotowane jakieś aktywności związane z Twoim kontem
• jeśli wolisz załatwić sprawę osobiście – tutaj znajdziesz adresy naszych salonów

A przede wszystkim – jak w przypadku wszystkich dotyczących Cię działań w sieci odbiegających od normy, pamiętaj, że:

Im więcej emocji wywołuje wiadomość, która do Ciebie dotarła i im bardziej są silne – tym większe prawdopodobieństwo, że ktoś próbuje Cię oszukać!

The post Uważaj na telefony od oszustów o próbie wymiany Twojej karty SIM appeared first on CERT Orange.

Za analizę tematu wzięliśmy się dzięki jednemu z klientów, który dał znak o podejrzanej aktywności za pośrednictwem formularza „Zgłoś zagrożenie” na naszej stronie. Dzięki za cynk, od razu zabraliśmy się do roboty!

Rzekoma rekruterka skontaktowała się z naszym klientem za pośrednictwem Messengera. Uwaga! Widoczny poniżej profil jest dalej aktywny w serwisie Facebook!

W następnym kroku pada pytanie, czy jest klientem Orange, a następnie prosi o odwiedzenie strony orange-praca[.]com. Ofiara jest zachęcana otrzymaniem kwoty 100 zł za zalogowanie na stronie, która okazuje się nieudolną kopią serwisu Mój Orange (stąd pytanie, czy oszust ma do czynienia z klientem naszych usług). Uzasadnieniem jest zarobek na zasadzie polecenia (tzw. referral). Co ciekawe, w naszym przypadku przestępca… pomylił adres strony! Dopiero po chwili wskazuje „prawidłowy” choć pamiętajmy, że prowadzący do oszustwa link.

Nasz klient zweryfikował te domenę, między innymi przy użyciu podpowiedzi Google Gemini. Czy jest to najlepsza metoda? Porady znajdziecie w podsumowaniu tego wpisu. Oszust zaniemówił, ale kilka godzin później wciąż nalegał aby zalogować się na wskazanej stronie.

Co skrywa fałszywa „praca w Orange”

Pod domeną orange-praca[.]com czekał formularz, w którym wyłudzane były dane dostępowe do konta Mój Orange. Ponieważ korzystając z niego mamy domyślnie włączane uwierzytelnianie dwuskładnikowe, w kolejnym kroku pojawia się prośba o przepisanie jednorazowego kodu z SMS-a. Jeśli to zrobimy – oddajemy dostęp do konta Mój Orange oszustowi. Ciekawostka – grafiki, które były wykorzystane na stronie pochodziły z prawdziwego serwisu rekrutacyjnego jednego z operatorów.

Gdy zajrzyjmy nieco głębiej, widać że dane z formularza za pośrednictwem aplikacji Telegram trafiają na kanał oszusta. Tam prawdopodobnie następuje ręczna weryfikacja i próba logowania na wyłudzone dane. Kolejna ciekawostka. Albo oszust poszedł na łatwiznę, bądź po prostu nie zwrócił na taki „drobiazg” uwagi, bowiem IP zarejestrowanej 5 stycznia 2026 domeny orange-praca[.]com prowadzi prosto do… Rosji.

Możemy Was zapewnić, że akurat ta „praca w Orange” już nikogo nie zainteresuje. Domena jeszcze w sobotni wieczór nie była już dostępna zarówno dla klientów Orange Polska (blokada na CyberTarczy), by niedługo później trafić również na listę CERT Polska.

Jakie było ryzyko i jak sobie z nim radzić?

Czym grozi przejęcie przez niepowołaną osobę konta Mój Orange? Największym ryzykiem wydaje się być – po dodatkowej weryfikacji – możliwość zamawiania usług i produktów w imieniu ofiary.

Jeśli chcesz pracować z nami – polecamy serwis https://orange.jobs, zaś w przypadku studentów – https://praktyki.orange.pl. Co do zasady – jeśli szukasz ofert pracy, sprawdzaj je na oficjalnych stronach pracodawców (szukaj zakładek takich jak „kariera”) lub serwisach z ogłoszeniami o pracę. I pamiętaj, że nikt i nigdy nie wymaga podczas procesu rekrutacyjnego logowania się w panelu klienta! No i nie płacimy za to 100 zł. Za pracę w Orange płacimy więcej. A już sam fakt próby rekrutacji przez Messengera warto traktować jako czerwoną flagę.

Wszędzie, gdzie wprowadzasz jakiekolwiek dane logowania, uprzednio zweryfikuj adres strony. Szukaj literówek. Zwróć uwagę na cały link. Oszuści wykorzystują tzw. subdomeny. Przykład: ogloszenie-stanowisko.nazwa-firmy-z-literowka.pl. Masz pewność, że to witryna firmy, agencji pośrednictwa lub portalu z ogłoszeniami? A może tylko ją przypomina? Ostatecznie poproś kogoś o pomoc.

No i wczytaj się w informacje i monity, które przychodzą do Ciebie SMS-em, czy w formie pusha w aplikacji. W naszym przypadku wiadomość z jednorazowym kodem szczegółowo informuje co autoryzujemy. Podobnie jest u większości usługodawców, więc przede wszystkim stanowczo zalecamy czytanie treści monitów.

Niezbędny w takiej sytuacji drugi krok daje nadzieję, iż potencjalna ofiara zorientuje się, że coś jest nie tak. I że logowanie do klienckiego serwisu operatora to nie jest praca w Orange. Dzięki konieczności wpisania kodu SMS oszust musi wykonać kolejne kroki, wyłudzać, czekać i wciągać ofiarę. To oznacza, większe ryzyko niepowodzenia. Zdobycie loginu i hasła to za mało.

The post Ktoś znów się pod nas podszywa. Tym razem wabikiem jest „praca w Orange” appeared first on CERT Orange.

W opisywanym przypadku wektorem ataku jest wiadomość e-mail.

Mamy ostrzeżenie: „Pisaliśmy do Państwa trzykrotnie”, mamy potencjalne konsekwencje „wszystkie zdjęcia i filmy zostaną usunięte”. I mamy nadawcę o nazwie „Ostrzeżenia Apple”. Jednak prezentowane odbiorcy adresy, to:

• admin@notino.pl
• powiadomienia@allegro.pl

Czy ktoś uzyskał nieautoryzowany dostęp do sieci obu wymienionych powyżej firm? Z prawdopodobieństwem bliskim pewności po prostu oszust zespoofował adresy. Czemu jednak akurat perfumeria online i czołowy serwis aukcyjny? Z jednej strony – znane firmy budzą zaufanie. Z drugiej jednak – jeśli potencjalna ofiara zobaczy Allegro w kontekście iClouda, może to spowodować, że zastanowi się zanim cokolwiek kliknie.

Kradną hasło do iCloud? Nie – pieniądze, jak zawsze

Co dzieje się dalej?

Choć powyższe zrzuty wyglądają podobnie, żaden z nich nie wymusza podania hasła do iCloud. Pierwszy przypadek to w zasadzie formalnie nie oszustwo. W tej sytuacji choć oszuści przekonują nas, że płacimy za miejsce w chmurze, w pewnym momencie trafiamy na stronę usługi zewnętrznej, gdzie płacimy 1,99€ za pierwszy miesiąc, a za kolejne już po 9,99€. Jeśli jesteśmy ofiarą i zorientowaliśmy się, za co zapłaciliśmy – wystarczy odezwać się do firmy i po prostu wstrzymać płatność.

W drugiej sytuacji już przez cały czas funkcjonujemy w infrastrukturze oszustów. Najpierw proponowana nam jest „wyjątkowa oferta lojalnościowa”, gdzie za jedyne 7 złotych zapewnimy sobie nieskończone miejsce na nasze pliki, które w innym przypadku zostałyby usunięte. Na decyzję mamy jednak tylko 5 minut (reguła niedostępności).

Wybór „upgrade storage” przeprowadzi nas do strony, gdzie podamy oszustom dane naszej karty płatniczej. W tym przypadku nie ma oczywiście mowy o zwrocie pieniędzy.

Jak nie dać się oszukać?

Jeśli trafi do Ciebie tego typu ostrzeżenie – zawsze zacznij od wejścia na stronę usługodawcy i sprawdzenia stanu swojej subskrypcji. Zawsze zweryfikuj domenę na stronie, na której podajesz dane logowania lub dane karty płatniczej.

Nie masz pewności, czy faktycznie kończy Ci się miejsce na koncie iCloud? Możesz to po prostu sprawdzić w ustawieniach swojego urządzenia Apple. A jeśli chcesz zakupić dodatkowe miejsce w chmurze – korzystaj z oficjalnych stron dostawcy usługi.

Orange Polska bierze udział w finansowanym przez Unię Europejską projekcie ThreatChase (ThreatChase – Open Platform for Protection against Phishing). Celem projektu jest stworzenie i wprowadzenie platformy wspomagającej strukturyzację danych w zakresie phishingowych adresów i domen oraz proaktywnie zapobiegającej skutkom ataków phishingowych. Obserwuj ThreatChase na LinkedIn.

The post Fałszywe maile o przepełnieniu iCloud appeared first on CERT Orange.

Choć w naszych wpisach poruszaliśmy już temat oszustw na Booking, ostatnie wydarzenia mogą pomóc spojrzeć inaczej na cały scenariusz. Przypominamy zarówno o stale widywanych metodach, jak i o głośnych atakach uderzających w gości oraz właścicieli obiektów noclegowych w Polsce. Warto zwrócić uwagę, że bardzo często mówimy o dwóch stronach jednego schematu działania oszustów.

W celu wysłania wiadomości do osób posiadających rezerwację w danym obiekcie, atakujący muszą pozyskać bazę klientów. Jak? Przejmując konto na platformie rezerwacyjnej lub dostęp do serwera, gdzie takie dane się znajdują. Uzyskany dostęp może posłużyć w wielu celach, ale rozsyłanie do gości wiadomości e-mail, na WhatsApp lub serwisach takich, jak Booking jest prawdopodobnie najpopularniejszą metodą okradania ofiar. O tym jak dokładnie wyglądają takie scenariusze przeczytacie poniżej.

Wypoczynek w Tatrach i „anulowane rezerwacje”

W grudniu media społecznościowe i portale informacyjne obiegło ostrzeżenie o  wiadomościach e-mail podszywających się pod Schronisko PTTK Murowaniec. W treści maila miała pojawić się informacja o konieczności potwierdzenia rezerwacji pod groźbą jej anulowania w przypadku braku reakcji.

Nie zabrakło też szczegółowej informacji o rzekomym „procesie weryfikacji”. Jeżeli przyjrzymy się uważnie, każdy punkt powinien zwrócić naszą uwagę, sprowokować do zastanowienia się oraz zatrzymania przed podjęciem jakichkolwiek działań. Tak nie powinno wyglądać potwierdzanie rezerwacji.

Na stronie wyłudzane są dane osobowe oraz dane karty płatniczej. Po ich przekazaniu z konta znikała wskazana kwota – nie „tymczasowo”, jak opisywała instrukcja, lecz bezpowrotnie.

Jak zwykle w przypadku wiadomości (potencjalnie) phishingowych, warto zwrócić uwagę na domenę strony, gdzie wpisujemy jakiekolwiek istotne dane. W tej sytuacji nie była to domena związana ze znaną marką, a uniwersalna, mająca kojarzyć się z potwierdzeniem rezerwacji:

reservation.confirm-id<NUMER>[.]com

Domen towarzyszących temu oszustwu jest wiele, operują na podobnych frazach. Różnią się szczegółami, w tym numerami w nich zawartymi. W naszym wcześniejszym materiale przytaczaliśmy przykłady takich domen i jak widać niewiele się zmieniło. Nie są to jednak oficjalne domeny jakichkolwiek usług, a jedynie infrastruktura atakujących mająca tworzyć pozory wiarygodności.

Sekret skuteczności ataków? Presja czasu i wizja anulowanego pobytu w gorącym okresie grudniowych wyjazdów. Ze względu na duże zainteresowanie, takie wyjazdy planuje się z wyprzedzeniem, a ryzyko utraty cennej rezerwacji może przysłonić zdrowy rozsądek.

Tygodnik Podhalański poinformował, że ofiarami analogicznych ataków padli także goście Willa Roztoka & SPA w Bukowinie Tatrzańskiej oraz hotelu Eco Tatry w Kościelisku. Obiekty udostępniły ostrzeżenia o zaistniałej sytuacji, lecz bez dodatkowych informacji o szczegółach incydentu. W przypadku Murowańca w oświadczeniu schroniska pojawiła się informacja o zewnętrznym źródle wycieku danych rezerwacyjnych. Według ustaleń znajdowały się one na serwerze firmy dostarczającej system do obsługi rezerwacji. Oświadczenie firmy nie pozwoliło jednak na jednoznaczne określenie jak doszło do przełamania zabezpieczeń i nieautoryzowanego dostępu do danych gości.

Znany scenariusz

Tego typu ataki uderzające w branżę hotelarską i ich gości mogą się wzmagać szczególnie w okresie zwiększonego zainteresowania turystyką. Przede wszystkim w wakacje, ferie, okolice świąt i długie weekendy. Od kilku lat regularnie wracają ostrzeżenia o fałszywych wiadomościach na Booking, ale warto nie tracić czujności także na innych platformach. Według analityków Sekoia podobne ataki mają miejsce w serwisach Agoda, Expedia i Airbnb. Analizując fałszywe strony można trafić także na szablony uniwersalne, wykorzystujące nazwy takie jak „Reservation Manager”. Może to być rozwiązaniem stosowanym w przypadku danych rezerwacji pozyskanych przez atakujących ze źródeł innych niż przejęte konto obiektu na którejś z popularnych platform do obsługi hotelowej. Dokładnie takie podejście można było zaobserwować na fałszywych stronach po ataku na Murowaniec.

Pisaliśmy już, jak to możliwe, że wiadomości z linkiem do strony phishingowej przychodzą z oficjalnego konta obiektu na platformie rezerwacyjnej. Dla przypomnienia – musiało dojść do nieautoryzowanego dostępu do takiego konta, ale to przejęcie mogło odbyć się na wiele sposobów.

Niebezpieczny załącznik, link i… komunikat błędu?

Jeżeli zagrożenia w sieci dalej kojarzą Wam się jedynie z fałszywymi stronami logowania i złośliwymi załącznikami, warto zwrócić uwagę na ataki z wykorzystaniem ClickFix oraz FakeCAPTCHA. Szerzej opisywaliśmy je już w czerwcowym artykule, ale w tym scenariuszu sposób wykorzystania tych technik bywa wyjątkowy.

Zaczyna się od maila informującego hotel o rzekomym anulowaniu rezerwacji przez gościa. Pod przyciskiem „See Details” kryje się link do strony podszywającej się pod Booking. Tam komunikat błędu skłoni nas do „odświeżenia strony”.

Kliknięcie „Refresh Page” sprawi, że przeglądarka otworzy się w trybie pełnoekranowym. Wyświetlone zostanie coś na kształt znanego niebieskiego ekranu świadczącego o błędzie w naszym systemie Windows. Wykonanie instrukcji widocznych na ekranie ma pozwolić nam przywrócić poprawne działanie systemu. Stąd nazwa techniki – ClickFix – wszystko ma się naprawić za paroma kliknięciami.

W rzeczywistości kopiowane i wykonywane jest polecenie pobierające złośliwe oprogramowanie, które jest następnie uruchamiane. Dla niepoznaki otwiera się także domyślna przeglądarka, a w niej prawdziwy panel logowania na konto Booking. W tle działa już malware, którego jedną z głównych funkcji jest kradzież poświadczeń. Do najcenniejszych należą te, które dają dostęp do kont umożliwiających zarządzanie obiektami na platformach rezerwacyjnych. Takie dane dostępowe mogą być od razu wykorzystane do przejęcia konta i podszycia się pod hotel w komunikacji z klientami.

Nie wykonuj poleceń i kodu, których działania nie znasz lub nie rozumiesz. Pośpiech jest tu niewskazany, warto się zastanowić dwa razy, czy wiemy, co tak naprawdę robimy.

Co robić jeśli rezerwujesz pobyt?

W przypadku otrzymania wiadomości o konieczności potwierdzenia rezerwacji, do czego konieczne jest pobranie pliku, wykonanie działań zgodnie z niestandardową instrukcją lub wejście w link do strony, gdzie mamy się zalogować – warto wstrzymać się z pochopnymi działaniami.

Najpierw, najlepiej skontaktować się z obiektem, telefonicznie lub mailowo, ale zgodnie z danymi podanymi na oficjalnej stronie hotelu. Nie korzystaj z informacji zawartych w wiadomości lub na stronie, która wzbudziła nasze podejrzenia. Ostrożnie należy podchodzić do komunikacji zarówno na platformach takich jak Booking, ale także mailowej czy na komunikatorach (np. WhatsApp). Atakujący zawsze znajdą sposób na dotarcie do ofiar, wzbudzenie zaufania i zbudowanie presji czasu.

Właściciele biznesów przyzwyczają nas do zróżnicowanych kanałów wymiany wiadomości, ale zawsze warto potwierdzić, czy konkretny sposób jest oficjalny i prawdziwy, czy jest może próbą podszycia się pod obiekt.

Dla właścicieli i zarządzających obiektami

Wiele publikacji skupia się na zaleceniach dla gości dotkniętych atakami, ale rola w prewencji i reakcji po stronie właścicieli hoteli jest nieoceniona. Podstawowa higiena cyfrowa, zasada ograniczonego zaufania do otrzymywanych wiadomości lub komunikatów i wdrożenie systemów bezpieczeństwa może zmniejszyć prawdopodobieństwo powodzenia takiego ataku. Niestety, na niektóre scenariusze ma się niewielki wpływ. Takim przykładem są incydenty w firmie trzeciej obsługującej system rezerwacyjny, gdzie przetwarzane są dane gości.

Niezależnie od jego przebiegu, konsekwencje takiego ataku można ograniczyć. Kluczowa jest szybka reakcja zarządzających obiektem, odzyskanie dostępu do przejętych kont i skutecznie skontaktowanie się z gośćmi, którzy otrzymali wiadomości od oszustów. Niezbędna jest w takiej sytuacji wnikliwa analiza incydentu wraz z odpowiedziami na pytania:

• Czy wiadomości były skierowane do przypadkowych osób, czy do gości hotelu?
  – Jeżeli byli to tylko goście z rezerwacjami, skąd atakujący mieli dostęp do bazy klientów?
• Czy w ostatnim czasie zaobserwowano niestandardową komunikację, która wyglądała jak wiadomość od gościa, platformy Booking lub podobnej?
  – Czy wiadomość zawierała linki, załączniki lub instrukcje do wykonania?
  – Czy miała miejsce interakcja z linkiem, załącznikiem, bądź wykonano opisywane działania?
• Czy wykorzystywany jest zewnętrzny system do zarządzania rezerwacjami?
  – Czy dane są przechowywane u dostawcy takiego rozwiązania?
  – Czy dostawca informował o potencjalnym incydencie w jego infrastrukturze?

W przypadku podejrzenia uzyskania nieuprawnionego dostępu do kont, konieczna jest zmiana haseł, ustawienie dwuskładnikowego uwierzytelniania tam, gdzie to możliwe. Kluczowa jest także analiza aktywności w systemach rezerwacyjnych i wiadomości z czasu, kiedy miał miejsce nieautoryzowany dostęp do kont. W przypadku potwierdzenia incydentu należy pamiętać o zgłoszeniu go do odpowiednich organów w tym PUODO i CERT Polska.

Infekcja służbowego urządzenia złośliwym oprogramowaniem nie kończy się na kradzieży poświadczeń do platformy rezerwacyjnej. Zagrożone mogą być inne konta, w tym dane dostępowe do bankowości elektronicznej i paneli zarządzania usługami (na przykład świadczonymi przez operatora). Zmiana haseł może nie być wystarczająca, jeżeli atakujący dalej mają dostęp do urządzenia. Niewykluczone, że profesjonalne wsparcie będzie konieczne do wyeliminowania wszystkich skutków incydentu i ocenienia jego wpływu na przetwarzane dane oraz wykorzystywaną infrastrukturę.

Orange Polska bierze udział w finansowanym przez Unię Europejską projekcie ThreatChase (ThreatChase – Open Platform for Protection against Phishing). Celem projektu jest stworzenie i wprowadzenie platformy wspomagającej strukturyzację danych w zakresie phishingowych adresów i domen oraz proaktywnie zapobiegającej skutkom ataków phishingowych. Obserwuj ThreatChase na LinkedIn.

The post Rezerwujesz nocleg na ferie? Uważaj na te oszustwa! appeared first on CERT Orange.

W obu przypadkach rozpoczyna się od wiadomości tekstowej sugerującej konieczność podjęcia działania. Albo w odniesieniu do zwrotu nadpłaty (PGE) albo wygasających „punktów Santander” (bank nie prowadzi programu lojalnościowego pod marką własną).

Na pewno nie oddadzą, zapewne zabiorą

W przypadku oszustwa na PGE link w SMS-ie prowadził na witrynę przypominającą stronę logowania na stronie dostawcy energii. Wiadomości były nadsyłane ze zwykłych numerów.

W momencie analizy witryna docelowa hxxps://renewsubsriptions[.]site/.well-known/PGE.pl.php już nie funkcjonowała. Bazując jednak na podobnych przypadkach można z dużym prawdopodobieństwem założyć, iż pod powyższym adresem trafilibyśmy na bramkę do wpisania danych karty płatniczej. Tak więc choć przekaz w SMS-ie sugeruje zwrot nadpłaty, oszuści obciążyliby naszą kartę do wysokości limitu.

Phishing SMS na nieistniejący program

Bank Santander to jeden z popularniejszych celów sieciowych przestępców. Dowodzi tego choćby częstotliwość poświęconych mu artykułów na naszej stronie. Tym razem jednak oszuści nie podszywają się pod Mastercardowy program Bezcenne Chwile (prowadzony również przez Santander) lecz informują o wygasających punktach „Santander Bank”. Warto zwrócić uwagę, że przestępcy postarali się o dość dobrą domenę, licząc, że ofiara widząc ciąg santander-pl nie zwróci uwagi, że między nimi nie ma kropki i adres tak naprawdę nie kończy się na .pl. Istotne jest też to, iż ten phishing SMS przychodził od nadawcy „Santander”.

Co dzieje się dalej? „Logujemy” się numerem telefonu:

następnie, po obejrzeniu katalogu rzekomych nagród, jesteśmy proszeni o podanie danych osobowych:

i – na koniec – podanie danych karty płatniczej.

Jak nie dać się oszukać?

Warto po raz kolejny powtórzyć 5 najważniejszych kwestii, co zrobić, gdy przychodzi do Ciebie SMS wymagający interakcji:

• sprawdź jego nadawcę
• jeśli przychodziły już do Ciebie SMS-y od tego nadawcy – sprawdź, czy ten wygląda tak samo/podobnie
• jeśli wiadomość zawiera linki – sprawdź je dokładnie; uważaj na adresy inne, niż kończące się na .pl lub ewentualnie .com
• myślisz, że wiadomość może być prawdziwa – zaloguj się do systemu usługodawcy wpisując własnoręcznie adres w przeglądarce i sprawdź, czy jest dla Ciebie korespondencja
• jeśli wciąż masz wątpliwości – skontaktuj się z infolinią

Orange Polska bierze udział w finansowanym przez Unię Europejską projekcie ThreatChase (ThreatChase – Open Platform for Protection against Phishing). Celem projektu jest stworzenie i wprowadzenie platformy wspomagającej strukturyzację danych w zakresie phishingowych adresów i domen oraz proaktywnie zapobiegającej skutkom ataków phishingowych. Obserwuj ThreatChase na LinkedIn.

The post Phishing SMS na „punkty Santander” i „fakturę PGE” appeared first on CERT Orange.

DDoS to jeden z tych typów zagrożeń, które przez lata były traktowane jako „problem kogoś innego”. Dopóki atak nie uderzy bezpośrednio w usługę, klienta albo krytyczny element infrastruktury – łatwo go bagatelizować. Tymczasem ostatnie lata – a w szczególności miesiące – dowodzą, że skala i brutalność ataków wolumetrycznych rosną szybciej niż świadomość zagrożeń.

Rekordowy atak DDoS w Wigilię

Data, którą napastnicy wybrali na rekordowy atak DDoS nie była przypadkowa. Okres świąteczny to tradycyjnie moment obniżonej czujności oraz funkcjonowania operacyjnych zespołów cyberbezpieczeństwa w ograniczonych składach. Pamiętajmy też o dużym obciążeniu sieci ruchem „legalnym”.

Odnotowany atak osiągnął poziom 1,5 Tbps / 134,5 Mpps. Te liczby same w sobie obrazują zmianę w krajobrazie DDoS-ów. Nie mówimy już o incydentach, które „zapychają łącze klienta”. To są już wolumeny, które w przypadku braku odpowiedniej ochrony mogą stanowić realne zagrożenie dla infrastruktury operatorskiej. 

Celem ataku był pojedynczy adres IP. To istotny szczegół wskazujący, że w praktyce celem mógł być dowolny pojedynczy użytkownik sieci funkcjonujący za tym adresem. Taki model ataku pokazuje, że dziś ofiara nie musi posiadać własnej infrastruktury ani publicznych usług, aby stać się celem.

Klasyczny DDoS wolumetryczny 

Z technicznego punktu widzenia był to klasyczny atak wolumetryczny, którego celem było wyczerpanie dostępnej przepustowości. Zastosowano jednocześnie kilka technik: IP Fragmentation, Total Traffic Flood, DNS Flood, UDP Flood, NetBIOS Amplification.

Wspominany na wstępie drugi co do wielkości atak DDoS na naszą sieć, który miał miejsce w maju mijającego roku, potwierdza, że nie mamy do czynienia z odosobnionym incydentem. To element szerszego trendu. Ataki liczone w setkach gigabitów są już codziennością, a – jak widać – atakującym zdarza się uderzać z mocą terabitów na sekundę. Co więcej – tak silne ataki przestają być domeną globalnych graczy i coraz częściej pojawiają się w sieciach krajowych.

Paradoksalnie mimo rosnącej skali DDoS-y wciąż nie są postrzegane jako jedno z kluczowych zagrożeń. Dlaczego? Ponieważ:

• nie prowadzą do kradzieży danych
• nie szyfrują systemów
• nie zostawiają artefaktów na systemach
• po skutecznej mitygacji „nic się nie stało”

I te błędne założenia warto zmienić. Warto traktować te ataki jako istotne dla internetu.

Z perspektywy użytkownika sieci taki atak często pozostaje niezauważalny – po prostu „nic się nie stało”. Usługi działają, nie ma przerw ani komunikatów. Ale to właśnie jest najlepszy dowód, że zespoły bezpieczeństwa po stronie operatora wykonały swoją pracę, a ochrona zadziałała, powstrzymując rekordowy atak DDoS. Brak wpływu nie oznacza braku ataku. Dowodzi jedynie, że po stronie operatora wdrożona została odpowiednia architektura, przygotowane narzędzia, a za komputerami siedział zespół, który wie, co robi.

Jednocześnie trzeba pamiętać, że każdy atak jest inny. DDoS to nieustannie zmieniający się krajobraz, który wymaga ciągłej obserwacji, analizy i dostosowywania się do nowych technik oraz rosnących wolumenów.

The post Rekordowy atak DDoS w sieci Orange Polska – skala i brutalność rosną appeared first on CERT Orange.

Aplikacja

Początkowy wektor ataku sprawia, że wygląda on na powszechną kampanię, jakie są obecnie prowadzone. Adwersarz, poprzez socjotechnikę, zachęca wybraną ofiarę do pobrania i zainstalowania aplikacji mobilnej (podszywającej się pod inną zaufaną aplikację). Pobierana, w postaci pliku apk, aplikacja jest typowym dropperem. Dropper to rodzaj złośliwej aplikacji, której zadaniem jest dostarczenie i uruchomienie ukrytego w sobie lub na urządzeniu payloadu, zwykle w postaci jednorazowego rozpakowania lub rozkodowania wbudowanego malware. W tym przypadku ma on za zadnie uzyskać akceptacje niezbędnych uprawnień od użytkownika (poprzez zaprezentowanie ekranów z zaufanej aplikacji) po czym instaluje i uruchamia drugą aplikację (stage 2), pobieraną z lokalizacji \assets\apk\target.apk.  

Zainstalowana aplikacja w istocie jest kolejnym dropperem. Analiza tej fazy ataku nie zdradza funkcjonalności tej aplikacji i na pozór nie widać w niej nic złośliwego. Na tym etapie następuje pobranie z zasobów aplikacji pliku o rozszerzeniu json (plik posiada entropię równą 7.99, co wskazuje na wysokie upakowanie lub zaszyfrowanie; w istocie jest on kontenerem zawierającym zaszyfrowaną bibliotekę dex dołączaną do właściwej aplikacji). Plik jest zaszyfrowany symetrycznym szyfrem strumieniowym RC4 (KSA/PRAGA). Klucz do odszyfrowania jest łatwy do zlokalizowania w zdeasemblowanym kodzie.  Po odszyfrowaniu uruchamiane są funkcje ukryte uprzednio w tej bibliotece. A są to takie funkcjonalności jak:

• Rejestrowanie i przekazywanie obrazu w czasie rzeczywistym (screen streaming)
• Zdalne zarządzanie urządzeniem (VNC / RDP over Accessibility,  real-time operator control)

Początkowo program był identyfikowany jako RAT, jednak analizując funkcjonalności i zarządzanie programem, można było dojść do wniosku, że jest to złośliwa aplikacja będąca zaawansowanym spyware (RCS – Remote Control System).

W trakcie analizy zidentyfikowano wielowarstwową architekturę komunikacji typu command-and-control (C2), zaprojektowaną w sposób umożliwiający długotrwałe, skryte oraz ręcznie sterowane utrzymanie dostępu do zainfekowanego urządzenia. Model komunikacji opiera się na rozdzieleniu funkcji sygnalizacji, orkiestracji zadań (zarządzania) od interaktywnego dostępu zdalnego, co pozwala na ograniczenie widoczności ruchu sieciowego oraz obejście klasycznych mechanizmów detekcji opartych na analizie beaconingu.

Dalsza część analizy skupia się na tym nieoczywistym sposobie komunikacji złośliwej aplikacji. Przedstawiono działanie komponentu komunikacyjnego, sposób inicjowania połączenia z serwerem kontrolującym oraz obserwowane artefakty świadczące o przygotowaniu do długotrwałej obecności na urządzeniu.

Command and Control 

Centralnym elementem infrastruktury jest serwer Command and Control (C2) dostępny przez protokół HTTPS, pełniący funkcję rejestru urządzeń, repozytorium konfiguracji oraz punktu koordynacji zadań. C2 jest bezpośrednio obsługiwany przez operatora, który w ręczny sposób inicjuje działania oraz zarządza sesjami dostępowymi do poszczególnych urządzeń. Komunikacja pomiędzy operatorem a złośliwą aplikacją odbywa się przy użyciu standardowych interfejsów webowych lub API, co utrudnia jednoznaczną identyfikację złośliwej aktywności na poziomie ruchu sieciowego.

Po stronie zainfekowanego urządzenia, to klasa BackendApi zarządza pełną komunikacją urządzenia z serwerem C2 operatora. Moduł ten realizuje m.in.:

• rejestrację urządzenia w panelu adwersarza,
• heartbeat,
• pobieranie (poolingiem) komend,
• wysyłanie zdarzeń pojedynczych i wsadowych (batch),
• upload list aplikacji,
• pobieranie informacji o systemie,
• wysyłanie identyfikatorów oraz całej telemetrii.

Widać tutaj implementację stabilnego identyfikatora urządzenia (generateStableDeviceId) – opartą na android_id. Metoda ta generuje stały tracking ID, który wykorzystywany jest przez cały czas w trakcie działania aplikacji. Na początku zbierane są dane środowiskowe, tj: 

• poziom i status ładowania baterii,
• typ połączenia sieciowego,
• aplikacje działające w tle (foreground application),
• listy zainstalowanych aplikacji,
• informacje o karcie SIM (karta, operator, numer telefonu – jeśli możliwe),
• informacje o pamięci urządzenia,
• informacje o stanie ekranu,
• IP zewnętrzne.

Jest to profilowanie urządzenia przed dalszą eksploitacją oraz wdrożeniem zdalnego zarządzania (RMM). Tak precyzyjne profilowanie ofiary jest typowe dla wąskiej grupy ataków, w której atakujący dokonuje dalszych etapów infekcji w zależności od tego kto jest ofiarą. Unika w ten sposób przypadkowych infekcji i zwiększa szansę na pozostanie w ukryciu.

W przypadku kontynuacji ataku, adwersarz z serwera C2 przekazuje konfigurację tunelu Fast Reverse Proxy (FRP), który następnie pozwala mu na dostęp do urządzenia. Parametry FRP (adres serwera, port, token) dostarczane są dynamicznie w czasie działania aplikacji (tzw. runtime) i nie są na stałe zapisane w aplikacji (hardcodowane). Mechanizmy polling i heartbeat umożliwiają operatorowi regularne wysyłanie poleceń oraz zbieranie informacji telemetrycznych o urządzeniu, w tym listę aplikacji, stan baterii, typ połączenia sieciowego, informacje o pamięci i SIM oraz aktualnie aktywnej aplikacji. Tunel FRP, natomiast, jest inicjowany wyłącznie po otrzymaniu konfiguracji z backendu złośliwej aplikacji i w konsekwencji pozwala na interakcję operatora z urządzeniem, przy czym serwer FRP znajduje się w infrastrukturze atakującego poza urządzeniem i kanałem HTTPS.

FCM – Firebase Cloud Messaging

Do realizacji kanału sygnalizacyjnego wykorzystywana jest usługa Firebase Cloud Messaging (FCM). Jest to usługa Google przeznaczona do asynchronicznego dostarczania komunikatów push do aplikacji mobilnych oraz klientów webowych. W legalnych zastosowaniach służy do wysyłania powiadomień, synchronizacji danych lub wyzwalania akcji aplikacji bez konieczności utrzymywania stałego połączenia sieciowego. Z technicznego punktu widzenia FCM działa jako broker komunikatów, w którym aplikacja po instalacji rejestruje się w infrastrukturze Google i otrzymuje unikalny token lub subskrybuje określony temat (topic). Serwer aplikacji wysyła komunikaty do Google, a Google dostarcza je do właściwych urządzeń, nawet jeśli aplikacja nie jest aktywna, a telefon znajduje się w stanie uśpienia. Kluczową cechą FCM jest to, że ruch sieciowy odbywa się wyłącznie pomiędzy urządzeniem a infrastrukturą Google, co powoduje, że z perspektywy sieci i systemów bezpieczeństwa komunikacja wygląda jak w pełni legalny ruch systemowy Androida.

Dla funkcjonalności FCM, w klasie konfiguracyjnej (rys. 1), umieszczono kluczowy parametr:

private static final String FCM_TOPIC = „device_commands”;

Oznacza to, że aplikacja subskrybuje globalny temat FCM, a nie indywidualny token. Każde urządzenie, na którym aplikacja jest zainstalowana, dołącza do tego samego logicznego kanału komunikacji. W praktyce oznacza to, że operator C2 może wysłać jedno polecenie, które zostanie dostarczone przez Google do dowolnej liczby zainfekowanych urządzeń, bez bezpośredniego łączenia się z nimi.

FCM w tym rozwiązaniu nie służy do przesyłania danych operacyjnych, lecz do asynchronicznej sygnalizacji sterującej. Operator C2 wysyła push do urządzenia (poprzez usługę i infrastrukturę Google), który jest odbierany w onMessageReceived(), a otrzymany w push’u JSON jest zamieniany na wewnętrzny identyfikator polecenia. Następnie następuje mapowanie JSON → metoda executeXYZ(), czyli bezpośrednie przeniesienie kodu rozkazującego na konkretne moduły funkcjonalne malware. Każde z wywołań nie tylko uruchamia jednostkową akcję, ale również aktywuje lub rekonfiguruje podsystemy trwałości i nadzoru: inicjalizację FRPC, odświeżenie rejestracji klienta, konfigurację warstwy overlay, kanał WebSocket, uwierzytelnienie tunelu, screen-stream, heartbeat, system logowania zdarzeń. W efekcie FCM pełni rolę kanału sygnalizującego klasy „wake+task”, w którym push nie przenosi komendy operacyjnej, lecz sygnalizuje konieczność pobrania jej z Backend API – to zapewnia oszczędność energii, redukuje ślad sieciowy, eliminuje cykliczne połączenia DNS/HTTP i znacząco podnosi poziom ukrycia (stealth mode).

Mając taki model, C2 dysponuje kategoriami komend sterowanych przez FCM, które dają pełne pokrycie funkcjonalne urządzenia. Komendy komunikacyjne (np. executeEnableWebSocket() czy executeDisableWebSocket()) pozwalają włączać i wyłączać WebSocket oraz tunel FRPC, a więc sterować kanałem zdalnego dostępu. Komendy dotyczące ciągłości łączności (heartbeat, polling) zapewniają fallback i utrzymywanie sesji bez telemetrii okresowej. Komendy instrumentacyjne inicjują żądania uprawnień, restart usług Accessibility lub MediaProjection oraz „wybudzenie” aplikacji na front UI. Segment screen-capture pozwala włączać/wyłączać usługę przechwytywania ekranu i obsługiwać overlay umożliwiający kliknięcia przestępcy. Event-logger to kolejna warstwa klasy operatorskiej – konfiguracja logowania, pobieranie liczników, flush zdarzeń – czyli przydatna telemetria. Wreszcie, polecenia statusowe (executePing(), updateCommandStatus()) utrzymują pętlę zgłaszania stanu, co stanowi dla operatora quasi-RTT (Round-Trip Time).

Jednym z kluczowych elementów jest uruchomienie klienta FRP (frpc – Fast Reverse Proxy Client), który zestawia połączenie wychodzące typu reverse tunnel do serwera pośredniczącego (frps – Fast Reverse Proxy Server) kontrolowanego przez operatora. Tunel ten umożliwia zdalny, interaktywny dostęp do funkcji urządzenia bez konieczności wystawiania jakichkolwiek portów po stronie ofiary. Całość komunikacji realizowana jest jako połączenie wychodzące z urządzenia, co pozwala ominąć zapory sieciowe oraz ograniczenia NAT.

To jest dokładnie ten model, który obserwujemy w zaawansowanych rodzajach malware mobilnego i narzędziach klasy komercyjnego spyware, gdzie push zastępuje stałe połączenia TCP i minimalizuje artefakty, logi oraz możliwość detekcji przez rozwiązania sieciowe.

FRP – Fast Reverse Proxy

Po otrzymaniu zdalnej komendy z FCM, aplikacja najpierw kontaktuje się z BackendAPI operatora, ponieważ to ono pełni funkcję kontrolną i rozdziela konfigurację sieciową dla kanałów zdalnego dostępu. W ramach tej komunikacji pobierany jest aktualny profil konfiguracyjny dla FRP, obejmujący adres serwera FRPS, porty, typ tunelu, klucze autoryzacyjne oraz ewentualne parametry dotyczące protokołu WebSocket wykorzystywanego do transmisji ekranu lub ruchu sterującego. Sam klient FRPC nie jest kompilowany w kodzie aplikacji – zostaje wydobyty z zasobów jako zakodowany plik binarny, po czym zostaje zdekodowany i zapisany jako wykonywalny plik, co pozwala uruchomić go poza cyklem życia aplikacji malware (rys. 2).

Gdy binarka klienta proxy jest już przygotowana, aplikacja uruchamia FRPC jako osobny proces systemowy – po to, by utrzymać stały tunel nawet wtedy, gdy Android zabije proces nadrzędny. Ten proces nawiązuje pierwotne połączenie do serwera FRPS zgodnie z otrzymanymi parametrami i natychmiast przekazuje operatorowi swój status uwierzytelnienia. W rezultacie dochodzi do rejestracji klienta po stronie serwera FRPS, co pozwala operatorowi widzieć infekcję jako dostępne urządzenie z unikalnym identyfikatorem. FRPC przechodzi następnie w stan idle / keep‑alive, czyli utrzymuje kanał sterujący, ale nie tworzy jeszcze aktywnego ruchu reverse‑proxy, dopóki operator nie zażąda sesji.

W tej fazie urządzenie oczekuje na zdalne zestawienie połączenia odwrotnego, a więc na sytuację, w której to serwer FRPS otworzy wejściowy port i poprowadzi ruch w dół tunelu wprost do telefonu. Gdy operator wyśle taką inicjację, FRPC zestawia konkretny tunel – TCP, WebSocket, RDP‑like, ADB-over‑TCP lub ekranowy streaming – i mapuje go na lokalny port w telefonie. Ponieważ tunel działa jak router portów, aplikacja nie musi mieć logicznych funkcji RAT – operator może podpiąć dowolne narzędzia, które działają lokalnie w systemie, np. WebDriver Accessibility, MediaProjection do obrazu ekranu, key‑overlay lub terminal.

W dalszym przebiegu tunel jest utrzymywany przez heartbeat FRP, co w praktyce oznacza ciągłe podtrzymywanie łącza bez konieczności beaconingu przez malware. Jeżeli kanał ulegnie przerwaniu, binarka sama wykona reconnect, a jeśli system zabije proces, aplikacja znów wystartuje go przez usługę rezydencyjną. To końcowo prowadzi do sytuacji, w której telefon pozostaje w pełni dostępny dla operatora jako zasób sieciowy, gotowy do manualnego sterowania.

Zestawiony tunel FRP stanowi główny kanał operacyjny, wykorzystywany do prowadzenia sesji zdalnych, w tym sterowania interfejsami systemowymi, przechwytywania obrazu ekranu, interakcji z aplikacjami oraz realizacji dalszych działań postkompromitacyjnych. Operator uzyskuje dostęp do urządzenia poprzez infrastrukturę FRP, a nie bezpośrednio, co dodatkowo utrudnia atrybucję oraz analizę topologii ataku. Wszystkie zidentyfikowane połączenia sieciowe inicjowane są wyłącznie z poziomu zainfekowanego urządzenia. Nie zaobserwowano mechanizmów nasłuchowych ani bezpośrednich połączeń przychodzących. Komunikacja z infrastrukturą Google (FCM), backendem C2 oraz serwerem FRP realizowana jest z użyciem powszechnie stosowanych protokołów i usług chmurowych, co pozwala na skuteczne maskowanie złośliwego ruchu w legalnym tle sieciowym.

Choć malware utrzymuje klasyczny kanał HTTPS z Backend API – wykorzystywany głównie do pobierania konfiguracji, potwierdzania komend, aktualizacji parametrów sesji i raportowania statusów – ten kanał nie jest warstwą transakcyjną dla zdalnego sterowania urządzeniem. Backend API pełni rolę sygnalizacyjną i administracyjną (kontrola, telemetria, rejestracja urządzenia), natomiast funkcję rezydencyjną i operacyjną przenosi dedykowany proces FRPC, uruchamiany jako osobny proces i utrzymujący stały kanał typu reverse‑proxy. W efekcie komunikacja dzieli się na trzy warstwy: FCM jako „asynchroniczny budzik”, BackendAPI jako panel administracyjny malware oraz FRP jako właściwy kanał operacyjny, który materializuje dostęp zdalny do urządzenia.

Podsumowanie

Zastosowana architektura, obejmująca separację kanałów komunikacji, wykorzystanie zewnętrznej infrastruktury chmurowej do sygnalizacji oraz manualnie sterowany dostęp interaktywny, wskazuje na zaawansowany charakter operacji. Tego typu rozwiązania są typowe dla działań ukierunkowanych, prowadzonych z udziałem operatora, a nie dla masowych kampanii zautomatyzowanego złośliwego oprogramowania. W przypadku tego malware nie podjęto się przeprowadzenia atrybucji. Zidentyfikowana kampania charakteryzuje się cechami operacji o podwyższonym stopniu ukierunkowania i planowania, co uzasadnia klasyfikację zagrożenia jako APT-grade malware. W analizowanym przypadku operator nie opiera się na dystrybucji masowej, ale prowadzi działania wymagające precyzyjnej kontroli nad pojedynczym urządzeniem. Mechanizm komunikacji oparty o kanał zwrotny, dynamiczne pobieranie parametrów pracy oraz możliwość tunelowania FRP wskazują na operacyjną potrzebę utrzymywania długotrwałego, nieobserwowalnego dostępu, typowego dla tradecraftu grup APT lub zaawansowanych cyber-crime-as-a-service.

Na poziomie infrastrukturalnym obserwowana domena była aktywna jedynie przez ok. 10 dni, została zarejestrowana, stworzono dla niej certyfikat SSL i po zakończeniu fazy operacyjnej wyrejestrowana. Taka sekwencja – krótkie okno ekspozycji (eksploatacji), wymuszenie szyfrowania komunikacji, szybkie porzucenie zasobu – odpowiada modelowi szybkiej, jednorazowej infrastruktury typu „burn-after-use”, stosowanej w kampaniach, które zakładają ryzyko deanonimizacji operatora. Nie jest to charakterystyka działań typowych dla niskiego szczebla cyberprzestępczości, która wykorzystuje domeny (często tanie i długoletnie) i ją porzuca, panele gotowe lub rotację ograniczoną kosztowo. Tutaj widoczny jest koszt operacyjny i intencja zacierania śladów.

Wektor komunikacji dowodzi, że oprogramowanie nie jest standardem trojana, ale stanowi mechanizm dostępowo-wywiadowczy. Aplikacja utrzymuje kontrolę operatorską poprzez FCM push do urządzenia, wykonuje telemetryczne heartbeat, pobiera konfigurację C2, a następnie aktywuje klienta Fast Reverse Proxy z parametrami dystrybuowanymi dynamicznie. Rezultatem jest dwukierunkowy kanał do wnętrza ekosystemu użytkownika, z możliwością ekspozycji usług lokalnych bez konieczności posiadania publicznego IP po stronie ofiary.

Próbki są generowane i modyfikowane per-install, konfiguracja FRP pobierana jest za każdym razem w modelu efemerycznym, a domeny i certyfikaty charakteryzują się krótką żywotnością. Cechy te uniemożliwiają budowanie tradycyjnych sygnatur detekcyjnych i dodatkowo sugerują aktora stosującego operational security, obliczoną rotację infrastruktury i minimalizację śladów wykrywalnych retrospektywnie. W konsekwencji analizowany kod nie jest klasycznym malware commodity, lecz narzędziem zdolnym do precyzyjnego sterowania urządzeniem, ukrytej łączności i kontroli operatorskiej – parametry te lokują go w spektrum TTP wykorzystywanych przez grupy APT lub podmioty komercyjnie świadczące takie zdolności.

W kontekście atrybucji warto odnotować, że próbka prezentuje dwa wyraźnie odmienne modele podejścia do zaciemniania kodu – i oba odbiegają od standardowych praktyk dla mobilnego malware. Po odszyfrowaniu głównego komponentu aplikacja zachowuje spójną i czytelną strukturę: utrzymano jawne nazwy klas, metod i zmiennych, nie widać śladów automatycznej obfuskacji, a część modułów implementuje lokalne mechanizmy logowania zdarzeń do plików, co jest rzadkością w kodzie pisanym z myślą o ukrywaniu aktywności. Taki profil sugeruje wysoki poziom kompetencji programistycznych oraz nawyki charakterystyczne raczej dla profesjonalnego wytwarzania oprogramowania niż dla kodu pisanego wyłącznie pod dystrybucję malware.  Jednocześnie inna warstwa aplikacji – obejmująca „silnik” operacyjny i zależności konstrukcyjne – jest już obfuscowana: klasy pozbawione są semantycznych nazw, występują struktury z automatycznie generowanymi identyfikatorami pól i mapowaniami (SparseIntArray → indeks → wartość), co utrudnia rekonstrukcję przepływu logicznego. Takie rozbieżności wskazują na proces rozwojowy, w którym część kodu mogła zostać przeniesiona z istniejącej, legalnej bazy wykonawczej (lub utrzymana przez doświadczonych programistów), a dopiero elementy operacyjne – odpowiedzialne  za wiązania klas, parametry działania i logikę wywołań – zostały poddane automatycznemu zaciemnianiu. Nie można wykluczyć, że implementacja była realizowana zespołowo, a część osób rozwijających kod mogła nie mieć pełnej świadomości operacyjnego przeznaczenia aplikacji.

Ze względu na powyższe nie wskazujemy wprost sygnatury badanej próbki oraz IoC sieciowych.

The post Operacyjna analiza kanałów komunikacyjnych mobilnego RCS’a appeared first on CERT Orange.

Nie ma złej pory na to, by uczyć bliskich jak uniknąć zagrożeń. Co więcej – święta wydają się być jednym z lepszych momentów, wtedy bowiem zazwyczaj najbliższych mamy tuż obok. I nie mają dokąd uciec

Telefon/urządzenie połączone z internetem pod choinką – co zrobić?

Telefony komórkowe to nieodłączny element naszego życia, co do tego nie ma wątpliwości. A ilu internautom przeszło przez myśl, by po wyciągnięciu z pudełka nowego urządzenia już na etapie wstępnej konfiguracji zająć się jego zabezpieczeniem? A coraz popularniejsze urządzenia Internetu Rzeczy? Nierzadko ich domyślna konfiguracja bywa na bakier z bezpieczeństwem. W czym pomóc po świątecznej kolacji członkowi rodziny, który znajdzie pudełko z taką zawartością pod choinką?

W przypadku smartfona:

• zadbajcie o odpowiednią blokadę urządzenia (odcisk palca, w przypadku iPhone’a – Face ID)
  • niech będący dodatkowym zabezpieczeniem PIN będzie nieoczywisty
• uruchomcie uwierzytelnianie dwuskładnikowe na koncie Google/Apple
  • wtedy w przypadku zalogowania kontem użytkownika na innym urządzeniu niezbędna będzie akceptacja komunikatu push lub wpisanie SMS-owego kodu
• wyjaśnij, dlaczego bliska osoba nie powinna instalować aplikacji z nieznanych źródeł

Przy pozostałych urządzeniach korzystających z internetu:

• zalogujcie się do panelu administracyjnego urządzenia
  • zmieńcie domyślne hasło dostępu
  • jeśli urządzenie nie musi być dostępne z sieci – wyłączcie tę opcję
    jeśli musi – pomóż bliskiemu w konfiguracji sieci/firewalla tak, by ograniczyć ryzyka

A przede wszystkim – porozmawiajcie i wyjaśnij dlaczego to robisz. Uświadom bliską osobę w kwestii:

• ryzyk związanych z przejęciem kontroli nad telefonem przez osobę niepowołaną (w tym np. możliwości przejęcia kont do których loguje się adresem e-mail)
• wrażliwych/prywatnych danych, które przechowujemy na telefonie
• dlaczego nie powinniśmy używać tego samego hasła w kluczowych serwisach/witrynach
• na czym polega działanie menedżera haseł, że to nic trudnego i warto z niego korzystać
• jakie ryzyka wiążą się z dostępem do urządzenia Internetu Rzeczy podpiętego do jej/jego domowej sieci

Na wigilijnej wieczerzy naucz ostrożności w sieci

Na tych łamach regularnie ostrzegamy o nowych zagrożeniach w sieci i schematach zachowań przestępców. Wielokrotnie powtarzamy kilka prostych rad, które znacząco ograniczą ryzyko padnięcia ofiarą oszustów. Ale czytanie na stronie to jedno. Dyskusja w rodzinnym gronie podczas wigilijnej wieczerzy to znacznie bardziej przyjazne okoliczności. Wspomnij więc bliskim mimochodem, by (i wyjaśnij dlaczego):

• byli bardzo ostrożni, gdy dostaną wywołującą silne emocje informację od nieznanej osoby/firmy
• w każdej sytuacji, gdy muszą się zalogować od jakiegoś serwisu, upewniali się, czy adres w pasku przeglądarki jest właściwy
• gdy niespodziewany mail wymaga od nas podjęcia działań (pobranie załącznika, kliknięcie w link i wykonanie komend, czy zalogowanie się) – dokładnie sprawdzili adres nadawcy
• jeśli ktokolwiek dowolnym kanałem komunikacji prosi ich niespodziewanie o pieniądze – przerwali rozmowę i zadzwonili do domniemanego rozmówcy
  • ten kontakt musi odbyć się innym kanałem – jeśli podejrzana wiadomości trafia do nich np. Messengerem, trzeba założyć, że konto zostało przejęte i do rzekomego rozmówcy po prostu zadzwonić
• ktoś dzwoni „z banku” i mówi o włamaniu na konto, pyta o rzekomo wzięty kredyt, czy cokolwiek podobnego – należy się rozłączyć i oddzwonić samemu na numer podany na stronie banku
• ustalić w rodzinie hasło, z którego będziecie korzystać w przypadku próby wyłudzenia „na wnuczka”
  • jeśli do seniora zadzwoni ktoś udający dziecko/wnuka (sztuczna inteligencja radzi sobie z tym coraz lepiej) – niech poprosi o hasło; oszust go nie poda, a wtedy mamy pewność, że to próba wyłudzenia pieniędzy
• nie wierzyli od razu we wszystko, co przeczytają/zobaczą w sieci; porozmawiajcie o tym jak rozpoznać materiały wideo stworzone przez sztuczną inteligencję, a także jak – i kiedy – upewnić się, czy budząca emocje treść w sieci nie jest fake newsem

Pamiętaj – każdy może zostać dla swoich bliskich Aniołem Cyberbezpieczeństwa. Nikt nie sugeruje, by czas wigilijnej wieczerzy poświęcić tylko temu tematowi. Bez wątpienia warto jednak wykorzystać okres spędzany wspólnie z rodziną. Edukacja w zakresie cyberbezpieczeństwa to w dzisiejszych czasach, gdy tak duża część naszego życia dzieje się w internecie, to kwestia na której pominięcie nie można sobie pozwolić.

Spokojnych, wesołych, rodzinnych i bezpiecznych – nie tylko w sieci – świąt!

The post O czym po wigilijnej wieczerzy opowiedzieć nietechnicznej rodzinie appeared first on CERT Orange.