Archiwa: PowerShell - Strona 23 z 42

Iran-nexus APT „Dust Specter” atakuje urzędników w Iraku nowymi rodzinami malware (SPLITDROP, TWINTASK, TWINTALK, GHOSTFORM)

Wprowadzenie do problemu / definicja luki

Nie mamy tu „jednej CVE”, tylko klasyczny scenariusz APT: ukierunkowany spear-phishing, wiarygodne podszycie się pod instytucję państwową i łańcuch infekcji prowadzący do zdalnego wykonania poleceń (RAT/backdoor). W nowej kampanii badacze Zscaler ThreatLabz przypisują z średnio-wysoką pewnością aktywność klastrowi „Dust Specter” (powiązania z Iranem na bazie TTP, doboru celów i podobieństw w kodzie).

Kluczowy element: atakujący podszywają się pod irackie Ministerstwo Spraw Zagranicznych, a do dystrybucji payloadów wykorzystują również skompromitowaną infrastrukturę powiązaną z irackim rządem.

W skrócie

Kampania była obserwowana w styczniu 2026 i celowała w urzędników państwowych w Iraku.
Zidentyfikowano dwa łańcuchy infekcji z nowymi, wcześniej nieopisywanymi rodzinami: SPLITDROP, TWINTASK, TWINTALK, GHOSTFORM (wszystko w .NET).
C2 obejmuje m.in. losowe ścieżki URI z checksumami, geofencing i weryfikację User-Agent, co utrudnia analizę i ogranicza „szum” od badaczy/sandboxów.
W kodzie znaleziono ślady sugerujące wsparcie generatywnej AI przy tworzeniu malware (np. „placeholdery”, nietypowe wstawki/znaki).

Kontekst / historia / powiązania

Zscaler opisuje „Dust Specter” jako klaster działający w paradygmacie znanym z operacji iran-nexus: lekkie, customowe backdoory w .NET, dopasowane do kampanii, plus mocne socjotechniczne przynęty i infrastruktura dobrana pod region/cele.

Dodatkowo w tle pojawia się trend „ClickFix-style” (nakłanianie ofiary do uruchomienia poleceń/PowerShell pod pretekstem dołączenia do spotkania/naprawy problemu). The Hacker News wskazuje, że powiązana domena/infrastruktura była wykorzystywana także wcześniej do przynęt udających np. zaproszenia do spotkań i instruujących uruchomienie skryptu PowerShell.

Analiza techniczna / szczegóły „luki” (łańcucha ataku)

Attack Chain 1: SPLITDROP → TWINTASK + TWINTALK (architektura „split”)

Wejście: zaszyfrowane/hasłowane archiwum RAR (przynęta podszyta pod MSZ), w którym znajduje się 32-bitowy dropper .NET „SPLITDROP” podszyty pod WinRAR.

SPLITDROP rozpakowuje/deployuje elementy do katalogu w ProgramData i uruchamia legalny komponent, by przejść do kolejnego etapu (typowy „living off the land” + zaufany binarny ładunek). W opisie kampanii pojawiają się artefakty ścieżek typu:

C:\ProgramData\PolGuid\... (m.in. pliki poleceń i wyników)

TWINTASK (worker) działa jako DLL i jest ładowany metodą DLL sideloading przez legalny proces (w opisie: „vlc.exe” sideloaduje „libvlc.dll”). Moduł cyklicznie odczytuje plik z poleceniami (co 15 sekund) i wykonuje je przez PowerShell, zapisując wyniki do osobnego pliku.

TWINTALK (orchestrator) koordynuje pracę z TWINTASK oraz komunikuje się z C2 (pobieranie poleceń, przesył wyników, transfer plików).

Attack Chain 2: GHOSTFORM (skonsolidowany RAT)

W drugim łańcuchu „GHOSTFORM” scala funkcje wcześniejszych modułów w jeden binarny RAT .NET i wyróżnia się m.in. in-memory PowerShell execution (mniej artefaktów na dysku) oraz technikami opóźniania/ukrywania wykonania (np. niewidoczne okna formularzy + timery).

Ciekawostka operacyjna: część próbek GHOSTFORM miała uruchamiać w przeglądarce link do Google Forms wyglądający jak oficjalna ankieta MSZ (treść po arabsku), co może służyć uwiarygodnieniu scenariusza socjotechnicznego lub jako element „distraction/decoy”.

C2 i utrudnianie analizy

Zscaler podkreśla kilka mechanizmów „kontroli dostępu” po stronie serwera C2:

losowe ścieżki URI z dołączonym checksumem (żądania mają wyglądać jak pochodzące z realnej infekcji),
geofencing (ograniczenie obsługi do wybranych lokalizacji),
weryfikacja User-Agent.

Praktyczne konsekwencje / ryzyko

Dla organizacji rządowych i podmiotów współpracujących (dostawcy, NGO, firmy consultingowe obsługujące administrację) ryzyka są bardzo konkretne:

Zdalne wykonanie poleceń i kradzież danych: PowerShell jako „uniwersalny interpreter” ułatwia szybkie dostosowanie działań (rekonesans, eksfiltracja, pobranie kolejnych narzędzi).
Trudniejsza detekcja: DLL sideloading i użycie legalnych binarek zmniejsza „podejrzaność” na poziomie EDR, jeśli organizacja nie ma twardych polityk allow-listing.
Selektywność kampanii: geofencing i walidacje w C2 sugerują, że atak nie jest masowy – celem są konkretne osoby/role, a infrastruktura jest ograniczana, by nie „wypalić” narzędzi.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu”, możliwie praktyczna dla SOC/Blue Teamu:

Email i wejście (pre-infection)

Wzmocnij ochronę przed spear-phishingiem: izolacja załączników (sandbox), blokady na archiwa hasłowane (RAR/ZIP) lub przynajmniej wymuszenie dodatkowej inspekcji dla „password-protected attachments”.
Polityki dla plików zewnętrznych: Mark-of-the-Web, blokada uruchamiania binarek z katalogów użytkownika i z nietypowych lokalizacji.

Endpoint/EDR

Włącz/zaostrz reguły dla PowerShell: Script Block Logging, AMSI, blokady dla podejrzanych parent-child (np. media player → PowerShell).
Monitoruj i alertuj na schemat: vlc.exe (lub inne legalne binarki) ładujące DLL z własnego katalogu + tworzenie/odczyt plików w C:\ProgramData\... (np. „in.txt/out.txt”).
Rozważ AppLocker/WDAC (allow-listing) w krytycznych segmentach – to realnie ogranicza DLL sideloading.

Sieć

Poluj na wskaźniki TTP: nietypowe beaconing do świeżych domen, żądania z nietypowymi ścieżkami URI (losowe + checksum), anomalie User-Agent (lub jego „sztywna” wartość).
Segmentacja i egress control: ogranicz ruch z hostów użytkowników do Internetu (zwłaszcza niepotrzebne porty/usługi) i wymuszaj proxy z inspekcją.

Threat hunting

Przeszukaj flotę pod kątem artefaktów z opisu kampanii (katalogi w ProgramData, pliki poleceń/wyników, podejrzane DLL obok legalnych exe, zadania harmonogramu/Run keys, jeśli wykryte w środowisku).
Skorzystaj z IOC/sekcji „Zscaler Coverage” w raporcie ThreatLabz jako punktu startowego do detekcji i blokad.

Różnice / porównania z innymi przypadkami

Split vs monolit: Chain 1 rozdziela role (worker/orchestrator) i komunikuje się plikami; Chain 2 (GHOSTFORM) ogranicza artefakty na dysku dzięki in-memory PowerShell – to typowa „ewolucja” w stronę mniejszej wykrywalności.
ClickFix jako trend: kampanie, które „uczą” użytkownika uruchomić PowerShell, stają się powtarzalnym motywem – nie tylko w przestępczości, ale i w operacjach ukierunkowanych. W tej sprawie podobieństwo zostało wskazane przez THN/Zscaler.
AI w wytwarzaniu malware: zamiast „magicznie nowego” wektora, mamy sygnały, że generatywna AI przyspiesza development (szablony, placeholdery, nietypowe artefakty), co obniża koszt iteracji po stronie atakującego.

Podsumowanie / kluczowe wnioski

