VPN jest bramą do firmowej sieci – ułatwia pracę zdalną, ale dla atakujących stanowi atrakcyjny cel. Wystarczy jedno przejęte konto lub luka w VPN, by intruz zyskał dostęp do zasobów wewnętrznych. Przykładowo, głośny atak na Colonial Pipeline w 2021 rozpoczął się od wykradzionych danych dostępowych VPN bez wymuszonego MFA, co sparaliżowało krytyczną infrastrukturę. To pokazuje, że kompromitacja VPN niesie poważne konsekwencje – od wycieku danych po zatrzymanie działalności firmy.
Krytyczna podatność deserializacji w SAP NetWeaver AS Java (RMI‑P4) pozwala nieautoryzowanemu napastnikowi zdalnie wykonać dowolne komendy systemowe przez wysłanie złośliwych obiektów Java na otwarty port P4 (5NN04/50004). Należy załatać wg not SAP #3634501 oraz wdrożyć dodatkowe filtrowanie deserializacji JVM wg #3660659, a także ograniczyć ekspozycję portu P4 tylko do zaufowanych sieci. Brak publicznych dowodów eksploatacji/PoC w momencie publikacji dostawców, ale ryzyko jest maksymalne (CVSS 10).
Krótka definicja techniczna
CVE‑2025‑42944 to błąd deserializacji niezaufanych obiektów Java w module RMI‑P4 SAP NetWeaver AS Java. Wystawiony port P4 (np. 50004) przyjmuje obiekty, które po zdeserializowaniu mogą uruchomić dowolny kod/komendy OS w kontekście procesu aplikacyjnego — bez uwierzytelnienia.
Gdzie występuje / przykłady platform
Windows / Linux: serwery z SAP NetWeaver AS Java (procesy java, jstart, sapstartsrv).
AD / ESXi: pośrednio — jeśli hosty SAP są członkiem domeny/VM; wektor RMI‑P4 pozostaje usługą aplikacyjną.
Chmury (AWS/Azure/GCP): NetWeaver na IaaS — krytyczne są Security Groups/NSG, które mogą otworzyć 5NN04 na świat.
Kubernetes: rzadkie, ale jeśli AS Java działa w kontenerze, zagrożeniem jest Service/LoadBalancer/NodePort wystawiający 5NN04.
M365: brak bezpośredniego wpływu; telemetryka MDE może pomóc w detekcji skutków (procesy). Porty P4/P4S/P4HTTP zgodnie z dokumentacją SAP.
Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)
RMI‑P4 to protokół zdalnych wywołań w AS Java. Usługa nasłuchuje na porcie 5NN04 (np. 50004) i obsługuje obiekty Java przesyłane do deserializacji. W CVE‑2025‑42944 brak właściwej walidacji powoduje, że przesłany złośliwy obiekt (tzw. gadget chain) zostaje zdeserializowany, co może zakończyć się wykonaniem komend systemowych (np. powłoki), skutkując pełnym naruszeniem C/I/A aplikacji. SAP wydał poprawkę (#3634501) oraz późniejsze zalecenia utwardzające z #3660659 — w tym zastosowanie JVM‑wide jdk.serialFilter dla klas dozwolonych/blokowanych, co ogranicza powierzchnię gadgetów.
Uwaga kontekstowa: niektóre źródła branżowe raportowały brak obserwacji PoC/eksploatacji w czasie publikacji, lecz historycznie luki RCE w SAP są szybko weaponizowane po ujawnieniu poprawek. Priorytet: patch + segmentacja + filtracja P4.
toPort w [50004..59904] (w przybliżeniu wzorzec 5NN04)
Wykrywa „otwarcie świata” na P4 w chmurze
K8s audit
Wystawienie P4 z klastra
create/patchService/Ingress
spec.ports.port: 5NN04 / nodePort kończący się …04
Jeśli NetWeaver w kontenerach
M365 Unified Audit Log
–
–
[brak zastosowania]
Detekcja skutków via MDE (telemetria endpoint)
Detekcja (praktyczne reguły)
Sigma (Windows – proces potomny od Javy/SAP)
title: SAP NetWeaver AS Java -> podejrzany interpreter poleceń (CVE-2025-42944)
id: 4c7b3c8b-7b5f-4f5f-9f1a-jnr-p4-rce
status: experimental
description: Wykrywa uruchomienie cmd/PowerShell przez procesy java/jstart/sapstartsrv (skutek RMI-P4 RCE).
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-42944
- https://onapsis.com/blog/sap-security-patch-day-october-2025/
logsource:
product: windows
category: process_creation
detection:
parent_java:
ParentImage|endswith:
- '\java.exe'
- '\jstart.exe'
- '\sapstartsrv.exe'
child_shell:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\wscript.exe'
- '\cscript.exe'
condition: parent_java and child_shell
fields:
- Image
- CommandLine
- ParentImage
- ParentCommandLine
- User
falsepositives:
- Rzadkie zadania serwisowe/upgrade AS Java wywołujące skrypty systemowe
level: high
tags:
- attack.t1059
- attack.t1190
- attack.t1210
Wariant Linux/auditd (skrót):
logsource:
product: linux
service: auditd
detection:
parent_java: selection where exe endswith "java" or "jstart" or "sapstartsrv"
child_shell: selection where a0 in ("sh","bash","zsh","ksh")
condition: parent_java and child_shell
Splunk (SPL)
A. Proces potomny od Javy/SAP (Win Security 4688 lub Sysmon 1)
(index=win* (sourcetype=WinEventLog:Security EventCode=4688)
OR (sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1))
| eval parent=coalesce(ParentImage, ParentProcessName)
| eval child=coalesce(Image, NewProcessName)
| where match(lower(parent), "(\\\\|/)java\\.exe$|(\\\\|/)jstart\\.exe$|(\\\\|/)sapstartsrv\\.exe$")
AND match(lower(child), "(\\\\|/)cmd\\.exe$|(\\\\|/)powershell\\.exe$|(\\\\|/)wscript\\.exe$|(\\\\|/)cscript\\.exe$")
| stats count min(_time) max(_time) values(CommandLine) by host parent child user
B. Połączenia przychodzące na P4 (Zeek/FW)
(index=net* OR index=zeek* OR index=firewall*)
| eval port_str=tostring(dest_port)
| where dest_port>=50004 AND dest_port<=59904 AND like(port_str,"%04")
| stats dc(src_ip) as uniq_src count by dest_ip dest_port
| sort - count
KQL (Microsoft Defender/Defender for Cloud)
A. Proces potomny od Javy/SAP
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("java.exe","jstart.exe","sapstartsrv.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","sh","bash")
| summarize cnt=count(), firstSeen=min(Timestamp), lastSeen=max(Timestamp)
by DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
B. Ruch na P4 (wejściowy)
DeviceNetworkEvents
| where RemotePort between (50004 .. 59904) and RemotePort % 100 == 4
| where Direction in ("Inbound","Listen") or Action =~ "Allowed"
| summarize cnt=count(), sources=dcount(RemoteIP) by DeviceName, RemotePort, Protocol, InitiatingProcessFileName
CloudTrail (AWS) — otwarcie portu 5NN04 w SG (CloudTrail Lake SQL)
SELECT eventTime, eventName, userIdentity.type AS actor,
requestParameters.groupId AS sg,
json_extract_scalar(requestParameters, '$.toPort') AS toPort,
sourceIPAddress
FROM aws_cloudtrail_events
WHERE eventSource='ec2.amazonaws.com'
AND eventName IN ('AuthorizeSecurityGroupIngress','AuthorizeSecurityGroupEgress','CreateSecurityGroup')
AND CAST(json_extract_scalar(requestParameters, '$.toPort') AS INT) BETWEEN 50004 AND 59904
AND LIKE(json_extract_scalar(requestParameters, '$.toPort'), '%04')
ORDER BY eventTime DESC;
Elastic / EQL
Proces potomny od Javy/SAP → interpreter poleceń
process where event.type == "start" and
(process.parent.name in ("java","jstart","sapstartsrv") or
process.parent.executable : "*\\java.exe") and
process.name in ("cmd.exe","powershell.exe","sh","bash","zsh","ksh")
Heurystyki / korelacje (co łączyć)
Inbound na P4 (5NN04/50004) z Internetu ⟶ w krótkim czasie dziecko cmd/sh od procesu java/jstart.
Materiały branżowe (Arctic Wolf) wskazywały brak obserwowanej eksploatacji i publicznego PoC w chwili publikacji, choć luki SAP są atrakcyjne i szybko weaponizowane po patchach.
Dodatkowy hardening (JVM jdk.serialFilter) został opisany przez Onapsis i powiązany z notą SAP #3660659 — warto wdrożyć nawet po aktualizacji.
Komunikaty prasowe/serwisy bezpieczeństwa szeroko opisywały wagę CVE‑2025‑42944 (CVSS 10.0) oraz że został ujęty w wrześniowych i październikowych poradnikach SAP.
Lab (bezpieczne testy) — przykładowe komendy
Tylko w odizolowanym labie. Celem jest weryfikacja detekcji, nie wykorzystanie luki.
Symulacja dziecka cmd od Javy (Windows):# skompiluj prostą klasę Java uruchamiającą bezpieczną komendę echo @" public class P4Echo { public static void main(String[] args) throws Exception { new ProcessBuilder("cmd.exe","/c","echo lab-test").inheritIO().start().waitFor(); } } "@ | Set-Content .\P4Echo.java javac P4Echo.java java P4Echo Oczekiwany efekt: trigger reguł Sigma/Splunk/KQL (rodzic java.exe → dziecko cmd.exe).
Ruch na port P4 (bez payloadu), do testu korelacji sieciowej:# Linux/WSL: próba TCP handshake do P4 nc -vz <host_sap> 50004 Oczekiwany efekt: wpisy w logach FW/Zeek; brak błędów aplikacji (brak payloadu).
Weryfikacja portów SAP wg dokumentacji: sprawdź, że P4 to 5NN04 (np. 50004).
Krytyczna luka (CVSS 10.0) w SQL Anywhere Monitor (Non‑GUI) 17.0 — wbudowane poświadczenia mogą dać zdalne RCE bez uwierzytelnienia.
Zastosuj SAP Note 3666261; SAP klasyfikuje jako HotNews. Onapsis: poprawka usuwa moduł monitora; doraźnie wyłącz i usuń bazę monitora.
Od strony detekcji: identyfikuj hosty nasłuchujące/historycznie na TCP/4950, koreluj z nietypowymi logowaniami i nowymi procesami systemowymi po ruchu na tym porcie.
Na moment publikacji brak informacji SAP o aktywnej eksploatacji; patchuj priorytetowo.
Krótka definicja techniczna
CVE‑2025‑42890 to błąd klasy CWE‑798 (hard‑coded credentials) w SAP SQL Anywhere Monitor (Non‑GUI), pozwalający zdalnemu napastnikowi — bez wcześniejszego uwierzytelnienia — uzyskać dostęp do funkcji administracyjnych monitora i potencjalnie wykonać kod z wysokimi uprawnieniami, co skutkuje wysokim wpływem na C/I/A.
Gdzie występuje / przykłady platform
Windows / Linux (on‑prem / IaaS): monitor uruchamiany jako usługa, historycznie eksponujący HTTP na TCP/4950.
VM/Cloud (AWS/Azure/GCP): spotykany jako komponent pomocniczy przy środowiskach rozproszonych SQL Anywhere; w chmurze ruch widoczny w VPC/NSG Flow Logs.
AD/M365/K8s/ESXi: brak bezpośredniej zależności; komponent jest aplikacją serwerową spoza tych platform.
Szczegółowy opis techniki
Moduł SQL Anywhere Monitor (Non‑GUI) zawiera w kodzie stałe poświadczenia. Jeżeli usługa jest osiągalna sieciowo, atakujący może z ich użyciem uzyskać dostęp administracyjny do funkcji monitora, a następnie (w zależności od konfiguracji i scenariusza) doprowadzić do zdalnego wykonania kodu na hoście. SAP sklasyfikował lukę jako Critical/HotNews i udostępnił notę 3666261; Onapsis podaje, że poprawka deinstaluje omawiany komponent, a do czasu wdrożenia łatki należy zatrzymać usługę monitora i usunąć jego bazę repozytoryjną. Praktycznie oznacza to, że ekspozycja TCP/4950 (lub port skonfigurowany lokalnie) z hosta z zainstalowanym monitorem znacząco zwiększa ryzyko nieautoryzowanego dostępu.
Artefakty i logi (tabela)
Źródło
Artefakt / log
Co obserwować
Firewall / NTA / Zeek
Połączenia dst.port=4950/tcp (lub port monitora)
Pierwsze kontakty z zewnątrz, skoki wolumenu, nowe źródła IP, długość sesji.
Sysmon
EID 3 (NetworkConnect)
Procesy nasłuchujące/łączące się na 4950; korelacja z nietypowymi parentami.
Windows System
EID 7045/7036 (Service install/start)
Pojawienie się/uruchomienie usługi powiązanej z SQL Anywhere/monitorem.
Linux
systemd journal / ss -lntp
Słuchanie na porcie monitora, restart usługi po patchu.
EDR (proc)
Nietypowe spawny (cmd.exe/powershell.exe/bash) po ruchu na 4950
Możliwy follow‑on execution.
Cloud (AWS)
VPC Flow Logs
dstport=4950 + action=ACCEPT dla instancji z SQL Anywhere.
Azure/GCP
NSG/Flow Logs
Analogiczne do VPC Flow.
K8s/M365
—
[brak danych / nie dotyczy]
Detekcja (praktyczne reguły)
a) Sigma (firewall/NTA) — zewnętrzny dostęp do monitora
title: External Access to SAP SQL Anywhere Monitor (TCP/4950)
id: 0f2e2b2c-5f1c-4a3c-8b0a-4a2b4c7e4950
status: stable
description: Wykrywa połączenia przychodzące do SQL Anywhere Monitor (historycznie TCP/4950) spoza sieci zaufanych.
references:
- https://help.sap.com/docs/SAP_SQL_Anywhere/.../Monitor-architecture # port 4950
logsource:
category: firewall
detection:
selection:
dst_port: 4950
action: allow
not_internal:
src_ip|cidr:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
condition: selection and not not_internal
fields:
- src_ip
- dst_ip
- dst_port
- bytes
- rule
falsepositives:
- Legalny zdalny dostęp administracyjny z zaufanych adresów (rozszerz allowlistę).
level: high
b) Splunk (CIM: Network_Traffic)
| tstats summariesonly=false count as events
from datamodel=Network_Traffic.All_Traffic
where All_Traffic.dest_port=4950 All_Traffic.action=allowed
by _time span=5m All_Traffic.dest, All_Traffic.src
| where NOT cidrmatch("10.0.0.0/8", 'All_Traffic.src')
AND NOT cidrmatch("172.16.0.0/12", 'All_Traffic.src')
AND NOT cidrmatch("192.168.0.0/16", 'All_Traffic.src')
| eventstats sum(events) as ev_by_pair by All_Traffic.dest, All_Traffic.src
| sort - ev_by_pair
c) KQL (Microsoft Defender for Endpoint / Sentinel – DeviceNetworkEvents)
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where LocalPort == 4950 or RemotePort == 4950
| where ActionType in ("ConnectionSuccess", "InboundConnectionAccepted", "ListeningConnectionCreated")
| summarize firstSeen=min(Timestamp), lastSeen=max(Timestamp), cnt=count()
by DeviceName, InitiatingProcessFileName, LocalIP, LocalPort, RemoteIP, RemotePort, Protocol
| order by cnt desc
d) AWS VPC Flow Logs (Athena)
SELECT dstaddr, dstport, srcaddr, COUNT(*) AS hits, MIN(start) AS first_seen, MAX(end) AS last_seen
FROM vpc_flow_logs
WHERE action='ACCEPT' AND dstport=4950 AND start BETWEEN from_iso8601_timestamp('${from}') AND from_iso8601_timestamp('${to}')
GROUP BY dstaddr, dstport, srcaddr
ORDER BY hits DESC;
e) Elastic (EQL)
network where destination.port == 4950 and event.action == "allowed"
and not cidrmatch(source.ip, ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"])
Uwaga: port 4950 jest historyczną wartością domyślną dla monitora — potwierdź w swojej konfiguracji (również pod kątem reverse proxy).
Heurystyki / korelacje
Ruch → wykonanie: przepływy na 4950 (lub port monitora) tuż przed nowymi procesami systemowymi na hoście (cmd/powershell/bash, instalacja usług).
Nowa ekspozycja: pojawienie się procesu nasłuchującego na 4950 po wdrożeniu lub aktualizacji hosta.
Anomalia źródeł: dostęp do monitora spoza adresów operacyjnych/monitorujących (jump‑hosty, narzędzia APM).
Zachowanie po kompromitacji: dodanie kont lokalnych, nowe zadania zaplanowane, modyfikacje reguł zapory.
False positives / tuning
Wewnętrzne systemy monitoringu/aplikacje APM mogą korzystać z dedykowanych portów — allowlista IP i okna czasowe maintenance.
Port 4950 bywa używany w dawnych wdrożeniach innych narzędzi — potwierdzaj banery/usługę zanim podniesiesz incydent.
Łańcuch dowodowy: przejrzyj logi (sekcje 6–7) pod kątem nadużyć przed patchowaniem; skoreluj z EDR.
Weryfikacja „po”: brak nasłuchu na 4950 (netstat/ss), brak procesu/usługi monitora, brak ruchu w Flow Logs.
Przykłady z kampanii / case studies
Stan na 11–12 lis 2025: SAP nie raportował wykorzystania „in the wild”; media branżowe również nie wskazują aktywnej eksploatacji — priorytet patchowania pozostaje wysoki ze względu na CVSS 10.0.
Lab (bezpieczne testy) — przykładowe komendy
Cel: sprawdzić, czy detekcje zadziałają bez reprodukowania luki.
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).
Nagłe crashe Flash niedługo przed nietypowym procesem‑dzieckiem.
Proxy/NGFW/DNS
Dostęp HTTP/S do *.swf, MIME application/x-shockwave-flash
url, mime, user_agent, referrer
Koreluj z kliknięciami z e‑maila (M365).
M365 Defender
EmailUrlInfo, UrlClickEvents
Url, UrlDomain, kliknięcia Safe Links
Łącz URL .swf z hostami, które uruchomiły procesy Flash.
MITRE ATT&CK (kontekst)
APT3 + SHOTPUT
Profilowanie, dostarczenie backdoora
Do korelacji z TTP grupy.
AWS (opcjonalnie)
CloudTrail Lake (S3 Data Events)
GetObject na kluczach %.swf
Wymaga włączonych data events.
CDN
CloudFront Access Logs / Athena
cs-uri-stem like '%.swf', sc-content-type
Przy 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
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)
Zablokuj źródło: domenę/URL z .swf w proxy/DNS firewall; wypchnij blokadę przez EDR.
Izoluj host z alertem (EDR quarantine).
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).
Hunting rozprzestrzenienie: użyj zapytań (SPL/KQL/EQL powyżej) w horyzoncie 7–30 dni.
Patch & harden: potwierdź brak Flash w flocie (wycofanie EOL), wymuś aktualizacje przeglądarek.
Eradykacja: usuń artefakty, przeinstaluj przeglądarkę, unieważnij poświadczenia pozyskane po kompromitacji.
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.
Test penetracyjny (ang. penetration test, potocznie pentest) to kontrolowany, celowy atak symulowany na system informatyczny, aplikację lub sieć, przeprowadzany w celu oceny bezpieczeństwa tego systemu. Innymi słowy, jest to zaplanowane “hakowanie” własnej infrastruktury – etyczny atak wykonywany za zgodą właściciela systemu.
W świecie cyberbezpieczeństwa Blue Team często korzysta z matrycy MITRE ATT&CK do mapowania taktyk i technik ataków przeciwnika. A co z naszą własną defensywą? Czy potrafimy równie przejrzyście zobrazować, jak broni się nasza organizacja? W tym artykule zobaczymy, jak framework MITRE D3FEND pomaga zbudować wizualną mapę obrony – swoisty dashboard defensywny zespołu SOC. Zamiast domyślać się, gdzie mamy luki, zwizualizujemy techniki obrony tak, by od razu wskazać mocne punkty i obszary wymagające uwagi.
Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.
W skrócie
Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.
Kontekst / historia / powiązania
Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.
Analiza techniczna / szczegóły luki
CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.
W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).
Moduły złośliwe obejmują:
Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.
Praktyczne konsekwencje / ryzyko
Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.
Rekomendacje operacyjne / co zrobić teraz
Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:
Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.
Podsumowanie / kluczowe wnioski
ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.
Źródła / bibliografia
BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)