Ostatni tydzień przyniósł analizy zróżnicowanych zagrożeń oferujące alternatywne spojrzenia na znane wyzwania dla cyberbezpieczeństwa. Naszą uwagę zwróciły dwa exploit kity na iPhone’y, których wykorzystanie w atakach rzuca nowe światło na zaawansowane ataki na urządzenia mobilne. Równolegle obserwujemy wyraźne przyspieszenie w obszarze wykorzystania modeli językowych, które przestają być jedynie wsparciem dla socjotechniki, a coraz częściej stają się elementem procesu tworzenia i skalowania malware. Nie zabrakło także wglądu w metody cyberprzestępców z grupy ShinyHunters stosujących radykalne techniki wywierania presji na ofiary. Każdy z tych wątków prezentuje inne oblicze dynamicznie rozwijającego się krajobrazu zagrożeń o czym przeczytacie poniżej.

Mobile

Dwa tygodnie marca, dwa exploit kity — Coruna i DarkSword.

W ciągu dwóch tygodni marca 2026 roku badacze ujawnili dwa osobne, w pełni funkcjonalne exploit kity wymierzone w iPhone’y. Oba wdrożyła w ataki ta sama rosyjska grupa, atakując kolejno ukraińskie serwisy internetowe w kampaniach typu watering hole. Coruna i DarkSword to nie odosobnione przypadki ani przypadkowe zbiegi okoliczności – to dokumentacja aktywnego rynku wtórnego, na którym zaawansowane narzędzia ofensywne klasy nation-state zmieniają właścicieli i trafiają do grup, które nie byłyby w stanie samodzielnie ich zbudować. 

Coruna 

W lutym 2025 roku Google Threat Intelligence Group przechwyciło fragmenty nieznanego wcześniej exploit kitu podczas analizy aktywności klienta komercyjnego dostawcy oprogramowania szpiegowskiego. Pierwszym uruchomionym modułem frameworku był fingerprinting, który weryfikował, czy ma do czynienia z faktycznym iPhonem, sprawdzał model urządzenia, wersję systemu, obecność trybu Lockdown Mode i przeglądania prywatnego. Jakikolwiek sygnał wskazujący na środowisko analityczne kończył działanie kitu. Dopiero po przejściu tych kontroli framework ładował odpowiedni exploit WebKit dla wykrytej wersji iOS. 

Latem tego samego roku GTIG natrafiło na ten sam framework na ukraińskich stronach, osadzony jako ukryty iFrame w witrynach sektora przemysłowego, handlowego i usługowego, serwowany wyłącznie użytkownikom iPhone’ów z określonej geolokalizacji. Stała za tym grupa UNC6353, oceniana jako podmiot o charakterze rosyjsko-szpiegowskim. Pod koniec roku ten sam kit trafił do zupełnie innego środowiska operacyjnego, a mianowicie dużego zbioru fałszywych chińskich witryn finansowych i platform kryptowalutowych. Geolokalizacyjnego filtra już nie było – każdy iPhone na podatnej wersji systemu był atakowany automatycznie. Grupę odpowiedzialną za tę fazę, oznaczoną jako UNC6691, GTIG ocenia jako finansowo motywowany podmiot operujący z Chin. iVerify, który prowadził niezależną analizę, zwrócił uwagę na kluczową cechę tego wdrożenia – kit nie zawierał mechanizmów jednorazowych linków ani targetowania konkretnych ofiar, a każde podatne urządzenie mogło zostać zainfekowane wielokrotnie. To nie jest typowe dla operacji wywiadowczych, lecz dla modelu działalności cyberprzestępczej. 

Kit jest zbiorem 23 exploitów zorganizowanych w pięć kompletnych łańcuchów, obejmujących iOS od wersji 13.0 do 17.2.1. Payloady są szyfrowane algorytmem ChaCha20 z unikalnym kluczem dla każdego bloku, pakowane we własnym formacie rozpoczynającym się nagłówkiem 0xf00dbeef i kompresowane LZW. Serwowane są z URL-i kończących się rozszerzeniem .min.js, co upodabnia je do standardowych skryptów webowych. W debugowej wersji kitu, odzyskanej z chińskiej infrastruktury, znaleziono wewnętrzne nazwy komponentów – stąd nazwa Coruna. Mechanizm proliferacji tego narzędzia pozostaje niejasny, ale wskazuje na aktywny rynek wtórny dla exploitów. 