Dust Specter to przykład dojrzałej operacji APT: wiarygodne podszycie się pod instytucję, dwa równoległe łańcuchy infekcji, nacisk na PowerShell oraz mechanizmy C2 ograniczające ekspozycję kampanii. Największa lekcja obronna jest prosta: blokowanie/ograniczanie PowerShell + kontrola uruchomień (allow-listing) + polowanie na DLL sideloading dają tu największy zwrot z inwestycji.

Źródła / bibliografia

Zscaler ThreatLabz – Dust Specter APT Targets Government Officials in Iraq (02.03.2026) (zscaler.com)
Security Affairs – Iran-nexus APT Dust Specter targets Iraq officials with new malware (06.03.2026) (Security Affairs)
The Hacker News – Dust Specter Targets Iraqi Officials with New SPLITDROP and GHOSTFORM Malware (05.03.2026) (The Hacker News)
SC Media / SC World – Iran targets Iraqi government officials with multiple new malware strains (04.03.2026) (SC Media)

Administrator Phobos ransomware przyznaje się do winy w USA: co oznacza „wire fraud conspiracy” dla ekosystemu RaaS

Wprowadzenie do problemu / definicja „luki”

Sprawa Phobos nie dotyczy pojedynczej „luki” w sensie CVE, tylko modelu biznesowego ransomware-as-a-service (RaaS): jedni dostarczają malware, panel, infrastrukturę i obsługę płatności, a inni (tzw. afilianci) wykonują włamania i wdrożenia ransomware. W tym układzie „administrator” jest kluczowym węzłem – zarządza dystrybucją narzędzia, rozliczeniami i często elementami negocjacji.

Na początku marca 2026 r. Evgenii Ptitsyn (43 lata) – wskazywany przez prokuraturę jako osoba administrująca sprzedażą/dystrybucją i operacjami Phobos – przyznał się do winy w USA w sprawie wire fraud conspiracy (spisek w celu oszustwa telekomunikacyjnego/finansowego).

W skrócie

Ptitsyn przyznał się do winy (wire fraud conspiracy); grozi mu do 20 lat więzienia.
Został ekstradowany z Korei Południowej do USA w listopadzie 2024 r.
Według DOJ Phobos (przez afiliantów) miał ponad 1 000 ofiar i >39 mln USD wymuszeń.
Mechanika RaaS w Phobos obejmowała m.in. opłatę za klucz deszyfrujący oraz rozliczenia kryptowalutowe między afiliantami a administracją.
Sprawa wpisuje się w szersze działania międzynarodowe przeciw Phobos (aresztowania afiliantów, działania koordynowane z Europolem).

Kontekst / historia / powiązania

Phobos to długotrwała operacja RaaS wiązana z rodziną Crysis. W praktyce oznacza to „produkt” ransomware oferowany wielu afiliantom, co zwiększa skalę i różnorodność kampanii.

Z perspektywy organów ścigania ważne są trzy momenty:

Co najmniej od listopada 2020 r. – administracja miała sprzedawać i udostępniać Phobos afiliantom oraz koordynować dystrybucję przez serwis w darknecie i reklamy na forach (m.in. aliasy „derxan” i „zimmermanx”).
Listopad 2024 r. – ekstradycja Ptitsyna z Korei Płd. do USA (wcześniej postawiono mu szeroki pakiet zarzutów).
Marzec 2026 r. – przyznanie się do winy i wyznaczony termin ogłoszenia wyroku na 15 lipca (środa) 2026, 14:30 czasu lokalnego sądu (USA).

Równolegle DOJ wcześniej komunikował aresztowania afiliantów i działania typu disruption wymierzone w infrastrukturę powiązaną z tą siatką.

Analiza techniczna / szczegóły działania „modelu Phobos”

Z punktu widzenia obrony najcenniejsze w tej sprawie są elementy opisujące operacyjny przepływ ataku i monetyzacji:

Włamanie przez afilianta
Afilianci mieli uzyskiwać dostęp do sieci ofiar często poprzez skradzione lub nieautoryzowane dane uwierzytelniające, a następnie kraść pliki i uruchamiać szyfrowanie.
Podwójne wymuszenie i presja poza techniką
Po eksfiltracji i szyfrowaniu pojawiały się żądania okupu oraz groźby ujawnienia danych – według opisu DOJ także z użyciem telefonów i e-maili w celu eskalacji negocjacji.
Klucze deszyfrujące jako usługa + opłata per incydent
W modelu opisanym przez prokuraturę po „udanym” ataku afiliant płacił administracji opłatę za klucz deszyfrujący, przypisaną do konkretnego wdrożenia (unikalny identyfikator/ciąg alfanumeryczny).
Rozliczenia kryptowalutowe i koncentracja środków
DOJ wskazuje, że od grudnia 2021 do kwietnia 2024 opłaty za klucze były transferowane z portfeli afiliantów do portfela kontrolowanego przez Ptitsyna. To ważny detal: pokazuje, że nawet przy „zdecentralizowanych” afiliantach często istnieje finansowy punkt centralny.

Praktyczne konsekwencje / ryzyko

Ryzyko „rebrandu”, a nie zniknięcia zagrożenia
Uderzenie w administratora ogranicza zdolność do rozliczeń/kluczy/obsługi, ale ekosystem RaaS bywa odporny – afilianci mogą migrować do innych programów lub powstają klony.
Dalsze wykorzystanie skradzionych dostępów
Skoro w opisach pojawiają się kradzione poświadczenia, to dla organizacji realnym długiem technicznym pozostają: nieszczelne IAM, brak MFA, słabe hasła, odziedziczone konta serwisowe i niekontrolowane zdalne dostępy.
Presja reputacyjna i regulacyjna przez wycieki
Groźby ujawnienia danych klientom/kontrahentom (a nie tylko publikacja w leak site) zwiększają koszty incydentu i skracają czas na decyzje kryzysowe.

Rekomendacje operacyjne / co zrobić teraz

Jeśli chcesz „zabezpieczyć się pod Phobos/RaaS”, sensownie jest myśleć o 3 warstwach: dostęp → ruch boczny → odporność na wymuszenie.

Dostęp (najczęstszy punkt wejścia)

Wymuś MFA wszędzie, szczególnie dla VPN/RDP, paneli administracyjnych, poczty i SSO.
Zrób przegląd kont uprzywilejowanych: usuń „osierocone” konta, ogranicz konta serwisowe, wprowadź JIT/JEA tam gdzie możliwe.
Wykrywaj logowania niemożliwe geograficznie, „password spraying”, nietypowe sukcesy logowania po wielu błędach.

Ruch boczny i eskalacja

Segmentuj sieć (co najmniej: stacje robocze ↔ serwery ↔ backup/AD).
Włącz telemetrię EDR i monitoruj narzędzia nadużywane w intruzjach (np. zdalne wykonanie, dump poświadczeń, nietypowe użycia PsExec/WMI/PowerShell).

Odporność na wymuszenie

Kopie zapasowe: zasada 3-2-1-1-0 (w tym jedna kopia offline/niemodyfikowalna) + regularne testy odtwarzania.
Playbook na „double extortion”: gotowe szablony komunikacji, procedury prawne/RODO, decyzje o odcięciu usług, kanały kontaktu poza domeną.

Higiena kryzysowa

Przygotuj listę działań „pierwsza godzina”: izolacja, zachowanie dowodów, snapshoty, blokady kont, rotacja kluczy/sekretów.
Ustal wcześniej: kto podejmuje decyzje dot. negocjacji, kto kontaktuje CERT/ubezpieczyciela, kto obsługuje komunikację.

Różnice / porównania z innymi przypadkami

W wielu grupach ransomware monetyzacja opiera się na udziale w okupie (procent od płatności). W opisie Phobos mocno wybrzmiewa także element „płatności za klucz per wdrożenie”, co zbliża model do „licencjonowania” ataku – i tworzy charakterystyczne ślady w blockchain (powtarzalne przepływy z portfeli afiliantów do portfela administracji).

To istotne dla obrony i ścigania: łatwiej wskazać punkty centralizacji (portfele, panele, serwisy dystrybucji), nawet gdy same włamania wykonuje rozproszona sieć afiliantów.

Podsumowanie / kluczowe wnioski

