hamburger

(jeśli zgłaszasz przypadek phishingu, zapisz mail (przesuń go z programu pocztowego na pulpit komputera lub wybierz opcję plik/zapisz jako), a następnie załącz)

Podejrzany SMS prześlij na nr 508 700 900

Jeśli zgłoszenie dotyczy bezpieczeństwa dzieci, zgłoś je również pod http://www.dyzurnet.pl
@CERT_OPL

Krajobraz zagrożeń 15-21/09/25

Shai-Hulud - epicka infekcja; lider ransomware - Qilin; ShadowLeak - agent w poczcie; Signal w rękach APT; Podatność w Entra;

W kolejnym wrześniowym Krajobrazie Zagrożeń znaleźliśmy miejsce na mityczne i książkowe stworzenia – Shai-Hulud i Qilin. Choć nazwy mogą wskazywać na fantastyczne stwory, to tak właśnie nazywane są jedne z kluczowych zagrożeń dotykających kolejno użytkowników paczek npm oraz ofiar ransomware. W sekcji traktującej o wydarzeniach pozornie futurystycznych, lecz bardzo aktualnych, przyjrzeliśmy się podatności ChatGPT na sztuczki socjotechniczne. W kategorii CVE Tygodnia tym razem niezwykle niebezpieczna i trudno wykrywalna podatność, ale bez akcji mitygujących do podjęcia przez użytkowników – dlaczego? O tym i innych interesujących wątkach z minionego tygodnia przeczytacie poniżej.

Na skróty:

  1. Temat tygodnia: Shai-Hulud – z Diuny do pakietów npm.
  2. Cybercrime: Ransomware Qilin przodujący na świecie, widoczny w Polsce.
  3. Future: ShadowLeak, czyli agent ChatGPT w poczcie.
  4. Cyberwar: Signal w domu, w pracy i na froncie
  5. Złośliwe oprogramowanie: FileFix i steganografia – czyli co nowego w StealC.
  6. CVE Tygodnia: CVE-2025-55241, czyli jak mogło dojść do skompromitowania giganta.

Temat tygodnia

Shai-Hulud – z Diuny do pakietów npm.

W poprzednim Krajobrazie Zagrożeń, pochylaliśmy się nad atakiem na łańcuch dostaw ekosystemu npm. Przewidywaliśmy w nim, że kolejne incydenty mogą przybrać bardziej wyrafinowaną formę, obejmującą nie tylko manipulację kodem w przeglądarce, lecz także ataki na procesy deweloperskie i systemy ciągłej integracji. Niestety, prognoza ta spełniła się szybciej niż ktokolwiek mógł przypuszczać.

11 września 2025 roku światło dzienne ujrzała nowa kampania, która szybko zyskała miano jednego z najbardziej niebezpiecznych ataków supply chain w historii ekosystemu npm. Otrzymała nazwę „Shai-Hulud”, zaczerpniętą z uniwersum Diuny Franka Herberta, gdzie określenie to odnosi się do legendarnych pustynnych czerwi zamieszkujących Arrakis. Symbolika nie jest tu przypadkowa – podobnie jak olbrzymie istoty kryjące się pod piaskami, atak rozrastał się lawinowo, infekując kolejne pakiety i środowiska z siłą, której trudno było się przeciwstawić.

Początkiem incydentu było przejęcie popularnej paczki @ctrl/tinycolor. Do jej archiwum wstrzyknięto skrypt bundle.js, którego zadaniem było uruchomienie narzędzia TruffleHog. Ten otwartoźródłowy komponent skanował system w poszukiwaniu wrażliwych poświadczeń – tokenów npm i GitHub, kluczy chmurowych czy innych sekretów wykorzystywanych w środowiskach developerskich i CI/CD. Poświadczenia były następnie weryfikowane i eksfiltrowane do zewnętrznego serwera, a w niektórych przypadkach narzędzie automatycznie generowało workflowy GitHub Actions, które służyły do dalszej kradzieży danych. Dalsza analiza wykazała, że malware nie ograniczało się wyłącznie do kradzieży sekretów. Po uruchomieniu, skrypt modyfikował pliki package.json, wstrzykiwał do nich odwołanie do własnego kodu i ponownie pakował tarball, by przesłać go na npm. W ten sposób infekował kolejne biblioteki w sposób niemal niewidoczny dla ich właścicieli. Co więcej, kod sprawdzał ważność przechwyconych tokenów za pomocą zapytań do API npm, a następnie wykorzystywał je do publikowania złośliwych wersji pod kontami prawowitych maintainerów. Malware potrafiło także pobierać metadane z instancji chmurowych, aby pozyskać tymczasowe poświadczenia systemowe, co umożliwiało atakującym dostęp do infrastruktury poza samym ekosystemem npm.

