BLIK to system płatności mobilnych, polegający na przepisaniu 6-cyfrowego kodu ważnego przez 2 minuty . Można go wprowadzić na terminalu w sklepie, klawiaturze bankomatu albo oknie płatności online. Właśnie z powodu tej prostoty jest bardzo atrakcyjny dla przestępców. Poniżej znajdziesz najpopularniejsze warianty oszustwa na BLIK.

Jak rozpoznać oszustwo na BLIK?

„Mamo/tato, to mój nowy numer” – SMS lub WhatsApp

• W jaki sposób dostajesz wiadomość? Przez SMS lub WhatsApp.
• Pod kogo się podszywają: syna, córkę, wnuka – lub inną bliską osobę.
• Scenariusz: „Mamo, zgubiłam telefon, piszę od koleżanki. Potrzebuję pilnie kodu BLIK na 500 zł, zaraz oddam„
  lub
  „Tato, znalazłem promocję na buty, o których tobie mówiłem. Daj mi BLIKa, bo promocja zaraz się skończy.”
• Co naprawdę się wydarzyło: oszuści mogli uzyskać twój numer z kupionej bazy. Realizują masową wysyłkę i liczą na to, że część odbiorców zawsze zareaguje. W takim przypadku gdy podasz kod BLIK, tzw. „runner” natychmiast wypłaci pieniądze z bankomatu, przesyłając je dalej po odliczeniu prowizji.
• Jak się obronić: zadzwoń na stary numer osoby, która prosi cię o kod BLIK, zanim cokolwiek wyślesz. Nawet jeśli nie odbierze – poczekaj.

Dokładny opis scenariusza „Potrzebuję pieniędzy – SMS z prośbą o kod BLIK” znajdziesz tutaj.

ejęte konto znajomego – Messenger / WhatsApp

• W jaki sposób dostajesz wiadomość? Przez Messenger lub WhatsApp.
• Pod kogo się podszywają: znajomego, którego konto zostało przejęte przez oszusta. Najczęściej po wycieku haseł i braku dwuetapowego uwierzytelnienia. Dostęp do konta na Facebooku zwykle oznacza także dostęp do Messengera.
• Scenariusz:„Hej, możesz mi teraz dać BLIK na 300 zł? Przekroczyłem limity na karcie i pilnie potrzebuję. Oddam jeszcze dziś.”
• Co naprawdę się wydarzyło: przestępca włamał się na konto twojego znajomego i rozsyła wiadomości do jego listy kontaktów.
• Jak się bronić? Zadzwoń do tej osoby i poinformuj o przejęciu konta. Nie podawaj kodu BLIK.

Więcej o tym, jak oszuści przejmują dostępy do kont znajdziesz tutaj.

Fałszywy pracownik banku + bankomat

• W jaki sposób przychodzi wiadomość? Dzwoni do ciebie rzekomo pracownik twojego banku.
• Pod kogo się podszywają: pracownika banku, działu bezpieczeństwa
• Scenariusz: dzwoni do ciebie rzekomy konsultant banku: „Wykryliśmy próbę zaciągnięcia kredytu na pańskie dane. Aby zablokować operację, proszę wygenerować kod BLIK – użyjemy go do weryfikacji tożsamości.”
• Co naprawdę się wydarzyło: w tym scenariuszu kod posłużył do wypłaty gotówki z bankomatu. Bank nigdy nie poprosi cię o kod BLIK przez telefon.
• Jak się bronić? Zawsze w takiej lub podobnej sytuacji rozłącz się i samodzielnie zadzwoń na infolinię banku. Numer znajdziesz na stronie internetowej lub w aplikacji bankowej.

Chcesz dowiedzieć się więcej na temat scenariusza tego oszustwa? Kliknij tutaj.

Fałszywe inwestycje

• W jaki sposób przychodzi wiadomość? Pośrednio, np. na Facebooku trafiasz na reklamę platformy inwestycyjnej. Często wykorzystującej wizerunek celebrytów, wygenerowanych przez AI.
• Pod kogo się podszywają: pod celebrytów reklamujących daną usługę.
• Scenariusz: Rejestrujesz się i na start musisz wpłacić depozyt. Jedną z form płatności może być kod BLIK.
• Co naprawdę się wydarzyło: kod posłużył do wypłaty gotówki z bankomatu. Straciłeś pieniądze.
• Jak się bronić? Fałszywe inwestycje stanowiły większość oszustw, jakie zaobserwowaliśmy przez cały zeszły rok. Takich ofert należy unikać, zwłaszcza gdy są promowane wizerunkiem celebryty.

O skali oszustw, z wykorzystaniem fałszywych inwestycji napisałem tutaj

Ktoś prosi cię o kod BLIK? Jak reagować

• Nie podawaj kodu BLIK. Najpierw zweryfikuj prośbę. Pomocna może być zasada:
  „3 Z: zaczekaj, zadzwoń, zweryfikuj.„
• Czy znasz tę osobę? Skontaktuj się z nią innym kanałem komunikacji.
• Zanim potwierdzisz płatność BLIK, sprawdź, co pokazuje aplikacja bankowa. Przed akceptacją widzisz kwotę transakcji oraz miejsce jej przeprowadzenia. Ktoś prosił o płatność w sklepie, a widzisz bankomat w innej części Polski? To absolutny sygnał ostrzegawczy.

Co powinno cię zaniepokoić, gdy ktoś prosi o kod BLIK?

• Druga osoba wywiera na tobie presję.
• Odzywa się do ciebie osoba, z którą dawno nie miałeś kontaktu.
• Jeśli w aplikacji widzisz „wypłata gotówki z bankomatu”, to pułapka!
• Pracownik banku lub jakiejkolwiek innej instytucji nigdy nie poprosi cię o kod BLIK.

Co zrobić, jeśli padłeś ofiarą oszustwa BLIK?

1. Natychmiast zadzwoń na infolinię banku i zgłoś transakcje, których nie dokonywałeś.
2. Zachowaj dowody – zrzuty ekranu wiadomości i numery telefonów.
3. Pilnie poinformuj znajomych, pod których ktoś się podszywał.

Jeśli podejrzewasz oszustwo na BLIK, najpierw zawsze zweryfikuj prośbę, a dopiero potem podejmuj jakiekolwiek działania.

The post Oszustwo na BLIK: Zobacz jak nie stracić pieniędzy appeared first on CERT Orange.

Booking.com to potentat na rynku turystycznym z przychodami przekraczającymi 17 mld USD (2022). W kwietniu tego roku firma przyznała, iż padła ofiarą włamania, nie informując jednak ile osób mogło być dotkniętych jego efektami. Wiele wskazuje na to, że możemy się o tym dowiedzieć teraz, na początku wakacji.

Oszuści znają Twoje imię i nazwisko

Podejrzane wiadomości z Booking.com to od lat swoisty element wakacyjnego krajobrazu. O oszustwie z podszyciem pod wydawać by się mogło wiarygodne konto dostawcy usługi pisaliśmy dwa lata temu, odnosząc się w tekście do sytuacji z jeszcze wcześniejszych wakacji.

Według potwierdzonych informacji CERT Orange Polska w obecnej kampanii do ofiar trafiają wiadomości zawierające faktyczne numery ich rezerwacji oraz faktyczne personalia osoby, która składała rezerwację. Wiadomości przychodzą przez WhatsApp, a dane nadawcy są zgodne z danymi faktycznego właściciela miejsca noclegowego.

Dalszy ciąg oszustwa „na rezerwację” opisywała na naszych łamach w styczniu, w okresie ferii, Julia Jancelewicz. O podobnym schemacie ostrzegaliśmy też – w tamtym przypadku również chodziło o booking.com – w sierpniu ub.r.:

• oszust podszywa się pod faktycznego usługodawcę za pośrednictwem:
  • WhatsApp
  • lub – w przypadku przejęcia dostępu do konta dostawcy usługi – z interfejsu Booking.com(!)
• ofiara dostaje informację o rzekomych problemach z płatnością
  • ta wygląda wiarygodnie, bowiem zawiera personalia ofiary i faktyczny numer jej rezerwacji
• oszust podsuwa fałszywą stronę do wpisania numeru karty, który od razu trafia w ręce przestępcy

Jak nie dać się oszukać „na Booking.com”?

• Sygnały ostrzegawcze to:
• kontakt przez WhatsApp zamiast oficjalnego panelu
• presja czasu
• prośba o dopłatę przez zewnętrzny link
• płatność poza oficjalną domeną
• wiadomość zawierająca prawdziwe dane, ale prowadząca poza serwis

Prośba o pilną dopłatę do rezerwacji online powinna wzbudzić szczególną ostrożność. Możliwość, że coś takiego będzie miało miejsce, jest tak nikła, że lepiej założyć, iż mamy do czynienia z oszustwem.

Jeśli masz wątpliwości, przede wszystkim sprawdź adres strony docelowej. Kliknięcie w link nie jest groźne – najważniejsze, by nie podawać danych na stronie, co do której nie masz absolutnej pewności, że jest właściwa. W przypadku opisywanej firmy płatności dokonuj wyłącznie w domenie booking.com.

Warto pamiętać: to, że ktoś pisze do Ciebie używając Twoich personaliów i zna numer Twojej rezerwacji – wciąż może być oszustwem! Lepiej być nieufnym niż stracić budżet na całe wakacje.

Co zrobić jeśli podałem/am dane mojej karty?

Przy tego typu kampaniach przestępcy najczęściej okradają ofiary na bieżąco. W takiej sytuacji czas jest kluczowy.

• natychmiast zablokuj kartę, której dane podałeś/aś oszustom
• skontaktuj się z bankiem i poinformuj ich o tym

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 Oszustwo na Booking.com wraca na wakacje. Fałszywe wiadomości na WhatsApp wyłudzają dane kart appeared first on CERT Orange.

Fałszywe SMS-y przychodzą z nadpisu Play24, więc mogą zmylić faktycznych klientów sieci. Oczywiście są one systematycznie blokowane. Treść wiadomości, które trafiły do nas, brzmi:

Podwójna płatność za fakturę. Sprawdź:

Adresy użyte przez oszustów to hxxps://playb24[.]com/en (do złudzenia przypominający faktyczny adres strony operatora) oraz hxxps://georgiamy[.]com/en

Kolejne kroki oszustwa to kolejna odsłona znanego od lat schematu. Najpierw informacja o rzekomo podwójnej płatności. To socjotechniczna sztuczka mająca odwrócić naszą uwagę sugestią, że to usługodawca chce zapłacić nam, a nie oczekuje pieniędzy od nas.

Tymczasem po przejściu dalej i wpisaniu danych karty do poniższego formularza, trafią one od razu w ręce przestępców. Ci, dysponując numerem karty ofiary, personaliami, datą ważności oraz kodem CVV mogą dokonać przy jej użyciu zakupów online. Zazwyczaj w przypadku takich kampanii oszust siedzi przy komputerze i używa wykradzionych danych na bieżąco, np. do błyskawicznego zakupu kryptowalut.

Czy to oszustwo dotyczy wyłącznie klientów Play?

Nie. Zaobserwowana kampania przygotowana jest akurat pod kątem tego operatora, jednak oszuści równie dobrze mogą użyć identyfikacji wizualnej innego dostawcy telekomunikacyjnego (również Orange Polska) lub usługodawcy z innej branży.

Co zrobić, by nie dać się oszukać?

Zawsze przed wpisaniem gdziekolwiek danych karty płatniczej sprawdź dokładnie adres strony i upewnij się, że to prawdziwa strona sklepu czy usługodawcy.

Jeśli masz wątpliwości, czy faktycznie nie masz zaległości w firmie, z której usług korzystasz – zaloguj się do panelu klienta (wpisując ręcznie adres – nie korzystaj z linku z SMS-a!) lub skorzystaj z aplikacji mobilnej i po prostu to sprawdź.

Wpisałam/em dane mojej karty – co zrobić?

Tu kluczowa jest szybkość. Natychmiast zablokuj kartę płatniczą w aplikacji/na stronie banku. Skontaktuj się z bankiem i poinformuj konsultanta o sytuacji.

The post Oszustwo z podszyciem pod Play pod pozorem podwójnej płatności za fakturę appeared first on CERT Orange.

Wraz z powstaniem sieci blockchain, realizujących smart kontrakty, pojawiły się również zdecentralizowane giełdy (DEX – Decentralized Exchange). To właśnie na smart kontraktach opiera się logika tych giełd. Sieci takie jak Ethereum, Solana czy omawiany w tym artykule SUI zabezpieczają realizację tych kontraktów tak, by kod zawarty w kontrakcie mógł już w sposób automatyczny, bez ingerencji stron trzecich, wykonać powierzone mu zadania. Jak się okazuje, każdy kij ma dwa końce. Źle napisany kod może doprowadzić do kompletnej porażki, czyli w przypadku zdecentralizowanych giełd utraty milionów, a czasem nawet setek milionów dolarów. Tak się zdarzyło w maju 2025 w przypadku funkcjonującej na blockchainie SUI zdecentralizowanej giełdy Cetus. 

Aby zrozumieć przypadek utraty środków giełdy Cetus funkcjonującej na sieci SUI konieczne jest wskazanie kilku aspektów i różnic pomiędzy giełdami centralnymi (CEX) a zdecentralizowanymi (DEX). 

Giełdy CEX i DEX różnią się w wielu aspektach, ale na potrzeby artykułu poruszymy ten kluczowy dla naszego przypadku aspekt – obsługę zleceń. 

CEX i arkusz zleceń

W tradycyjnych scentralizowanych giełdach cena podyktowana jest zleceniami, które wystawiają klienci. Przykład: 

Sprzedający wystawiają oferty sprzedaży, kupujący oferty kupna. Obie strony robią to bez opłat. Gdy oferta kupna/sprzedaży pokryje się z istniejącą ofertą w arkuszu zleceń (orderbook) ostateczna cena waloru wynika z ostatniej zrealizowanej oferty z arkusza (dopiero tu pojawia się zysk giełdy – wynika z opłaty ze zrealizowanej transakcji). Na przykład, wystawiając ofertę kupna 2 SUI po każdej cenie pokryjemy 1.5 SUI kosztujące 30 i 0.5 z ceny 31, wtedy cena waloru na naszej giełdzie wyniesie 31, a oferta 2 SUI po cenie 31 zmieni się na 1.5 SUI kosztujące 31.  

DEX – AMM i CLMM 

Giełdy zdecentralizowane oparte na smart kontraktach działają “głównie” w nieco inny sposób niż giełdy CEX (głównie – bo zdarzają się giełdy z arkuszami zleceń działające na sieciach szybkich i tanich jak np. Solana). Samo wystawienie oferty wiązałoby się z dużymi kosztami w zależności od używanej platformy – np. w Ethereum przy aktualnej cenie mogłoby być to kilkanaście dolarów i więcej. Co za tym idzie częstotliwość aktualizacji orderbooka – a zatem i płynność – byłyby mocno ograniczone. Dlatego powstał protokół AMM (Automated Market Maker). W jego ramach wprowadzone zostały pule płynności – każdy może zostać LP (Liquidity Provider), zdeponować parę walutową i zarabiać na opłatach związanych z obrotem tej pary. W ten sposób giełdzie dostarczana jest płynność (zdeponowane środki).  Ale jak jest ustalana cena, skoro nie ma tu klasycznego arkusza zleceń? Przy każdej zamianie (swapie) tokenu, DEX dba o to by proporcja zdeponowanych środków się zgadzała (stała k była taka sama), a cenę reprezentuje ilość środków y do x: 

k = x * y  

x - ilość tokenów A w puli (np. SUI) 
y - ilość tokenów B w puli (np. USDC) 
k - stała 

Tym samym, jeśli w puli jest 100 SUI i 100 USDC (k to 10000) i zakładając, że 1 SUI to 1 USDC (dla uproszczenia), to przy zakupie (swapie) 50 SUI w puli zostanie 50 SUI i 200 USDC. Stała k będzie taka sama jak wcześniej (10000), cena wynosi już 4 USDC za 1 SUI (200/50), a realna cena przy zakupie to 2 USDC (zapłacono 100 USDC zatem 100/50). Dalej całą “pracę” wykonają arbitrażyści, którzy bardzo chętnie wykorzystają okazję, gdy zauważą atrakcyjną cenę SUI/USDC. Tym samym zamienią więcej SUI na rzecz USDC, jeśli będzie to dla nich korzystne. Zdeponowane środki będą się przesuwać jak na wykresie. 

Przeskok ilości zdeponowanych środków przed i po zamianie (swapie) jednego tokenu na drugi – ilość tokenu x wzrosła, a tokenu y zmalała.  

AMM ma bardzo istotną wadę – środki zdeponowane przez LP rozkładają się na cały zakres cen (od 0 do nieskończoności), przez co znaczna część środków nie jest wykorzystywana, a efektywność kapitału jest niska – swapy powodują większą zmianę cen (slippage). Problem ten rozwiązuje CLMM (Concentrated Liquidity Market Maker), gdzie LP może zdecydować w którym zakresie cen (y/x) jego płynność może być wykorzystywana przez DEX-a (i również zarabiać tylko w tym zakresie). Daje to możliwość skondensowania kapitału w konkretnych przedziałach cenowych zamiast do nieskończoności jak to ma miejsce w AMM. W CLMM cena nie jest ciągła a reprezentowana przez “ticki” czyli logarytmiczny krok ceny: 

Przy zamianie tokenów, gdy skończy się płynność w danym zakresie (przy swapie), następuje przeskok do następnego ticka (ceny) do momentu osiągnięcia określonej ilości środków lub maksymalnej ceny wskazanej przez klienta (sqrtPriceLimit). 

LP deponując środki decyduje, w których tickach (poziomach cenowych) jego płynność “pracuje” (proporcja zdeponowanej pary walutowej jest narzucana przez DEX-a tak, by nie zachwiać ceny udostępniając płynność).

Wzór na obliczenie ilości tokenu na podstawie podanej płynności wygląda jak poniżej: 

L – płynność 
A – ilość tokenu x 
PL – cena z niższego zakresu tick 
PU – cena z wyższego zakresu tick 

Błyskawiczne pożyczki (Flash Loan) 

DEX-y udostępniają możliwość udzielenia pożyczek i o ile w przypadku zwykłych pożyczek konieczne jest zdeponowanie określonej ilości innego tokenu (o większej wartości niż sama pożyczka) o tyle jest możliwość pożyczki błyskawicznej. Jedynym kosztem jest koszt transakcji plus ewentualna mała opłata, ale jest też pewien bardzo istotny warunek. Pożyczkobiorca musi obrócić pożyczonymi tokenami naraz. Tzn. musi zaciągnąć pożyczkę, wykonać jakąś opłacalną dla niego akcję i zwrócić pożyczkę. Giełda zaakceptuje ją tylko wtedy, gdy zostanie zwrócona w jednej transakcji.  

Podatny kontrakt 

Poniżej znajduje się funkcja, do której trafia kod odpowiedzialny za dodanie płynności. Funkcja add_liquidity ostatecznie wywołuje funkcje get_delta_a, która pokazuje, ile środków powinno się pojawić przy zadeklarowanej przez LP płynności: 

public fun get_delta_a( 
    sqrt_price_0: u128, 
    sqrt_price_1: u128, 
    liquidity: u128, 
    round_up: bool, 
): u64 { 
    let sqrt_price_diff = if (sqrt_price_0 > sqrt_price_1) { 
        sqrt_price_0 - sqrt_price_1 
    } else { 
        sqrt_price_1 - sqrt_price_0 
    }; 
    if (sqrt_price_diff == 0 || liquidity == 0) { 
        return 0 
    }; 

    let (numberator, overflowing) = math_u256::checked_shlw( 
        full_math_u128::full_mul(liquidity, sqrt_price_diff), 
    ); 
    if (overflowing) { 
        abort EMULTIPLICATION_OVERFLOW 
    }; 
    let denominator = full_math_u128::full_mul(sqrt_price_0, sqrt_price_1); 
    let quotient = math_u256::div_round(numberator, denominator, round_up); 
    assert!(quotient <= std::u64::max_value!() as u256, EAMOUNT_CAST_TO_U64_OVERFLOW); 
    (quotient as u64) 
} 

