Archiwa: APT - Strona 21 z 32 - Security Bez Tabu

APT31 (Violet Typhoon/Zirconium) prowadzi ciche cyberataki na rosyjski sektor IT. Cloud C2, CloudyLoader i nowe backdoory na celowniku

Wprowadzenie do problemu / definicja kampanii

Chińsko-powiązana grupa APT31 (znana także jako Violet Typhoon/Zirconium/Judgement Panda) została powiązana z długofalową kampanią cyberszpiegowską przeciw rosyjskiemu sektorowi IT. Ataki miały trwać co najmniej w latach 2024–2025, a w jednym przypadku utrzymanie dostępu sięgało końcówki 2022 r. Kluczową cechą operacji jest wykorzystanie popularnych usług chmurowych (w tym Yandex Cloud oraz Microsoft OneDrive) jako kanałów C2 i exfiltracji, co utrudniało detekcję w ruchu „legitnym” dla ofiar.

W skrócie

  • Cele: rosyjskie firmy IT – integratorzy i kontraktorzy dla administracji publicznej.
  • Taktyki: C2 i staging w usługach chmurowych i… w profilach serwisów społecznościowych; operacje intensyfikowane w weekendy i święta.
  • Wejście: phishing z archiwami RAR/ZIP zawierającymi LNK oraz „DLL side-loading” do uruchomienia CloudyLoader (loader Cobalt Strike).
  • Nowe narzędzia w arsenale: OneDriveDoor, VtChatter (C2 via VirusTotal comments), COFFProxy (Golang), AufTime (Linux, wolfSSL), YaLeak (exfil do Yandex Cloud), a także LocalPlugX do ruchu bocznego.
  • Utrzymanie: harmonogram zadań podszywający się pod legalne aplikacje (np. YandexDisk/Chrome), tunelowanie przez Tailscale i Microsoft Dev Tunnels.

Kontekst / historia / powiązania

APT31 działa co najmniej od 2010 r., a na jej koncie są operacje przeciw instytucjom rządowym, finansom, obronności i high-tech na wielu kontynentach. W 2025 r. grupa była łączona m.in. z incydentami wobec czeskiego MSZ oraz z wcześniejszymi operacjami w Europie. Zestaw aliasów obejmuje m.in. Violet Typhoon (Microsoft), Zirconium, Judgement Panda.

Analiza techniczna / szczegóły kampanii

Wejście (Initial Access).
Udokumentowano spear-phishing z archiwami zawierającymi skróty .LNK. Po uruchomieniu następował łańcuch DLL side-loading bazujący na legalnym pliku BsSndRpt64.exe, który ładował bibliotekę BugSplatRc64.dll z wbudowanym CloudyLoaderem (loader Cobalt Strike). Warianty socjotechniki obejmowały „zapytania zakupowe” oraz przynęty stylizowane na dokumenty ministerstw (np. Peru).

Dowodzenie i kontrola (C2).
Komendy i payloady były „stage’owane” w profilach mediów społecznościowych (lokalnych i zagranicznych), a w komunikacji wykorzystywano powszechne usługi chmurowe (Yandex, Microsoft OneDrive), co maskowało ruch. Wybrane narzędzia:

  • OneDriveDoor – backdoor używający OneDrive jako C2;
  • VtChatter – narzędzie komunikujące się co 2 godz. przez zakodowane komentarze do pliku na VirusTotal;
  • YaLeak – .NET do wysyłki danych do Yandex Cloud.

Ruch boczny i utrzymanie.
Zaobserwowano LocalPlugX (odmiana PlugX do poruszania się wewnątrz sieci), COFFProxy (Golang: tunelowanie/komendy/zarządzanie plikami), AufTime (Linux backdoor z wolfSSL), Tailscale VPN i Microsoft Dev Tunnels do szyfrowanego P2P, a także liczne zadania w Harmonogramie Zadań Windows, których nazwy imitują legalne procesy (np. YandexDisk_Servers, GoogleUpdater). Wykryto też technikę tworzenia ukrytych zadań przez manipulację TaskCache\Tree\ i plikami XML.

Techniki ukrywania (Defense Evasion) i „timing”.
Operacje „pod święta/weekendy” oraz generowanie ruchu do legalnych serwisów utrudniało korelację i triage. Dodatkowo opisywano nietypowe wykorzystanie oobe\Setup.exe /ui do odpalenia łańcucha z własnym ErrorHandler.cmd.

Powiązane obserwacje branżowe.
Niezależne badania Kaspersky z lipca 2025 roku dokumentowały kampanie z Cobalt Strike i hostingiem komend/payloadów na platformach społecznościowych/GitHub, co spójnie wpisuje się w TTPs widoczne u APT31.

Praktyczne konsekwencje / ryzyko

  • Detekcja utrudniona: ruch C2/outbound do chmur i popularnych serwisów jest zwykle dozwolony, co obniża skuteczność klasycznych list kontroli, proxy i filtrów reputacyjnych.
  • Długotrwałe utrzymanie: potwierdzono przypadki „zagnieżdżenia” od końca 2022 r. i eskalacji aktywności podczas długich przerw świątecznych.
  • Różnorodny arsenał: miks living-off-the-land, narzędzi publicznych (SharpChrome, SharpDir) oraz custom backdoorów utrudnia budowę jednego wzorca IOC.

Rekomendacje operacyjne / co zrobić teraz

  1. Egress i kontrola chmury
    • Stwórz granularne zasady dla wyjściowego ruchu HTTP(S) do usług: OneDrive, Yandex Cloud, Paste/VT i wybranych social-media. Wymuś tenant allow-list dla Microsoft 365/OneDrive i monitoruj nietypowe identyfikatory aplikacji oraz User-Agent. Loguj i alertuj o transferach nietypowych dla profilu użytkownika/systemu.
  2. Hunting na zadania i „DLL side-loading”
    • Cycliczny hunting Scheduled Tasks: nazwy podobne do YandexDisk, GoogleUpdater, Crashpad_Server; sprawdzaj brakujące wpisy SecurityDescriptor w HKLM\...TaskCache\Tree\ vs. fizyczne pliki XML.
    • Szukaj BsSndRpt64.exe uruchamianego spoza domyślnych ścieżek oraz towarzyszących bibliotek BugSplatRc64.dll.
  3. Zasady czasu pracy (blue-team ops)
    • Podnieś wrażliwość alertów w weekendy i święta; wprowadź „holiday surge playbooks” (IR on-call, szybsza triage exfilu, czasowe zaostrzenie egressu).
  4. EDR/Proxy detections & telemetry
    • Reguły na nietypowe użycie Tailscale, Dev Tunnels, tunelowanie z hostów serwerowych; detekcje na narzędzia SharpADUserIP/SharpChrome/StickyNotesExtract. W proxy: wywołania do znanych end-pointów graph.microsoft.com, api.onedrive.com, storage.yandexcloud.net z hostów, które normalnie tego nie robią.
  5. Hardening poczty i stacji roboczych
    • Blokada uruchamiania .LNK z archiwów, polityki „mark of the web”, ASR dla „Office/shortcut LNK child processes”, ograniczenie DLL search order (WDAC/Applocker) dla znanych binariów podatnych na side-loading.
  6. Łańcuchy wskaźników i TTP-mapa
    • Zmapuj kontrole do MITRE ATT&CK dla APT31 (T1566.002 Spearphishing Link; T1053.005 Scheduled Task/Job; T1105 Exfil via C2; T1572 Protocol Tunneling itp.) i wdrażaj detekcje oparte na zachowaniu (behavioural).

Różnice / porównania z innymi przypadkami

  • Nietypowy wektor geopolityczny: raporty o chińskich operacjach przeciw rosyjskim podmiotom pojawiają się rzadko – ten przypadek potwierdzają niezależnie źródła branżowe.
  • C2 na platformach społecznościowych: trend widoczny w szerszym krajobrazie (Kaspersky) – ale u APT31 jest szczególnie przemyślany i łączony z chmurą lokalną (Yandex).

Podsumowanie / kluczowe wnioski

APT31 kontynuuje ewolucję: łączy „stare” techniki (phishing + Cobalt Strike) z nowymi backdoorami i C2 ukrytym w chmurze/publicznych serwisach. Dla obrońców oznacza to przejście z detekcji opartej na domenach/IP na kontrolę kontekstową i behawioralną (tenant enforcement, model ryzyka dla egressu, hunting na zadania i side-loading). Kampania pokazuje również, że „okna operacyjne” (weekendy/święta) pozostają skutecznym narzędziem aktorów APT – i wymagają dedykowanych playbooków IR.

Źródła / bibliografia

  1. The Hacker News: „China-Linked APT31 Launches Stealthy Cyberattacks on Russian IT Using Cloud Services” (22 listopada 2025). (The Hacker News)
  2. Positive Technologies, „Атаки разящей панды: APT31 сегодня” (20 listopada 2025) – raport techniczny. (ptsecurity.com)
  3. Kaspersky Securelist, „Cobalt Strike Beacon z dostawą przez GitHub i social media” (30 lipca 2025). (securelist.ru)
  4. The Record (Recorded Future News), „China’s APT31 linked to hacks on Russian tech firms” (21 listopada 2025). (The Record from Recorded Future)
  5. MITRE ATT&CK: „ZIRCONIUM (APT31) – G0128” (profil grupy i technik). (MITRE ATT&CK)