Rys. Pierwsza wersja zmodyfikowanego skryptu package.json, prezentująca funkcjonalność robaka; źródło: socket.dev
Rys. Pierwsza wersja zmodyfikowanego skryptu package.json, prezentująca funkcjonalność robaka; źródło: socket.dev

Kluczowym elementem było tworzenie plików .github/workflows/shai-hulud.yml, które uruchamiały się automatycznie w procesach CI/CD, utrwalając infekcję i pozwalając jej działać nawet wtedy, gdy sam pakiet został już usunięty. Na tym jednak działanie Shai-Hulud się nie kończyło. Skrypt potrafił samodzielnie modyfikować kolejne paczki, dodając do nich ten sam złośliwy komponent i publikując je jako nowe wersje. Mechanizm ten sprawiał, że infekcja przypominała klasyczne robaki sieciowe, które przez lata były rzadko obserwowane in-the-wild. Ostatnia dekada przyniosła głównie ataki oparte na statycznym malware, wymagające ręcznej dystrybucji lub socjotechniki. Shai-Hulud stanowił odwrót od tego trendu, pokazując, że robaki potrafią znaleźć dla siebie nową niszę – tym razem w globalnym łańcuchu dostaw open source. Szczególnie niepokojące były szybkie iteracje samego malware. Badacze opisali co najmniej siedem wersji, z których każda wprowadzała zmiany mające na celu zwiększenie skuteczności infekcji, redukcję widocznych logów i lepsze dopasowanie do środowisk CI/CD. Oznacza to, że kod był stale modyfikowany, prawdopodobnie w odpowiedzi na działania badaczy bezpieczeństwa i systemy detekcji.

Rys. Lista repozytoriów Github zainfekowanych robakiem; źródło: socket.dev
Rys. Lista repozytoriów Github zainfekowanych robakiem; źródło: socket.dev

Skala infekcji była bezprecedensowa. Początkowo zainfekowano kilkadziesiąt paczek, lecz w kolejnych dniach liczba ta przekroczyła pięćset. Wśród nich znalazły się również paczki publikowane pod oficjalnym kontem CrowdStrike’a, co dowodzi, że malware skutecznie przejmowało poświadczenia renomowanych dostawców. Efektem była lawina publikacji nowych wersji, które z pozoru wyglądały wiarygodnie, lecz zawierały wstrzyknięty kod robaka.

Konsekwencje tego ataku wykraczały poza dotychczasowe scenariusze. Instalacja zainfekowanej paczki mogła prowadzić nie tylko do utraty wrażliwych danych, ale również do trwałego zainfekowania repozytorium, w którym tworzono złośliwe workflowy CI/CD. Co więcej, te workflowy mogły działać nadal nawet po usunięciu podatnych bibliotek, co czyniło infekcję wyjątkowo trudną do pełnego usunięcia.

Shai-Hulud stał się punktem zwrotnym w historii bezpieczeństwa open source. Pokazał, że ataki łańcucha dostaw mogą nabierać cech autonomicznych, samopropagujących się zagrożeń, których rozwój nie wymaga ciągłego nadzoru człowieka. To sprawia, że tradycyjne podejście do zarządzania zależnościami przestaje być wystarczające. Organizacje korzystające z npm muszą zakładać, że przyszłe ataki mogą być równie destrukcyjne, a ich neutralizacja będzie wymagała zarówno natychmiastowej reakcji, jak i długofalowych działań, takich jak wdrożenie SBOM, audyt zależności, ograniczenie uprawnień tokenów i systematyczne monitorowanie anomalii w procesach CI/CD.

Więcej informacji:
https://socket.dev/blog/tinycolor-supply-chain-attack-affects-40-packages
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

Wybrane zagrożenia tygodnia

Cybercrime

Ransomware Qilin przodujący na świecie, widoczny w Polsce.