DarkSword 

Dwa tygodnie po ujawnieniu Coruny, GTIG opublikowało razem we współpracy z iVerify i Lookout analizy kolejnego kitu. Trop pojawił się przy śledzeniu infrastruktury UNC6353 po ujawnieniu Coruny. DarkSword jest technicznie odrębną konstrukcją napisaną w całości w JavaScript, bez tradycyjnych binarnych payloadów – i celuje w iOS 18.4–18.7, czyli w zupełnie inny zakres wersji niż Coruna. Powiązanie między nimi ma charakter operacyjny, gdyż UNC6353 włączyła DarkSword do swoich kampanii watering hole. Wektorem wejścia były tym razem dwie skompromitowane ukraińskie domeny: serwis informacyjny związany z sytuacją w Donbasie i witryna instytucji sądowniczej z czego jedna z nich była wcześniej używana do dystrybucji Coruny. Serwer exploitów zlokalizowano w Estonii, a pliki były ostatnio modyfikowane 23 grudnia 2025 roku. Wczesne etapy łańcucha zawierały komentarze w języku rosyjskim, dalsze w angielskim. 

Łańcuch infekcji przebiega przez kolejne procesy systemowe. Exploit WebKit uzyskuje opcję wykonania kodu w procesie WebContent, następnie DarkSword wykorzystuje podatność w komponencie GPU (ANGLE), aby dostać się do demona mediaplaybackd. Stamtąd buduje prymitywy odczytu i zapisu pamięci jądra, pozwalające na obejście mechanizmów sandboxa. Finalny moduł post-exploitation pe_main.js wstrzykuje payloady do kluczowych usług systemowych – configd, wifid, securityd i UserEventAgent – skąd dane są zbierane i przesyłane na serwer C2. Kit nie zakłada trwałej obecności w systemie, po eksfiltracji usuwa ślady i kończy działanie. Czas przebywania na urządzeniu to prawdopodobnie kilka minut. 

Pełny łańcuch opiera się na błędach w JavaScriptCore, mechanizmie PAC w dyld, komponencie ANGLE oraz jądrze iOS. Większość załatano przed publikacją raportu, pozostałe z wydaniem iOS 26.3. GTIG obserwowało DarkSword w rękach kilku odrębnych podmiotów – zarówno aktorów państwowych, jak i komercyjnych dostawców spyware – co potwierdza, że dystrybucja kitu wykroczyła daleko poza jednego operatora. Zakres eksfiltrowanych danych obejmuje historię komunikacji przez SMS, iMessage i komunikatory, kontakty, dane lokalizacyjne, pliki użytkownika oraz dane portfeli i kont na giełdach kryptowalutowych. 

UNC6353 

Lookout, który przeprowadził najgłębszą analizę grupy, charakteryzuje UNC6353 jako podmiot dobrze finansowany i powiązany, lecz relatywnie słabszy pod względem inżynieryjnym. Brak zaawansowanej obfuskacji, proste nazewnictwo infrastruktury C2 oraz ślady wykorzystania LLM przy tworzeniu części backendu sugerują ograniczone kompetencje techniczne lub niski priorytet dla opsec. Pliki exploitów zawierały odniesienia do starszych wersji iOS, co wskazuje, że mogły zostać zaadaptowane z wcześniejszych zestawów narzędzi – potencjalnie pozyskanych od zewnętrznego dostawcy. 

Zarówno Coruna, jak i DarkSword łączą funkcje szpiegowskie z możliwością pozyskiwania danych o wartości finansowej. Lookout ocenia, że UNC6353 może funkcjonować jako podmiot działający równolegle w interesie państwowym i dla własnego zysku. 

iOS dołącza do krajobrazu zagrożeń Apple 

Coruna i DarkSword wpisują się w szerszy trend obserwowany w ostatnim czasie: stopniowe obniżanie bariery wejścia dla zaawansowanych exploitów na platformy Apple. Na iOS próg wejścia był dotąd znacznie wyższy – koszty i złożoność pełnych łańcuchów exploitów skutecznie ograniczały ich dostępność. Te dwa kity dokumentują moment, w którym ta bariera zaczyna się obniżać,m co sprawia, że exploity klasy nation-state przestają być ograniczone do precyzyjnie wybranych celów i mogą być stosowane wobec szerszej grupy użytkowników. 