Przyznanie się do winy przez osobę opisywaną jako administrator Phobos to ważny sygnał: organy ścigania coraz skuteczniej łączą operacje techniczne z dowodami finansowymi i kooperacją międzynarodową.
Dla firm najważniejsza lekcja jest praktyczna: RaaS żyje z kradzionych dostępów, słabego IAM i braku odporności na „double extortion”.
Nawet jeśli Phobos osłabnie, afilianci mogą migrować – więc inwestycje w MFA, segmentację, kopie niemodyfikowalne i gotowy playbook IR pozostają najlepszym „ubezpieczeniem technicznym”.

Źródła / bibliografia

BleepingComputer – opis sprawy, kontekst RaaS, szczegóły afiliantów i opłat za klucze. (BleepingComputer)
U.S. DOJ, U.S. Attorney’s Office (District of Maryland) – komunikat o guilty plea, skala ofiar/kwot i termin wyroku. (Department of Justice)
U.S. DOJ (Office of Public Affairs, archiwum) – szczegóły ekstradycji i ramy zarzutów/okres transferów krypto. (Department of Justice)
U.S. DOJ (Office of Public Affairs) – wcześniejsze działania przeciw afiliantom i międzynarodowy disruption infrastruktury. (Department of Justice)

APT28 i nowy duet malware: BadPaw + MeowMeow w kampanii przeciw Ukrainie

Wprowadzenie do problemu / definicja luki

Na początku marca 2026 r. badacze opisali ukierunkowaną kampanię phishingową wymierzoną w ukraińskie podmioty, w której pojawiają się dwie wcześniej nieudokumentowane rodziny złośliwego oprogramowania: BadPaw (loader w .NET) oraz MeowMeow (backdoor). Rdzeniem problemu nie jest pojedyncza „luka” CVE, lecz złożony łańcuch infekcji oparty o socjotechnikę, wieloetapowe uruchamianie komponentów oraz mechanizmy utrudniające analizę i detekcję.

W skrócie

Wejście: phishing z wiarygodnie wyglądającego nadawcy w domenie ukr[.]net, plus przynęta związana z „apelacją / sprawą graniczną”.
Telemetria kliknięcia: ofiara jest kierowana najpierw na tracking pixel (miniaturowy obraz), co daje operatorom sygnał, że link został otwarty.
Dropper: archiwum ZIP zawiera plik udający HTML, który w praktyce jest HTA uruchamiającym kolejne etapy.
Steganografia: VBScript wyciąga z obrazu PNG ukryty plik wykonywalny (PE) – tak powstaje loader BadPaw.
Backdoor: BadPaw pobiera i instaluje MeowMeow, zdolny m.in. do uruchamiania poleceń PowerShell i operacji na plikach.
Atrybucja: ClearSky ocenia kampanię jako rosyjsko-ukierunkowaną (wysoka pewność) oraz wiąże ją z APT28 tylko z niską pewnością; THN opisuje powiązanie z APT28 jako umiarkowane.

Kontekst / historia / powiązania

APT28 (znany też m.in. jako Fancy Bear / STRONTIUM / Forest Blizzard) to wieloletnio aktywny klaster działań przypisywany rosyjskim strukturom wojskowego wywiadu; w ATT&CK widnieje jako grupa G0007, aktywna co najmniej od 2004 r.
Microsoft w publicznych materiałach opisuje Forest Blizzard (d. STRONTIUM) jako aktora państwowego wykorzystującego m.in. spearphishing i techniki kradzieży poświadczeń, atakującego sektor rządowy, dyplomatyczny i obronny, w tym Ukrainę.

W omawianej kampanii istotny jest też „lokalny realizm” przynęty: narracja w języku ukraińskim i tematyka przekraczania granicy / urzędowej korespondencji. To typowa oś dla operacji szpiegowskich, gdzie liczy się nie masowość, a trafienie w konkretnych adresatów.

Analiza techniczna / szczegóły luki

Poniżej – łańcuch infekcji od kliknięcia do backdoora, w ujęciu „co robi napastnik” i „co widać w telemetryce”.

1. Inicjacja: phishing + telemetria kliknięcia

Wiadomość pochodzi z adresu w ukr[.]net (według raportu: konkretna skrzynka nadawcy związana z narracją „graniczną”).
Kliknięcie uruchamia dwa równoległe przekierowania:
1. na domenę hostującą tracking pixel (sygnał „link kliknięty”),
2. na skrócony URL, który inicjuje pobranie ZIP.

Warto detekcyjnie: nietypowa sekwencja przekierowań + pobranie archiwum po „mikro-obrazie” często wskazuje na kampanie z telemetrią skuteczności.

2. ZIP → HTA (podszycie pod HTML)

W archiwum znajduje się plik z rozszerzeniem .html, który w rzeczywistości jest HTA (HTML Application). Uruchomienie HTA:

otwiera dokument-wabik (odwrócenie uwagi),
w tle odpala kolejne etapy infekcji.

3. Anti-sandbox na starcie: „wiek systemu”

HTA sprawdza klucz rejestru HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate i przerywa działanie, jeśli system jest „zbyt świeży” (mniej niż 10 dni). To klasyczny trik na unikanie automatycznych sandboxów i świeżych maszyn analityków.

4. Persistencja i steganografia: VBS + PNG

Kolejny etap to:

wydobycie z ZIP VBScript i obrazu PNG,
utworzenie Scheduled Task uruchamiającego VBS (persistencja),
VBS parsuje PNG, szuka markera typu <STEGO_START> i wyciąga ukryty PE (zapisuje go jako osobny plik).

To ważne, bo w wielu środowiskach obrazki nie są traktowane jako nośnik „aktywny”, a tu PNG pełni rolę kontenera dla wykonywalnego loadera.

5. BadPaw: loader w .NET z „dummy mode”

BadPaw to komponent w .NET, dodatkowo pakowany/obfuskowany przez .NET Reactor, co utrudnia analizę statyczną.
Cechy wyróżniające:

jeśli uruchomiony poza właściwym łańcuchem, wykonuje „fałszywą” logikę i pokazuje pozornie legalne GUI (w raporcie: narzędzie typu „Regex Finder”).
właściwa złośliwa logika uruchamia się dopiero po podaniu parametru uruchomieniowego (np. -renew).

6. Komunikacja C2 i etapowe pobieranie payloadu

W raporcie wskazano infrastrukturę C2 oraz etapowe odpowiedzi serwera:

po stronie sieci widać żądania do domeny C2 i endpointów typu /getcalendar, /eventmanager, /planneractivate,
w jednym z etapów serwer zwraca stronę HTML zawierającą blok ASCII osadzony między znacznikami, który następnie jest dekodowany do kolejnego komponentu,
po tym malware upuszcza m.in. pliki konfiguracyjne oraz finalny backdoor MeowMeow.

7. MeowMeow: backdoor z wielowarstwową ochroną

MeowMeow również wykorzystuje:

obfuskację (.NET Reactor),
„dummy mode” (fałszywe GUI z motywem kota; kliknięcie przycisku wyświetla komunikat, bez działań szkodliwych),
uruchomienie złośliwej funkcjonalności dopiero przy właściwym parametrze (np. -v przekazywanym przez łańcuch infekcji),
rozbudowane anti-analysis: wykrywanie narzędzi typu Wireshark/Procmon/Ollydbg/Fiddler i mechanizmów wirtualizacji, z przerwaniem pracy po detekcji.

Funkcjonalnie MeowMeow pozwala na:

zdalne wykonywanie poleceń (wprost wskazywany PowerShell),
operacje na plikach: sprawdzanie istnienia, odczyt/zapis/usuwanie.

Praktyczne konsekwencje / ryzyko

Szpiegostwo i dostęp długoterminowy: MeowMeow to backdoor, więc ryzyko obejmuje rekonesans, eksfiltrację i przygotowanie kolejnych etapów (np. kradzież dokumentów, utrzymanie przyczółka).
Trudniejsza analiza incydentu: „dummy mode” + parametry uruchomieniowe mogą powodować, że próbki uruchamiane w izolacji wydają się „nieszkodliwe”, co opóźnia klasyfikację i reakcję.
Wysoka skuteczność spearphishingu: lokalny kontekst (ukraińska treść, tematyka graniczna, nadawca w ukr[.]net) zwiększa wiarygodność i szanse kliknięcia.

Rekomendacje operacyjne / co zrobić teraz

1. Szybkie działania defensywne (48–72h)