Ransomware Qilin, który jest obserwowany już od 2022 roku, nieustannie zbiera żniwa, a przez analityków jest określany jako jeden z najaktywniejszych. Według Ransomware.live, agregatora informacji dotyczących tego typu złośliwego oprogramowania, właśnie ta rodzina ransomware miała najwięcej ofiar w tym roku. Qilin działa jako RaaS (Ransomware-as-a-Service) w modelu double extortion – okup jest wyłudzany na podstawie obietnicy udostępnienia narzędzia umożliwiającego odszyfrowanie danych dotkniętych atakiem i zobowiązania się do niepublikowania skradzionych plików. Początkowo ten ransomware był wykorzystywany przez klientów powiązanych z chińskim wojskiem i okołorządowymi jednostkami. Później Qilin, którego nazwa pochodzi od chińskiego mitycznego stworzenia, był wykorzystywany przez Scattered Spider i threat actorów związanych z Koreą Północną. Mimo wielu poszlak wskazujących na chińskie korzenie Qilin, wiele wskazuje, że do twórców złośliwego oprogramowania należą rosyjskojęzyczni przestępcy. Analizując szeroki zasięg ataków Qilin, badacze wskazują na kluczowe czynniki wpływające na ich sukces – dojrzały model operacyjny, wsparcie (w tym prawne) dla klientów i rozbudowane rozwiązania zapewniające celowane, skuteczne ataki stworzone tak, by maksymalizować zyski grupy. Cele są wybierane przez afiliantów, nie przez twórców oprogramowania, ale najgłośniejsze ataki z wykorzystaniem Qilin uderzały w sektory edukacji i ochrony zdrowia.

We wrześniu Qilin pojawiło się także w Polsce informując o ataku na firmę ochroniarską Ekotrade, której rzekomo skradziono 900 GB danych. Upublicznione zostały między innymi dane pracowników, pliki zawierające hasła dostępu do kont oraz informacje wewnętrzne firmy. Klientom i partnerom firmy zalecono weryfikację danych udostępnianych w komunikacji z Ekotrade, zablokowanie dostępów i zmianę poświadczeń do kont wykorzystywanych przez tę spółkę oraz analizę logów co najmniej od 1 sierpnia 2025 roku. Według komunikatu Pełnomocnika Rządu do spraw Cyberbezpieczeństwa atak miał miejsce 31 sierpnia. Na DLS (Dedicated Leak Site) Qilin poinformowano także, iż w sierpniu ofiarą tej grupy padła również inna polska firma – MARMA Polskie Folie.

Ataki ransomware są stałym punktem w krajobrazie zagrożeń, a oportunistyczne podejście grup i afiliantów sprawia, że mogą one dotknąć każdego. Atakujący szukają najłatwiejszych celów, stosując phishing, automatyczne skanując w poszukiwaniu podatności oraz wykorzystując poświadczenia pracowników skradzione przez malware typu stealer. Niedostateczna segmentacja sieci, brak wdrożonych skutecznych metod zarządzania podatnościami oraz korzystanie przez pracowników z urządzeń prywatnych do dostępu do sieci firmowej, to jedne z kluczowych czynników odpowiadających za tak duże liczby ofiar ataków. Wśród technik wykorzystywanych konkretnie przez Qilin wskazuje się także na spearphishing, MFA Bombing, wykorzystanie oprogramowania do zdalnego zarządzania i SIM Swapping. Warto pamiętać, że na zaniedbaniach w zakresie cyberbezpieczeństwa może stracić nie tylko firma, ale także jej klienci, kontrahenci i pracownicy, których dane zostaną upublicznione. To istotne przypomnienie o zagrożeniach związanych z incydentami w firmach trzecich i konieczności przygotowania procedur na taką ewentualność.

Więcej informacji:
https://blog.qualys.com/vulnerabilities-threat-research/2025/06/18/qilin-ransomware-explained-threats-risks-defenses
https://cyberdefence24.pl/cyberbezpieczenstwo/duzy-wyciek-danych-z-polskiej-firmy-ochroniarskiej
https://www.gov.pl/web/baza-wiedzy/pelnomocnik-rzadu-do-spraw-cyberbezpieczenstwa-krzysztof-gawkowski-informuje-o-utrzymujacym-sie-duzym-poziomie-ryzyka-wystapienia-incydentow-w-polskiej-cyberprzestrzeni-do-najbardziej-destrukcyjnych-atakow-naleza-ataki-ransomware-prowadzace-do-wyciekow-danych-jednym-z-najnowszych-przypadkow-jest-cyberatak-dokonany-wobec-firmy-ekotrade-sp-z-oo
https://www.ransomware.live/group/qilin

Future

ShadowLeak, czyli agent ChatGPT w poczcie.

Sztuczna Inteligencja – czyli zewsząd atakujące nas AI – potrafi ułatwić życie użytkowników w wielu aspektach. Pozwala w sekundę przeszukać sieć w poszukiwaniu odpowiedzi na nurtujące nas pytania, rozwiązywać złożone problemy matematyczne lub informatyczne, czy zautomatyzować nasze obowiązki i zadania. W czasach boomu na AI, ciężko znaleźć miejsce, gdzie nie byłoby ono wykorzystywane, o tym fakcie wiedzą również threat actorzy, którzy wykorzystają każdą lukę do uzyskania zamierzonego celu, i właśnie taka luka została znaleziona w ChatGPT.