Najważniejszą funkcją jest tutaj check_shlw. To w niej jest podatność – przepełnienie liczby całkowitej: 

public fun checked_shlw(n: u256): (u256, bool) { 
        let mask = 0xffffffffffffffff << 192; 
        if (n > mask) { 
              (0, true) 
         } else { 
              ((n << 64), false) 
        } 
} 

Funkcja ta jest odpowiedzialna za zwiększenie precyzji poprzez przesunięcie w lewo o 64 bity (kontrakt nie używa liczb zmiennoprzecinkowych, obliczenia wykonywane są na liczbach całkowitych bez znaku), czyli wartością zwracaną jest argument przesunięty o 64 bity w lewo lub 0 wraz z informacją czy nastąpiło przepełnienie. Sprawdzenie jest błędne ze względu na to, że 0xffffffffffffffff << 192 to górna wartość liczby 256 bitowej. Tymczasem kod powinien upewnić się, że argument nie jest liczbą, która mieści się w najstarszych 64 bitach, aby ostateczna wartość po przesunięciu nie została ucięta. Poprawne sprawdzenie wystąpiłoby przy porównaniu argumentu z wartością 1 << 192. Wtedy, jeśli argument jest równy lub większy od tej wartości, funkcja checked_shlw zwróci zmienną overflow jako true, w efekcie czego proces dodania płynności zakończyłby się niepowodzeniem.  

Wynik obliczeń w funkcji get_delta_a w przypadku istnienia podatności wyniesie 1, ponieważ licznik (numberator) będzie mniejszy (bo przepełniony – ucięta wartość) od mianownika (denominator) co w konsekwencji z funkcją div_round i zaokrągleniem (round_up) na true da wynik 1. 

Konsekwencje? Wystarczyłoby, żeby atakujący zdeponował tylko jedną jednostkę tokenu jako dostawca płynności (LP), by osiągnąć ogromne ilości płynności z perspektywy kontraktu, a następnie móc zwracać rzekomą wcześniej wprowadzoną płynność i w ten sam sposób drenować pule, jedną po drugiej (haSUI/SUI, SCA/USDC itd.). 

W dniu wystąpienia ataku deweloperzy wdrożyli poprawkę:  