Rekomendujemy aktualizację systemu operacyjnego, dodatkowo korzystanie z Lockdown Mode, co skutecznie ogranicza powierzchnię ataku. Jednakże w niektórych środowiskach enterprise urządzenia mobilne nadal rzadko są zarządzane jak klasyczne endpointy, co w praktyce utrudnia wdrożenie tych podstawowych środków ochrony na dużą skalę. 

Więcej informacji: 
https://cloud.google.com/blog/topics/threat-intelligence/coruna-powerful-ios-exploit-kit 
https://iverify.io/blog/coruna-inside-the-nation-state-grade-ios-exploit-kit-we-ve-been-tracking 
https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain 
https://iverify.io/blog/darksword-ios-exploit-kit-explained 
https://www.lookout.com/threat-intelligence/article/darksword 

Future

Jak modele językowe zmieniają produkcję malware.

W ostatnich kilkunastu miesiącach obserwujemy wyraźne przesunięcie w krajobrazie zagrożeń – modele językowe przestają pełnić wyłącznie funkcję wsparcia dla operacji socjotechnicznych, a zaczynają być bezpośrednio wykorzystywane w procesie tworzenia i operacjonalizacji złośliwego oprogramowania. Początkowo ich zastosowanie koncentrowało się głównie na generowaniu phishingu czy automatyzacji komunikacji z ofiarą, obecnie jednak coraz częściej uczestniczą w tworzeniu kodu, logiki działania oraz elementów łańcucha ataku. Zjawisko to wpisuje się w szerszy trend upraszczania narzędzi ofensywnych i ułatwienia dostępu do zaawansowanych technik ataku, w którym modele LLM zaczynają pełnić rolę „interaktywnego developera”, zdolnego generować kod na żądanie, tłumaczyć błędy oraz iteracyjnie poprawiać działanie narzędzi. 

Łatwo jednak ulec wrażeniu, że rozwój sztucznej inteligencji prowadzi do powstania autonomicznego malware, zdolnego do samodzielnego prowadzenia operacji ofensywnych. Dotychczasowe obserwacje wskazują jednak na ewolucyjny charakter tej zmiany. Zgodnie z analizą Recorded Future, AI pełni przede wszystkim rolę „force multiplier” – wzmacniacza istniejących technik ataku, a nie źródła fundamentalnie nowych TTPs. Oznacza to, że obserwowane kampanie nie odbiegają znacząco od znanych schematów. Nadal dominują klasyczne łańcuchy ataku obejmujące phishing, droppery, wykorzystanie narzędzi typu living-off-the-land oraz eksfiltrację danych, natomiast AI przyspiesza ich przygotowanie, lokalizację i skalowanie. 

Modele językowe wykorzystywane są głównie do generowania kodu, tłumaczenia dokumentacji, tworzenia skryptów oraz automatyzacji powtarzalnych czynności, nie zastępując operatora. Większość obserwowanych przypadków nie stanowi więc „AI-native malware”, lecz tradycyjne narzędzia wzbogacone o komponenty AI. Aktywność ta mieści się w niższych poziomach dojrzałości wykorzystania AI, wspierając istniejące procesy zamiast je redefiniować. Zasadnicza zmiana nie dotyczy natury samych ataków, lecz ich ekonomii – czasu przygotowania, kosztu wytworzenia oraz możliwości skalowania. 

Kolejnym istotnym efektem jest zmiana charakteru samego malware. Tradycyjnie był on artefaktem statycznym – binarnym lub skryptowym – którego logika była w pełni zawarta w kodzie. W rozwiązaniach wykorzystujących AI coraz częściej obserwuje się przejście w kierunku architektury rozproszonej, w której część logiki realizowana jest dynamicznie poprzez zapytania do modeli językowych. W efekcie malware przestaje być zamkniętym programem, a zaczyna funkcjonować jako komponent większego systemu, obejmującego infrastrukturę API, modele oraz zewnętrzne źródła danych. To przesunięcie nie oznacza jeszcze rewolucji technologicznej, ale wyraźnie sygnalizuje kierunek dalszej ewolucji operacji ofensywnych. 