Zero-click, nazwany ShadowLeak, wykorzystuje funkcję Deep Research agenta. Funkcja ta pozwala na dogłębne poszukiwanie informacji na określony temat w sieci, ale także oferuje podpięcie jej pod nasze usługi i udostępnienie jej możliwości operowania na naszych danych.

Atak celowany jest w osoby, które używają funkcji Deep Research do automatyzacji zadań, np. wyszukanie konkretnych danych ze skrzynki pocztowej, dając agentowi wgląd w każdego maila. Przyjmiemy, że wspomnianą skrzynką jest Gmail. Atakujący tworzy specjalnie spreparowanego maila, z ukrytymi promptami np. za pomocą bardzo małej czcionki czy użycia białego tekstu na białym tle. Wspomniane prompty mają na celu pozyskanie konkretnych danych i ich eksfiltrację.

Przyjmujemy, że atakujący wysłał maila z ukrytymi promptami, następnie pracownik firmy, odpowiedzialny za rekrutację, wykorzystuje funkcję Deep Research do przeglądu skrzynki i wyszukania informacji o kandydatach. Podczas swojego działania, ChatGPT natrafia na maila wysłanego przez threat actora, a w nim złośliwe prompty. Zlecają one agentowi wykonanie konkretnego zadania, takie jak znalezienie i przesłanie danych konkretnego kandydata na wskazany adres. ChatGPT jest oszukiwany przez atakującego twierdzeniami, że ma pełną autoryzację, i każe zakodować dane (według instrukcji atakującego są one publicznie dostępne) za pomocą Base64, które dzięki temu będą „bezpieczne”. Następnie dane wysyłane są na wskazany URL maskujący się jako zweryfikowana, bezpieczna strona. Dodatkowym czynnikiem jest presja wywierana wobec ChatGPT w promptach, które mówią o pilności szukanych danych i możliwych poważnych konsekwencjach, jeżeli zadanie się nie powiedzie. Czasem operacja threat actora nie powiedzie się przez politykę bezpieczeństwa OpenAI, która jest niedeterministyczna. Przed niepowodzeniem ma uchronić mechanizm persystencji, w którym agent ma próbować wykonać operację aż do skutku. Ostatecznym wynikiem operacji mają być dane przesłane na wskazany przez atakującego URL, a wszystko to bez interakcji użytkownika, który nawet nie zostanie poinformowany przez agenta o przesłanych danych. W tym przypadku to wobec AI zastosowano znane sztuczki socjotechniczne wykorzystywane częściej wobec ofiar phishingu.

Rys. Przykładowy schemat ataku ShadowLeak; źródło: Radware
Rys. Przykładowy schemat ataku ShadowLeak; źródło: Radware

Więcej informacji:
https://www.radware.com/blog/threat-intelligence/shadowleak/

Cyberwar

Signal w domu, w pracy i na froncie.

Ministerstwo Cyfryzacji, 22 września 2025 roku, opublikowało ostrzeżenie przed nasilającą się kampanią phishingową wymierzoną w użytkowników komunikatora Signal. Wskazano, że oszuści podszywają się pod zespół wsparcia aplikacji, rozsyłając wiadomości informujące o rzekomej blokadzie konta z linkiem do „odblokowania”, a ofiary, które klikną i wykonają sugerowane czynności, ryzykują utratę dostępu do konta i przejęcie poufnej korespondencji. Resort podkreśla, że kampania przybiera na intensywności, wymierzona jest w szczególności w osoby publiczne i może być prowadzona przez dobrze zorganizowane grupy powiązane z państwami wrogimi.

Sam komunikat łączy prostą informację o mechanizmie ataku z praktycznymi zaleceniami dla użytkowników: pierwszym i najważniejszym krokiem jest ograniczone zaufanie do linków zawartych w wiadomościach oraz natychmiastowe zgłaszanie incydentu – w przypadku urządzeń prywatnych kierując zgłoszenie do CSIRT NASK poprzez incydent.cert.pl, a w przypadku urządzeń służbowych informując wewnętrzny zespół cyberbezpieczeństwa organizacji, który następnie przekazuje sprawę do właściwego CSIRT. Komunikat przypomina także o włączeniu dostępnych w aplikacji funkcji bezpieczeństwa, takich jak weryfikacja numeru bezpieczeństwa (safety number), oraz odsyła do załączonych materiałów z dokładniejszymi wskazówkami.