SolarWinds łatka trzy krytyczne luki RCE w Serv-U (CVE-2025-40547/48/49). Zaktualizuj do 15.5.3

Wprowadzenie do problemu / definicja luki

SolarWinds opublikował poprawki dla trzech krytycznych podatności w Serv-U (rozwiązanie MFT/SFTP), które mogą prowadzić do zdalnego wykonania kodu (RCE). Błędy oznaczono jako CVE-2025-40547 (logic error → RCE), CVE-2025-40548 (broken access control → RCE) oraz CVE-2025-40549 (path restriction bypass → RCE). Wszystkie wymagają uprawnień administratora Serv-U do nadużycia, a na Windows ich ryzyko oceniono niżej (z uwagi na domyślne, mniej uprzywilejowane konta usług). Poprawka dostępna jest w wydaniu Serv-U 15.5.3.

W skrócie

  • Wpływ: potencjalne RCE po stronie serwera Serv-U. Wymagane uprawnienia admina w produkcie.
  • Dotyczy wersji: 15.5.2.2.102. Naprawione w 15.5.3 (wydanie z 18 listopada 2025 r.).
  • CVSS: w advisory podano 9.1 (Critical/High); na Windows zaznaczono niższy poziom ryzyka operacyjnego.
  • Dodatkowo: SolarWinds załatał też podatności open redirect i XSS w Observability Self-Hosted (średnia waga).

Kontekst / historia / powiązania

Produkty SolarWinds – w tym Serv-U – były już wcześniej celem ataków; część ich luk widnieje w katalogu CISA Known Exploited Vulnerabilities (KEV), np. CVE-2024-28995 (path traversal w Serv-U). To potwierdza, że błędy w tym ekosystemie bywają szybko wykorzystywane i wymagają pilnych aktualizacji.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze informacje z advisory producenta:

  • CVE-2025-40547 – Logic Abuse → RCE. Błąd logiki, którego nadużycie przez konto administratora Serv-U może skutkować wykonaniem dowolnego kodu. Na Windows ryzyko operacyjne niższe (często mniej-uprzywilejowane konta usług). Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1.
  • CVE-2025-40548 – Broken Access Control → RCE. Braki w walidacji dostępu; wymagane uprawnienia admina Serv-U. Windows: niższe ryzyko z powodów jak wyżej. Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1.
  • CVE-2025-40549 – Path Restriction Bypass → RCE. Obejście ograniczeń ścieżek mogące umożliwić wykonanie kodu w obrębie wskazanego katalogu; wymaga uprawnień admina Serv-U. Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1 (na Windows zaklasyfikowane niżej).

Według notek wydania Serv-U 15.5.3 został opublikowany 18 listopada 2025 r. i stanowi wersję naprawczą dla tych luk.

Praktyczne konsekwencje / ryzyko

Choć nadużycie każdej z luk wymaga konta admina w Serv-U, w praktyce:

  • Lateral movement & post-exploitation: w środowiskach, gdzie napastnik uzyskał już pewne przywileje (np. po kradzieży poświadczeń), podatności te upraszczają eskalację skutków węzła MFT (np. do persistencji lub pivotu).
  • Wpływ na poufność i ciągłość: serwer MFT bywa centralnym punktem wymiany plików; RCE może oznaczać kradzież lub modyfikację transferowanych danych i zakłócenia procesów biznesowych. (Wniosek na podstawie charakteru RCE i roli Serv-U).
  • Ryzyko zgodności: organizacje regulowane (finanse, zdrowie, sektor publiczny) narażone są na niezgodność z wymogami bezpieczeństwa, gdy usterki RCE nie są łatane priorytetowo. (Wniosek ogólny dla klas podatności RCE).

Dodatkowo warto pamiętać, że luki SolarWinds trafiały już do CISA KEV, więc przy braku aktualizacji należy zakładać możliwość szybkiego weaponization przez grupy APT i cybercrime.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj Serv-U do 15.5.3 na wszystkich hostach (Windows/Linux). Zweryfikuj wersję po aktualizacji.
  2. Przegląd uprawnień: ogranicz liczbę kont admin Serv-U do minimum; włącz MFA/klucze SSH, a tam gdzie możliwe – least privilege dla kont usług. (Dobre praktyki + wskazania advisory nt. mniejszego ryzyka na kontach mniej-uprzywilejowanych).
  3. Telemetria i detekcja: monitoruj procesy Serv-U i katalogi robocze pod kątem anomalii (nieoczekiwane binarki, skrypty, harmonogramy zadań, nowe usługi). Koreluj z logami uwierzytelniania adminów. (Wniosek operacyjny dla RCE).
  4. Segmentacja i hardening: izoluj serwer MFT w wydzielonej strefie, ograniczaj ruch administracyjny (VPN/jump host), wymuś TLS 1.2+/aktualne szyfry. (Wniosek operacyjny).
  5. Threat hunting poaktualizacyjny: sprawdź ślady potencjalnego nadużycia (nietypowe logowania adminów, modyfikacje konfiguracji, nowe eventy/zdarzenia Serv-U) w okresie przed wdrożeniem 15.5.3. (Wniosek operacyjny).
  6. Śledź komunikaty producenta/CISA: jeśli pojawią się sygnały o aktywnej eksploatacji, CISA doda wpisy do KEV – wtedy aktualizacja ma charakter pilny (emergency).

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

  • Wobec CVE-2024-28995 (path traversal, KEV): tegoroczne RCE różnią się wymaganiem PR=High (admin w produkcie), co podbija wpływ po przejęciu konta, ale zmniejsza ryzyko pre-auth. Z kolei CVE-2024-28995 był pre-auth read-only (odczyt plików), lecz z niższymi wymaganiami wstępnymi i został realnie eksploatowany.
  • Wobec wcześniejszych luk w SolarWinds (Orion/Web Help Desk/ARM): ekosystem SolarWinds historycznie przyciąga atakujących, a pojawienie się nowych RCE – nawet z PR=High – należy traktować priorytetowo w środowiskach o podwyższonych wymaganiach zgodności.

Podsumowanie / kluczowe wnioski

  • Trzy luki (CVE-2025-40547/48/49) w Serv-U umożliwiają RCE po stronie serwera, gdy atakujący ma uprawnienia admina Serv-U. Aktualizacja do 15.5.3 jest obecnie jedynym skutecznym remedium.
  • Historia wcześniejszych incydentów i wpisy w CISA KEV dotyczące SolarWinds sugerują, że opóźnianie poprawek znacząco zwiększa ryzyko.

Źródła / bibliografia

  • SecurityWeek: „SolarWinds Patches Three Critical Serv-U Vulnerabilities”, 20 listopada 2025. (SecurityWeek)
  • SolarWinds Trust Center – Advisory: CVE-2025-40547 (Serv-U Logic Abuse – RCE). (SolarWinds)
  • SolarWinds Trust Center – Advisory: CVE-2025-40548 (Serv-U Broken Access Control – RCE). (SolarWinds)
  • SolarWinds Trust Center – Advisory: CVE-2025-40549 (Serv-U Path Restriction Bypass – RCE). (SolarWinds)
  • SolarWinds Documentation – Serv-U 15.5.3 Release Notes (data wydania: 18.11.2025). (SolarWinds Documentation)

EdgeStepper: implant AitM przekierowujący DNS, który podszywa się pod aktualizacje oprogramowania (PlushDaemon)

Wprowadzenie do problemu / definicja luki

Badacze ESET opisali nowy implant sieciowy EdgeStepper, używany przez grupę APT PlushDaemon (powiązaną z Chinami) do ataków adversary-in-the-middle (AitM). Narzędzie działa na urządzeniach brzegowych (np. routerach) i przekierowuje cały ruch DNS na kontrolowany przez atakujących „węzeł przechwycenia”, który podmienia adresy serwerów aktualizacji popularnych aplikacji. W efekcie legalny mechanizm update’u pobiera złośliwe pierwsze etapy (LittleDaemon, DaemonicLogistics), a następnie właściwy backdoor SlowStepper. Informacje ujawniono 19 listopada 2025 r.

W skrócie

  • Wejście: kompromitacja urządzenia sieciowego ofiary (eksploatacja podatności lub słabe hasła), instalacja EdgeStepper.
  • Technika: przechwycenie i przekierowanie DNS (udp/53) do złośliwego węzła; selektywne odpowiadanie na domeny aktualizacji (np. Sogou Pinyin).
  • Łańcuch infekcji: LittleDaemon → DaemonicLogistics → SlowStepper (zbieranie informacji, eksfiltracja, rozbudowany „toolkit”).
  • Zasięg: cele w Chinach, Hongkongu, Tajwanie, Kambodży, Korei Płd., USA, Nowej Zelandii (co najmniej od 2018 r.).
  • Precedensy: PlushDaemon wcześniej zrealizował atak łańcucha dostaw na VPN IPany (2023). Podobną taktykę AitM DNS stosowały Blackwood/NSPX30 i Evasive Panda.

Kontekst / historia / powiązania

Przechwytywanie aktualizacji poprzez manipulację DNS to trend widoczny w wielu klastrach APT powiązanych z Chinami. ESET opisywał Blackwood/NSPX30 (AitM aktualizacji) oraz przypadki, w których Evasive Panda (StormBamboo) kompromitowała operatora ISP i zatruwała DNS na poziomie sieci, aby dostarczać backdoory do systemów Windows i macOS. Z kolei u PlushDaemon ten wektor stał się głównym mechanizmem dostępowym, uzupełnianym o exploity w serwerach www i kampanie supply-chain (IPany).