Blokuj/ogranicz HTA i VBScript: jeśli biznesowo możliwe, wyłącz obsługę lub uruchamianie mshta.exe, ogranicz wscript.exe/cscript.exe (ASR / AppLocker / WDAC). Łańcuch bazuje na HTA→VBS.
Poluj na Scheduled Tasks tworzone nietypowo (nowe zadania uruchamiające VBS z katalogów użytkownika/tymczasowych) – to kluczowy punkt persistencji.
Detekcje EDR: alerty na procesy mshta.exe → wscript.exe + dostęp do plików PNG, a następnie uruchomienie nowego .exe z nietypowej ścieżki.
Zasady proxy/DNS: dodaj blokady i alerty na domeny i ścieżki opisane w raporcie (C2 i tracking), oraz na nietypowe sekwencje przekierowań (pixel → pobranie ZIP).

2. Hardening i odporność na kampanie podobnego typu

Zaostrzenie polityk pocztowych: filtrowanie linków do archiwów, sandboxing załączników/URL, ostrzeganie o skracaczach linków. (Tu skrócony URL był elementem łańcucha.)
Least privilege + segmentacja: backdoor z PowerShell to paliwo do ruchu bocznego i działań post-exploitation — ogranicz uprawnienia lokalne i lateral movement.
Ćwiczenia socjotechniczne: scenariusze „urząd / dokument graniczny / potwierdzenie” dopasowane do realiów odbiorców są dziś ważniejsze niż ogólne szkolenia.

Różnice / porównania z innymi przypadkami

Na tle „typowych” loaderów .NET, ta kampania wyróżnia się trzema elementami praktycznie podnoszącymi koszt obrony:

Steganografia w PNG jako kanał przeniesienia PE (utrudnia polityki oparte o typy plików).
Podwójna przynęta: wabik dokumentu + „dummy GUI” w przypadku uruchomienia poza łańcuchem (utrudnia triage i reverse engineering).
Parametry uruchomieniowe jako „klucz” do aktywacji złośliwych funkcji — bez nich próbka może wyglądać na nieszkodliwą.

Podsumowanie / kluczowe wnioski

BadPaw i MeowMeow pokazują, że spearphishing nadal jest skuteczny, gdy jest konsekwentnie lokalizowany, a technicznie wzmacniany przez wieloetapowość, steganografię i anti-analysis. Raport ClearSky sugeruje silne powiązania z rosyjskim ekosystemem operacji przeciw Ukrainie, przy ostrożności w przypisywaniu tego konkretnie do APT28.
Dla obrony kluczowe są: kontrola HTA/VBS, monitoring Scheduled Tasks, oraz detekcje na łańcuch procesów i nietypowe pobrania/redirecty.

Źródła / bibliografia

ClearSky, BadPaw and MeowMeow (raport PDF, marzec 2026). (clearskysec.com)
The Hacker News, APT28-Linked Campaign Deploys BadPaw Loader and MeowMeow Backdoor in Ukraine (05.03.2026). (The Hacker News)
The Record (Recorded Future News), Russian hackers deploy new malware in phishing campaign targeting Ukraine (04.03.2026). (The Record from Recorded Future)
MITRE ATT&CK, APT28 (G0007). (attack.mitre.org)
Microsoft Security Insider, Threat Actor: Forest Blizzard (formerly STRONTIUM). (Microsoft)

Microsoft: ataki wykorzystujące „OAuth error flows” do przekierowań i dystrybucji malware — jak działa nadużycie i jak je ograniczyć

Wprowadzenie do problemu / definicja luki

Microsoft opisał trwające kampanie phishingowe, w których napastnicy nie „łamą” OAuth, tylko nadużywają poprawnego (standardowego) zachowania mechanizmu przekierowań w OAuth — szczególnie w scenariuszach błędów (tzw. error flows). Efekt: link wygląda na prowadzący do zaufanej domeny dostawcy tożsamości (np. Entra ID), po czym ofiara zostaje przekierowana na infrastrukturę atakującego i trafia na stronę phishingową lub automatyczny download złośliwego pliku.

W praktyce to kolejny przykład „identity-first”: łańcuch ataku startuje od tożsamości i protokołów logowania, a dopiero później przechodzi w kompromitację endpointu (malware) lub przejęcie sesji (AiTM).

W skrócie

Atakujący rejestruje złośliwą aplikację OAuth w kontrolowanym tenantcie i ustawia w niej redirect URI na własną domenę (np. pod dystrybucję malware).
Phishing zawiera link do prawdziwego endpointu autoryzacji, ale z parametrami celowo wywołującymi błąd (m.in. prompt=none + nieprawidłowy scope).
Dostawca tożsamości (IdP) zwraca błąd i — zgodnie ze specyfikacją — przekierowuje przeglądarkę na zarejestrowany redirect URI aplikacji, czyli… domenę atakującego.
Celem nie musi być kradzież tokenów OAuth — często chodzi o dostarczenie payloadu (ZIP/LNK/HTML smuggling) albo AiTM (np. EvilProxy) do przejęcia cookies/sesji.

Kontekst / historia / powiązania

OAuth od lat jest atrakcyjny dla przestępców, bo stoi „na ścieżce zaufania” użytkownika: logowanie przez znaną domenę i spodziewane przekierowania obniżają czujność. Nowość w opisywanej fali nie polega na nowej luce w implementacji, tylko na tym, że mechanika przekierowań w warunkach błędu stała się praktycznie operacyjna i masowo wykorzystywana do obejścia klasycznych filtrów linków w poczcie i przeglądarkach.

Microsoft wskazuje też, że kampanie celowały m.in. w sektor publiczny/rządowy, a wiadomości miały „klasyczne” przynęty: e-podpisy, HR, finanse, tematy społeczne/polityczne, zaproszenia/„nagrania” z Teams, reset hasła.

Analiza techniczna / szczegóły luki

1) Złośliwa aplikacja i redirect URI

Atak zaczyna się od utworzenia aplikacji OAuth w tenantcie kontrolowanym przez napastnika. Kluczowe jest ustawienie redirect URI na domenę/ścieżkę, gdzie atakujący kontroluje dalszy krok (phishing lub malware download).

2) Link, który wygląda „normalnie”, ale jest celowo popsuty

Użytkownik dostaje URL do legalnego endpointu autoryzacji (np. login.microsoftonline.com/.../authorize). Parametry są jednak ustawione tak, by wywołać błąd bez interaktywnego logowania:

prompt=none wymusza próbę „cichej” autoryzacji,
scope bywa niepoprawny/nieobsługiwany (albo w inny sposób gwarantuje błąd),
a state bywa nadużywany do przeniesienia danych (np. zakodowanego adresu e-mail ofiary), co potem umożliwia autopodstawienie e-maila na stronie docelowej i podbicie wiarygodności.

3) Error flow → przekierowanie na domenę napastnika

Gdy IdP nie może dokończyć autoryzacji „po cichu”, generuje błąd (np. wymaganie interakcji/zgody) i — zgodnie z zachowaniem protokołu — odsyła przeglądarkę na redirect URI przypisany do aplikacji, dołączając parametry błędu oraz state. To właśnie ten „legalny” redirect jest nadużywany jako trampolina z zaufanej domeny do złośliwej.

4) Co dalej: AiTM albo malware delivery (ZIP → LNK → PowerShell → DLL sideloading)

Microsoft i media branżowe opisują dwa główne warianty:

AiTM / phishing-as-a-service (np. EvilProxy): przejęcie sesji poprzez wyłudzanie poświadczeń i cookies, potencjalnie z obejściem MFA dzięki kradzieży tokenów sesyjnych/cookies.
Malware delivery: przekierowanie na ścieżkę typu /download, automatyczne pobranie ZIP zawierającego m.in. LNK oraz elementy HTML smuggling. Otwarcie LNK uruchamia PowerShell (rekonesans + staging), a następnie dochodzi do DLL side-loading: legalny binarny plik ładuje złośliwą bibliotekę (w opisach pojawiają się m.in. stream_monitor.exe i crashhandler.dll), która odszyfrowuje i ładuje payload w pamięci (np. crashlog.dat) i zestawia komunikację z C2.

Warto podkreślić: w tych kampaniach celem często nie jest kradzież tokenów OAuth, bo użytkownik nie udziela poprawnej autoryzacji — błąd jest celowy. Chodzi o wiarygodne „podprowadzenie” użytkownika i systemów filtrujących do kontrolowanej destynacji.