Komunikat zwraca uwagę na konieczność organizacyjnych procedur reagowania: szybkie zgłoszenie incydentu, izolacja zainfekowanego urządzenia, przekazanie sprawy do CSIRT oraz działania naprawcze i informacyjne wobec potencjalnych kontaktów – wszystkie te kroki mają ograniczyć dalsze rozprzestrzenianie się ataku oraz minimalizować szkody wynikające z przejęcia konta; w praktyce oznacza to, że jednostki administracji powinny mieć zdefiniowane ścieżki eskalacji, dostęp do narzędzi monitoringu i EDR oraz procedury przywracania dostępu i weryfikacji tożsamości.

Załączone do komunikatu dokumenty – oficjalny komunikat Pełnomocnika oraz obszerne rekomendacje przygotowane przez DK WOC dotyczące weryfikacji obecnie podłączonych urządzeń do konta Signal – dostarczają technicznych instrukcji i list kontrolnych, które warto wdrożyć: jak sprawdzić listę połączonych urządzeń, jak usuwać nieznane sesje, jak skonfigurować dodatkowe zabezpieczenia aplikacji oraz jakie kroki podjąć przy podejrzeniu kompromitacji (np. wymuszenie wylogowania wszystkich sesji, zmiana ustawień weryfikacji numerów/kluczy oraz kontakt z obsługą CSIRT). Resort udostępnia te materiały i zachęca do ich rozpowszechnienia w instytucjach.

Jak się okazało, Signal jako medium dobrze celowanego ataku był wykorzystywany nie tylko w Polsce. Otóż, rosyjska grupa APT28 prowadziła ukierunkowaną kampanię szpiegowską, której elementy techniczne i operacyjne zostały zebrane i przeanalizowane przez zespół Sekoia.io na podstawie próbek powiązanych z CERT-UA; raport pokazuje, że badane artefakty nie były wcześniej publicznie udokumentowane i stanowią wariant infekcji o wielowarstwowej konstrukcji typowej dla grupy przypisywanej GRU.

Wektor wejścia opiera się na sprecyzowanym spearphishingu dostarczanym przez prywatne kanały w komunikatorze Signal, gdzie spreparowane dokumenty Word zawierają makra VBA przygotowane tak, by wykryć wersję Windows/Office, zdeobfuskować osadzone dane i zainstalować implant kodu przez zarejestrowanie złośliwego DLL jako COM server — technika ta umożliwia wykonywanie kodu w kontekście procesów systemowych, takich jak explorer.exe.

Drugi etap infekcji polega na wykorzystaniu tzw. proxy DLL, które podszywa się pod prawdziwy serwer COM: złośliwa biblioteka podczas ładowania wywołuje oryginalny plik przez LoadLibrary i GetProcAddress, a równolegle uruchamia własne funkcje. Dzięki temu infekcja jest trudna do wykrycia, bo aplikacja działa poprawnie, a złośliwy kod jest wstrzykiwany przy każdym uruchomieniu procesu systemowego (np. podczas logowania użytkownika do systemu).
Kolejną warstwą ukrycia jest użycie pliku graficznego (windows.png i analogiczne) jako schowka dla zaszyfrowanego shellcode’u: złośliwy DLL odczytuje dane ukryte w obrazach (steganografia), odszyfrowuje je i ładuje .NET-owy kod (GruntHTTPStager z frameworku Covenant). Ten mechanizm łańcucha „makro – DLL proxy – steganografia – .NET stager” ilustruje świadome mieszanie technik zarządzanego i natywnego kodu w celu ominięcia wykrywania.

Operatorzy APT28 wykorzystali usługi chmurowe jako kanały command and control: Covenant nawiązuje API-driven łączność z Koofr, podczas gdy BeardShell (C++/PowerShell) używa Icedrive do odpytywania folderów zawierających zaszyfrowane polecenia i zwrotne wyniki. Maskowanie C2 jako ruch do legalnych usług chmurowych komplikuje analizę sieciową i powoduje, że komunikacja wygląda jak normalna aktywność użytkownika, co jest wyraźnym trendem w nowoczesnych operacjach cyberwywiadowczych.

Rys. Łańcuch ataku w operacji Phantom Net Voxel; źródło: https://blog.sekoia.io/apt28-operation-phantom-net-voxel/
Rys. Łańcuch ataku w operacji Phantom Net Voxel; źródło: https://blog.sekoia.io/apt28-operation-phantom-net-voxel/

Na maszynach ofiar zaobserwowano także moduły szpiegowskie typu SlimAgent, odpowiedzialne za logowanie wpisywanych komend, zrzuty ekranu i zbieranie zawartości schowka; choć bez jednoznacznego dowodu łańcuchowego powiązania z BeardShell, współwystępowanie tych komponentów na tych samych hostach wskazuje na kompleksowe zbieranie wywiadu technicznego i operacyjnego. Dane są agregowane, szyfrowane i eksfiltrowane, co potwierdza intencje pozyskania materiałów operacyjnych i personalnych.