Analiza techniczna / szczegóły luki

Architektura EdgeStepper

  • Implant napisany w Go (oparty o framework GoFrame) jako ELF dla MIPS32 – targetem są typowe platformy routerowe/edge. Konfigurację odszyfrowuje z /etc/bioset.conf algorytmem AES-CBC z „stałym” kluczem/IV związanym z GoFrame (ciąg znaków „I Love Go Frame!”).
  • Przykładowa konfiguracja zawiera sekcję: [cheat] toPort = 1090 host = "ds20221202.dsc.wcsset[.]com" (w kodzie występuje też blok z test.dsc.wcsset[.]com, historycznie wskazujący na adres 47.242.198[.]250 – węzeł przechwycenia).

Mechanizm przekierowania DNS

  • Moduł Ruler wstawia reguły iptables przekierowujące cały UDP/53 → lokalny port (np. 1090), gdzie działa proxy DNS implant. Pakiety są następnie forwardowane do „malicious DNS node” wskazanego przez konfigurację.

Selektywna podmiana aktualizacji

  • „Złośliwy DNS” rozpoznaje domeny kanałów update (np. info.pinyin.sogou.com, ime.sogou.com, mobads.baidu.com) i zwraca adres węzła hijacking, który instruuje aplikację do pobrania DLL „popup_4.2.0.2246.dll” – to LittleDaemon.

Łańcuch ładunków

  • LittleDaemon: 32-bit PE (DLL/EXE), bez trwałości; komunikuje się z węzłem przechwycenia, pobiera DaemonicLogistics.
  • DaemonicLogistics: shell-code/position-independent, interpretuje kody odpowiedzi HTTP jako komendy (np. 200/207), pobiera pliki (file6.bdat, file2.bdat), a docelowo dostarcza SlowStepper.
  • SlowStepper: rozbudowany backdoor (C++ + moduły Python/Go, >30 komponentów), z C2 inicjalizowanym m.in. przez rekordy DNS TXT (7051.gsm.360safe[.]company), z szerokimi zdolnościami eksfiltracji (przeglądarki, komunikatory, multimedia).

Praktyczne konsekwencje / ryzyko

  • Omijanie kontroli endpointowych: atak odbywa się przed hostem – na urządzeniu brzegowym lub w ścieżce sieciowej. Kontrole EDR/AV mogą nie zadziałać przed pobraniem ładunku przez „legalny” proces aktualizatora.
  • Zaufanie do update’ów: kompromitacja kanału aktualizacji legalnych aplikacji (często popularnych, jak klawiatury czy pakiety biurowe) radykalnie podnosi współczynnik sukcesu infekcji i ułatwia lateral movement.
  • Trudna detekcja w DNS: EdgeStepper działa jak transparentny proxy DNS – z perspektywy hostów zapytania wyglądają zwyczajnie, tylko ścieżka odpowiedzi jest podmieniana.
  • Ryzyko sektorowe: według telemetryki ESET ofiary to m.in. uczelnie, przemysł elektroniczny i motoryzacyjny, oddziały firm w regionie APAC oraz pojedyncze podmioty w USA/NZ.

Rekomendacje operacyjne / co zrobić teraz

Higiena urządzeń brzegowych

  1. Aktualizacje firmware/routerów i wymuszenie MFA + silnych, unikalnych haseł do paneli admina; wyłącz zdalny dostęp administracyjny z Internetu (lub ogranicz go przez VPN/SSH z listy dozwolonych).
  2. Monitoring reguł netfilter/iptables: wykrywaj anomalie typu PREROUTING -p udp --dport 53 -j REDIRECT --to-port 1090 oraz nietypowe procesy nasłuchujące na udp/1090. (Dopasowane do artefaktów EdgeStepper).
  3. Kontrola konfiguracji DNS na brzegach: wymuszaj rezolwery autoryzowane/pinowane (np. DoT/DoH do organizacyjnego resolwera z certificate pinning na kliencie). Uwaga: jeśli implant przechwytuje port 53 na urządzeniu, DoH/DoT z hosta może ograniczyć skuteczność ataku, o ile nie jest breakowany na bramie.