Vibe coding w operacjach ofensywnych 

Pojęcie „vibe codingu” odnosi się do praktyki generowania kodu w sposób iteracyjny, przy minimalnym zrozumieniu jego szczegółowego działania, opierając się na sugestiach modelu AI. W kontekście cyberzagrożeń oznacza to fundamentalną zmianę w sposobie powstawania złośliwego oprogramowania. Autor nie musi już posiadać głębokiej wiedzy z zakresu programowania systemowego, kryptografii czy technik omijania zabezpieczeń. Wystarczające staje się umiejętne formułowanie zapytań oraz testowanie i modyfikowanie wygenerowanych fragmentów kodu. 

Analizy kampanii malware wskazują, że kod tworzony w ten sposób posiada charakterystyczne cechy. Z jednej strony jest funkcjonalny i kompletny, z drugiej zawiera liczne artefakty świadczące o jego genezie – nadmiarowe komentarze, niespójne nazewnictwo zmiennych, fragmenty kodu o nieoptymalnej logice czy implementacje mechanizmów działających poprawnie, ale w sposób daleki od efektywnego. W wielu przypadkach obserwuje się także fragmenty kodu testowego lub debugującego, co sugeruje brak pełnej kontroli autora nad projektem. 

Z perspektywy operacyjnej vibe coding umożliwia szybkie prototypowanie i skalowanie narzędzi. Aktor może w krótkim czasie wygenerować wiele wariantów tego samego malware, różniących się szczegółami implementacyjnymi, co utrudnia detekcję opartą na sygnaturach. Co więcej, modele językowe mogą być wykorzystywane nie tylko do tworzenia kodu, ale także do jego modyfikacji w odpowiedzi na wykrycie przez systemy bezpieczeństwa, wprowadzając element quasi-adaptacyjności do procesu tworzenia malware. 

Kampania „vibe-coded malware”  

Jednym z najbardziej reprezentatywnych przykładów wykorzystania AI w tworzeniu malware jest kampania opisana przez McAfee, określana jako „vibe-coded malware”. Analiza tej operacji pokazuje, jak modele językowe są używane nie do tworzenia nowej klasy zagrożeń, lecz do przyspieszenia i uproszczenia produkcji istniejących typów złośliwego oprogramowania. 

Kampania obejmowała dystrybucję setek złośliwych archiwów podszywających się pod popularne narzędzia, oprogramowanie użytkowe oraz komponenty związane z ekosystemem AI. Wewnątrz znajdowały się stosunkowo proste łańcuchy infekcji, oparte na loaderach oraz skryptach PowerShell, których zadaniem było pobranie i uruchomienie kolejnych etapów payloadu, w tym oprogramowania typu infostealer lub cryptominer. Struktura ataku pozostaje więc zgodna z klasycznymi schematami, co potwierdza, że AI nie zmienia fundamentów technicznych kampanii, lecz wpływa na tempo przygotowania i skalę operacji. Najbardziej charakterystycznym elementem tej operacji jest sposób implementacji kodu. Analizowane próbki wykazują wyraźne artefakty wskazujące na wykorzystanie modeli językowych – kod jest uporządkowany i modularny, ale zawiera nadmiarowe komentarze, niespójne nazewnictwo oraz fragmenty funkcjonalności o ograniczonej sensowności implementacji. Widoczna jest także redundancja i brak optymalizacji, co wskazuje na iteracyjny sposób generowania i modyfikowania kodu – typowy dla vibe coding.  

Charakterystyczna dla kampanii jest architektura próbek. Zamiast monolitycznych implementacji obserwuje się zwiększoną modularność i fragmentaryzację – malware składa się z wielu mniejszych komponentów, generowanych niezależnie i łączonych w większe łańcuchy infekcji. Takie podejście sprzyja szybkiemu tworzeniu wariantów oraz dostosowywaniu ich do różnych scenariuszy dystrybucji, zwiększając skalę operacji. Konsekwencją tego modelu produkcji jest powstawanie wielu próbek o zbliżonej funkcjonalności, lecz różniących się szczegółami implementacyjnymi. Klasyczne podejścia detekcyjne oparte na sygnaturach stają się mniej skuteczne, ponieważ każda próbka może mieć inny „kształt” kodu przy zachowaniu identycznej funkcjonalności. W takim środowisku większe znaczenie zyskuje analiza behawioralna i korelacja zdarzeń, pozwalająca identyfikować powtarzalne wzorce działania zamiast konkretnych artefaktów. 