Dokumenty, które miał zachęcić do uruchomienia (tzw. „wabik”) wskazywały, że cele kampanii obejmowały administrację wojskową Ukrainy — formularze personelu, dokumenty medyczne, zapisy logistyczne i dokumentację związaną z wyposażeniem i operacjami polowymi — co wpisuje tę operację w klasyczne cele wywiadu operacyjnego: mapowanie zasobów, identyfikacja jednostek i zbieranie informacji o stratach i zasobach. W kontekście cyberwojny „Phantom Net Voxel” demonstruje, jak precyzyjny targeting, socjotechnika i techniczne ukrycie (steganografia, proxy DLL, chmurowe C2) współdziałają, by uzyskać długotrwały, trudny do wykrycia dostęp do źródeł informacji o znaczeniu taktycznym i strategicznym.

W kontekście opisanej operacji zauważamy, że użycie prywatnych, szyfrowanych komunikatorów takich jak Signal znacząco komplikuje wykrywanie i kontrolę takich kampanii. Dla analityków zagrożeń najistotniejszy problem polega na tym, że szyfrowanie end-to-end uniemożliwia pośrednią inspekcję treści wiadomości na poziomie sieci — nie ma dostępu do payloadów, makr czy linków przesyłanych w prywatnych czatach bez przejęcia samego urządzenia. To oznacza, że spearphishing prowadzony „poza” firmowym systemem komunikacji może być skutecznie dostarczony i aktywowany bez żadnych śladów widocznych dla standardowych mechanizmów DLP/NGFW/SMTP-proxy.

Dodatkowo, funkcjonalności Signal, tj. krótkotrwałe wiadomości, znikające wiadomości, brak centralnego archiwum i silna ochrona metadanych na poziomie aplikacji, ograniczają artefakty dostępne śledczym. Forward secrecy i rotacja kluczy sprawiają, że nawet jeśli przechwycone zostaną pojedyncze komunikaty, odzyskanie wcześniejszych treści z przechwyconych kluczy jest praktycznie niemożliwe. W praktyce oznacza to, że po kompromitacji środowiska ofiary analitycy dysponują jedynie tym, co pozostawił lokalny system: pliki tymczasowe, kopie zapasowe wykonywane przez użytkownika, zrzuty pamięci, zrzuty ekranu lub inne artefakty endpointowe – nic z samej treści korespondencji przesłanej przez Signal, jeśli nie była ona przechowywana na dysku w jawnej postaci.
Wykorzystanie Signala przez operatorów APT – tak jak w opisywanej operacji – nie jest technicznym novum, ale esencją współczesnej asymetrii: atakujący mogą używać prywatnych, szyfrowanych kanałów jako bezpiecznych kanałów komunikacyjnych do dostarczania i koordynowania ataku, podczas gdy obrońcy muszą rekompensować brak widoczności przez wzmocnienie kontroli urządzeń końcowych, polityk organizacyjnych i procesów reagowania, bez naruszenia prywatności i z uwzględnieniem ograniczeń prawnych.

Więcej informacji:
https://www.gov.pl/web/baza-wiedzy/ataki-phishingowe-na-uzytkownikow-signal—jak-chronic-swoje-konto
https://blog.sekoia.io/apt28-operation-phantom-net-voxel/

Złośliwe oprogramowanie

FileFix i steganografia – czyli co nowego w StealC.

Niedawno badacze z Acronis Threat Research Unit zaobserwowali pierwszy przypadek ataku FileFix w warunkach rzeczywistych, dużo bardziej rozwinięty niż wcześniejszy proof-of-concept (POC). FileFix to wariant ataków „*Fix” (które obejmują ClickFix, PromptFix i inne), opartych na socjotechnice, polegającej na nakłanianiu użytkownika do skopiowania i wklejenia polecenia systemowego, ale niekoniecznie uruchomienia go w terminalu, w przeglądarce lub w oknie uploadu pliku – co prowadzi do wykonywania złośliwego kodu. W przypadku FileFix zamiast okna Run czy Terminala celem ataku staje się polecenie w pasku adresu okna dialogowego z lokalizacją pliku, co bywa mniej podejrzane dla użytkownika i może być trudniej zablokować niż typowe metody.