Segmentacja i egress
4. Blokady egress DNS: zezwalaj wyłącznie na DNS z zaufanych resolverów (kontrolowanych przez SOC), drop dla ruchu DNS od hostów bezpośrednio do Internetu.
5. Listy wskaźników: monitoruj/blokuj domeny *.dsc.wcsset[.]com, IP 47.242.198[.]250 (historyczny hijacking node), ścieżki HTTP ime.sogou.com/update/*, oraz niestandardowe DLL np. popup_4.2.0.2246.dll. (Aktualizuj IOC wg najnowszych publikacji).

Kontrole hostowe
6. AppControl/Allow-list dla updaterów: egzekwuj TLS z weryfikacją certów/pinningiem i blokuj połączenia HTTP plaintext w procesach aktualizujących (częsty wektor w opisanym łańcuchu).
7. EDR/YARA: reguły na artefakty LittleDaemon/DaemonicLogistics/SlowStepper; heurystyki na anomalię korzystania z PerfWatson.exe/DLL sideloadingu (znane z kompromitacji IPany).

Detekcja w DNS/NetFlow
8. Anomalie DNS: niespójność odpowiedzi dla domen aktualizacji (częste NXDOMAIN/timeouty, zmiany TTL, brak spójności EDNS), niespodziewane TXT-lookup do *.360safe[.]company itd. (wątek SlowStepper).
9. Telemetryka brzegowa: porównuj sumaryczne QNAME/serwery autorytatywne z referencyjnym resolverem poza siecią (wykrywanie trojanizacji ścieżki).

Procedury
10. Threat hunting: przejrzyj logi od 2019 r. w sieciach o podwyższonym ryzyku (APAC/firmy z chińskojęzycznym łańcuchem dostaw).
11. SBOM/ketchain aktualizacji: wymuś podpisywanie i weryfikację aktualizacji, TLS-pinning oraz re-download fallback wyłącznie z hard-coded domen + cert pinning.

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

  • PlushDaemon / EdgeStepper – przechwycenie przez implant na urządzeniu brzegowym z przekierowaniem całego DNS; multi-stage (LittleDaemon → DaemonicLogistics → SlowStepper).
  • Blackwood / NSPX30 – także AitM aktualizacji, ale inna linia artefaktów (NSPX30) i odrębne TTP/C2; również ataki na popularne chińskie oprogramowanie.
  • Evasive Panda (StormBamboo) – kompromitacja ISP i DNS poisoning na poziomie operatora, trafianie zarówno Windows, jak i macOS; bliskie tematycznie, ale inna infrastruktura i grupa.

Podsumowanie / kluczowe wnioski

EdgeStepper to dojrzały implant AitM dla DNS, który przesuwa punkt przełamania z hosta na urządzenie brzegowe. Dzięki selektywnej podmianie odpowiedzi DNS dla domen aktualizacji atakujący przekształcają zaufany proces update’u w łańcuch infekcji kończący się bogatym funkcjonalnie backdoorem SlowStepper. Organizacje powinny traktować DNS i urządzenia brzegowe jako krytyczny wektor supply-chain, wdrażając monitoring reguł, pinning kanałów update’u, restrykcje egress DNS oraz hunting za IOC wskazanymi przez ESET.

Źródła / bibliografia

  1. The Hacker News – „EdgeStepper Implant Reroutes DNS Queries to Deploy Malware via Hijacked Software Updates”, 19 listopada 2025. (The Hacker News)
  2. ESET WeLiveSecurity – „PlushDaemon compromises network devices for adversary-in-the-middle attacks (EdgeStepper)”, 19 listopada 2025. (We Live Security)
  3. ESET WeLiveSecurity – „PlushDaemon compromises supply chain of Korean VPN service (SlowStepper)”, 22 stycznia 2025. (We Live Security)
  4. ESET WeLiveSecurity – „NSPX30: A sophisticated AitM-enabled implant… (Blackwood)”, 24 stycznia 2024. (We Live Security)
  5. Volexity – „StormBamboo compromises ISP to abuse insecure software update mechanisms”, 2 sierpnia 2024. (Volexity)

Amazon: Iran łączy cyberszpiegostwo z atakami kinetycznymi. Nowa kategoria zagrożeń – „cyber-enabled kinetic targeting”

Wprowadzenie do problemu / definicja luki

Amazon Threat Intelligence opisał trend, który nazywa „cyber-enabled kinetic targeting” – sytuacje, w których operacje cybernetyczne (rozpoznanie, przejęcia infrastruktury, dostęp do strumieni wideo) bezpośrednio umożliwiają lub ulepszają fizyczne uderzenia (np. ostrzał rakietowy). W dwóch studiach przypadków Amazon łączy działania grup przypisywanych Iranowi z późniejszymi atakami kinetycznymi na cele morskie i miejskie. Firma argumentuje, że granica między cyber a fizycznym polem walki zaciera się i wymaga zmiany modeli zagrożeń po stronie obrońców.

W skrócie

  • Imperial Kitten (IRGC/Tortoiseshell/TA456): od 2021 r. kompromitacja systemów AIS i CCTV na statkach; w styczniu 2024 aktor wyszukiwał dane AIS konkretnej jednostki, która 1 lutego 2024 r. została ostrzelana przez Huti na Morzu Czerwonym (strzał nieskuteczny). Korelacja czasowa wskazuje na wykorzystanie cyber-rozpoznania do planowania uderzenia.
  • MuddyWater (MOIS/Rana): w maju 2025 przygotowano infrastrukturę CNO; 17 czerwca 2025 r. użyto jej do dostępu do przejętego serwera z na żywo strumieniami CCTV z Jerozolimy; 23 czerwca 2025 r. Iran przeprowadził zmasowany atak rakietowy, a władze izraelskie ostrzegały przed wykorzystaniem zhakowanych kamer do korekty ognia w locie.
  • Amazon publikuje przykładowe IOC (adresy IP) i nawołuje do rozszerzenia modelowania zagrożeń o scenariusze, w których pozornie „nieistotne” systemy (np. kamery, AIS) służą jako sensory dla uderzeń fizycznych.

Kontekst / historia / powiązania

W 2025 r. amerykańskie agencje (CISA, FBI, NSA, DC3) ostrzegły, że aktorzy związani z Iranem regularnie atakują słabo zabezpieczone sieci i urządzenia IoT/OT, a firmy z łańcuchami powiązań z izraelską obronnością są w podwyższonym ryzyku. Podkreślono nadużywanie domyślnych haseł, podatności „KEV” oraz wzrost defacementów i DDoS. Ten obraz wpisuje się w przypadki opisane przez Amazon – cyberoperacje nie kończą się na kradzieży danych, lecz zasilają cele taktyczne.

Relacje branżowe (SecurityWeek, CyberScoop, CSO) potwierdzają szczegóły osi czasu i atrybucje do Imperial Kitten i MuddyWater, a także nacisk Amazona na zmianę paradygmatu obrony.

Analiza techniczna / szczegóły luki

Łańcuch ataku (przykładowy):

  1. Przygotowanie infrastruktury – aktorzy zestawiają serwery C2/VPN i warstwę anonimizacji (infrastruktura „actor-controlled”).
  2. Dostęp do systemów „sensorowych” – przejęcie systemów AIS, serwerów z CCTV (często z domyślnymi hasłami lub słabymi konfiguracjami). Celem nie musi być sabotaż, lecz pozyskanie strumienia danych w czasie rzeczywistym.
  3. Fuzja danych i korekcja ognia – wykorzystanie wideo/GNSS/AIS do śledzenia obiektu i prowadzenia ognia z korektą (ang. in-flight retargeting), co Amazon nazywa „cyber-enabled kinetic targeting”.
  4. IOC i ślady – Amazon publikuje m.in. 18[.]219.14.54 (MuddyWater C2) oraz kilka IP proxy Imperial Kitten (85[.]239.63.179; 37[.]120.233.84; 95[.]179.207.105) – użyteczność: korelacja logów, blokady czasowe, hunting.

Różnica względem „cyber-kinetic operations”: tu cyber nie niszczy sprzętu bezpośrednio (jak w Stuxnecie), lecz podnosi precyzję uderzeń kinetycznych dzięki rozpoznaniu i telemetrii.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórne dla podmiotów cywilnych: kamery biurowe, portowe, miejskie i przemysłowe mogą stać się „czujnikami” przeciwnika, nawet jeśli organizacja nie jest bezpośrednim celem wojskowym.
  • Sektor morski i logistyczny: kompromitacja AIS/CCTV na statkach ułatwia namierzanie jednostek. Łańcuch dostaw staje się podatny na ataki punktowe.
  • Eskalacja międzydomenowa: incydenty cyber mogą generować skutki fizyczne, podnosząc wymagania dla zarządzania ryzykiem, zgodności i ubezpieczeń. (Wnioski na podstawie raportów branżowych i zaleceń rządowych).

Rekomendacje operacyjne / co zrobić teraz

Higiena i segmentacja systemów „sensorowych” (CCTV, NVR, AIS, VMS):

  • Odseparuj je sieciowo (VLAN/VRF), zablokuj dostęp z Internetu, egzekwuj MFA do wszystkich zdalnych paneli (RDP/VNC/SSH/WebUI).
  • Wymuś zmianę domyślnych haseł, RBAC i zasady deny-by-default dla dostępu zdalnego.
  • Szybko łatataj systemy wystawione (sprawdź wpisy z katalogu CISA KEV).

Monitoring i threat hunting:

  • Przeskanuj logi pod kątem IOC z publikacji Amazona oraz własnych wskaźników nietypowego dostępu do strumieni RTSP/HTTP z kamer. (np. IP: 18[.]219.14.54; 85[.]239.63.179; 37[.]120.233.84; 95[.]179.207.105).
  • Ustaw detekcje na anomalie ruchu wideo (długie sesje, zewnętrzne ASN/VPN), z osobnym priorytetem w okresach napięć geopolitycznych. (Wnioski z AWS i IC3/CISA).

Modelowanie zagrożeń i procedury:

  • Włącz do threat modeling scenariusz: „nasze kamery/sensory jako cel rozpoznawczy dla obcego ataku fizycznego” – oraz konsekwencje odłączenia kamer w trybie alarmowym (playbook).
  • Ćwicz table-top z udziałem zespołów bezpieczeństwa fizycznego (GSOC) i SOC: decyzja o czasowym wyłączeniu publikowanych strumieni i mechanizmy degradacji usług (fail-secure). (Wnioski na podstawie rekomendacji Amazona).
  • Zintensyfikuj wymianę TI z partnerami/przemysłem – Amazon wskazuje na wagę korelacji międzydomenowej.

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

  • Cyber-enabled kinetic targeting vs. cyber-kinetic operations: w pierwszym przypadku cyber to sensor i wsparcie celowania; w drugim – cyber sam powoduje skutek fizyczny (sabotuje/niszczy).
  • OT/ICS: CISA i partnerzy zwracają uwagę, że aktorzy irańscy chętnie atakują urządzenia OT (PLCs/HMIs) przez domyślne hasła i wystawione interfejsy – to inna ścieżka do skutków fizycznych (np. zakłócanie pracy infrastruktury).

Podsumowanie / kluczowe wnioski

  • Amazon dostarczył mocne, czasowo skorelowane przykłady łączenia cyber-rozpoznania z uderzeniami fizycznymi i zaproponował precyzyjny termin dla tego zjawiska.
  • Dla obrońców to sygnał, by traktować CCTV/AIS/IoT jako cele o wysokiej wartości wywiadowczej, nawet poza klasycznym obszarem OT.
  • Najważniejsze działania: segmentacja, uszczelnienie zdalnego dostępu, wymuszenie MFA i haseł, hunting po IOC, procedury odłączania kamer, ćwiczenia GSOC+SOC.

Źródła / bibliografia

  1. AWS Security Blog: New Amazon Threat Intelligence findings: Nation-state actors bridging cyber and kinetic warfare (19 XI 2025). (Amazon Web Services, Inc.)
  2. SecurityWeek: Amazon Details Iran’s Cyber-Enabled Kinetic Attacks… (19 XI 2025). (SecurityWeek)
  3. CyberScoop: Amazon warns of global rise in specialized cyber-enabled kinetic targeting (19 XI 2025). (CyberScoop)
  4. CSO Online: Iranian APT hacks helped direct missile strikes in Israel and the Red Sea (19 XI 2025). (csoonline.com)
  5. IC3/CISA/NSA/DC3 (TLP:CLEAR): Iranian Cyber Actors May Target Vulnerable US Networks and Entities of Interest (30 VI 2025). (ic3.gov)

Dziesiątki tysięcy routerów ASUS przejętych w kampanii „WrtHug”. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Nowo ujawniona kampania Operation WrtHug kompromituje dziesiątki tysięcy domowych i SOHO routerów ASUS WRT, przede wszystkim urządzenia EoL (poza wsparciem). Badacze ze STRIKE (SecurityScorecard) szacują, że ponad 50 tys. unikatowych adresów IP należących do zainfekowanych routerów było widocznych w ciągu ostatnich 6 miesięcy. Wspólnym wskaźnikiem infekcji jest identyczny, samopodpisany certyfikat TLS na usłudze AiCloud z nietypowym 100-letnim terminem ważności od kwietnia 2022 r.. Kampania łączy się taktykami i zasięgiem z operacjami klasy ORB (Operational Relay Box), które służą do skrytego pośredniczenia w ruchu na potrzeby cyber-szpiegostwa.

W skrócie

  • Skala: ≥50 000 zainfekowanych routerów ASUS, głównie w Tajwanie i Azji Płd-Wsch., ale również w USA, Rosji i Europie.
  • Wektor: łańcuch n-day na AiCloud + zestaw błędów OS command injection i auth bypass w starszych firmware’ach ASUS WRT.
  • IoC: wspólny self-signed cert (AiCloud) z ważnością 100 lat.
  • Powiązania: zbieżność TTP z wcześniejszą kampanią AyySSHush na routery ASUS (GREYNOISE).
  • Kluczowe CVE: CVE-2023-41345/6/7/8, CVE-2023-39780, CVE-2024-12912, CVE-2025-2492 (AiCloud).

Kontekst / historia / powiązania

W maju 2025 r. GreyNoise opisał cichą kampanię AyySSHush: trwałe tylne wejście w tysiącach routerów ASUS, z wykorzystaniem CVE-2023-39780, modyfikacji konfiguracji SSH oraz przechowywania artefaktów w NVRAM (przetrwanie restartów i aktualizacji). WrtHug dzieli część TTP (wykorzystanie tych samych rodzin błędów i celów), ale STRIKE notuje zaledwie 7 hostów z nakładającą się infekcją, więc traktuje WrtHug jako oddzielną kampanię – potencjalnie tego samego lub skoordynowanych aktorów.

Analiza techniczna / szczegóły luki

Łańcuch ataku w WrtHug opiera się na publicznie znanych (n-day) błędach w ASUS WRT oraz podatnościach AiCloud:

  • OS command injection:
    • CVE-2023-41345 / 41346 / 41347 / 41348 – rodzina błędów powiązana z mechanizmami tokenowymi oraz „apply” w panelu, w praktyce skorelowana z CVE-2023-39780 (RT-AX55; wstrzyknięcie komend po uwierzytelnieniu).
  • AiCloud (arbitrary command / auth bypass):
    • CVE-2024-12912 – błąd w AiCloud pozwalający na wykonanie poleceń (CVSS 7.2, NVD).
    • CVE-2025-2492improper authentication control w AiCloud (CVSS 9.2); możliwe wywołanie funkcji bez autoryzacji przygotowanym żądaniem.

Artefakt/kondensator IoC: na zainfekowanych urządzeniach usługa AiCloud prezentuje ten sam certyfikat TLS, samopodpisany, z okresem ważności 100 lat (od 04.2022). To najprostszy punkt zaczepienia dla huntów i detekcji.

Modele na celowniku: raporty wymieniają m.in. 4G-AC55U/860U, DSL-AC68U, GT-AC5300, GT-AX11000, RT-AC1200HP/1300G+/1300UHP i inne starsze/EoL wersje. (Lista może nie być kompletna; kluczowe jest sprawdzenie statusu wsparcia danego modelu).

Praktyczne konsekwencje / ryzyko

  • Skryte proxy/relay (ORB): urządzenia stają się węzłami ukrywającymi ruch na potrzeby eksfiltracji i rozpoznania – mniejsze ryzyko DDoS, większy nacisk na szpiegostwo i pivoting.
  • Trwałość: atak często przetrwa aktualizacje firmware’u (konfiguracja w NVRAM, zmiany SSH), więc „patch ≠ remediacja”.
  • Ekspozycja MŚP i domów: domowe/SoHo routery bywają pomijane w procesach hardeningu, a AiCloud bywa wystawiony do Internetu bez MFA i segmentacji.

Rekomendacje operacyjne / co zrobić teraz

  1. Szybki hunting IoC
    • Sprawdź, czy AiCloud prezentuje nietypowy, samopodpisany cert z datą ważności do 2122 r.. Jeśli tak – traktuj jako wysoki wskaźnik kompromitacji.
  2. Weryfikacja AiCloud i dostępu zdalnego
    • Jeżeli urządzenie jest EoL lub brak łatki – wyłącz AiCloud i każdy zdalny dostęp z Internetu (HTTP/HTTPS, SSH, WAN admin).
  3. Remediacja trwałości
    • Jeżeli podejrzewasz kompromitację: pełny factory reset, następnie ręczna, czysta konfiguracja (nie przywracaj kopii!), sprawdź authorized_keys, porty SSH (GREYNOISE raportował niestandardowy TCP/53282), usuń obce klucze.
  4. Aktualizacje firmware’u
    • Zastosuj najnowsze firmware’y naprawiające m.in. CVE-2025-2492 (AiCloud) oraz luki z 2023 r. W przypadku EoL – wymiana urządzenia.
  5. Hardening
    • Zmień hasła admina, włącz MFA (jeśli wspierane), ogranicz panel do LAN/VPN, wyłącz UPnP, stosuj ACL/geo-IP na brzegu, segmentuj sieć (IoT/Wi-Fi gości oddzielnie). (Dobre praktyki na bazie ogólnych zaleceń i obserwacji z raportów).
  6. Monitoring i bloki
    • Blokuj znane IP/porty z raportów (np. 53282/TCP dla SSH), loguj odwołania do AiCloud, ustaw alerty na zmiany certyfikatów i włączenie SSH.

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

  • WrtHug vs. AyySSHush: oba celują w ASUS WRT i łączą CVE-2023-39780, ale WrtHug ma wyraźny IoC TLS (100-letni cert) na AiCloud i inną dystrybucję geograficzną; AyySSHush akcentował trwałość przez NVRAM/SSH. Mało hostów z podwójną infekcją → różne klastry/etapy jednego lub skoordynowanych aktorów.
  • Botnet vs. ORB: klasyczne botnety = hałaśliwe DDoS/kripto-koparki; ORB = ciche szlaki ruchu dla operacji APT (maskowanie źródła, pivot). WrtHug ma profil ORB-like.

Podsumowanie / kluczowe wnioski

  • Słabe ogniwo #1: EoL routery z włączonym AiCloud i zdalnym dostępem.
  • Najprostsza detekcja: sprawdzenie certyfikatu TLS AiCloud (100 lat).
  • Remediacja ≠ patch: przy podejrzeniu infekcji reset do fabrycznych + ręczna rekonfiguracja, dopiero potem aktualizacja; dla EoL – wymiana.
  • Zagrożenie strategiczne: rosnący trend ORB na urządzeniach brzegowych – cichsze, długotrwałe kampanie.

Źródła / bibliografia

  1. SecurityScorecard STRIKE – Operation WrtHug, The Global Espionage Campaign Hiding in Your Home Router (19.11.2025). (SecurityScorecard)
  2. The Register – Tens of thousands more ASUS routers pwned by suspected, evolving China operation (19.11.2025). (The Register)
  3. GreyNoise – Stealthy Backdoor Campaign Affecting Thousands of ASUS Routers (28.05.2025). (greynoise.io)
  4. NVD – CVE-2023-39780 (ASUS RT-AX55 OS command injection). (nvd.nist.gov)
  5. NVD – CVE-2025-2492 (ASUS AiCloud improper authentication control). (nvd.nist.gov)

CVE-2019-3396 — Atlassian Confluence “Widget Connector” RCE

TL;DR

W Atlassian Confluence (Server/Data Center) luka CVE‑2019‑3396 w makrze Widget Connector pozwala zdalnemu, nieuwierzytelnionemu napastnikowi na RCE poprzez Server‑Side Template Injection (Velocity) i path traversal. W praktyce ataki często uderzają w endpoint /rest/tinymce/1/macro/preview i prowadzą do dropu web‑shella i uruchamiania powłoki systemowej przez proces Javy/Tomcata. Mitygacja: natychmiastowy upgrade do wersji naprawczych (≥ 6.6.12, 6.12.3, 6.13.3, 6.14.2 lub nowsze), ewentualnie tymczasowe wyłączenie wtyczki Widget Connector; Confluence Cloud nie jest podatny. Mapowanie do ATT&CK: przede wszystkim T1190, a dalej typowo T1059 (Interpreter poleceń) i T1505.003 (Web shell).


Krótka definicja techniczna

CVE‑2019‑3396 to błąd w komponencie Widget Connector Confluence powodujący server‑side template injection (Velocity Template), umożliwiający path traversal i ostatecznie zdalne wykonanie kodu (RCE) bez uwierzytelnienia. Błąd dotyczy wersji Server/Data Center poniżej wydań naprawczych; Confluence Cloud nie jest narażony.


Gdzie występuje / przykłady platform

  • Linux/Windows: Confluence Server/Data Center hostowany na Tomcat/Java (instalacje on‑prem/VM/bare‑metal).
  • Reverse proxy/WAF: NGINX/Apache/ALB/WAF przed Confluence — logi tych warstw są kluczowe do detekcji. [Źródła ogólne — patrz sekcja 6/7]
  • Kubernetes/K8s/ESXi: Confluence wdrożone w kontenerze/na VM (artefakty w logach kontenerów i audycie K8s). [Źródła ogólne — patrz sekcja 6/12]
  • Chmury (AWS/Azure/GCP): Same API chmurowe nie są wektorem tej luki, ale logi ALB/WAF/Front Door pomagają identyfikować próby eksploatacji. [Źródła ogólne — patrz sekcja 7]

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Błąd znajduje się w makrze Widget Connector odpowiedzialnym za osadzanie treści (np. wideo) na stronach Confluence. Przez niewłaściwą walidację parametrów napastnik może wstrzyknąć szablon Velocity i/lub skorzystać z path traversal do wczytania niezamierzonych plików szablonów, co kończy się wykonaniem arbitralnego kodu w kontekście procesu Confluence (Java/Tomcat). Typowy wektor żądań obserwowany był na endpointzie /rest/tinymce/1/macro/preview (metoda POST) z nietypowymi polami (np. _template) — legalne użycie nie powinno ich zawierać. Po skutecznej eksploatacji napastnicy często zrzucają web‑shelle i uruchamiają powłokę systemową, a następnie pobierają narzędzia (T1105) i przechodzą do ruchów bocznych. Zależnie od środowiska obserwuje się kampanie z ransomware (np. GandCrab) i kryptominery po udanym RCE, a także wykorzystanie przez grupy APT (np. APT41).

Wersje i statusy: Atlassian wydał łatki 20 marca 2019 r. (m.in. 6.6.12, 6.12.3, 6.13.3, 6.14.2). Confluence Cloud nie jest podatny. Jako obejście do czasu aktualizacji zalecano wyłączenie Widget Connector (oraz WebDAV dla innej luki CVE‑2019‑3395).


Artefakty i logi

ŹródłoCo szukaćPrzykładowe pola / EIDUwaga
HTTP reverse proxy / web server (NGINX/Apache/ALB/WAF)POST do */rest/tinymce/1/macro/preview*; obecność "_template" lub wzorca traversal ../, nagły wzrost 4xx/5xxcs-method, cs-uri-stem, request, http.request.body.content, statusW wielu raportach ten endpoint pojawiał się w eksploatacji.
Confluence/TomcatW atlassian-confluence.log/catalina.out: błędy Velocity, stacktrace’y, nietypowe wyjątki w momencie żądańTekst surowyKoreluj z czasem żądań HTTP.
WindowsProcesy potomne od java.exe/usługi Confluence: cmd.exe, powershell.exe, narzędzia siecioweSecurity 4688, Sysmon 1/3/11Spawn powłoki spod Javy jest anomalią dla Confluence.
Linuxjava/bin/bash//bin/sh/curl/wget/nc; nowo utworzone pliki w katalogu aplikacji/WEB-INFauditd: type=EXECVE, Sysmon‑for‑Linux EID 1/3/11Sprawdzaj użytkownika usługi (np. confluence).
K8s audit (jeśli Confluence w kontenerze)verb: create/get na pods/exec; podejrzane kubectl exec do podów z Confluencekubernetes.audit.verb, objectRef.subresource=="exec"Polityka audytu K8s rejestruje pods/exec (GET/CREATE).
AWS WAF/ALB (CloudWatch Logs)Wzorce żądań jak wyżejrequestUri, httpRequest.uriCloudTrail tu nie pomoże — to ruch L7, nie API.
M365[nie dotyczy]Brak bezpośrednich artefaktów.
CISA/NSA/CTIWzmianki o kampaniach, IOCWskazywane jako powszechnie eksploatowane.