Praktyczne konsekwencje / ryzyko

„Hover to check link” przestaje działać: użytkownik widzi zaufaną domenę dostawcy tożsamości, a realne ryzyko siedzi w parametrach i późniejszym przekierowaniu.
Obejście części zabezpieczeń poczty i przeglądarki: filtry URL mogą przepuszczać linki do legalnych domen, a dopiero później następuje redirect na domenę atakującego.
Ryzyko kompromitacji endpointu (malware, pre-ransom, hands-on-keyboard) oraz ryzyko przejęcia sesji (AiTM) nawet przy włączonym MFA.
Szybka rotacja domen docelowych: payload hostowany „za redirectem” pozwala napastnikom dynamicznie zmieniać infrastrukturę, gdy kolejne domeny trafiają na blocklisty.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, które bezpośrednio wynikają z opisu Microsoftu (i są spójne z dobrymi praktykami IAM/Entra):

Kontrola aplikacji OAuth i zgód

Ogranicz user consent (wiele organizacji powinno przejść na model, gdzie zgody na aplikacje wymagają akceptacji admina).
Regularnie przeglądaj Enterprise Applications / App registrations pod kątem nowych, nieużywanych lub nadmiernie uprzywilejowanych aplikacji; usuwaj zbędne.
Monitoruj i alertuj zmiany w redirect URI (to pole jest w tym scenariuszu kluczowe).

Polityki dostępu i sygnały tożsamości

Wzmocnij Conditional Access (w tym wymagania urządzenia zgodnego/compliant, ryzyko logowania, lokalizacje, itp.). Microsoft wskazuje na konieczność korelowania sygnałów z email/identity/endpoint.
Traktuj nietypowe żądania OAuth (np. wzorce z prompt=none + podejrzany scope) jako sygnał detekcyjny w telemetryce.

Twarde zabezpieczenia endpointu i poczty

Blokuj/ogranicz ryzykowne typy (ZIP z LNK, HTML smuggling), wzmacniaj reguły ASR / polityki uruchamiania skryptów, kontroluj PowerShell (Constrained Language Mode tam, gdzie możliwe) i detekcje DLL side-loading.
W email security nie polegaj wyłącznie na reputacji domeny w linku — wdrażaj analizę łańcucha przekierowań i sandbox/URL detonation (o ile środowisko na to pozwala). Uzasadnienie jest wprost w obserwacjach o „benign-looking URLs”.

Edukacja (ale „nowa”: parametry i przekierowania)

Uaktualnij szkolenia: „zaufana domena w linku” nie wystarcza, bo zagrożenie może siedzieć w parametrach i późniejszym redirect.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

To nie jest klasyczne „consent phishing”, gdzie użytkownik faktycznie nadaje uprawnienia i atakujący dostaje tokeny do zasobów. Tutaj błąd jest intencjonalny, a mechanizm redirectu służy jako wiarygodna przesiadka do kolejnego etapu (phish/malware).
W porównaniu do „zwykłego” phishingu na podrabianą domenę: przewaga atakującego polega na tym, że pierwszy hop jest na domenie zaufanej (IdP), co osłabia wiele heurystyk użytkownika i części narzędzi.

Podsumowanie / kluczowe wnioski

Nadużycie OAuth error flows to sprytny, a zarazem prosty w operacjonalizacji wzorzec: „legalny” endpoint autoryzacji + celowo wywołany błąd + standards-compliant redirect = wiarygodny łańcuch prowadzący do phishingu lub malware. Najważniejsze w obronie jest przesunięcie ciężaru z „czy domena wygląda legitnie” na zarządzanie aplikacjami OAuth, kontrolę zgód, monitoring redirect URI oraz korelację sygnałów identity + email + endpoint.

Źródła / bibliografia

Microsoft Security Blog — OAuth redirection abuse enables phishing and malware delivery (02.03.2026). (Microsoft)
BleepingComputer — Microsoft: Hackers abuse OAuth error flows to spread malware (04.03.2026). (BleepingComputer)
Malwarebytes — Attackers abuse OAuth’s built-in redirects to launch phishing and malware attacks (04.03.2026). (Malwarebytes)
CSO Online — OAuth phishers make ‘check where the link points’ advice ineffective (03.03.2026). (CSO Online)
The Register — Microsoft OAuth scams abuse redirects for malware delivery (03.03.2026). (theregister.com)

APT41-linked „Silver Dragon” atakuje administrację: Cobalt Strike, tunelowanie DNS i C2 przez Google Drive

Wprowadzenie do problemu / definicja luki

W marcu 2026 r. Check Point opisał aktywność klastra APT nazwanego Silver Dragon, który od co najmniej połowy 2024 r. prowadzi kampanie ukierunkowane głównie na instytucje rządowe w Europie i Azji Południowo-Wschodniej. Wyróżnikiem działań jest łączenie kilku łańcuchów infekcji z utrzymaniem dostępu poprzez nadużycie legalnych komponentów Windows, a także „ukrywanie” komunikacji C2 w zaufanych usługach (m.in. Google Drive).

W skrócie

Silver Dragon przypisywany jest z wysokim prawdopodobieństwem do chińskiego ekosystemu APT41 (na podstawie zbieżności technik i artefaktów operacyjnych).
Wejście: eksploatacja publicznie wystawionych serwerów + phishing z załącznikami.
Utrzymanie i C2: Cobalt Strike + tunelowanie DNS oraz własny backdoor GearDoor komunikujący się przez Google Drive.
Narzędzia post-exploitation: m.in. SliverScreen (zrzuty ekranu) i SSHcmd (zdalne komendy/transfer przez SSH).

Kontekst / historia / powiązania

Silver Dragon jest opisywany jako „cluster” (zestaw kampanii i TTP), a nie koniecznie zupełnie nowa, niezależna grupa. Check Point wskazuje na korelację operacyjną z APT41; The Hacker News doprecyzowuje, że powiązania wynikają m.in. z podobieństw w skryptach instalacyjnych post-exploitation oraz zbieżności mechanizmów kryptograficznych/loaderów obserwowanych wcześniej w aktywności China-nexus.

Dla przypomnienia: APT41 (MITRE: G0096) to aktor oceniany jako państwowo sponsorowany (szpiegostwo) z historią działań równolegle „dla zysku” i szerokim spektrum celów od co najmniej 2012 r.

Analiza techniczna / szczegóły kampanii

1) Trzy łańcuchy infekcji (delivery → beacon → utrwalenie)

Check Point wyróżnia trzy ścieżki dostarczania i uruchomienia Cobalt Strike:

AppDomain hijacking (scenariusze .NET, nadużycie mechanizmów ładowania w domenie aplikacji)
Service DLL / nadużycie usług Windows (ładunek osadzony „pod” legalną usługą)
Phishing z załącznikiem LNK (skrót Windows uruchamiający łańcuch przez cmd.exe/PowerShell).

W dwóch pierwszych łańcuchach (AppDomain hijacking i Service DLL) wspólnym mianownikiem są archiwa RAR + skrypty batch oraz fakt, że bywają one wdrażane po kompromitacji podatnych serwerów wystawionych do Internetu (post-exploitation/pivot).

2) Loadery i uruchamianie w pamięci

W opisie pojawiają się m.in.:

MonikerLoader: .NET-owy loader służący do deszyfrowania i uruchamiania kolejnego etapu w pamięci.
BamboLoader: loader shellcode (opisany jako mocno obfuskowany), rejestrowany jako usługa Windows; deszyfruje/dekompresuje shellcode, a następnie wstrzykuje go do legalnego procesu (np. taskhost.exe).

3) Phishing LNK + DLL sideloading

W kampanii phishingowej wymierzonej m.in. w Uzbekistan wykorzystywano załączniki LNK, które inicjowały wykonanie PowerShell. Dalej pojawiał się zestaw plików: dokument-przynęta, legalny program podatny na DLL sideloading (w tekście: GameHook.exe), złośliwa biblioteka DLL (wariant BamboLoader) i zaszyfrowany payload Cobalt Strike.

4) C2 przez tunelowanie DNS i Google Drive

W sieci Silver Dragon często wykorzystuje DNS tunneling jako kanał C2, co ma utrudniać wykrywanie na poziomie ruchu sieciowego.