Odkryta kampania wykazywała znaczące zaawansowanie techniczne i wiele mechanizmów zaciemniania kodu (obfuscation) oraz unikania analizy. Strona phishingowa stylizowana była na stronę bezpieczeństwa Facebooka i posiadała wersje wielojęzyczne, używała minifikacji kodu JavaScript, losowych nazw funkcji i zmiennych, martwego kodu (dead code) i fragmentacji logicznej. Wersje językowe obejmowały m.in. język polski, niemiecki, rosyjski, japoński i inne, co sugeruje, że kampania została przygotowana starannie, by uniknąć wykrycia, a jednocześnie kierowana globalnie.

Rys. Atak Filefix; źródło: https://www.acronis.com/en/tru/posts/filefix-in-the-wild-new-filefix-campaign-goes-beyond-poc-and-leverages-steganography/
Rys. Atak Filefix; źródło: https://www.acronis.com/en/tru/posts/filefix-in-the-wild-new-filefix-campaign-goes-beyond-poc-and-leverages-steganography/

Jedną z ciekawszych cech technicznych jest użycie steganografii w plikach JPG jako nośników drugiego etapu ataku. W obrazach ukryty jest skrypt PowerShell oraz zaszyfrowane pliki wykonywalne. Pierwszy etap to obfuskowany PowerShell, często zakodowany częściowo Base64, który pobiera obraz („stealthy” JPG), następnie odczytuje z niego bajty, wycina fragment odpowiadający drugiemu skryptowi lub zaszyfrowanym plikom, deszyfruje je (np. RC4), dekompresuje, jeśli potrzeba (gzip), a potem uruchamia jako kod binarny lub DLL. Dodatkowo, URL do obrazka bywa szyfrowany (np. przez XOR) i dekodowany w czasie działania, aby utrudnić analizę statyczną.

Rys. Wykorzystanie steganografii by ukryć kod Powershell w pliku jpeg; źródło: https://www.acronis.com/en/tru/posts/filefix-in-the-wild-new-filefix-campaign-goes-beyond-poc-and-leverages-steganography/
Rys. Wykorzystanie steganografii by ukryć kod Powershell w pliku jpeg; źródło: https://www.acronis.com/en/tru/posts/filefix-in-the-wild-new-filefix-campaign-goes-beyond-poc-and-leverages-steganography/

Końcowy malware to loader napisany w Go, zawierający mechanizmy wykrywania środowiska wirtualnego/sandboxu (np. sprawdzanie nazwy karty graficznej poprzez API EnumDisplayDevicesA; nazwy API są zaszyfrowane i odszyfrowywane w trakcie działania), który po pomyślnym przebiegu tych testów ładuje shellcode i uruchamia StealC.

StealC to znany infostealer, który kradnie dane z popularnych przeglądarek, portfeli kryptowalutowych (m.in. Bitcoin, Ethereum, Ledger Live), komunikatorów (Telegram, Discord), VPN-ów (OpenVPN, ProtonVPN) oraz klucze do usług chmurowych (Azure, AWS).

Infrastruktura ataku jest rozproszona i dynamiczna:

  • Kampania obsługuje wiele wersji językowych, co wskazuje na globalny zasięg.
  • C2 zlokalizowane są w Niemczech i hostowane na publicznych platformach (Bitbucket).
  • Domeny phishingowe imitują strony Facebooka, co zwiększa wiarygodność socjotechnicznego podmiotu.

Z technicznego punktu widzenia użycie steganografii w obrazach, rozdzielenie łańcucha ataku na dwa etapy, fragmentacja i szyfrowanie URL, a także uruchamianie złośliwych plików przez rzadko monitorowane mechanizmy (conhost.exe jako proces macierzysty), wyróżniają ten atak jako wyspecjalizowany i trudny do wykrycia. Wymaga on detekcji anomalii na poziomie aktywności PowerShell, monitorowania operacji pobierania nietypowych plików oraz wykrywania nietypowych relacji procesów w systemie.

Kampania szybko ewoluuje: w ciągu zaledwie dwóch tygodni atak przeszedł przez różne wersje – od prostszego jednego skryptu, przez wieloetapowe podejście (dwustopniowy skrypt), zmiany payloadów (różne pliki EXE, DLL, różna obfuskacja), a także zmiany w socjotechnice (np. zamiast prośby o przesłanie dokumentu tożsamości pojawiały się fałszywe komunikaty o rzekomych naruszeniach bezpieczeństwa i konieczności „rozwiązania incydentu”).
Takie podejście jest nowatorskie i wskazuje na rosnącą złożoność kampanii phishingowych, które idą znacznie dalej niż klasyczne metody, wykorzystując niskopoziomowe mechanizmy systemowe i zaawansowane techniki ukrywania payloadów w plikach binarnych.