Detekcja (praktyczne reguły)

Sigma — próba eksploatacji w logach HTTP (web/proxy)

title: Confluence CVE-2019-3396 Macro Preview Exploit Attempt
id: 1e2a2c9a-2b3d-4c4d-9d66-3396cve-http
status: experimental
description: Wykrywa podejrzane POST do /rest/tinymce/1/macro/preview z parametrem _template i traversal.
logsource:
  category: webserver
detection:
  sel_path:
    cs-uri-stem|contains: "/rest/tinymce/1/macro/preview"
  sel_method:
    cs-method: POST
  sel_body_a:
    request|contains: "_template"
  sel_body_b:
    request|contains:
      - "../"
      - "web.xml"
      - ".vm"
  condition: sel_path and sel_method and sel_body_a and sel_body_b
fields:
  - src_ip
  - dest_ip
  - user_agent
  - cs-uri-stem
  - request
falsepositives:
  - Bardzo mało prawdopodobne (parametr _template nie jest używany w legalnym ruchu).
level: high
tags:
  - attack.T1190

(wzorzec oparty o publiczne opisy wektora żądań i szablonu skanera; dopasowania do _template i traversal minimalizują FP).

Sigma — potomne procesy spod Confluence (Windows+Linux)

title: Confluence Spawns Shell/LOLBins (Post-Exploitation)
id: 84a3b92d-7f6f-42a1-bdb6-confluence-child-proc
status: experimental
logsource:
  category: process_creation