PromptSpy – AI jako element adaptacji, nie inteligencji 

Przypadek PromptSpy, opisywany przez nas we wcześniejszej publikacji, stanowi jeden z reprezentatywnych przykładów obecnego kierunku wykorzystania AI w krajobrazie zagrożeń mobilnych. Integracja modeli AI na etapie wykonania (tzw. runtime) pokazuje nowy kierunek rozwoju — przejście od wykorzystania AI jako narzędzia pomocniczego (np. do generowania kodu) do roli komponentu operacyjnego, wspierającego konkretne funkcje malware. Jednocześnie obecne implementacje pozostają ograniczone — mają charakter statyczny i wyspecjalizowany, co oznacza, że AI nadal pełni rolę wąskiego modułu, a nie autonomicznego mechanizmu decyzyjnego. 

Kierunki rozwoju: malware jako workflow AI 

Obserwowane trendy wskazują, że malware będzie coraz bardziej integrować się z systemami AI, prowadząc do powstania narzędzi działających jako autonomiczne agenty. W takim modelu malware nie będzie już jedynie zestawem instrukcji, lecz częścią większego workflow – obejmującego generowanie decyzji, adaptację do środowiska oraz dynamiczną modyfikację zachowania. 

Można spodziewać się dalszego rozwoju w kierunku integracji z technikami typu living-off-the-land, gdzie AI generuje polecenia wykorzystujące natywne narzędzia systemowe i usługi chmurowe. Pozwoli to ograniczyć potrzebę dostarczania własnego kodu i zmniejszyć powierzchnię detekcji. Równocześnie rośnie znaczenie infrastruktury wspierającej, w tym dostępu do modeli językowych, mechanizmów anonimizacji zapytań oraz systemów zarządzania kampaniami. 

W efekcie cyberprzestępczość coraz bardziej przypomina model pracy legalnych organizacji technologicznych, w którym kluczową rolę odgrywają procesy, automatyzacja i skalowalność. Wszystkie przypadki pokazują, że obecnie AI zwiększa efektywność i skalę operacji, ale nie wprowadza inteligencji w malware – wyzwaniem pozostaje adaptacyjność oraz analiza behawioralna. 

Więcej informacji: 
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ai-written-malware-vibe-coded-campaign/ 
https://www.recordedfuture.com/blog/ai-malware-hype-vs-reality 
https://www.welivesecurity.com/en/eset-research/promptspy-ushers-in-era-android-threats-using-genai/  
https://cert.orange.pl/cyber-threat-intelligence/krajobraz-zagrozen-19-25-02-2026/#future 

Cybercrime

Phishing, groźby, szantaż i okup — ShinyHunters znów atakują.

Ataki ShinyHunters, znanych także jako Scaterred Lapsus ShinyHunters, SLSH lub ScatteredLapsu$Hunters, to powracający problem dla wielu dużych firm. Zazwyczaj najpierw pojawiają się informacje medialne oparte na deklaracjach samych atakujących, wyprzedzające komunikację ze strony ofiar. Ten pozornie nieistotny szczegół może być kluczem do zrozumienia grupy, której ataki nie są zaawansowane w technikach, lecz bardzo rozległe w skutkach.  

ShinyHunters 

Ich głównym celem także w poprzednich atakach było Salesforce oraz inne platformy typu SaaS. W atakach nie wykorzystywano nowatorskich exploitów, ani złośliwego oprogramowania. ShinyHunters stosują przede wszystkim socjotechnikę w różnych wydaniach, w tym phishing, vishing i wyłudzanie kodów MFA. Stosowali także technikę MFA Fatigue polegającą na ciągłych próbach logowania prowadzących do zalewania ofiary powiadomieniami z żądaniami akceptacji logowania z aplikacji autoryzacyjnej. Miało to doprowadzić do akceptacji logowania – przypadkowej lub podyktowanej nadzieją na zakończenie uciążliwych prób. Kolejne etapy ataku umożliwiały dostęp za pośrednictwem skradzionych poświadczeń i sesji. Informacje o szczegółach ataków zwykle pochodzą od samych atakujących, więc nie można ich uznać za wiarygodne. Można jednak je przeanalizować i potencjalnie z nich skorzystać, by lepiej zrozumieć adwersarza. Doniesienia warto traktować jako przestrogę i inicjatywę do wzmocnienia zabezpieczeń, nie jako okazję do potępienia ofiar takiego ataku za niedostateczną dbałość o cyberbezpieczeństwo. 