Dodatkowo wyróżnia się backdoor GearDoor, który używa Google Drive jako kanału C2 (w praktyce: komunikacja i zadania „udają” legalną aktywność w chmurze). W opisie The Hacker News pojawia się nawet konwencja rozszerzeń plików używanych do sygnalizowania typu zadania (np. „heartbeat” i tasking), a także upload wyników zadań z hosta do Drive.

5) Narzędzia wspierające operację (szpiegostwo, utrzymanie dostępu)

SliverScreen: okresowe zrzuty ekranu (monitoring aktywności użytkownika).
SSHcmd: wrapper/CLI do zdalnych komend i transferu przez SSH.

Praktyczne konsekwencje / ryzyko

Trudniejsze wykrywanie: nadużycie legalnych usług Windows i „zaufanych” usług chmurowych (Google Drive) przesuwa sygnały ataku w stronę zachowań, które w wielu organizacjach nie są ściśle kontrolowane.
Długotrwała obecność (persistence): priorytetem jest utrzymanie dostępu i zbieranie informacji, a nie szybka destrukcja — typowe dla szpiegostwa.
Ryzyko rozlania w sieci po kompromitacji serwerów brzegowych: jeśli wejście następuje przez publicznie wystawione systemy, atakujący może szybko przejść do ruchu bocznego i wdrożenia beaconów.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „praktycznych” pod ten konkretny profil TTP (Windows services + DNS tunneling + Drive C2 + Cobalt Strike):

1) Ogranicz powierzchnię wejścia (internet-facing)

Zrób przegląd usług wystawionych do Internetu i priorytetowo łatkuj systemy brzegowe (VPN, web, middleware, portale). Źródła wskazują, że kompromitacja serwerów publicznych bywa etapem poprzedzającym wdrożenie łańcuchów RAR/batch.
Włącz wymuszenia MFA i ogranicz dostęp administracyjny (VPN/admin panels) do zaufanych adresów / urządzeń.

2) Zabezpiecz pocztę i endpointy pod LNK/DLL sideloading

Zablokuj lub ściśle kontroluj załączniki LNK w poczcie oraz pobieranie/uruchamianie skrótów z Internetu (ASR rules, Mark-of-the-Web).
Monitoruj nietypowe uruchomienia cmd.exe → PowerShell z kontekstu aplikacji użytkownika oraz anomalie DLL loading przy procesach typu „legit-exe obok podejrzanej DLL”.

3) Polowanie na persistence w usługach Windows

Ustal bazową listę usług i ich binarek; alertuj na:
- tworzenie nowych usług,
- modyfikacje istniejących,
- nietypowe ścieżki binarek usług (np. profile użytkowników, katalogi tymczasowe),
- zatrzymywanie/odtwarzanie usług w krótkich oknach czasowych (pattern utrwalania opisany przez Check Point).

4) Detekcja tunelowania DNS

Wdroż analizę: wysokie entropie subdomen, nietypowe długości nazw, wolumen NXDOMAIN, stały beaconing. Źródła wiążą to z C2 w tej kampanii.

5) Kontrola ruchu do usług chmurowych (Google Drive jako C2)

Jeśli organizacja używa Google Workspace: włącz logowanie zdarzeń i korelację (nietypowe tokeny/OAuth, nowe aplikacje, nietypowe uploady/downloady).
Jeśli nie używa: rozważ egress allowlisting i blokadę/ograniczenie Drive na hostach serwerowych oraz segmentach „high trust”. GearDoor wprost opisano jako backdoor z C2 przez Drive.

6) Gotowe „hunting cues” (bez wchodzenia w IOC-dump)

Nietypowe archiwa RAR + skrypty .bat w środowisku serwerowym.
Procesy typu taskhost.exe lub inne legalne hosty z anomaliami wątku/iniekcji (EDR).
Obecność Cobalt Strike (wzorce beaconingu, artefakty pamięci, nietypowe named pipes) — w kampanii wskazany jako element utrzymania dostępu.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

„Cloud C2” vs klasyczne serwery C2: Google Drive jako kanał sterowania jest szczególnie problematyczny, bo miesza się z legalnym ruchem i politykami „dozwolone, bo biznes”. To odróżnia kampanię od prostszych infrastruktur VPS/domen jednorazowych.
Nacisk na stealth i persistence: zamiast agresywnych działań (ransomware), Silver Dragon kładzie nacisk na utrzymanie długiego dostępu (hijack usług Windows, DNS tunneling), co jest bardziej spójne z szpiegostwem i z profilem „umbrella” APT41.

Podsumowanie / kluczowe wnioski

Silver Dragon to przykład nowoczesnej kampanii szpiegowskiej, w której nie pojedynczy malware, a kombinacja technik robi różnicę: wejście przez serwery publiczne i phishing, szybkie osadzenie Cobalt Strike, utrwalenie przez legalne usługi Windows, C2 przez DNS tunneling oraz „maskowanie” komunikacji w Google Drive (GearDoor). Dla obrony oznacza to konieczność połączenia higieny perymetru (patching), twardych polityk endpointowych (LNK/DLL), oraz obserwowalności ruchu DNS i aktywności chmurowej.

Źródła / bibliografia

The Hacker News — opis kampanii i łańcuchów infekcji (04.03.2026). (The Hacker News)
Check Point Research — raport techniczny „Silver Dragon Targets Organizations in Southeast Asia and Europe” (03.03.2026). (Check Point Research)
Check Point Blog — podsumowanie i wnioski operacyjne (03.03.2026). (Check Point Blog)
Dark Reading — kontekst i streszczenie zagrożenia (04.03.2026). (Dark Reading)
MITRE ATT&CK — profil APT41 (G0096). (MITRE ATT&CK)

Cyber Advisory Sophos: wzrost ryzyka cyberataków w cieniu eskalacji USA–Izrael–Iran (marzec 2026)

Wprowadzenie do problemu / definicja „luki”

W okresach gwałtownej eskalacji militarnej rośnie nie tylko ryzyko klasycznych operacji państwowych (APT), ale też „szumu” generowanego przez grupy ideologiczne i persony podszywające się pod hacktywistów. Sophos X-Ops (Counter Threat Unit) opisuje bieżącą sytuację jako Threat Level: Elevated oraz wskazuje, że główne okno ryzyka to dni–tygodnie, a najbardziej prawdopodobne są działania zakłócające, oportunistyczne i wpływowe (influence-oriented).

W praktyce nie chodzi o jedną „lukę” w sensie CVE, tylko o moment podwyższonej podatności organizacji na kombinację: presji czasu, przeciążenia SOC, kampanii phishingowych pod newsy dnia, działań DDoS oraz prób niszczenia danych (wiper) maskowanych jako ransomware.

W skrócie

Sophos ocenia ryzyko jako podniesione i wskazuje na możliwe uderzenia w: administrację, sektor finansowy, podmioty „defense-adjacent” oraz infrastrukturę krytyczną.
SentinelOne zakłada wzrost aktywności irańskich aktorów państwowych i proxy (od rozpoznania po działania destrukcyjne i wpływowe), nawet jeśli w momencie publikacji nie przypisał jeszcze dużych incydentów bezpośrednio do tych wydarzeń.
Check Point opisuje m.in. Agrius (MOIS-linked) i jego playbook: wipery / „fake ransomware”, web-serwery jako wektor wejścia, webshell (ASPX), LOLBins, narzędzia tunelujące i rekonesans.
Agencje USA (NSA/CISA/FBI/DC3) przypominają, że irańscy aktorzy (w tym „hacktiviści”) często biorą na cel słabo zabezpieczone, wystawione do internetu systemy, wykorzystują niezałatane podatności oraz domyślne/pospolite hasła.
Reuters raportuje już pierwszą falę cyberoperacji towarzyszących uderzeniom kinetycznym (m.in. kompromitacje serwisów i aplikacji) oraz oczekiwanie na możliwy odwet w cyberprzestrzeni.

Kontekst / historia / powiązania

Sophos podkreśla, że irańskie operacje często korzystają z proxy grup i person, które biorą na siebie „odpowiedzialność” medialną. W advisory padają przykłady: HomeLand Justice (kojarzona z wiperami i „hack-and-leak” przeciw Albanii od 2022) oraz Handala Hack (persona łączona z MOIS, skłonna do gróźb, czasem do realnych kradzieży danych i wiperów).