detection:
  parent_java:
    ParentImage|endswith:
      - '\java.exe'
      - '\tomcat*.exe'
    ParentCommandLine|contains:
      - 'atlassian-confluence'
  child_shells:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '/bash'
      - '/sh'
      - '/curl'
      - '/wget'
      - '/nc'
  condition: parent_java and child_shells
level: high
tags:
  - attack.T1059
  - attack.T1505.003
fields: [Image, ParentImage, CommandLine, ParentCommandLine, User, Hostname]

Splunk (SPL) — warstwa HTTP

(index=proxy OR index=web OR sourcetype=aws:alb:accesslogs OR sourcetype=nginx OR sourcetype=apache)
"POST" "/rest/tinymce/1/macro/preview"
| search _raw="*_template*" (_raw="*../*" OR _raw="*web.xml*" OR _raw="*.vm*")
| stats count by src_ip, uri_path, user_agent, status
| where count > 1

Splunk (SPL) — potomne procesy spod Javy/Tomcata

index=sysmon (EventCode=1 OR EventCode=4688)
(ParentImage="*\\java.exe" OR ParentCommandLine="*atlassian-confluence*")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*/bash" OR Image="*/sh" OR Image="*/curl" OR Image="*/wget" OR Image="*/nc")
| table _time host User ParentImage Image CommandLine ParentCommandLine

KQL — Microsoft Defender for Endpoint (procesy)

DeviceProcessEvents
| where (InitiatingProcessFileName =~ "java.exe" or InitiatingProcessCommandLine has "atlassian-confluence")
| where FileName in~ ("cmd.exe","powershell.exe","bash","sh","curl","wget","nc")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName

KQL — Azure Application Gateway WAF / Front Door (HTTP)

AzureDiagnostics
| where Category in ("ApplicationGatewayFirewallLog","FrontDoorAccessLog")
| where requestUri_s has "/rest/tinymce/1/macro/preview"
| where requestUri_s has "_template" and (requestUri_s has "../" or requestUri_s has "web.xml" or requestUri_s has ".vm")
| project TimeGenerated, clientIp_s, requestUri_s, httpStatus_d, userAgent_s

AWS — CloudWatch Logs Insights (ALB/WAF; CloudTrail nie dotyczy tej luki)