Telus Digital 

Telus Digital jest odnogą odpowiedzialną za outsourcing procesów biznesowych i usług cyfrowych kanadyjskiego operatora telekomunikacyjnego Telus. Grupa ShinyHunters ogłosiła, że dzięki wielomiesięcznym dostępie do ich infrastruktury pozyskali 1 petabajt (lub 700 terabajtów według innej informacji) danych. Wiadomość obiegła media 12 marca, jednak już w styczniu Telus poinformowało BleepingComputer o zaistnieniu incydentu, ale nie podzieliło się szczegółami. Ze względu na szeroki zakres działalności Telus Digital skradzione dane mogą być bardzo zróżnicowane.  

W obliczu braku odpowiedzi od poszkodowanych, BleepingComputer zwróciło się o komentarz do ShinyHunters. Według przedstawionej przez nich wersji wydarzeń wykorzystali poświadczenia do Google Cloud Platfrom pozyskane w ramach incydentu Salesloft Drift. W ramach przypomnienia, atak na Salesloft Drift (aplikację często integrowaną z Salesforce) pozwolił ShinyHunters na dostęp do danych 760 firm i pozyskanie z nich poświadczeń znajdujących się m.in. w ticketach supportowych. W przypadku Telus Digital atakujący mieli wykorzystać dostęp do dostania się do wielu zasobów firmy, w tym hurtowni danych BigQuery. Następnie wykorzystali trufflehog do poszukiwania poświadczeń w już pozyskanych danych, co umożliwiało dalsze poruszanie się po infrastrukturze. Według samego ShinyHunters skradzione zostały informacje o obsłudze klienta i działaniu call center, ale także kod źródłowy, informacje finansowe, dane z Salesforce oraz nagrania rozmów z supportem. Przejęte mogły zostać także historie połączeń wraz z metadanymi. ShinyHunters zażądało 65 milionów dolarów okupu za niepublikowanie danych, lecz według doniesień Telus nie negocjuje z atakującymi. 

Odido 

W weekend 7-8 lutego holenderski operator telekomunikacyjny Odido zidentyfikował incydent związany z nieautoryzowanym dostępem do danych. 12 lutego pojawiła się publiczna informacja i oświadczenie ze strony firmy. 6,2 miliona klientów obecnych i byłych mogło zostać dotkniętych atakiem. Według oświadczenia dane klientów, do których atakujący uzyskali dostęp to dane osobowe, adresowe, kontaktowe, związane z kontem klienta oraz identyfikacyjne (numer paszportu lub prawa jazdy i ważność). Nie uzyskali dostępu do billingów, logów połączeń ani haseł użytkowników. Do ataku przyznała się grupa ShinyHunters. Dane z wycieku były stopniowo udostępniane, a 1 marca całość danych została upubliczniona na stronie Tor grupy. Odido nie negocjowało z atakującymi i nie zapłaciło okupu.  

Według informacji medialnych atak był przeprowadzony z wykorzystaniem scenariusza standardowego dla tej grupy. Phishing oraz vishing kierowany do pracowników firmy miał na celu uzyskanie dostępu do danych klientów znajdujących się w rozwiązaniach typu SaaS. Najpierw wyłudzano login i hasło do Salesforce lub SSO za pomocą standardowego phishingu, następnie atakujący kontaktowali się z pracownikami telefonicznie podając się za pracowników IT, by nakłonić ich do zaakceptowania logowania (na przykład w powiadomieniu) lub podania kodu z SMS czy aplikacji. Atakujący omijali tym sposobem MFA zrealizowane w sposób nieodporny na phishing. Po uzyskaniu dostępu atakujący pobierali dane klientów znajdujące się w Salesforce. Dokładny sposób pobrania danych w tym przypadku jest nieznany. Wiadomo jednak, że w przeszłości atakujący z pomocą socjotechniki nakłaniali pracowników do zaakceptowania instalacji złośliwych „Connnected Apps”, czyli zewnętrznych aplikacji do Salesforce. Aplikacje służyły do sprawniejszej kradzieży danych i wtopieniu się w normalny ruch. Z poziomu logów, taka aktywność wyglądała jak zachowanie wpisujące się w działanie standardowej integracji w Salesforce. Nie były to pobrania dużego wolumenu plików w ramach sesji jednego użytkownika logującego się z niestandardowej lokalizacji, a maksymalne wtopienie się w normalne działania na platformie. 