Równolegle media opisują cyberoperacje wymierzone w irańskie zasoby (np. włamania do serwisów i aplikacji), co może działać jak „iskra” do działań odwetowych lub kampanii wpływu. To ważne, bo cyber w takich momentach bywa jednocześnie narzędziem presji i propagandy.

Analiza techniczna / szczegóły (TTP), których należy się spodziewać

1) „Szybkie” zakłócenia: DDoS, defacement, przejęcia kont

Najbardziej „dostępne” i widoczne techniki, które zwykle eskalują w pierwszej fazie, to: DDoS, defacement oraz kompromitacje kont (np. przez password spraying / phishing). Sophos wymienia te kategorie wprost jako prawdopodobny zestaw działań.

2) Destrukcja danych: wipery i „fake ransomware”

SentinelOne i Sophos wskazują na możliwość użycia wiper malware (niszczenie danych) oraz na trend maskowania destrukcji jako „ransomware”. Check Point opisuje to bardzo konkretnie w kontekście Agrius: wipery/fake-ransomware, webshell (ASPX), a potem egzekucja przy użyciu LOLBins i automatyzacji (np. zadania harmonogramu).

3) Wejście przez „internet-facing”: VPN, web-serwery, usługi zewnętrzne

Wspólny mianownik w zaleceniach to redukcja ekspozycji: patching i przegląd powierzchni ataku. Agencje USA akcentują typowy pattern: niezałatane systemy i słabe hasła na urządzeniach/usługach dostępnych z internetu.

4) Phishing i kradzież tożsamości jako dźwignia do dalszego ruchu

SentinelOne przewiduje intensyfikację spearphishingu, credential harvestingu oraz nadużyć legalnych narzędzi (PowerShell/script abuse), a Sophos wprost rekomenduje wzmocnienie kontroli IAM i monitoring nietypowych logowań (w tym password spraying).

5) OT/ICS: „nisko-uderzeniowe, wysoko-widoczne” incydenty

SentinelOne przypomina, że w okresach napięć Iran potrafi sięgać po cele w infrastrukturze krytycznej i środowiskach OT/ICS, często w sposób demonstracyjny. Wskazuje też na precedensy związane z systemami przemysłowymi i celowanie w wodociągi/utility.

Praktyczne konsekwencje / ryzyko

Ryzyko nie jest równomierne. Najbardziej narażone są organizacje, które:

mają powiązania z sektorem obronnym, administracją, finansami lub infrastrukturą krytyczną (USA/Izrael oraz podmioty sojusznicze),
utrzymują duży „zewnętrzny footprint” (VPN-y, bramy OWA/IdP, panele admin, stare aplikacje web),
są wrażliwe na przestoje (DDoS) lub mają niski poziom segmentacji (łatwiejsza destrukcja przy wiperach).

Reuters opisuje także element „psyops”: ataki, które jednocześnie zakłócają działanie usług i wstrzykują przekaz. Dla firm oznacza to nie tylko incydent techniczny, ale też kryzys reputacyjny i komunikacyjny.

Rekomendacje operacyjne / co zrobić teraz (checklista „dni–tygodnie”)

Poniżej priorytety zsyntetyzowane z zaleceń Sophos CTU, SentinelOne, Check Point oraz wspólnych wniosków agencji USA:

Tożsamość i dostęp (IAM)

Wymuś MFA (preferuj phishing-resistant) na zdalnym dostępie i kontach uprzywilejowanych.
Monitoruj password spraying, nietypowe logowania, replay tokenów/sesji.

Redukcja ekspozycji

Zrób szybki przegląd internet-facing usług i załatane vs. niezałatane (priorytet: bramy VPN, serwery web, panele zarządzania).
Usuń/ogranicz niekrytyczne usługi wystawione do internetu, szczególnie bez MFA.

Gotowość na DDoS i defacement

Odśwież playbooki DDoS (contact list do ISP/CDN/WAF, progi eskalacji, procedury failover).

Przygotowanie na wipery / destrukcję

Przećwicz scenariusz „data-wipe” (izolacja, triage, odtwarzanie, decyzje biznesowe).
Zweryfikuj kopie zapasowe pod kątem immutability i odseparowania od domeny produkcyjnej (to krytyczne przy destrukcji, nie tylko szyfrowaniu). (Wniosek operacyjny oparty o typ ataków wiper/fake-ransomware).

OT/ICS

Segmentacja OT, przegląd zdalnych dostępów, skan ekspozycji HMI/PLC, blokada domyślnych haseł.

Influence ops i „fake leaks”

Ustal szybki tor weryfikacji „wycieków” i komunikatów (PR + Legal + SOC), bo aktorzy mogą recyklingować stare naruszenia jako „nowe”.

Różnice / porównania z innymi przypadkami

To, co wyróżnia takie okresy napięć, to mieszanka aktorów: obok klasycznych APT pojawia się „hacktivism” (często z elementami państwowego wsparcia lub przynajmniej inspiracji), a cele bywają wybierane oportunistycznie — tam, gdzie najłatwiej o efekt medialny. Sophos i SentinelOne wprost zwracają uwagę na operacje wpływu oraz działania „pod przykrywką” hacktywizmu.

Dodatkowo rośnie ryzyko błędnej atrybucji: presja na szybkie komunikaty + wysyp „brandowanych” person = idealne środowisko do podszywania się pod znane grupy. To ma bezpośrednie znaczenie dla IR (co eskalować jako incydent krytyczny, a co traktować jako szum).

Podsumowanie / kluczowe wnioski

Sophos podnosi alert: Elevated, okno dni–tygodnie, a na liście ryzyk dominują DDoS, wipery, hack-and-leak, phishing i ataki na systemy wystawione do internetu.
SentinelOne i Check Point dostarczają „mapy playbooków”: od spearphishingu i kradzieży poświadczeń po destrukcję danych i operacje wpływu; szczególnie istotne są techniki LOLBins, webshell, scheduled tasks oraz targetowanie infrastruktury/OT.
Największy zwrot z inwestycji „na już” daje: MFA + patching + redukcja ekspozycji + gotowość na destrukcję + procedury DDoS + dyscyplina komunikacyjna.

Źródła / bibliografia

Sophos X-Ops – Cyber Advisory: Increased Cyber Risk Amid U.S.–Israel–Iran Escalation (1 marca 2026). (SOPHOS)
SentinelOne – Intelligence Brief: Iranian Cyber Activity Outlook (28 lutego 2026). (SentinelOne)
Check Point Research – What Defenders Need to Know about Iran’s Cyber Capabilities (1 marca 2026). (Check Point Blog)
NSA – Press release: Iranian cyber actors may target vulnerable US networks (30 czerwca 2025). (National Security Agency)
Reuters – Hackers hit Iranian apps, websites after US-Israeli strikes (1 marca 2026). (Reuters)

APT37 (ScarCruft) przełamuje izolację: nowy zestaw malware do ataków na sieci air-gapped przez USB

Wprowadzenie do problemu / definicja luki

Sieci air-gapped (fizycznie odseparowane od Internetu) uchodzą za jedną z najmocniejszych kontroli bezpieczeństwa w środowiskach OT/ICS, wojsku czy badaniach. Problem w tym, że „air gap” prawie nigdy nie oznacza absolutnej izolacji — w praktyce dane i pliki i tak krążą pomiędzy segmentami dzięki nośnikom wymiennym (USB, dyski zewnętrzne). To właśnie ten „most operacyjny” staje się celem atakujących.

Najnowsze ustalenia pokazują, że północnokoreański aktor APT37 (ScarCruft) wdrożył narzędzia, które zamieniają pendrive’y w dwukierunkowy, ukryty kanał C2: pozwala to zarówno dostarczać polecenia do maszyn odciętych od sieci, jak i wynosić z nich dane.

W skrócie

Kampania została opisana przez Zscaler ThreatLabz jako „Ruby Jumper” i jest łączona z APT37.
Łańcuch infekcji startuje od złośliwego pliku LNK, który uruchamia PowerShell, wyciąga komponenty z samego skrótu i odpala dokument-przynętę.
Zidentyfikowane komponenty obejmują m.in.: RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE (oraz obserwowany wcześniej backdoor BLUELIGHT).
THUMBSBD realizuje kluczową funkcję: używa nośników wymiennych jako „transportu” do przekazywania poleceń i danych między systemami online i air-gapped.