fields @timestamp, @message
| filter @message like /POST \\/rest\\/tinymce\\/1\\/macro\\/preview/
| filter @message like /_template/ and (@message like /\\.\\.\// or @message like /web\\.xml/ or @message like /\\.vm/)
| sort @timestamp desc

Elastic / EQL — procesy

process where
  process.parent.executable : ("*java*", "*tomcat*")
  and process.name : ("cmd.exe","powershell.exe","bash","sh","curl","wget","nc")

Heurystyki / korelacje (co łączyć)

  • Korelacja czasowa: (1) POST do …/macro/preview z _template±30 s → (2) java/Tomcat spawnuje powłokę/LOLBIN → (3) wywołania sieciowe z hosta Confluence (curl/wget/nc).
  • Ścieżki i rozszerzenia: nowo utworzone pliki .jsp, .jspx, .vm, nietypowe w katalogach Confluence/WEB-INF/attachments.
  • Anomalie HTTP: wzrost 4xx/5xx dla /rest/tinymce/1/macro/preview, nietypowe UA, brak CSRF‑tokenów, nienaturalna objętość POST.
  • K8s: zdarzenia pods/exec na podzie z Confluence w oknie ±5 min od wzorca HTTP.

False positives / tuning

  • Legalne podglądy makr nie używają parametru _template; warunek obecności _template + ../ znacząco ogranicza FP.
  • Zdarza się, że administracja/backup tworzy procesy potomne (skrypty konserwacyjne) — whitelista po ścieżkach, podpisie, hashach i planach crona.
  • Ustal baseline dla ruchu do endpointu /rest/tinymce/1/macro/preview (kto edytuje strony, kiedy), a alertuj odchylone UA/IP/ASN.

Playbook reagowania (kroki + komendy)

Triage & izolacja

  1. Odłącz Confluence od Internetu/DMZ (lub włącz tryb tylko‑do‑odczytu, jeśli to jedyna wiedza bazowa).
  2. Zbierz logi: reverse proxy, atlassian-confluence.log, catalina.out, systemowe, WAF/ALB.

Szybkie sprawdzenia na hoście (bezpieczne polecenia administracyjne):

  • Linux # proces + drzewo ps -ef | egrep 'confluence|tomcat|java' pstree -ap | egrep 'java|tomcat' # ostatnie podejrzane pliki w instalacji i HOME Confluence find /opt/atlassian /var/atlassian -type f -mmin -60 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort # ślady ruchu wychodzącego z procesu java sudo lsof -nP -p "$(pgrep -f 'atlassian|confluence|tomcat|java' | tr '\n' ',')" | egrep 'TCP|UDP' # grep wzorca endpointu w logach grep -R "/rest/tinymce/1/macro/preview" /opt/atlassian/confluence/logs /var/log/nginx 2>/dev/null
  • Windows (PowerShell jako Administrator) Get-Process java,Tomcat* -IncludeUserName Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object { $_.Id -eq 1 -and $_.Message -match "java.exe" -and $_.Message -match "(cmd.exe|powershell.exe)" } | Select-Object TimeCreated, Id, Message Get-ChildItem "C:\Program Files\Atlassian\Confluence\" -Recurse | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) }

Eradykacja i przywracanie

  • Aktualizacja Confluence do wersji naprawczych; jeżeli to niemożliwe, wyłącz plugin Widget Connector jako obejście (tymczasowe).
  • Przeskanuj pod kątem web‑shelli, skryptów .jsp/.jspx/.vm, sprawdź sumy kontrolne binariów.
  • Rotacja haseł i sekretów używanych na serwerze aplikacyjnym, w tym integracji (LDAP/DB).
  • Ocena lateral movement (kontrolery domeny, serwery plików, jump‑hosty).

Przykłady z kampanii / case studies

  • Ransomware GandCrab — obserwowano drop ransomware po eksploatacji CVE‑2019‑3396.
  • Kryptominery z rootkitem — Trend Micro opisało łańcuch: CVE‑2019‑3396 → kryptominer + rootkit.
  • Wykorzystanie przez aktorów APT — APT41 wymieniany w kontekście tego CVE i techniki T1190.
  • Ujęcie rządowe — CISA/NSA klasyfikowały CVE‑2019‑3396 jako powszechnie eksploatowaną lukę; zalecenia wykrywania web‑shelli.

Lab (bezpieczne testy) — przykładowe komendy

Cel: Walidacja reguł detekcyjnych bez atakowania podatnych systemów.

  1. Test pipeline’u logów HTTP
    • Na serwerze testowym (np. lokalny NGINX, nie Confluence) wygeneruj sztuczne wpisy zawierające wzorzec: logger 'POST /rest/tinymce/1/macro/preview HTTP/1.1 ... {"_template":"../web.xml"}'
    • Upewnij się, że Twoje źródło logów (Filebeat/Fluentd/Splunk UF) przesyła to do SIEM.
    • Sprawdź, czy reguła Sigma/Splunk/KQL podnosi alert (FP=0).
  2. Test korelacji hostowej
    • Na hoście testowym uruchom „fałszywy” łańcuch procesów: # symulacja: java (rodzic) -> bash (dziecko) (sleep 5; /bin/bash -c 'echo test') & (lub uruchom minimalny proces Java, który spawnuje bash, tylko w środowisku labowym; celem jest sprawdzenie, czy korelacja Parent=java → Child=shell działa).
    • Zweryfikuj, że reguła procesowa łapie zdarzenie.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software (regularne patchowanie aplikacji webowych).
  • M1048 — Application Isolation and Sandboxing (izolacja procesów serwera www/aplikacji).
  • M1037 — Filter Network Traffic / M1030 — Network Segmentation (DMZ dla serwerów publicznych, WAF).
  • M1016 — Vulnerability Scanning (ciągłe skanowanie i zarządzanie podatnościami).

Powiązane techniki ATT&CK:

  • T1190 — Exploit Public‑Facing Application (wektor wejściowy dla CVE‑2019‑3396).
  • T1059.003/.004 — Command & Scripting Interpreter (Windows/Unix Shell) — powłoka po RCE.
  • T1505.003 — Web Shell — utrwalenie i sterowanie przez web‑shell.
  • T1105 — Ingress Tool Transfer — pobieranie narzędzi po udanym RCE.

Źródła / dalsza literatura


Checklisty dla SOC / CISO

SOC (operacyjne)

  • Alerty na POST do …/macro/preview + _template + ../ (HTTP).
  • Korelacja: HTTP → java/tomcat spawnuje cmd/bash w ≤60 s.
  • Polowanie na web‑shelle (*.jsp, *.jspx, *.vm) w katalogach Confluence/WEB-INF.
  • Monitoring ruchu wychodzącego z hosta Confluence (curl/wget/nc/certutil).
  • K8s: alerty na pods/exec do podów z Confluence.

CISO / właściciel usługi

  • Patch: utrzymuj Confluence na wersji ≥ 6.6.12/6.12.3/6.13.3/6.14.2/6.15.x+.
  • WAF/segregacja: DMZ, WAF reguły dla macro/preview, rate‑limit.
  • Zarządzanie podatnościami: regularne skany, SLA na krytyczne poprawki.
  • Hardening: uruchamiaj Confluence z kontem o najmniejszych uprawnieniach, bez powłoki logowania.
  • IR readiness: gotowe playbooki i kopie zapasowe, rotacja sekretów po incydencie.

CVE-2015-3113 — Adobe Flash Player RCE

TL;DR

Krytyczna luka w Adobe Flash Player (CVE‑2015‑3113) umożliwiała zdalne wykonanie kodu poprzez przepełnienie bufora na stercie, m.in. po wejściu na złośliwą stronę lub kliknięciu odsyłacza w kampanii phishingowej. Zero‑day wykorzystywany był w operacji Clandestine Wolf (APT3), z łańcuchem: e‑mail → profilowanie JS → załadowanie pliku SWF/FLV → ROP/DEP/ASLR bypass → zrzut backdoora (SHOTPUT). Detekcja: obserwuj pobrania .swf, procesy/załadowane moduły Flash oraz nietypowe dzieci procesów Flash (cmd/powershell/wscript). Ponieważ Flash jest EOL (12.2020), każde użycie Flash w 2025 r. jest co najmniej podejrzane.


Krótka definicja techniczna

CVE‑2015‑3113 to luka typu heap‑based buffer overflow w Adobe Flash Player (przed 13.0.0.296; 14.x–18.x < 18.0.0.194 dla Windows/OS X; Linux < 11.2.202.468), pozwalająca zdalnie wykonać kod przy przetwarzaniu specjalnie spreparowanych treści Flash; w czerwcu 2015 była aktywnie wykorzystywana na wolności.


Gdzie występuje / przykłady platform

  • Endpointy: Windows (IE/Edge Legacy/Chrome/Firefox), macOS (Safari/Firefox/Chrome), Linux (Firefox/Chromium – PPAPI/NPAPI).
  • Scenariusze ataku: phishing z linkiem do serwisu z exploitem, drive‑by po wejściu na zainfekowaną stronę; znane cele zawierały m.in. Windows 7 (IE) i Firefox na XP.
  • Stan dzisiaj: Flash Player zakończył życie 31.12.2020 (blokada uruchomienia od 12.01.2021) — użycie w sieci produkcyjnej to incydent ryzyka.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Kampania Operation Clandestine Wolf przypisywana APT3 wykorzystywała e‑maile z odsyłaczami do przejętych witryn. Po kliknięciu ofiara była przekierowywana do skryptów profilujących (JS), które sprawdzały wersje przeglądarki/wtyczek. Następnie serwer dostarczał parę plików SWF + FLV wykorzystujących CVE‑2015‑3113. Exploit uzyskiwał arbitralny zapis/odczyt, wykonywał łańcuch ROP omijający DEP/ASLR, a finalnie odpalał shellcode i zrzucał backdoora SHOTPUT. Efekt: zdalne RCE i trwała kontrola hosta.

Dlaczego skuteczna?
(1) popularność Flash w 2015, (2) atak drive‑by nie wymagał pobierania plików przez użytkownika, (3) łańcuch exploitów obchodził mechanizmy łagodzące (DEP/ASLR), (4) szybka adopcja w ekosystemie exploit kitów (np. Magnitude).


Artefakty i logi

WarstwaArtefakt / źródłoWskaźniki / polaUwagi
Windows (Sysmon)EID 1 Process CreateImage/ParentImage: FlashPlayer.exe, FlashUtil*.exe, FlashPlayerPlugin*.exe; dzieci: cmd.exe, powershell.exe, wscript.exe, rundll32.exe, regsvr32.exeNietypowe dziecko procesu Flash = silny sygnał RCE. Nazwy procesów potwierdza Adobe Flash Player Admin Guide.
Windows (Sysmon)EID 7 Image LoadedImageLoaded = \pepflashplayer.dll (Chrome/Chromium)Obserwuj załadowanie w procesach przeglądarki.
Windows (Application)EID 1000 Application ErrorAwaria modułów Flash/pepflashNagłe crashe Flash niedługo przed nietypowym procesem‑dzieckiem.
Proxy/NGFW/DNSDostęp HTTP/S do *.swf, MIME application/x-shockwave-flashurl, mime, user_agent, referrerKoreluj z kliknięciami z e‑maila (M365).
M365 DefenderEmailUrlInfo, UrlClickEventsUrl, UrlDomain, kliknięcia Safe LinksŁącz URL .swf z hostami, które uruchomiły procesy Flash.
MITRE ATT&CK (kontekst)APT3 + SHOTPUTProfilowanie, dostarczenie backdooraDo korelacji z TTP grupy.
AWS (opcjonalnie)CloudTrail Lake (S3 Data Events)GetObject na kluczach %.swfWymaga włączonych data events.
CDNCloudFront Access Logs / Athenacs-uri-stem like '%.swf', sc-content-typePrzy hostowaniu/pośrednictwie treści.

Detekcja (praktyczne reguły)

Sigma (Windows / Sysmon – anomalie dzieci procesów Flash)

title: Flash Plugin Spawns Suspicious Child (CVE-2015-3113 Context)
id: 5a8b2f3b-8ce3-49d0-9f1f-6a2e1d1f3f31
status: experimental
description: Wykrywa nietypowe dzieci procesów Flash (cmd/powershell/skrpty), co bywa obserwowane przy RCE (np. CVE-2015-3113).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2015-3113
  - https://cloud.google.com/blog/topics/threat-intelligence/operation-clandestine-wolf-adobe-flash-zero-day/
tags:
  - attack.t1203
  - attack.t1189
  - attack.t1566.002
  - cve.2015-3113
logsource:
  category: process_creation
  product: windows
detection:
  sel_parent:
    ParentImage|contains:
      - '\FlashPlayer'
      - '\FlashUtil'
      - '\FlashPlayerPlugin'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: sel_parent and sel_child
fields:
  - ParentImage
  - ParentCommandLine
  - Image
  - CommandLine
falsepositives:
  - Rzadkie narzędzia korporacyjne wołane z aplikacji opartej na Flash (dziś skrajnie rzadkie)
level: high

Splunk (SPL)

1) Flash uruchomiony przez przeglądarkę