W konkluzji autorzy artykułu ostrzegają, że widzimy przemianę FileFix z eksperymentu (PoC) w groźną technikę stosowaną „in-the-wild”, zdolną do szerokiego zastosowania. Takie ataki, łączące socjotechnikę, steganografię, wieloetapowe payloady, obfuskację i mechanizmy obronne, będą widziane coraz częściej i będzie to wyzwanie dla tradycyjnych narzędzi detekcji.

Więcej informacji:
https://www.acronis.com/en/tru/posts/filefix-in-the-wild-new-filefix-campaign-goes-beyond-poc-and-leverages-steganography/
https://mrd0x.com/filefix-clickfix-alternative/

CVE tygodnia

Krytyczna podatność w SAP in-the-wild.

W ubiegłym tygodniu świat cyberbezpieczeństwa obiegła informacja o krytycznej podatności Microsoft Entra ID (dawniej Azure AD), oznaczonej jako CVE-2025-55241, której potencjalne skutki wykorzystania mogłyby być katastrofalne dla globalnego ekosystemu chmurowego Microsoft. Choć luka została odkryta i załatana w lipcu, informacje o niej i jej naprawie zostały szerzej opisane dopiero teraz, co podkreśla wagę i czas reakcji, a także ryzyko, które mogło się zmaterializować, gdyby podatność została wykorzystana w ataku in-the-wild.

Opis podatności i mechanizm działania potwierdzają, że problem wynikał z połączenia dwóch elementów: usługowych tokenów typu „Actor tokens”, wydawanych przez wewnętrzny komponent Microsoftu zwany Access Control Service (ACS), oraz defektu w starym interfejsie Azure AD Graph API (graph.windows.net), który nie weryfikował prawidłowo, z którego tenanta pochodzi żądanie.
W praktyce oznaczało to, że atakujący mógł, dysponując tokenem z własnego środowiska testowego czy innego tenanta (nawet bez uprzedniego dostępu do docelowego tenanta), podszyć się pod dowolnego użytkownika — w tym Global Admina — w dowolnym innym tenancie, pod warunkiem, że znał identyfikator (tenant ID) oraz netID danego użytkownika.

Skutki potencjalnego ataku byłyby bardzo poważne. Atakujący mógł zyskać pełne uprawnienia administracyjne w dowolnym tenancie, tworzyć nowe konta, nadawać role, uzyskiwać dostęp do danych Microsoft 365, Exchange Online, SharePoint, zarządzać urządzeniami, a nawet manipulować ustawieniami subskrypcji Azure. Luka pozwalała ominąć polityki typu Conditional Access, MFA (multi-factor authentication) i mechanizmy logowania oraz audytu, ponieważ wiele operacji (zwłaszcza odczytów danych przez Graph API) nie pozostawiało śladów w logach docelowego tenanta.

Microsoft, po otrzymaniu informacji od badacza Dirka-jana Mollemy 14 lipca 2025, odpowiedział bardzo szybko. Globalna poprawka została wdrożona już 17 lipca, a do końca lipca i w sierpniu zastosowano dodatkowe środki zabezpieczające oraz zmiany w kodzie walidacji. Firma zakomunikowała też, że nie znalazła żadnych dowodów na to, by luka była aktywnie wykorzystywana in-the-wild przed załataniem. Sama luka dostała najwyższą możliwą wycenę CVSS

Więcej informacji:

https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241

Zobacz także

Komunikat dotyczący plików cookies

Ta witryna używa plików cookies (małych plików tekstowych, przechowywanych na Twoim urządzeniu). Są one stosowane dla zapewnienia prawidłowego działania strony oraz do zbierania informacji o Twoich preferencjach i nawykach użytkowania witryny.

Pliki cookies niezbędne do działania strony używamy do zapewnienia podstawowych funkcji, takich jak logowanie oraz zapewnienie bezpieczeństwa witrynie. Ich wykorzystanie nie wymaga Twojej zgody.

Pliki cookies funkcyjne. Pozwalają nam zbierać informacje na temat zalogowanych sesji oraz przechowywać dane wpisane przez Ciebie w formularzach znajdujących się na stronie takich jak: czas trwania zalogowanej sesji , nazwę użytkownika.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

Pozostałe kategorie wykorzystywania plików cookies, które wymagają Twojej zgody na używanie

Pliki cookies statystyczne/analityczne. Pozwalają nam zbierać anonimowe informacje o ruchu na stronie (liczba odwiedzin, źródło ruchu i czas spędzony na witrynie). Te dane pomagają nam zrozumieć, jak nasi użytkownicy korzystają z witryny i poprawiają jej działanie.

Możesz zmienić swoje preferencje dotyczące plików cookies w każdej chwili. W celu zarządzania plikami cookies lub wycofania zgody na ich używanie, prosimy skorzystać z ustawień przeglądarki internetowej.