diff --git a/sui/sources/math_u256.move b/sui/sources/math_u256.move 
index 01d1412..25bfd30 100644 
--- a/sui/sources/math_u256.move 
+++ b/sui/sources/math_u256.move 
@@ -16,7 +16,7 @@ module integer_mate::math_u256 { 
     } 

     public fun checked_shlw(n: u256): (u256, bool) { 
-        let mask = 0xffffffffffffffff << 192; 
+        let mask = 1 << 192; 
         if (n > mask) { 
             (0, true) 
         } else { 
diff --git a/sui/sources/math_u256.move b/sui/sources/math_u256.move 
index 25bfd30..2775033 100644 
--- a/sui/sources/math_u256.move 
+++ b/sui/sources/math_u256.move 
@@ -17,7 +17,7 @@ module integer_mate::math_u256 { 

     public fun checked_shlw(n: u256): (u256, bool) { 
         let mask = 1 << 192; 
-        if (n > mask) { 
+        if (n >= mask) { 
             (0, true) 
         } else { 
             ((n << 64), false) 

Przebieg ataku na giełdę Cetus

Poniżej lista zdarzeń wygenerowana dla pierwszej puli, którą zaatakowano – haSUI/SUI: 

1. Atakujący generuje SwapEvent. W rzeczywistości jest to flash_swap czyli jedna z form wspomnianej wcześniej pożyczki błyskawicznej, którą musi spłacić w jednym z wyżej kroków – podczas jednej transakcji. Atakujący pożycza SUI i musi oddać odpowiednią ilość haSUI.  

Pożyczona ilość to amount_out (SUI), kwota do oddania to amount_in (haSUI). 

2. Otwarcie pozycji. Potrzebuje oddzielnego wywołania by stworzyć NFT, w którym zapisze jej szczegóły – m. in. dolny i górny tick. 

3. Tu wykonuje się przepełnienie. Atakujący deponuje jedną jednostkę tokenu i otrzymuje ogromne ilości płynności: 

Odpowiednio dobrane parametry liquidity i tick dzięki przepełnieniu dają możliwość wpłacenia tylko jednej jednostki tokenu – amount_a=1. 

4. RemoveLiquidity. Atakujący wybiera taką ilość tokenu A, aby w pierwszej kolejności spłacić wcześniejszą pożyczkę: 

Na tym etapie atakujący jest już w posiadaniu 5,765,124.790450508 SUI, ponieważ spłacił pożyczkę wybierając 10,024,321.275017082 haSUI z puli. 

5. RemoveLiquidity. Atakujący pobiera 1 haSUI na rzecz spłaty add_liquidity: 

6. RemoveLiquidity. Atakujący “wyciąga” z puli 10,024,321.275017081 haSUI 

Przestępca na tej jednej puli zdobył łącznie w przybliżeniu 5765125 SUI i 10024321 haSUI. 

Podsumowanie ataku na Cetus

Łączne środki wykradzione przez atakującego to aż ok. 223 miliony dolarów! Zdążył jednak wyprowadzić „tylko” ok. 60 milionów dolarów, ponieważ całą resztę udało się zamrozić na poziomie sieci SUI. Atakujący sprytnie wykorzystał podatność przepełnienia w kontrakcie giełdy Cetus. Sprawę komplikuje fakt, że kontrakty w sieci SUI bazują na języku Move, który słynie przede wszystkim z odporności na przepełnienia arytmetyczne. Niefortunnie dla giełdy oprócz błędnych mechanizmów bezpieczeństwa zastosowanych w krytycznych funkcjach okazało się, że przepełnienia z udziałem przesunięć bitowych nie są brane pod uwagę w mechanizmach bezpieczeństwa języka Move. Istotne jest również to, że Cetus przechodził wiele audytów w przeszłości (ostatni miał miejsce miesiąc przed zdarzeniem!) i żaden nie wykrył tej podatności. 

Atak oprócz samej giełdy trafił przede wszystkim w dostawców płynności (LP) i ich zdeponowane środki. Przykład ten dobitnie pokazuje, że nawet w pozornie bezpiecznym, zdecentralizowanym miejscu, które regularnie dokonuje audytów bezpieczeństwa zgromadzone środki mogą zostać zagrożone. 

Właściciele Cetus zaproponowali atakującemu możliwość zatrzymania 6 milionów dolarów, jeśli oddałby resztę zrabowanych środków. Po czasie i braku prób nawiązania kontaktu z jego strony, właściciele Cetus zaproponowali 5 milionów dolarów za informacje o przestępcy, które pomogłyby go schwytać organom ścigania.

Adam Pichlak

The post Jak okradziono zdecentralizowaną giełdę Cetus appeared first on CERT Orange.

Cybercrime

Sezon wakacyjny? Nie dla operatorów ransomware

• Ransomware jest końcowym etapem całego ataku, a nie początkiem incydentu. Kluczowe etapy to eskalacja uprawnień, przejęcie kontrolera domeny, eksfiltracja danych i przygotowanie środowiska do szyfrowania.
• Atak trwał niemal pięć dni – od infekcji poprzez SEO Poisoning do zaszyfrowania dwóch domen Active Directory, pokazując jak dużo czasu organizacje mają na wykrycie i zatrzymanie przeciwnika.
• Łańcuch infekcji wykorzystał znane narzędzia, jednak interesujące jest pojawienie się AdaptixC2, który coraz częściej zastępuje klasyczne frameworki C2 w rękach operatorów ransomware.

Sezon wakacyjny? Nie dla cyberprzestępców 

Rozpoczynający się sezon urlopowy nie oznacza wakacji dla cyberprzestępców. Wręcz przeciwnie – okres letni od wielu lat sprzyja prowadzeniu kampanii ransomware. Mniejsza obsada zespołów bezpieczeństwa, opóźnione reakcje oraz większa podatność użytkowników na socjotechnikę sprawiają, że jest to dogodny moment do prowadzenia długotrwałych operacji. 

Jednym z najlepszych źródeł wiedzy o rzeczywistych działaniach grup ransomware pozostają analizy publikowane przez projekt The DFIR Report. Opisywane tam incydenty pokazują nie tylko sposób działania przeciwników, ale przede wszystkim miejsca, w których organizacja mogła wykryć i zatrzymać atak. 

Najnowszy raport przedstawia kompromitację środowiska zakończoną wdrożeniem ransomware Akira. Cała operacja trwała niemal pięć dni. To bardzo ważna obserwacja – ransomware nie pojawia się natychmiast po uzyskaniu dostępu. Jest ostatnim etapem wieloetapowej operacji, podczas której istnieje wiele okazji do wykrycia aktywności napastnika. 

Od wyszukiwarki do ransomware 

Atak rozpoczął się od klasycznego już scenariusza SEO Poisoning. Ofiara, wyszukując w przeglądarce instalatora ManageEngine OpManager, trafiła na spreparowaną stronę oferującą zmodyfikowany instalator aplikacji. 

Uruchomienie programu doprowadziło do instalacji BumbleBee, który od kilku lat pozostaje jednym z loaderów najczęściej wykorzystywanych przez operatorów. Malware zapewnił napastnikom pierwszy dostęp do stacji roboczej, a następnie uruchomił beacon frameworka AdaptixC2. 

To właśnie wykorzystanie AdaptixC2 stanowi jeden z ciekawszych elementów tej kampanii. Framework ten jest coraz częściej obserwowany w rzeczywistych atakach i stanowi alternatywę dla znacznie lepiej znanych platform takich jak Cobalt Strike czy Brute Ratel. Dzięki niemu operatorzy mogli prowadzić dalsze działania wewnątrz sieci bez konieczności utrzymywania aktywności BumbleBee. 

Kolejne etapy odpowiadały klasycznemu scenariuszowi prowadzenia operacji ransomware: 

• rozpoznanie środowiska Active Directory,  
• przejęcie kontrolera domeny,  
• pozyskanie bazy NTDS.dit zawierającej skróty (hashe) haseł kont domenowych,
• powrót następnego dnia i ustanowienie tunelu SSH umożliwiającego trwały dostęp,
• przemieszczanie się pomiędzy systemami,  
• eksfiltracja danych z wykorzystaniem FileZilla oraz protokołu SFTP,  
• wdrożenie ransomware Akira w domenie głównej,  
• ponowny powrót dwa dni później i zaszyfrowanie kolejnej domeny potomnej.  

Cały proces był realizowany etapami, a operatorzy wielokrotnie wracali do środowiska ofiary, przygotowując kolejne fazy operacji. 

Co nowego w tym ataku? 

Choć sam schemat działania nie odbiega od współczesnych operacji ransomware, raport zwraca uwagę na kilka interesujących elementów. Przede wszystkim obserwujemy dalszą ewolucję infrastruktury C2. AdaptixC2 pojawia się coraz częściej jako narzędzie wykorzystywane po uzyskaniu dostępu przez loader. Może to świadczyć o stopniowym odchodzeniu części grup od bardziej rozpoznawalnych frameworków, które są intensywnie monitorowane przez rozwiązania EDR. 

Drugim istotnym elementem pozostaje wykorzystanie SEO Poisoning. Technika ta od kilku lat utrzymuje wysoką skuteczność i nadal jest jednym z najprostszych sposobów dostarczania malware bez konieczności prowadzenia kampanii phishingowych. 

Raport przypomina również, że operatorzy ransomware coraz częściej rozdzielają działania na kilka dni. Pozwala im to ograniczyć liczbę alarmów generowanych jednocześnie, lepiej poznać środowisko ofiary oraz przygotować skuteczną eksfiltrację danych przed uruchomieniem procesu szyfrowania.re

Patrząc szerzej

Największą wartością tego raportu nie jest sam fakt wykorzystania Akiry czy BumbleBee. W tym przypadku napastnicy potrzebowali około pięciu dni, aby przejść od pierwszej infekcji do pełnego zaszyfrowania infrastruktury. W tym czasie pozostawiali liczne artefakty możliwe do wykrycia. 

Skuteczna obrona przed ransomware nie polega wyłącznie na wykrywaniu procesu szyfrowania, lecz na identyfikowaniu działań przeciwnika znacznie wcześniej – podczas uzyskiwania dostępu, eskalacji uprawnień, ruchu bocznego i przygotowywania eksfiltracji danych. 

Raport DFIR po raz kolejny pokazuje, że najlepszą ochroną przed ransomware jest skrócenie czasu wykrycia (MTTD) i reakcji (MTTR). Im wcześniej organizacja przerwie łańcuch ataku, tym mniejsza szansa, że ransomware w ogóle zostanie uruchomione.

Więcej informacji:
https://thedfirreport.com/2026/06/29/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira-3/#collection 

Malware

„Tutaj Dom”? Tutaj mobilny malware Glitch SPY

• Analitycy firmy Cyble opisali złośliwe oprogramowanie na systemy Android, które podaje się za aplikację służącą do wynajmu nieruchomości „Tutaj Dom”.
• W rzeczywistości, po zainstalowaniu, oprogramowanie okazuje się dropperem Brokewell Android Loader, instaluje Glitch SPY i żąda szerokich uprawnień, dzięki którym realizuje funkcje RAT.
• Oryginalność kampanii, odrębność od innego malware mobilnego i wyraźne zdefiniowanie Polski jako celu ataku sprawia, że warto przyjrzeć się sprawie bliżej. 

Analitycy Cyble Research and Intelligence Labs opisali kampanię wymierzoną w polskich użytkowników Androida, w której złośliwe oprogramowanie rozpowszechniane jest pod przykrywką aplikacji do wynajmu nieruchomości „Tutaj Dom”. Sam wybór tematyki dobrze koresponduje z okresem wakacyjnym sprzyjającym krótkoterminowemu wynajmowi nieruchomości. Serwisy związane z ogłoszeniami najmu mieszkań i domów należą do usług, z których korzysta szerokie grono użytkowników, a przygotowanie wiarygodnie wyglądającej strony internetowej z opiniami i odnośnikiem do pobrania aplikacji nie stanowi dziś większego wyzwania. Atakujący nie musieli nawet wzorować się na prawdziwej usłudze. W analizowanej kampanii fałszywa witryna oraz marka zostały zaprojektowane od podstaw w sposób estetyczny i spójny dla lepszej wiarygodności i mniejszej szansy wykrycia poprzez oczywiste podszycia. 

Strona poza elementami czysto estetycznymi i mającymi zbudować wizję prawdziwej oraz zaufanej marki zawiera przede wszystkim odnośnik do pobrania pliku APK – mobilnej aplikacji na system Android. Pobierany plik APK nie zawiera jednak właściwego malware. Rolę pierwszego etapu infekcji pełni już wcześniej znany Brokewell Android Loader – dropper odpowiedzialny za dostarczenie docelowego ładunku. Po uruchomieniu aplikacja nakłania użytkownika do zezwolenia na instalację programów z nieznanych źródeł, a następnie instaluje właściwy komponent – Glitch SPY. Taki podział funkcji utrudnia analizę i wykrywanie zagrożenia, ponieważ właściwe złośliwe oprogramowanie pojawia się na urządzeniu dopiero po wykonaniu dodatkowych działań przez ofiarę. 

Glitch SPY jest rozbudowanym trojanem typu Remote Access Trojan (RAT), którego możliwości wykraczają daleko poza klasyczną kradzież danych. Według analizy Cyble malware obsługuje ponad 70 komend przekazywanych z serwera zarządzającego. Komunikacja realizowana jest z wykorzystaniem WebSocketów, co pozwala utrzymywać stały, dwukierunkowy kanał wymiany danych pomiędzy urządzeniem ofiary a infrastrukturą operatorów. W praktyce umożliwia to niemal natychmiastowe wykonywanie poleceń i bieżące sterowanie zainfekowanym telefonem. 

Zakres dostępnych funkcji pokazuje, że twórcy platformy projektowali ją z myślą o długotrwałym przejęciu urządzenia. Glitch SPY potrafi transmitować obraz ekranu w czasie rzeczywistym, wykonywać zrzuty ekranu, rejestrować aktywność użytkownika, odczytywać wiadomości SMS, listy kontaktów i historię połączeń, zarządzać plikami, wykonywać polecenia systemowe czy zdalnie kontrolować interfejs telefonu poprzez nadużywanie mechanizmów Accessibility Services. Szczególnie interesującym elementem jest wykorzystanie ukrytej przeglądarki WebView, pozwalającej operatorowi wykonywać działania z wykorzystaniem aktywnych sesji użytkownika. Oznacza to możliwość interakcji z serwisami internetowymi z perspektywy zaufanego urządzenia ofiary, co może utrudniać wykrywanie nadużyć przez mechanizmy antyfraudowe. 

Wśród dostępnych modułów znajduje się również crypto clipper. Malware monitoruje zawartość schowka i rozpoznaje adresy popularnych portfeli kryptowalutowych. W momencie wykrycia takiego ciągu znaków automatycznie podmienia go na adres kontrolowany przez atakujących. Użytkownik, nie weryfikując ponownie odbiorcy transakcji, może nieświadomie przesłać środki do cyberprzestępców. 

Na uwagę zasługuje również architektura całej platformy. Badacze zidentyfikowali publicznie dostępny panel administracyjny wykorzystywany do zarządzania kampaniami, co pozwoliło przeanalizować zaplecze operacyjne projektu i przypisać zagrożeniu nazwę Glitch SPY. Panel wskazuje na obecność modułu Builder umożliwiającego operatorom dostosowywanie parametrów malware do konkretnych kampanii – od nazwy aplikacji i ikony po zestaw funkcji czy konfigurację komunikacji. Analiza ujawniła także przygotowania do wdrożenia modułu Cryptor, którego zadaniem będzie utrudnianie wykrywania próbek przez rozwiązania bezpieczeństwa. Stopniowe rozbudowywanie funkcji jest standardowym podejściem wśród współczesnych platform Malware-as-a-Service, szczególnie dopiero rozwijających swoje możliwości i rozpoczynających sprzedaż swoich usług na rynku cyberprzestępczym. 

Kampania jest również interesująca pod kątem jej celu. W przeciwieństwie do wielu mobilnych zagrożeń rozprzestrzenianych globalnie, w tym przypadku przygotowano infrastrukturę wyraźnie ukierunkowaną na polskich użytkowników. Obejmuje to zarówno nazwę fałszywej usługi, jak i język wykorzystany na stronie internetowej oraz scenariusz socjotechniczny. Pokazuje to, że Polska została jedynym lub jednym z niewielu celów operacji, a nie wyłącznie przypadkowym odbiorcą globalnych kampanii organizowanych na masową skalę. 

Rys. Zrzut ekranu z wyszukiwarki Google wraz z “Przeglądem od AI” rekomendującym skorzystanie z fałszywej strony. 

Patrząc szerzej

Przypadek Glitch SPY wpisuje się w szerszy trend obserwowany na rynku zagrożeń mobilnych. Dominujące przez lata bankery Android coraz częściej ustępują miejsca wielofunkcyjnym platformom zdalnego dostępu. Tego typu malware pozwala operatorowi elastycznie decydować o sposobie monetyzacji infekcji – od kradzieży danych logowania i przejmowania kont, przez oszustwa finansowe, po wyłudzanie kryptowalut. Rozbudowana architektura modułowa sprawia również, że nowe funkcjonalności mogą być dodawane bez konieczności przebudowy całego projektu.  

Z perspektywy użytkowników podstawową rekomendacją pozostaje instalowanie aplikacji wyłącznie z oficjalnych sklepów oraz zachowanie szczególnej ostrożności wobec plików APK pobieranych z witryn internetowych. Dodatkowym sygnałem ostrzegawczym powinny być żądania włączenia instalacji z nieznanych źródeł oraz przyznania uprawnień usług dostępności aplikacjom, które nie mają uzasadnionej potrzeby korzystania z takich mechanizmów. W tym przypadku metoda docierania do ofiar nie jest znana, ale zalecamy szczególną ostrożność w stosunku do reklam w mediach społecznościowych i odpowiedzi zwracanych przez wyszukiwarki internetowe lub chaty wspierane LLM. 

W ramach CERT Orange Polska uważnie śledzimy zagrożenia dla polskich internautów i z pomocą CyberTarczy chronimy przed znaną i nową złośliwą aktywnością, a stosowne działania podjęliśmy także i w tym przypadku. 

Więcej informacji:  
https://cyble.com/blog/glitch-spy-rat-distributed-via-fake-polish-app/ 

Telco

Sprawa NetNut i Popa – residential proxy na celowniku

• W czerwcu w mediach pojawiły się informacje o platformie NetNut oferującej residential proxy oraz jej powiązaniach z botnetem Popa i Vo1d.
• 2 lipca Google poinformowało o skoordynowanej akcji wymierzonej właśnie w tę usługę oraz dodatkowych działaniach podjętych, by zapobiegać kolejnym infekcjom.
• Residential proxy to istotny temat dla konsumentów technologii oraz przedmiot dyskusji z zakresu świadomej zgody na warunki użytkowania usług lub urządzeń.

Na początku lipca FBI, przy wsparciu Google, Lumen, Shadowserver oraz innych partnerów branżowych, przejęło setki domen wykorzystywanych przez platformę NetNut oraz powiązany z nią botnet Popa. Informacja o działaniach organów ścigania przyszła niedługo po opublikowaniu ustaleń badaczy Qurium, Synthient, Nokia Deepfield oraz Briana Krebsa, którzy przedstawili techniczne dowody wskazujące na ścisłe powiązania pomiędzy komercyjną usługą residential proxy a infrastrukturą wykorzystywaną przez miliony zainfekowanych urządzeń. Równolegle Google Threat Intelligence Group poinformował o własnych działaniach wymierzonych w zaplecze NetNut, wskazując, że z infrastruktury tej korzystały setki grup cyberprzestępczych oraz aktorów prowadzących operacje szpiegowskie. 

Model działania botnetu Popa opierał się na budowaniu rozproszonej sieci urządzeń pełniących funkcję węzłów proxy. Po przejęciu kontroli nad urządzeniem malware utrzymywał trwały kanał komunikacyjny i umożliwiał przekazywanie przez nie ruchu sieciowego innych użytkowników. W praktyce oznaczało to, że aktywność cyberprzestępców mogła być realizowana z adresów IP należących do zwykłych użytkowników, znacząco utrudniając identyfikację sprawców i obchodząc mechanizmy wykrywania nadużyć. 

Według ustaleń badaczy znaczną część infrastruktury tworzyły nieoficjalne urządzenia z Android TV oraz tanie przystawki multimedialne sprzedawane pod dziesiątkami różnych marek. Część z nich zawierała złośliwe komponenty już na etapie sprzedaży, w innych infekcja następowała poprzez instalację nieoficjalnych aplikacji do streamingu, odtwarzaczy multimedialnych, klientów VPN czy zmodyfikowanego oprogramowania. W efekcie właściciel urządzenia często nie miał świadomości, że jego domowa sieć stała się elementem komercyjnej infrastruktury proxy wykorzystywanej przez podmioty trzecie. 

Największe kontrowersje wywołały jednak ustalenia dotyczące powiązań Popa z NetNut – komercyjną platformą residential proxy należącą do izraelskiej spółki Alarum Technologies. Badacze wskazali szereg zależności technicznych, organizacyjnych i infrastrukturalnych, obejmujących wspólne domeny, komponenty SDK oraz elementy zaplecza administracyjnego. Alarum konsekwentnie odrzuca przedstawione zarzuty, utrzymując, że oferowane rozwiązania opierają się na mechanizmie świadomej zgody użytkownika, a wykorzystywane wcześniej komponenty mogły zostać zmodyfikowane przez podmioty trzecie. Niezależnie od stanowiska spółki działania FBI oraz Google pokazują, że zgromadzony materiał dowodowy został uznany za wystarczający do przeprowadzenia szeroko zakrojonej operacji wymierzonej w infrastrukturę NetNut. 

Google oznaczyło i usunęło aplikacje związane ze SDK NetNut za pomocą wbudowanego w systemy Android Google Play Protect i zobowiązało się do chronienia użytkowników przed tym zagrożeniem w przyszłości. Firma poinformowała, że tylko w jednym tygodniu czerwca zaobserwował 316 odrębnych klastrów zagrożeń wykorzystujących węzły NetNut do ukrywania źródła ruchu, prowadzenia kampanii password spraying, przejmowania kont oraz działań szpiegowskich. Skala wykorzystania tej infrastruktury pokazuje, że residential proxy są jednym z podstawowych elementów zaplecza współczesnej cyberprzestępczości, porównywalnym pod względem znaczenia z usługami bulletproof hostingu czy anonimowymi dostawcami VPS.

Patrząc szerzej

Temat ten dobrze wpisuje się również w obserwacje przedstawione w naszym czerwcowym Krajobrazie Zagrożeń. Nieustannie zwracamy uwagę na rosnące znaczenie zagrożeń wymierzonych w urządzenia Internetu Rzeczy (IoT) oraz sprzęt konsumencki, które coraz częściej stają się elementem infrastruktury wykorzystywanej przez grupy cyberprzestępcze. Przejęte Smart TV, przystawki multimedialne czy inne urządzenia oparte na Androidzie pełnią funkcję trwałych zasobów infrastrukturalnych wykorzystywanych przez wiele niezależnych podmiotów do zróżnicowanych celów o różnych intencjach. Wiąże się to z potencjalnymi konsekwencjami, o których warto pamiętać. 

Z perspektywy użytkowników oznacza to konieczność zwracania znacznie większej uwagi na pochodzenie kupowanych urządzeń oraz instalowanego oprogramowania. Tanie przystawki pochodzące spoza oficjalnych kanałów dystrybucji, urządzenia z odblokowanym systemem czy aplikacje pobierane z niezweryfikowanych źródeł mogą stać się punktem wejścia do całej sieci domowej. Z perspektywy cyberbezpieczeństwa organizacyjnego warto pamiętać, że adres IP użytkownika domowego coraz częściej nie świadczy o rzeczywistym źródle ataku, lecz o tym, że jego urządzenie mogło zostać wcześniej włączone do infrastruktury wykorzystywanej przez cyberprzestępców. 

Więcej informacji:
https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks/  
https://www.linkedin.com/pulse/maintaining-pressure-malicious-proxies-blacklotuslabs-pl35e/  
https://krebsonsecurity.com/2026/06/popa-botnet-linked-to-publicly-traded-israeli-firm/  

The post Krajobraz Zagrożeń – 06.07.2026 appeared first on CERT Orange.

Cyberprzestępcy wysyłają SMS-y sugerujące zaległą opłatę za parkowanie. Celem nie jest jednak pobranie niewielkiej należności, ale wyłudzenie danych karty płatniczej i danych osobowych.

Już nadawca SMS-a to dowód na to, że mamy do czynienia z oszustwem. W opisywanym przykładzie – podobnie jak w naszym tekście o phishingach „na paczkę DPD” – wiadomość przychodzi z numeru rozpoczynającego się od +212. To strefa numeracyjna… Maroka. Co więcej – jeśli czytając teksty na naszej stronie przyzwyczailiście się do sprawdzania adresu strony docelowej, zauważycie, że użyta w opisywanej wiadomości mieści się w domenie .ink.

Firma, której nazwy używają oszuści, faktycznie istnieje. Jednak adres jej strony kończy się literami .pl.

Jak wygląda oszustwo?

Co się dzieje, jeśli klikniemy? Sprawdziłem cały proces, żebyście Wy nie musieli.

Pierwsza strona, z logotypem istniejącej firmy zajmującej się usługami parkingowymi, informuje nas, iż możemy sprawdzić, czy na naszym koncie jest jakieś nieopłacone parkowanie.

Testując funkcjonalności strony phishingowej wpisałem oczywiście nieistniejący numer rejestracyjny. Okazało się, że faktycznie „mój samochód” ma zaległą opłatę za parkowanie. Niewiele – zaledwie 8 złotych. To znana socjotechniczna sztuczka, mająca uśpić naszą czujność. Niska kwota nie budzi niepokoju, jednak podając dane karty – potencjalnie możemy stracić znacznie więcej.

Co ciekawe – w tym przypadku poza szczegółami dotyczącymi karty oraz danymi osobowymi jesteśmy proszeni również o numer telefonu. Dlaczego? Po to, by uwiarygodnić formularz. By później wykorzystać numer do innej złośliwej aktywności. A być może i jedno i drugie.

Wpisując dane podałem numer karty z generatora numerów do testowania płatności. Potem przez około minutę czekałem m.in. na to, by „międzynarodowa sieć płatnicza” wykonała „szyfrowanie SSL i certyfikację PCI-DSS”. Ostatecznie okazało się, że kartą o tym numerze nie zapłacę za „parkowanie”.

Fakt tak szybkiej weryfikacji (próbowałem z kilkoma numerami kart w różnych standardach) dowodzi, że oszuści na bieżąco monitorują aktywność ofiar w trakcie kampanii. W momencie, gdy ofiara widzi powoli napełniający się pasek postępu – przestępcy wpisują podane dane np. na stronie giełdy kryptowalut, by dokonać kradzieży zanim dla ofiary będzie już za późno.

Jak nie dać się oszukać?

Najlepiej po prostu… płacić za parkowanie. Wiem, że to taka sama rada, jak:

Nie chcesz mandatów za prędkość? To jej nie przekraczaj.

Jednak ta rada działa, a jeśli będziesz mieć pewność, że zawsze płacisz za parkowanie, od razu będziesz wiedzieć, że taki SMS to oszustwo.

No i oczywiście warto być wyczulonym na to, co przy każdym phishingu, niezależnie od tematyki:

• sprawdź nadpis/nr nadawcy (numer z Maroka jest co najmniej podejrzany)
• przyjrzyj się dokładnie adresowi strony (adres w domenie .ink to absolutnie czerwona flaga)
  • jeśli na docelowej stronie jest nazwa firmy – wpisz ją w Google, wtedy z dużym prawdopodobieństwem znajdziesz jej prawdziwą witrynę
• no i to, o czym wspominamy regularnie na tej stronie: jeśli gdziekolwiek wpisujesz swoje wrażliwe dane, hasła, podajesz dane karty, miej absolutną pewność, że to prawdziwa strona banku, sklepu, czy usługodawcy!

The post Fałszywy SMS o opłacie za parkowanie. Jak działa to oszustwo i jak nie dać się okraść appeared first on CERT Orange.

SMS-y wysyłane są z nadpisów Wsparcie oraz Obsługa. Treść analizowanych przez nas wiadomości brzmi:

Netflix: Konto zablokowane. Zaktualizuj dane rozliczeniowe, by przywrócić dostęp. Wykonaj kroki pod linkiem: abonament-dostep[.]pl

Nie przywiązuj się jednak do dokładnie takiej treści – oszuści mogą wysyłać różne, tylko podobnie brzmiące wiadomości.

Co dzieje się w kolejnych krokach?

Dalej schemat działania jest bliźniaczo podobny do wszystkich oszustw tego typu. Pod pozorem tego, że Twoje konto Netflix jest zablokowane oszuści najpierw podstawiają fałszywą stronę (qadrs[.]com, niepowiązana z Netflixem) z ekranem logowania:

Kolejny krok to informacja o rzekomym zawieszeniu konta. By je odwiesić, musisz podać adres pocztowy (do „faktury”) oraz dane karty płatniczej. Przyjrzyj się dokładnie ostatniej grafice. Dowodzi ona, iż phishing przygotowywany był półautomatycznie. Brzmiący zabawnie zwrot „Uchwyt na kartę” to anglojęzyczny zwrot „cardholders handle” czyli Dane właściciela karty.

Jak nie dać się oszukać?

• Do SMS-ów z linkami podchodź z bardzo ograniczonym zaufaniem.
• Upewnij się, czy strona, którą odwiedzasz, jest na pewno witryną tego usługodawcy.
• Nie masz pewności i myślisz, że SMS może dotyczyć Ciebie? Zaloguj się do aplikacji mobilnej, wybierz Profil => Konto i sprawdź dane dotyczące płatności.

Uwierzyłeś/aś, że Twoje konto Netflix jest zablokowane i podałeś/aś dane – co zrobić?

• Natychmiast zablokuj kartę płatniczą. Jeśli dokonano nią już jakiejś transakcji – niezwłocznie skontaktuj się z bankiem.
• Zaloguj się na konto Netflix i zmień hasło. Nie możesz zresetować hasła? Być może ktoś zmienił adres e-mail logowania. Skontaktuj się z działem pomocy Netflix!

The post Twoje konto Netflix jest zablokowane? Nie – to oszuści chcą Twojego hasła i danych karty appeared first on CERT Orange.

SMS wysyłany jest z nadpisu „SKRL” i ma następującą treść:
„Twoje konto Skrill zostanie trwale ograniczone, je?li nie potwierdzisz swoich danych za po?rednictwem strony https://skrill-secure[.]com”

To kolejna odsłona podszywania się pod Skrill. Platforma informowała o podobnym scenariuszu na platformie X w zeszłym roku. Wtedy wykorzystywano fałszywy profil „Skrill Help”, który kontaktował się z klientami za pośrednictwem bezpośrednich wiadomości.

Dałem się nabrać? Co mi grozi?

Po podaniu danych logowania przestępcy wykorzystują nasze konto do wypłaty środków, a także do pośredniczenia w nielegalnych transakcjach. Wtedy problem zaczyna być bardzo poważny, ponieważ to właśnie przejęte konto staje się elementem przestępstwa.

Jak nie dać się oszukać? Co zrobić, gdy wpisaliśmy dane?

• Do SMS-ów z linkami podchodź z bardzo ograniczonym zaufaniem.
• Upewnij się, czy strona, którą odwiedzasz, jest na pewno witryną tego usługodawcy.
• Skorzystaj z aplikacji mobilnej i sprawdź zakładkę z powiadomieniami.

Jeśli jednak zalogowałeś się na fałszywej stronie, spróbuj natychmiast:

• Zresetować hasło i włączyć dwuetapowe uwierzytelnienie.
• Nie możesz zresetować hasła? Być może ktoś zmienił adres e-mail logowania. Skontaktuj się z działem pomocy Skrill!

The post Korzystasz ze Skrill? Ktoś chce przejąć twoje konto. appeared first on CERT Orange.

W hali treningowej znajdują się m.in. domy, pokoje, szpital, stacja benzynowa, biuro, elektrownia i centrum danych. Całość wyposażono w prawdziwą infrastrukturę cyfrową: stacje robocze z kontami i mechanizmami logowania wieloskładnikowego, do tego zapory sieciowe, kamery a nawet data center. Jednocześnie środowisko pozostaje odizolowane od internetu, dzięki czemu można bezpiecznie odtwarzać scenariusze ataków i działań operacyjnych.

Jak informuje na swojej stronie FBI, „miasteczko” zostało otwarte w lutym 2025 r. Do dziś przeszkolono tam ponad 1400 osób z takich służb jak FBI, US Army czy policja.

Od teorii do praktyki – koniec szkolenia przed rzutnikiem.

Chcemy, żeby robili błędy w Kinetic Cyber Range, aby uczyć się na symulacji, nie na miejscu zdarzenia

Stephanie Cassioppi – dowódca sekcji cyber training na kampusie w Huntsville

Przedsięwzięcie jest adaptacją sprawdzonych już w USA rozwiązań tego typu, polegających na fizycznym odtworzeniu struktury atakowanego obiektu. Kinetic Cyber Range to swego rodzaju hybrydowe połączenie obiektów fizycznych uzupełnionych o elementy infrastruktury cyfrowej.

Czy jest tam odtwarzany scenariusz zatrzymania Rossa Ulbrichta? Tego nie wiemy, ale na pewno tamta spektakularna akcja może służyć jako dobry przykład.

Dla tych którzy nie wiedzą, kim jest Ross Ulbricht – krótkie przypomnienie. To twórca darknetowego marketplace (platforma pośrednicząca pomiędzy sprzedawcami a odbiorcami) Silk Road. Kwitł tam handel wszystkim co nielegalne na niebywałą skalę. Ross Ulbricht został wytropiony przez FBI, a kluczowym elementem jego zatrzymania było przechwycenie komputera. W trakcie zaaranżowanej przez agentów FBI kłótni w bibliotece został obezwładniony i nie zdążył zamknąć ekranu laptopa aby uniemożliwić dostęp do danych. Jego komputer znajduje się jako eksponat w siedzibie FBI.

Jakie scenariusze ćwiczy FBI

„Kinetyczny” cyberpoligon ma umożliwiać odwzorowanie różnych zdarzeń w realnych warunkach. Wśród przykładowych scenariuszy znajdziemy między innymi:

• zebranie i odtworzenie danych z zaparkowanego samochodu
• symulację ataku ransomware na szpital, włącznie z alarmem oraz aktorami grającymi personel medyczny i pacjentów
• przeszukanie domu pełnego urządzeń IoT – które urządzenia zabrać i jak zabezpieczyć pod materiał dowodowy
• pracę w data center – pełnym pajęczyn, zamkniętych drzwi i brakującego osprzętu

W praktyce chodzi nie tylko o analizę techniczną, ale też o podejmowanie decyzji w warunkach presji, niepełnych informacji i różnych ograniczeń.

W planach jest aktualizowanie i rozbudowywanie scenariuszy o kolejne obszary technologiczne. Całość jest elementem większej i będącej nadal w budowie infrastruktury Innovation Center. Z pewnością nie może odtworzyć skali problemu w realnym świecie. Niemniej adresuje realne problemy.

Zapraszamy na zwiedzanie z przewodnikiem

A jak to wygląda w Polsce?

Chociaż nie ma odpowiednika „poligonowego miasteczka” to istnieje dużo bardziej rozwinięty ekosystem cyberćwiczeń.

Wojska Obrony Cyberprzestrzeni (w skrócie WOC) to jednostka wojskowa budowana od lutego 2019 i przygotowywana do zadań związanych z operowaniem w cyberprzestrzeni. w ramach programu DKWOC. Założycielem i wieloletnim dowódcą był gen. dyw. Karol Molenda (powołany w marcu 2026 na stanowisko doradcy strategicznego dowódcy NATO ds. transformacji) i zastąpiony przez gen. bryg. dr inż. Mariusza Chmielewskiego. Siedziba mieści się w podwarszawskim Legionowie.

W ramach WOC funkcjonuje Cyberlegion. To program łączący polską społeczność „cyber” wokół Sił Zbrojnych RP i Wojsk Obrony Cyberprzestrzeni.

Dookoła niego utworzone są aktywności (wszystkie opisane są na tej stronie internetowej). Najciekawszymi z nich są ćwiczenia Locked Shields i Operation Cyber Flag. Skupiają cywilnych ekspertów, a przede wszystkim praktyków. Nie są oni w strukturze wojskowej rozumianej jako „pod rozkazem” ale ochotnikami. Dzięki regularnym ćwiczeniom i symulacjom ataków na ogromną skalę pozostają w stałej gotowości do obrony Rzeczypospolitej. Wojsko buduje w ten sposób zaufanie do osób na co dzień zatrudnionych w miejscach krytycznych, z punktu widzenia obronności.

Te ćwiczenia prowadzone są regularnie i w formule międzynarodowej. To oznacza tworzenie drużyn różnych narodowości. Polska reprezentacja regularnie gości na podium.

Ideę można podsumować w następujący sposób „nie chcemy informatyków w okopach”.

Amerykanie stawiają na fizyczny realizm. Sami nawet używają słowa „kinetyczny”. Uczą się reagować na incydent tam, gdzie cyber styka się z fizycznym światem. Polskie podejście jest czysto cyfrowe. To trening skupiony na samej walce w sieci, bez scenografii.

Aby dołączyć do Cyberlegionu, należy zacząć od formularza na stronie https://cyberlegion.wp.mil.pl/

Źródła:
https://www.inc.com/chloe-aiello/inside-the-fbis-fake-alabama-town-and-the-real-reason-it-has-a-gas-station-and-data-center/91361033
https://www.fbi.gov/news/stories/inside-the-fbis-kinetic-cyber-range
https://cyberlegion.wp.mil.pl/
https://www.fbi.gov/history/artifacts/ross-william-ulbrichts-laptop
https://www.wojsko-polskie.pl/woc/kadra/

The post Jak FBI szkoli śledczych w realistycznym cyberpoligonie? appeared first on CERT Orange.

Future

AI coraz bliżej cyberprzestępców — WhatsApp tylko początkiem historii

• AI coraz częściej wspiera tworzenie kampanii malware. Analizowana operacja pokazuje, że generatywna AI może służyć nie tylko do pisania kodu, ale również do budowy modułów, komentarzy oraz automatyzacji całego procesu przygotowania ataku.
• Znane techniki, nowe połączenie. Kampania wykorzystuje dobrze znane elementy – WhatsApp, VBScript, legalne narzędzia RMM oraz wieloetapowy loader – jednak ich integracja tworzy skuteczny i trudniejszy do wykrycia łańcuch infekcji.
• Poszlaki wskazują na chiński ekosystem malware. Powiązania infrastrukturalne z kampaniami wykorzystującymi ValleyRAT i Gh0st RAT oraz charakterystyczne chińskie komentarze w kodzie mogą świadczyć o wykorzystaniu narzędzi lub infrastruktury powiązanej z chińskimi operatorami.

Kampania opisana przez badaczy z Kaspersky pokazuje kolejny etap ewolucji cyberprzestępczości. Choć na pierwszy rzut oka mamy do czynienia z dobrze znanym scenariuszem – przejęte konta WhatsApp rozsyłają złośliwe pliki VBS prowadzące do instalacji oprogramowania RMM – analiza kodu sugeruje znacznie ciekawsze zjawisko.  Techniki wykorzystane w kampanii nie są nowe. Atakujący łączą kompromitację zaufanych kont komunikatora, socjotechnikę, wieloetapowy łańcuch infekcji, zaciemniony kod VBScript oraz legalne narzędzia do zdalnego zarządzania. To zestaw technik znanych od lat. Nowością jednak wydaje się sposób ich przygotowania. Zmienia się więc nie tyle arsenał atakujących, ile ekonomia prowadzenia operacji. 
 
Kod, który wygląda jak napisany przez AI 

Na uwagę zasługują bardzo rozbudowane komentarze znajdujące się w skryptach VBScript. Wiele z nich napisano w języku chińskim i opisują rzekome funkcje związane z Windows Update, weryfikacją certyfikatów, integralnością systemu czy procesami wdrożeniowymi. Komentarze nie mają praktycznego znaczenia dla działania malware, lecz sprawiają wrażenie wygenerowanych automatycznie i mają utrudniać analizę kodu.  Nie jest to oczywiście dowód na wykorzystanie modeli językowych, jednak taki sposób tworzenia kodu jest zgodny z obserwowanym sposobem wykorzystania generatywnej AI przez cyberprzestępców. 

Coraz częściej AI nie służy do stworzenia całego malware’u, lecz do: 

• automatycznego generowania fragmentów kodu,  

• przygotowywania komentarzy i dokumentacji utrudniających analizę,  

• budowy wielu wariantów tych samych modułów,  

• szybkiej adaptacji kampanii do nowych języków i regionów,  

• orkiestracji całego procesu infekcji.  

AI nie zastępuje operatora, lecz skraca czas potrzebny na przygotowanie kolejnych elementów kampanii, ułatwia ich modyfikację i pozwala operatorowi skupić się na logice całej operacji. 

AI jako orkiestrator, nie tylko programista 

Najciekawszy nie jest sam zestaw wykorzystanych technik, lecz sposób ich połączenia w spójny łańcuch infekcji. Łańcuch infekcji obejmuje: 

• wykorzystanie przejętych kont WhatsApp,  

• lokalizację nazw plików do wielu języków,  

• wieloetapowe pobieranie kolejnych komponentów,  

• instalację legalnego rozwiązania RMM,  

• uzyskanie trwałego zdalnego dostępu do systemu.  

Żaden z tych elementów nie jest nowy. Wartość i skuteczność kampanii wynikają z ich spójnego połączenia, które pokazuje coraz większą automatyzację przygotowania operacji. 

Powiązania z chińskim ekosystemem malware 

Autorzy analizy wskazują również na pokrywającą się infrastrukturę wykorzystywaną wcześniej przez operatorów malware ValleyRAT oraz Gh0st RAT. Szczególnie drugi z nich od lat kojarzony jest z chińskim ekosystemem zagrożeń. Dodatkową poszlaką są liczne komentarze zapisane po chińsku oraz wykorzystanie infrastruktury hostowanej między innymi w usługach chmurowych popularnych w regionie Azji i Pacyfiku. Choć żadna z tych przesłanek nie pozwala na jednoznaczną atrybucję, ich współwystępowanie wzmacnia hipotezę o powiązaniach kampanii z chińskim operatorami malware

Patrząc szerzej

Najciekawszym elementem tej kampanii nie jest WhatsApp ani VBScript, lecz sposób zbudowania całej operacji. Coraz więcej kampanii przypomina składanie gotowych komponentów, a generatywna AI staje się narzędziem wspierającym ich tworzenie, modyfikację i integrację. Pozwala szybko przygotować kolejne moduły, generować warianty kodu, tworzyć komentarze utrudniające analizę czy lokalizować kampanie na wiele języków.  Poszczególne komponenty tworzą modułową architekturę, w której poszczególne elementy można łatwo wymieniać i ponownie wykorzystywać. Takie podejście przypomina bardziej budowę oprogramowania niż klasyczne tworzenie malware. 

Być może właśnie obserwujemy zmianę podejścia do tworzenia kampanii malware. Jeszcze kilka lat temu modele językowe kojarzyły się głównie z pomocą przy pisaniu kodu. Dziś coraz częściej stają się elementem procesu projektowania całych kampanii. Nie zmienia to samych technik ataku, ale radykalnie skraca czas potrzebny do przygotowania kolejnych operacji. W efekcie przewagę będą zdobywać nie ci operatorzy, którzy opracują nowe techniki ataku, lecz ci, którzy najszybciej złożą znane techniki w kolejne skuteczne kampanie. 

Więcej informacji:
https://securelist.com/whatsapp-vbs-rmm-campaign/120290/

Łańcuch dostaw

Nie przez paczkę, lecz przez integrację. Klue i ryzyko łańcucha dostaw w SaaS

• Przypadek Klue pokazuje, że atak na łańcuch dostaw w modelu SaaS może przebiegać przez zaufane integracje i tokeny OAuth, bez potrzeby dostarczania złośliwego kodu do środowiska klienta.
• Dane przechowywane w CRM mają dużą wartość operacyjną. Mogą ułatwiać dalszy rekonesans, zwiększać wiarygodność podszyć i wspierać kolejne próby wyłudzeń lub phishingu.
• Zarządzanie bezpieczeństwem usług SaaS nie powinno kończyć się na kontach użytkowników. Równie istotne są przegląd integracji, ograniczanie zakresu uprawnień aplikacji i gotowość do szybkiego unieważniania tokenów po incydencie u dostawcy. 

Ataki na łańcuch dostaw w tym roku często kojarzą się z podmienioną biblioteką albo złośliwą aktualizacją. Tym razem skojarzenie z npm można odłożyć na bok. Punktem wejścia okazała się zaufana usługa SaaS, zintegrowana z systemami klientów i z uprawnieniami, które w normalnych warunkach miały po prostu usprawniać pracę. 

Incydent związany z Klue  miał miejsce 12 czerwca 2026 i przyciągnął uwagę ze względu na listę poszkodowanych organizacji, ale z perspektywy obrony ważniejszy jest sam mechanizm. Z opublikowanych informacji wynika, że naruszenie objęło warstwę integracyjną wykorzystywaną przez Klue do łączenia się z innymi platformami, a skutki objęły również klientów korzystających z tych połączeń. 

Według ustaleń opublikowanych przez poszkodowane firmy i podmioty analizujące incydent atakujący uzyskali dostęp do części systemów backendowych Klue, a następnie wykorzystali je do pozyskiwania tokenów OAuth używanych przez klientów do integracji z własnymi usługami. W praktyce oznaczało to możliwość sięgnięcia po dane w zewnętrznych systemach bez przejmowania kont konkretnych pracowników. To nadużycie skompromitowanej integracji Klue Battlecards do pobierania danych z Salesforce przez tokeny OAuth i zapytania do API. 

Wokół sprawy pojawiły się też rozbieżności dotyczące przypisania ataku. Początkowo incydent łączono z grupą ShinyHunters, ale dostępne przesłanki coraz wyraźniej wskazują na odrębnego aktora określanego jako Icarus, który wykorzystywał skradzione dane do działań wymuszeniowych. Na obecnym etapie ważniejszy od atrybucji pozostaje jednak sposób działania i skala ryzyka po stronie klientów korzystających z integracji. 

Właśnie dlatego ten przypadek jest ciekawszy niż tylko jako kolejny wyciek danych. W klasycznym skojarzeniu z supply chain główną rolę gra złośliwy kod dostarczony do środowiska ofiary. Tutaj problem pojawił się w relacji zaufania między klientem a usługą, która już wcześniej dostała dostęp do danych. Jeśli taka integracja działa na szerokich uprawnieniach, incydent po stronie dostawcy szybko staje się incydentem po stronie klienta. 

W przypadku Klue szczególnie istotne były połączenia z systemami CRM, przede wszystkim z Salesforce. To ważne, bo CRM bywa traktowany jako narzędzie sprzedażowe, a nie jako zasób o wysokiej wartości z perspektywy bezpieczeństwa. Tymczasem właśnie tam znajdują się dane kontaktowe, informacje o relacjach z klientami, notatki handlowe, szczegóły komunikacji i kontekst prowadzonych spraw. Huntress oraz Recorded Future wskazywały, że zakres narażonych informacji obejmował m.in. dane kontaktowe, informacje o klientach, szczegóły subskrypcji i elementy komunikacji sprzedażowej. 

Taki zestaw danych może być bardzo użyteczny operacyjnie. Pozwala odtworzyć, kto z kim rozmawia, jak wygląda język komunikacji, jakie sprawy są aktualnie prowadzone i kto odpowiada za relację po obu stronach. To wystarczająco dużo, by przygotować wiarygodne wiadomości podszywające się pod handlowca, opiekuna klienta albo partnera technologicznego. Powstaje ryzyko dalszego phishingu opartego na danych pozyskanych w tym incydencie. 

Z perspektywy obrony ten przypadek zostawia kilka praktycznych wniosków. Pierwszy dotyczy widoczności. Organizacje zwykle wiedzą, którzy użytkownicy mają dostęp do kluczowych systemów, ale nie zawsze potrafią szybko wskazać, które aplikacje trzecie mają taki dostęp, od kiedy i z jakim zakresem uprawnień. W środowisku SaaS to za mało. Integracje OAuth trzeba traktować jak element powierzchni ataku, czyli należy je inwentaryzować, monitorować i okresowo przeglądać. 

Drugi wniosek dotyczy zakresu uprawnień. Jeżeli integracja potrzebuje tylko części danych albo samego odczytu, nie powinna dostawać szerszego dostępu wyłącznie dla wygody wdrożenia. W Klue zakres możliwych do pobrania danych zależał bezpośrednio od konfiguracji uprawnień po stronie klienta. To pokazuje, że decyzje podejmowane na etapie wdrożenia mają bezpośredni wpływ na późniejszą skalę incydentu. 

Trzeci wniosek dotyczy reakcji na incydent u dostawcy. W takim scenariuszu trzeba być gotowym nie tylko do zmiany haseł czy przeglądu kont użytkowników, ale również do unieważniania tokenów, weryfikacji aktywnych integracji i analizy logów z powiązanych usług. 

Patrząc szerzej

Incydent Klue dobrze pokazuje, że jedna usługa z dostępem do wielu środowisk klientów może otworzyć drogę do serii wtórnych incydentów, nawet jeśli po stronie samych klientów nie doszło do przełamania zabezpieczeń w tradycyjnym rozumieniu. To model, który dobrze pasuje do środowisk opartych na integracjach, API i rozproszonych procesach biznesowych. 

Druga rzecz dotyczy samych danych biznesowych. CRM, narzędzia sprzedażowe i platformy wspierające relacje z klientami nadal bywają oceniane niżej niż systemy tożsamości czy repozytoria kodu. Tymczasem ich zawartość może być bardzo użyteczna na kolejnych etapach operacji przestępczej. Dlatego przegląd w środowisku SaaS aplikacji trzecich, ich uprawnień i cyklu życia dostępu powinno być elementem podstawowej higieny bezpieczeństwa. 

Więcej informacji:  
https://klue.com/blog/an-update-on-recent-klue-security-incident 
https://www.huntress.com/blog/klue-breach-investigation

Malware

AI wspierająca analityków staje się nowym celem ataków

• Opisano nowy backdoor dla macOS – Gaslight, przypisywany z dużym prawdopodobieństwem grupie powiązanej z Koreą Północną. Malware napisano w języku Rust i wykorzystuje Telegram jako kanał komunikacji C2.
• Najbardziej unikalnym elementem kampanii jest zastosowanie prompt injection jako techniki anti-analysis. Zamiast omijać sandboxy, malware próbuje manipulować modelami LLM wspierającymi analizę próbek.
• Kampania pokazuje nowy kierunek rozwoju zagrożeń – wraz z popularyzacją AI w procesach Reverse Engineering i Incident Response modele językowe stają się kolejnym celem ataków, a nie tylko narzędziem obrony.

Badacze SentinelOne opisali nową rodzinę malware dla macOS o nazwie Gaslight, przypisywaną z dużym prawdopodobieństwem aktorom powiązanym z Koreą Północną. Najciekawszym elementem opisanej kampanii jest jednak coś zupełnie innego. Po raz pierwszy opisano malware zaprojektowany tak, aby manipulować narzędziami AI wykorzystywanymi przez analityków bezpieczeństwa. 

Najbardziej innowacyjnym elementem Gaslight jest zastosowanie techniki prompt injection jako mechanizmu utrudniającego analizę próbki. W kodzie malware umieszczono dziesiątki spreparowanych komunikatów przypominających błędy systemowe lub informacje diagnostyczne, takie jak wygaśnięcie tokena, uszkodzenie środowiska analitycznego czy konieczność przerwania analizy. Komunikaty te nie są wykorzystywane przez sam malware ani system operacyjny – ich jedynym odbiorcą mają być modele językowe analizujące kod lub artefakty podczas procesu Reverse Engineering. Celem nie jest więc oszukanie sandboxa czy debuggera, ale wpłynięcie na interpretację próbki przez AI wspierającą analityka. 

Przez lata twórcy malware rozwijali mechanizmy wykrywające środowiska wirtualne, debugery czy emulatory. Gaslight pokazuje, że wraz z upowszechnieniem modeli LLM w procesach SOC, CTI i Reverse Engineering pojawia się nowa powierzchnia ataku – proces analityczny wspomagany sztuczną inteligencją. Modele językowe stają się kolejnym elementem infrastruktury obronnej, który napastnicy próbują omijać i świadomie wprowadzać w błąd. 

Opisana kampania wpisuje się również w wyraźny trend obserwowany w ostatnich dwóch–trzech latach – dynamiczny wzrost liczby zaawansowanych zagrożeń wymierzonych w użytkowników macOS. Jeszcze kilka lat temu ekosystem Apple był traktowany przez cyberprzestępców głównie jako cel niszowy, wykorzystywany przede wszystkim w operacjach szpiegowskich prowadzonych przez grupy APT. Obecnie sytuacja uległa istotnej zmianie. Wraz ze wzrostem udziału komputerów Mac w środowiskach korporacyjnych oraz ich popularnością wśród administratorów, programistów i kadry zarządzającej, platforma stała się atrakcyjnym celem również dla cyberprzestępczości finansowej. Coraz częściej obserwowane są kampanie prowadzone na dużą skalę, wykorzystujące model Malware-as-a-Service (MaaS), fałszywe instalatory popularnych aplikacji, malvertising, SEO poisoning oraz techniki ClickFix zachęcające użytkowników do samodzielnego uruchamiania złośliwych poleceń w Terminalu.  

Szczególnie widoczny jest rozwój rodzin Atomic macOS Stealer (AMOS), Poseidon, Cthulhu oraz Banshee, które wyspecjalizowały się w kradzieży danych z przeglądarek, pęku kluczy Keychain, portfeli kryptowalut, menedżerów haseł oraz dokumentów użytkownika. Część z nich jest rozwijana komercyjnie i oferowana w modelu abonamentowym na forach przestępczych, co świadczy o dojrzewaniu podziemnego ekosystemu malware dla macOS. Badacze zwracają uwagę, że infostealery stały się obecnie najliczniejszą kategorią nowego malware dla tej platformy, a w telemetrii producentów bezpieczeństwa liczba wykrywanych kampanii wzrosła w 2024 roku nawet o ponad 100% kwartał do kwartału.  

Równolegle obserwowany jest wzrost liczby bardziej zaawansowanych implantów wykorzystywanych przez grupy APT. W ostatnich latach opisywano m.in. RustDoor, SpectralBlur, XCSSET, CloudMensis, ZuRu czy obecnie Gaslight, pokazując, że twórcy zaawansowanego malware coraz częściej przygotowują pełnoprawne wersje swoich narzędzi dla macOS, a nie jedynie portują istniejące rozwiązania z Windows. W efekcie macOS przestaje być postrzegany jako platforma o ograniczonym znaczeniu operacyjnym i staje się równorzędnym celem zarówno dla kampanii cyberszpiegowskich, jak i operacji motywowanych finansowo. 

Opisany tu przypadek należy postrzegać nie tylko jako analizę kolejnej rodziny malware, lecz przede wszystkim jako zapowiedź nowego kierunku rozwoju zagrożeń. Wraz z rosnącym wykorzystaniem sztucznej inteligencji do analizy incydentów, klasyfikacji zagrożeń i wspomagania Reverse Engineering można oczekiwać, że techniki LLM-targeted prompt injection staną się standardowym elementem przyszłych kampanii. 

Patrząc szerzej

Gaslight przypomina, że każda nowa technologia wykorzystywana przez obrońców prędzej czy później staje się celem ataków. AI nie jest wyjątkiem. Wraz z rosnącym wykorzystaniem modeli językowych w procesach SOC, CTI, Reverse Engineering i Incident Response należy zakładać, że techniki manipulujące ich działaniem staną się naturalnym elementem arsenału cyberprzestępców i grup APT. 

Dlatego organizacje wdrażające AI do procesów bezpieczeństwa powinny już dziś projektować rozwiązania zgodnie z zasadą “zero trust” wobec analizowanych danych. Modele językowe powinny wspierać pracę analityka, przyspieszać analizę i automatyzować rutynowe zadania, ale nie mogą stanowić jedynego źródła decyzji. Odporność na prompt injection, walidacja wyników oraz nadzór eksperta staną się równie istotne, jak odporność na klasyczne techniki omijania zabezpieczeń. To właśnie w tym kierunku będzie ewoluował krajobraz zagrożeń w erze AI. 

Więcej informacji:
https://www.sentinelone.com/labs/macos-gaslight-rust-backdoor-turns-prompt-injection-on-the-analyst-not-the-sandbox/ 

The post Krajobraz Zagrożeń – 29.06.2026 appeared first on CERT Orange.