Kontekst / historia / powiązania

APT37 to państwowa grupa szpiegowska powiązana z Koreą Północną, aktywna co najmniej od 2012 r., silnie skupiona na celach w Korei Południowej, ale z szerszym zasięgiem regionalnym.

Wzorzec działań pasuje do znanego modus operandi tej grupy: spear-phishing, pliki skrótów LNK, „living off trusted services” (nadużywanie zaufanych usług chmurowych jako infrastruktury C2 lub dystrybucji). Przykładowo, wcześniejsze analizy (np. Genians) opisywały kampanie APT37 wykorzystujące Dropbox i pliki LNK jako etap inicjalny.

„Ruby Jumper” rozwija te techniki o element szczególnie groźny dla środowisk odseparowanych: kontrolowaną propagację przez USB i mechanizm transferu poleceń/danych przez nośnik.

Analiza techniczna / szczegóły luki

1. Wejście: LNK + PowerShell + przynęta

Łańcuch startuje, gdy użytkownik otworzy złośliwy Windows Shortcut (LNK). Ten uruchamia PowerShell, który „wycina” (carving) zaszyte w skrócie elementy (m.in. kolejne skrypty/payloady) oraz uruchamia dokument-wabik, by zająć uwagę ofiary.

2. RESTLEAF: C2 przez Zoho WorkDrive

Pierwszym implantem jest RESTLEAF, który komunikuje się z infrastrukturą C2 wykorzystując Zoho WorkDrive (z perspektywy obrońcy: ruch do legalnej usługi SaaS).

W praktyce oznacza to:

ukrycie komunikacji na tle normalnego ruchu do usług chmurowych,
łatwiejsze obchodzenie blokad/allow-list opartych na reputacji domen,
potencjalnie trudniejsze atrybuowanie infrastruktury (bo „serwerem” jest repozytorium w chmurze).

3. SNAKEDROPPER: środowisko Ruby jako „kontener” dla kolejnych etapów

Kolejny etap to SNAKEDROPPER – loader, który instaluje środowisko Ruby 3.3.0 i maskuje je jako narzędzie związane z USB (m.in. poprzez nazwę wykonywalną typu usbspeed.exe). Następnie utrwala wykonanie (scheduled task wykonywany cyklicznie).

To ważne z dwóch powodów:

atakujący dostarczają własny „runtime”, uniezależniając się od tego, co jest zainstalowane na stacji,
nietypowy stos (Ruby runtime w katalogach systemowych/ProgramData) może utrudniać reguły detekcji oparte wyłącznie o klasyczne TTP (np. tylko PowerShell/LOLbins).

4. THUMBSBD: „dwukierunkowy przekaźnik C2” przez USB

THUMBSBD pełni rolę backdoora i mechanizmu „mostu” pomiędzy systemem online a air-gapped: przygotowuje pliki z poleceniami, zbiera wyniki i przenosi je przez ukryte katalogi na nośniku. Zscaler opisuje to wprost jako zamianę nośników wymiennych w dwukierunkowy ukryty przekaźnik C2.

W uproszczeniu: operator może „wgrać” polecenia na pendrive na maszynie mającej dostęp do C2 (chmury), a następnie ten sam pendrive przenosi polecenia do stacji air-gapped i wraca z danymi/rezultatami do środowiska online.

5. VIRUSTASK: propagacja w segmencie odciętym

Komponent VIRUSTASK odpowiada za rozprzestrzenianie w środowiskach air-gapped: „uzbraja” nośniki, ukrywając legalne pliki i zastępując je skrótami LNK, które uruchamiają zainstalowany runtime Ruby i dalsze elementy łańcucha. Co istotne, mechanizm ma warunek uruchomienia (np. minimalna wolna przestrzeń na nośniku).

6. FOOTWINE i BLUELIGHT: działania rozpoznawcze i szpiegowskie

W dalszym etapie THUMBSBD dostarcza FOOTWINE – spyware/backdoor z możliwościami takimi jak keylogging, zrzuty ekranu, nagrywanie audio/wideo czy zdalna powłoka. W kampanii obserwowano też BLUELIGHT, wcześniej wiązany z APT37, co wzmacnia atrybucję.

Praktyczne konsekwencje / ryzyko

Największa zmiana nie polega na „magicznej” zdolności łamania air-gapu, tylko na industrializacji przenoszenia kontroli między segmentami:

Ryzyko dla OT/ICS i infrastruktury krytycznej: nawet jeśli stacje operatorskie/HMI są odcięte od Internetu, operacyjny obieg plików (raporty, konfiguracje, logi) tworzy ścieżkę ataku.
C2 ukryte w chmurze: RESTLEAF wykorzystujący Zoho WorkDrive może wyglądać jak „normalny ruch SaaS”, co komplikuje polityki oparte na prostym allow/deny dla domen.
Skuteczna inwigilacja: finalne payloady nastawione są na długotrwałe zbieranie informacji (keylogging, screen/audio/video), co jest typowe dla operacji szpiegowskich.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko w scenariuszu „USB jako most”:

Twarda kontrola nośników wymiennych

wdrożenie polityk device control (whitelist konkretnych VID/PID/seriali),
wymuszenie szyfrowania i rejestrowania użycia nośników,
ograniczenie autorun i blokada uruchamiania skrótów LNK z nośników (tam gdzie to możliwe operacyjnie).

Detekcja na endpointach (EDR) pod kątem TTP z kampanii

alarmy na nietypowe uruchomienia PowerShell pochodzące z LNK,
monitoring tworzenia zadań harmonogramu (scheduled tasks) o podejrzanych nazwach/cykliczności,
polowanie na anomalię: runtime Ruby wypakowany w nietypowych lokalizacjach (np. %PROGRAMDATA%) i procesy typu usbspeed.exe uruchamiane cyklicznie.

Kontrola dostępu do usług chmurowych (CASB / SWG / proxy)

inspekcja i alertowanie na nietypowe użycie Zoho WorkDrive w organizacji (zwłaszcza jeśli nie jest wykorzystywany biznesowo),
korelacja: tokeny/operacje API do chmury + zdarzenia endpointowe (LNK/PowerShell) w krótkim oknie czasu.

Procedury dla środowisk air-gapped

„strefa buforowa” (kiosk) do skanowania nośników przed wejściem do segmentu odseparowanego,
walidacja plików przenoszonych do OT (formaty, podpisy, źródło, integralność),
jeśli to możliwe: jednokierunkowy transfer (data diode) zamiast przenoszenia danych na USB.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Klasyczne infekcje przez LNK: APT37 korzysta z tej techniki od lat, co widać także w starszych kampaniach opisywanych publicznie (np. nadużycia usług chmurowych i LNK jako wektora).
Nowość w „Ruby Jumper”: nie sam phishing, lecz spójny zestaw narzędzi do obsługi pełnego cyklu air-gap (propagacja + przenoszenie poleceń + exfil przez nośnik), oraz wyraźne postawienie na chmurę SaaS (Zoho WorkDrive) jako warstwę C2.

Podsumowanie / kluczowe wnioski

APT37 pokazuje, że „air-gap” bez kontroli nośników wymiennych jest bardziej założeniem niż zabezpieczeniem. Kampania Ruby Jumper łączy:

inicjalny dostęp przez LNK + PowerShell,
C2 ukryte w Zoho WorkDrive,
oraz krytyczny element: THUMBSBD/VIRUSTASK, które zamieniają USB w kanał sterowania i transferu danych do/z środowisk air-gapped.

Jeśli w organizacji istnieje choćby minimalny „ruch USB” między segmentami, warto potraktować ten scenariusz jako realny i wdrożyć kontrolę nośników, hunting endpointowy oraz polityki dla usług SaaS.

Źródła / bibliografia

BleepingComputer – opis kampanii i przegląd narzędzi (RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE, BLUELIGHT). (BleepingComputer)
Zscaler ThreatLabz – raport techniczny „APT37 Adds New Capabilities for Air-Gapped Networks” (Ruby Jumper, Zoho WorkDrive, szczegóły łańcucha infekcji). (zscaler.com)
MITRE ATT&CK – profil grupy APT37 (G0067) i kontekst operacyjny. (MITRE ATT&CK)
Genians – przykład wcześniejszych kampanii APT37 z LNK i nadużyciem chmury (kontekst TTP). (genians.co.kr)