“Nie karmić ShinyHunters” 

Szczególnie istotnym elementem obu tych historii jest fakt niezapłacenia okupu przez Odido i Telus Digital. To podejście, do którego zachęcają specjaliści w przypadku ShinyHunters i innych grup wywodzących się z The Com (społecznością internetową, która współpracuje i wymienia się wiedzą w zakresie cyberprzestępczości). Szczegółowa analiza metod i wiarygodności atakujących wykazuje, że zapłata okupu lub negocjacje nie gwarantują ani wstrzymania się od publikacji skradzionych danych, ani ich usunięcia z zasobów atakujących. Według analityków Unit221b śledzących ich działania, w środowisku The Com panuje chaos, a między samymi przestępcami wyraźnie widoczne są wewnętrzne konflikty i wzajemne sabotowanie się. Sprawia to, że mimo wieloletnich działań i udanych ataków, SLSH nie przeprowadza działań zgodnie z rozbudowaną strategią lub w sposób zorganizowany. Wpływa to także na wiarygodność grupy, co ma szczególne znaczenie w przypadku operacji wymuszających na ofierze zapłatę okupu. W tym przypadku po otrzymaniu okupu grupa w żaden sposób nie udowadnia usunięcia danych, a szkody reputacyjne są już zwykle wyrządzone poprzez bezpośrednią komunikację atakujących z mediami. Według doniesień, SLSH stosują liczne techniki mające na celu wywrzeć presję, zastraszyć, a nawet sterroryzować pracowników zaatakowanej firmy. Zasypywanie wiadomościami e-mail lub SMS, ataki DDoS, groźby i szantaż, to jedynie część działań mających pozwolić atakującym „złamać” ofiarę. Warto pamiętać, że ataki na organizację, firmę czy markę bezpośrednio oddziałują na ich pracowników, którzy zajmują się obsługą incydentu lub komunikacją w związku z nim.  

Odporność techniczna i psychiczna 

Odporność na ataki socjotechniczne i ochrona pracowników przed wpływem incydentu w firmie na ich dobrostan musi być elementem przygotowania i reagowania na takie wydarzenia. Poza poprawą sytuacji samych osób zatrudnionych, zmniejszy to także szansę atakujących na wywarcie wpływu na wewnętrzne procesy decyzyjne poprzez personalne ataki na pracowników za te decyzje odpowiedzialnych. ShinyHunters informują media o ataku również dlatego, by firma w toku rozwiązywania incydentu była też pod presją wydania komunikatów do mediów. Odpowiednia strategia komunikacyjna i równoległe, skoordynowane działania wspierają odporność na sytuacje, gdy incydent cyberbezpieczeństwa wymaga niezwłocznej reakcji także w zakresie przygotowania przekazów do mediów przy równoległej wewnętrznej analizie problemu. O metodach zabezpieczania środowisk SaaS i chmurowych można napisać wiele, ale w tym zakresie możemy szczególnie polecić poradnik przygotowany przez zespół GTIG skupiający się konkretnie na TTP ShinyHunters. 

Więcej informacji: 
https://www.bleepingcomputer.com/news/security/telus-digital-confirms-breach-after-hacker-claims-1-petabyte-data-theft/  
https://www.telusdigital.com/cybersecurity-update 
https://www.odido.nl/veiligheid-eng
https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft  
https://cloud.google.com/blog/topics/threat-intelligence/defense-against-shinyhunters-cybercrime-saas 
https://krebsonsecurity.com/2026/02/please-dont-feed-the-scattered-lapsus-shiny-hunters/