index=sysmon EventCode=1
(ParentImage="*\\iexplore.exe" OR ParentImage="*\\chrome.exe" OR ParentImage="*\\firefox.exe" OR ParentImage="*\\msedge.exe")
(Image="*\\FlashPlayer*.exe" OR Image="*\\FlashUtil*.exe" OR Image="*\\FlashPlayerPlugin*.exe")
| stats count min(_time) max(_time) by host, ParentImage, Image, CommandLine, ParentCommandLine

2) Dzieci procesów Flash

index=sysmon EventCode=1
(ParentImage="*\\FlashPlayer*.exe" OR ParentImage="*\\FlashUtil*.exe" OR ParentImage="*\\FlashPlayerPlugin*.exe")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe")
| table _time host ParentImage Image CommandLine

3) Proxy/HTTP — pobrania .swf

index=proxy (uri_path="*.swf" OR mime_type="application/x-shockwave-flash")
| stats count by src_ip, user, uri, http_status, user_agent, referrer

KQL (Microsoft Defender / M365)

Defender for Endpoint — dzieci procesów Flash

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

MDO — kliknięcia linków .swf

UrlClickEvents
| where Url endswith ".swf" or Url has ".swf?"
| summarize Clicks=count() by UrlDomain, Url, AccountUpn, Timestamp

MDO — adresy URL w wiadomościach

EmailUrlInfo
| where Url endswith ".swf" or Url has ".swf?"
| join kind=leftouter EmailEvents on NetworkMessageId
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Url, UrlDomain, Subject, ThreatTypes

(Definicje tabel: EmailUrlInfo, UrlClickEvents — dokumentacja Microsoft).

CloudTrail / CloudWatch (AWS)

Założenie: włączone S3 Data Events lub logi CloudFront.

CloudTrail Lake SQL (AWS CLI): wyszukaj pobrania *.swf z bucketów

SELECT eventTime, sourceIPAddress, userIdentity.principalId, requestParameters.bucketName AS bucket,
       requestParameters.key AS objectKey
FROM event_data_store
WHERE eventSource = 's3.amazonaws.com'
  AND eventName   = 'GetObject'
  AND requestParameters.key LIKE '%.swf'
  AND eventTime > TIMESTAMP '2025-11-01 00:00:00';

(Wymaga włączonych data events).

CloudFront / Athena (przykład):

SELECT date, time, cs_host, cs_uri_stem, sc_status, sc_content_type, c_ip, cs_user_agent
FROM cloudfront_logs
WHERE cs_uri_stem LIKE '%.swf'
ORDER BY date, time DESC;

Elastic EQL

process where
  process.parent.name in ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")

Heurystyki / korelacje

  • Klik .swf ⇒ proces Flash ⇒ podejrzane dziecko ⇒ połączenie wychodzące (czasowo blisko) — korelacja M365 (UrlClickEvents / EmailUrlInfo) + EDR + egress DNS/HTTP.
  • Załadowanie pepflashplayer.dll przez przeglądarkę, następnie nietypowe zachowanie (np. nagłe powershell.exe).
  • Rzadko używane dziś MIME application/x-shockwave-flash w ruchu web — traktuj jako anomalię.
  • Artefakty APT3/SHOTPUT (nietypowe rozpoznanie hosta/użytkowników/sieci po kompromitacji) jako sygnały post‑exploitation do korelacji (np. lista kont, netstat).

False positives / tuning

  • Dziedzictwo wewnętrzne: pojedyncze kioski/offline‑aplikacje z zawartością SWF (dziś wyjątkowe). Użyj allowlist domen/aplikacji biznesowych i ogranicz reguły do organizacji/OU, gdzie jakiekolwiek Flash jest dopuszczone.
  • Narzędzia administracyjne mogą incydentalnie wywołać interpretery (np. skrypty logowania), ale rodzicem nie powinien być proces Flash.
  • Ustal okno czasowe (np. ±5 min od kliknięcia URL .swf) i filtruj znane testy w labie.

Playbook reagowania (SOC/IR)

  1. Zablokuj źródło: domenę/URL z .swf w proxy/DNS firewall; wypchnij blokadę przez EDR.
  2. Izoluj host z alertem (EDR quarantine).
  3. Triage artefaktów:
    • Procesy potomne Flash, dropy w %APPDATA%, połączenia C2.
    • Zrzut pamięci procesu przeglądarki/Flash (jeśli polityka na to pozwala).
  4. Hunting rozprzestrzenienie: użyj zapytań (SPL/KQL/EQL powyżej) w horyzoncie 7–30 dni.
  5. Patch & harden: potwierdź brak Flash w flocie (wycofanie EOL), wymuś aktualizacje przeglądarek.
  6. Eradykacja: usuń artefakty, przeinstaluj przeglądarkę, unieważnij poświadczenia pozyskane po kompromitacji.
  7. Lessons learned: blokada typów/MIME, EDR policy na podejrzane dzieci procesów, kampania edukacyjna „nie klikaj .swf”.

Przykłady z kampanii / case studies

  • Operation Clandestine Wolf (APT3/UPS) — phishing z odsyłaczami do przejętych witryn; profilowanie JS; exploit CVE‑2015‑3113; backdoor SHOTPUT (Backdoor.APT.CookieCutter). Branże: A&D, telco, high‑tech, transport, budownictwo.
  • Eksploatacja na szeroką skalę — szybka adopcja w exploit kitach (np. Magnitude) w 2015 r.

Lab (bezpieczne testy) — tylko w kontrolowanym środowisku

Nie instaluj Flash w produkcji. Nie testujemy exploitu — jedynie łańcuch detekcji.

  • Symulacja ruchu web
    • curl -I https://lab.example.org/test.swf (serwuj neutralny plik binarny z nagłówkiem Content-Type: application/x-shockwave-flash).
    • Zweryfikuj, że proxy/NGFW/Athena (CloudFront) odnotowały żądanie *.swf.
  • Symulacja korelacji M365
    • Wyślij na skrzynkę testową e‑mail z linkiem do https://lab.example.org/test.swf.
    • Sprawdź EmailUrlInfo / UrlClickEvents (KQL z sekcji 7).
  • Symulacja anomalii procesów
    • Zastępczo uruchom aplikację, która imituje wzorzec: proces „AplikacjaGUI.exe” → cmd.exe /c whoami. Reguły powinny złapać schemat „aplikacja multimedialna → interpreter”. (Bez użycia Flash).

Mapowania

Mitigations (ATT&CK):

  • M1050 Exploit Protection — ASR/Exploit Guard/EDR exploit prevention.
  • M1033 Limit Software Installation — blokada instalacji wtyczek/dodatków; usunięcie Flash.
  • M1040 Behavior Prevention on Endpoint — blokuj podejrzane łańcuchy (Flash → skrypty/LOLBins).
  • M1017 User Training — prewencja kliknięć w odsyłacze .swf.

Powiązane techniki (kaskada):

  • T1105 Ingress Tool Transfer — dociąganie backdoora po RCE.
  • T1027 Obfuscated/Compressed Files & Information — xor/steganografia/packery w payloadach.

Źródła / dalsza literatura

  • NVD: opis, wersje, „exploited in the wild” (VI 2015). (NVD)
  • Mandiant/FireEye: Operation Clandestine Wolf, łańcuch ataku, SHOTPUT (APT3). (Google Cloud)
  • SecurityWeek: zero‑day, cele (IE na Win7, Firefox na XP), powiązanie z APT3. (SecurityWeek)
  • Trend Micro: adopcja w exploit kitach (Magnitude). (www.trendmicro.com)
  • Adobe: EOL Flash (31.12.2020). (Adobe)
  • Adobe Flash Player 32 Admin Guide: procesy/plik DLL (FlashUtil*, pepflashplayer.dll). (open-flash.github.io)
  • MITRE ATT&CK: T1189, T1566.002, T1203; wersja v18.0. (MITRE ATT&CK)
  • Microsoft Defender: tabele EmailUrlInfo, UrlClickEvents. (Microsoft Learn)
  • AWS: CloudTrail Data Events, CloudFront/Athena zapytania. (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Włączone telemetry: Sysmon (EID 1/7), proxy/DNS, M365 Defender (EmailUrlInfo/UrlClickEvents).
  • Reguły: Sigma (Flash → cmd/powershell), SPL/KQL/EQL z sekcji 7.
  • Korelacja: klik .swf ↔ procesy Flash ↔ dziecko/egress DNS/HTTP.
  • Blokady: MIME application/x-shockwave-flash, rozszerzenie .swf w bramkach.
  • Hunting retro 30 dni: dzieci procesów Flash i ruch do domen z kampanii (wg TI).

CISO (strategiczne):

  • Potwierdzić brak Flash w organizacji (EOL).
  • Polityka „deny by default” dla wtyczek przeglądarek.
  • Wymuszony Exploit Protection/EDR (M1050/M1040).
  • Szkolenia użytkowników (M1017) z naciskiem na klikalność linków.
  • Gotowość IR: playbook powyżej, retencja logów ≥ 30–90 dni.