Archiwa: SIEM - Strona 44 z 61 - Security Bez Tabu

Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0

Czy backup to wystarczająca tarcza przed ransomware?

Jeszcze do niedawna wiele firm spało spokojnie, wierząc, że regularne kopie zapasowe uchronią je przed każdym atakiem. W końcu, jeśli dane zostaną zaszyfrowane, zawsze można je odzyskać z backupu, prawda? Niestety, nowa generacja ransomware – tzw. Ransomware 2.0 – brutalnie weryfikuje to założenie.

Czytaj dalej „Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0”

CVE-2019-19781 — Citrix ADC/NetScaler Gateway Directory Traversal → RCE

TL;DR

Krytyczna podatność Directory Traversal w Citrix ADC/NetScaler Gateway umożliwiała pre‑auth RCE na urządzeniu brzegowym. Typowy łańcuch: żądanie zapisujące plik XML w katalogu szablonów + odwołanie renderujące go jako szablon → wykonanie kodu (Perl/Unix shell). Priorytety: sprawdź logi /var/log/httpaccess.log i /var/log/ns.log, uruchom oficjalny IoC Scanner (Citrix/Mandiant), załatataj lub przeinstaluj do wersji naprawionej, usuń zakładki/podstawione pliki w /netscaler/portal/templates/, oceń lateral movement.


Krótka definicja techniczna

CVE‑2019‑19781 to błąd walidacji ścieżek (CWE‑22) w Citrix ADC/Gateway (10.5–13.0), który pozwalał na przejście katalogów i zapisywanie plików w lokalizacjach przetwarzanych przez mechanizm szablonów (Template Toolkit). W efekcie niezalogowany napastnik mógł zapisać złośliwy szablon XML i wywołać jego renderowanie, co prowadziło do wykonania kodu i przejęcia urządzenia.


Gdzie występuje / przykłady platform

  • Citrix ADC / NetScaler ADC i Citrix Gateway / NetScaler Gateway (wdrożenia fizyczne/VM, także w chmurach IaaS). Wrażliwe były linie 10.5, 11.1, 12.0, 12.1, 13.0 przed poprawkami.
  • Środowiska hybrydowe (np. ADC za ALB/ELB, Azure Front Door, on‑prem DMZ) — ekspozycja jest publiczna, więc podatność pełni rolę wektora Initial Access (T1190).
  • Oficjalne komunikaty i poradniki aktualizacji/mitigacji dostarczył Citrix.

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

Mechanizm obsługi żądań do ścieżek /vpns/portal/ w ADC przekazywał je do modułu Perl renderującego pliki jako szablony. Błąd path traversal pozwalał sterować nazwą/położeniem pliku (np. poprzez funkcję csd/filewrite w łańcuchu wywołań), co umożliwiało zapis przygotowanego XML w katalogu szablonów oraz jego wyrenderowanie kolejnym żądaniem (lub w niektórych wariantach jednym żądaniem). Po renderyzacji Template Toolkit umożliwiał wykonanie akcji prowadzących do RCE.

Dlaczego technika była skuteczna:

  • Pre‑auth oraz publiczna ekspozycja urządzeń (brzeg/DMZ).
  • Logi i inspekcja sieci często omijane (urządzenia przed IDS/NDR albo ruch TLS).
  • Szybka weaponizacja (publiczne PoC i masowe skanowanie).
  • Pojawiły się przypadki „vigilante patching” (NOTROBIN), które maskowały rzeczywisty poziom kompromitacji.

Artefakty i logi (co zbierać)

Źródło / komponentCo szukać (wzorzec)Przykład / uwagiEID / CloudTrail / K8s / M365
ADC /var/log/httpaccess.logSekwencja: POST do skryptu Perl w /vpns/portal/ + GET/HEAD .xml w /vpns/portal/ (200/304)Polecenia grep używane przez IR: grep -iE 'POST.*\\.pl.* 200' /var/log/httpaccess.log oraz `grep -iE 'GET.\.xml. (200304)’ /var/log/httpaccess.log`
ADC filesystemNowe/zaskakujące pliki *.xml i skompilowane *.ttc2 w /netscaler/portal/templates/Artefakt po udanym zapisie oraz renderowaniu szablonu
ProcesyProcesy uruchamiane przez użytkownika nobody (poza typowym httpd)`ps auxgrep nobody` – wskazówka Mandiant dla triage
CrontabNieautoryzowane wpisy (cykliczne pobieranie/uruchamianie binariów)M.in. linie z curl i uruchamianiem plików w /tmp/.init/
ADC /var/log/ns.log (AAA/syslog)Nietypowe logowania/porzucone sesje, wzmianki LOGIN_FAILED/Client_ipSłuży też do korelacji czasu ataku z sesjami użytkowników
WAF/ALB/Front DoorURI zawierające /vpn/../vpns/portal oraz odwołania do *.xmlAnaliza AWS WAF/ALB, Azure WAF, appliance WAFCloudTrail: n/d (zamiast tego CloudWatch Logs Insights / AzureDiagnostics)

Uwaga: zakres kolumn CloudTrail/M365/K8s zwykle nie dotyczy natywnej analityki ADC; zbieraj logi sieciowe (WAF/ALB) i syslog z ADC.


Detekcja (praktyczne reguły)

Sigma (HTTP access logs – pre‑auth traversal do skryptu Perl)

title: Citrix ADC CVE-2019-19781 Pre-Auth Traversal to Perl Script
id: 0d7d8b3a-3c2f-4c2e-a2b0-citrix-19781-a
status: stable
description: Wykrywa żądania POST z traversalem do /vpns/portal/*.pl (np. newbm.pl)
references:
  - https://cloud.google.com/blog/topics/threat-intelligence/rough-patch-promise-it-will-be-200-ok
logsource:
  category: webserver
detection:
  sel_uri:
    request:
      - '*\/vpn/*../*/vpns/portal/*'
    url|contains:
      - '/vpn/../vpns/portal/'
  sel_pl:
    url|endswith: '.pl'
  sel_method:
    http_method: POST
  condition: sel_uri and sel_pl and sel_method
falsepositives:
  - Skanery podatności / testy pentestowe
level: high
tags:
  - attack.T1190

Sigma (HTTP access logs – renderowanie szablonu XML)

title: Citrix ADC CVE-2019-19781 XML Template Render
id: 7f0a6e60-9fda-4a7f-b3f9-citrix-19781-b
status: stable
description: Żądania GET/HEAD do /vpns/portal/*.xml (200/304) po wcześniejszym POST
logsource:
  category: webserver
detection:
  sel_xml:
    url|contains: '/vpns/portal/'
    url|endswith: '.xml'
  sel_code:
    http_status:
      - 200
      - 304
  condition: sel_xml and sel_code
level: high
tags:
  - attack.T1190

(W regułach SIEM zalecana korelacja POST→GET w krótkim oknie czasu i z tym samym src_ip/user_agent).

Splunk (SPL)

(index=weblogs OR index=proxy OR index=adc)
| eval uri=coalesce(cs_uri_stem, uri_path, request)
| eval method=coalesce(cs_method, http_method, method)
| search (uri="/vpn/*../*/vpns/portal/*" method=POST) OR (uri="/vpns/portal/*.xml" (status=200 OR status=304))
| stats earliest(_time) as first_seen, latest(_time) as last_seen, values(status) as http_status by src, uri, user_agent, method
| sort - last_seen

KQL (Azure – WAF/App Gateway/Front Door)

let T1 = (
  AzureDiagnostics
  | where Category in ("ApplicationGatewayFirewallLog","FrontDoorWebApplicationFirewallLog")
  | where requestUri_s has "/vpn/../vpns/portal" and httpMethod_s == "POST"
);
let T2 = (
  AzureDiagnostics
  | where Category in ("ApplicationGatewayAccessLog","ApplicationGatewayFirewallLog","FrontDoorAccessLog","FrontDoorWebApplicationFirewallLog")
  | where requestUri_s has "/vpns/portal/" and requestUri_s endswith ".xml" and toint(substatus_s) in (200,304)
);
T1
| join kind=innerunique T2 on ClientIP_s, userAgent_s
| project TimeGenerated, ClientIP_s, userAgent_s, requestUri_s, Resource

(Łańcuch POST→GET z tym samym IP/UA).

AWS (CloudWatch Logs Insights – WAF/ALB)

fields @timestamp, httpRequest.clientIp, httpRequest.httpMethod, httpRequest.uri
| filter httpRequest.uri like /\/vpn\/\.\.\/vpns\/portal\// or httpRequest.uri like /\/vpns\/portal\/.*\.xml$/
| sort @timestamp desc

(Uwaga: CloudTrail nie rejestruje ruchu HTTP do ADC; używaj logów WAF/ALB/ELB).

Elastic (EQL – korelacja sekwencji)

sequence by source.ip with maxspan=3m
  [ network where url.path like "*\/vpn/*../*/vpns/portal/*" and http.request.method == "POST" ]
  [ network where url.path like "/vpns/portal/*.xml" and http.response.status_code in (200,304) ]

Źródła: opis łańcucha Mandiant.


Heurystyki / korelacje

  • Koreluj POST → GET/HEAD do /vpns/portal/*.xml w oknie 1–3 min z tym samym src_ip/User-Agent.
  • Po udanym renderze spodziewaj się pojawienia plików *.xml + *.ttc2 w /netscaler/portal/templates/.
  • Sprawdź procesy nobody wykraczające poza httpd oraz nowe wpisy crontab.
  • IOC typu „vigilante” (NOTROBIN) też wskazuje kompromitację (modyfikuje/domyka wektor, ale zostawia tylną furtkę).

False positives / tuning

  • Skanery podatności, testy pentestowe i health‑checki mogą generować żądania z ... Ogranicz alerty do konkretnych ścieżek (/vpns/portal/) i kodów 200/304 dla .xml.
  • Agreguj po /24 i User‑Agent — masowe skany będą miały wiele hostów/UA; eksploatacja zwykle ma spójny UA w krótkim czasie.
  • Włącz allow‑list znanych skanerów (np. IP Twojej usługi ASM/WAF).

Playbook reagowania (IR)

  1. Izolacja & widoczność
    • Tymczasowo ogranicz dostęp do ADC (geo/IP allow‑list lub VPN admins only).
    • Włącz pełny syslog do SIEM + eksport logów WAF/ALB/Front Door.
  2. Triaging artefaktów (na ADC)
    • Logi HTTP: grep -iE 'POST.*\.pl.* 200' /var/log/httpaccess.log -A1 grep -iE 'GET|HEAD.*\.xml.* (200|304)' /var/log/httpaccess.log -B1
    • Pliki: find /netscaler/portal/templates -type f \( -name '*.xml' -o -name '*.ttc2' \) -mtime -30 -ls
    • Procesy/utrwalenie: ps aux | grep nobody | grep -v httpd crontab -l
  3. Skan IoC (oficjalny)
    • Uruchom Citrix/Mandiant IoC Scanner na urządzeniu (tryb live). Zapisz wynik, zabezpiecz artefakty.
  4. Eradykacja
    • Zastosuj fixed buildy / przeinstaluj do wersji poprawionej; usuń pliki z /netscaler/portal/templates/; wyczyść crontab; sprawdź modyfikacje ns.conf.
  5. Odzyskanie i twardnienie
    • Rotacja haseł/kluczy, re‑issue certyfikatów (wyciek ns.conf bywał obserwowany).
    • WAF: reguły blokujące /vpn/../vpns/portal/ i dostęp do *.xml w /vpns/portal/.
    • Monitoring ciągły według reguł z sekcji 7.

Bezpieczeństwo: wszelkie działania wykonuj wyłącznie na własnym, testowym lub firmowym sprzęcie i w celu obrony.


Przykłady z kampanii / case studies

  • Masowe skanowanie i exploitation od 10–14 stycznia 2020; szybka weaponizacja PoC i infekcje (m.in. koparki, web‑shelle).
  • NOTROBIN (vigilante) – aktor wykorzystywał podatność do „łatania” innych backdoorów i blokowania kolejnych ataków, jednocześnie utrzymując własny dostęp. Wykrywano cykliczne czyszczenie plików .xml w katalogu szablonów.
  • Analizy IR (Fox‑IT/NCC Group) – szczegółowa rekonstrukcja łańcucha: zapis XML poprzez csd/filewrite, render i obejścia (w tym jednorazowe żądanie).

Lab (bezpieczne testy)

Cel: sprawdzić, czy detekcje/WAF reagują na wzorzec, bez eksploatacji.

  • Generowanie bezpiecznego zdarzenia (Twoje labowe ADC lub serwer testowy): curl -k -I --path-as-is "https://lab.adc.example/vpn/../vpns/portal/test.xml" Spodziewany 404; zdarzenie powinno trafić do WAF/ALB/NGINX/IIS i zadziałać reguła wykrywająca wzorzec URI.
  • Weryfikacja w Splunk/KQL – odpal zapytania z pkt 7 i potwierdź, że testowe zdarzenie podniosło alert.
  • Symulacja artefaktów – utwórz puste pliki .xml w ścieżce testowej poza ADC i sprawdź, czy reguły FIM (jeśli masz) łapią zdarzenia tworzenia plików.

Nie testuj na systemach produkcyjnych i nie używaj exploitów – to ćwiczenie detekcyjne.


Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK)

  • M1051 – Update Software: aktualizacje/łatki firmware ADC.
  • M1050 – Exploit Protection: reguły WAF/IPS dla ścieżek z traversalem.
  • M1031 – Network Intrusion Prevention: sygnatury IDS/IPS dla /vpn/../vpns/portal/ i .xml.
  • M1030 – Network Segmentation: ogranicz zasięg ADC (DMZ, mikrosegmentacja, tylko niezbędne serwisy).

Powiązane techniki (ATT&CK)

  • T1190 – Exploit Public-Facing Application (wejście).
  • T1505.003 – Web Shell (utrwalenie na urządzeniu).
  • T1059.004 – Unix Shell (wykonanie komend).
  • T1105 – Ingress Tool Transfer (dociąganie narzędzi).
  • T1053.003 – Cron (utrwalenie).

Źródła / dalsza lektura

  • Citrix — ogłoszenie podatności / blogi i mitgacje. (Citrix.com)
  • NVD – opis CVE i listy wersji: CVE‑2019‑19781. (NVD)
  • Mandiant (Google Cloud) – „Rough Patch: I Promise It’ll Be 200 OK” (artefakty, wzorce logów, detekcje). (Google Cloud)
  • Mandiant/Citrix – IoC Scanner (repo). (GitHub)
  • Fox‑IT/NCC Group – „A Second Look at CVE‑2019‑19781” (wewnętrzna mechanika, obejścia). (Fox-IT International blog)
  • CISA – Alert AA20‑031A (detekcja, kontekst zagrożeń). (CISA)
  • Unit 42 – analiza i dane o skanach/eksploatacjach. (Unit 42)
  • NCSC‑UK – ostrzeżenie o aktywnej eksploatacji. (NCSC)
  • ATT&CK T1190 – strona techniki. Wersja frameworku: v18. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjna):

  • Reguły detekcji: Sigma/SPL/KQL/EQL wdrożone i przetestowane.
  • Ingest: syslog z ADC (httpaccess.log, ns.log) + WAF/ALB/Front Door.
  • Korelacja POST→GET .xml (200/304) + alert wysokiego priorytetu.
  • Playbook IR: zbieranie artefaktów, IoC Scanner, triage procesów nobody, crontab.
  • Dashboard/Trend: skany vs. udane odwzorowania.

CISO (strategiczna):

  • Polityka patch management dla urządzeń brzegowych (M1051).
  • WAF/IPS – sygnatury traversal dla /vpn/../vpns/portal/ (M1031/M1050).
  • Segmentacja ADC (DMZ, least access) + mikrosegmentacja (M1030).
  • Regularny threat hunt po artefaktach /netscaler/portal/templates/*.xml i .ttc2.
  • Testy detekcji (purple team) i przeglądy konfiguracji WAF przed oknami świątecznymi.

Uwaga o zgodności z ATT&CK: CVE‑2019‑19781 mapuje się przede wszystkim do T1190 (Initial Access). Dalsze TTP (web‑shell, cron, transfer narzędzi) reprezentują etapy po‑eksploatacyjne obserwowane w incydentach opisanych przez Mandiant/Fox‑IT i powinny być objęte monitorowaniem.

OpenAI ujawnia wyciek danych użytkowników API po incydencie u dostawcy Mixpanel — co to oznacza dla zespołów bezpieczeństwa

Wprowadzenie do problemu / definicja luki

OpenAI poinformowało 26 listopada 2025 r., że na skutek incydentu bezpieczeństwa w firmie Mixpanel (dostawca analityki front-end) doszło do wycieku ograniczonych danych identyfikujących część użytkowników OpenAI API. OpenAI podkreśla, że nie był to atak na jej infrastrukturę i nie wyciekły: treści czatów, zapytania API, klucze API, hasła, dane płatnicze ani dokumenty tożsamości. Z integracji Mixpanel zrezygnowano i rozpoczęto notyfikację podmiotów dotkniętych zdarzeniem.

Mixpanel opisał zdarzenie jako skutek kampanii smishingowej z 8 listopada 2025 r., która doprowadziła do nieautoryzowanego eksportu zbiorów danych części klientów. Firma wdrożyła działania IR, m.in. reset haseł pracowników, unieważnienie sesji i rotację poświadczeń.

W skrócie

  • Zdarzenie miało miejsce u Mixpanel, nie w systemach OpenAI.
  • Dotyczy użytkowników platformy API (platform.openai.com), nie zwykłych kont ChatGPT.
  • Potencjalnie ujawnione: imię/nazwa konta, e-mail, przybliżona lokalizacja (miasto/stan/kraj) z przeglądarki, system/PRZEGLĄDARKA, referrery, ID organizacji/użytkownika.
  • Brak ujawnienia haseł, tokenów, kluczy API, treści zapytań/odpowiedzi, danych płatniczych. Brak potrzeby rotacji haseł/kluczy z tego powodu.
  • OpenAI usunęło Mixpanel z produkcji i prowadzi dochodzenie.
  • Media branżowe oraz raporty wskazują, że wyciek mógł dotknąć także innych klientów Mixpanel (np. CoinTracker). To nie jest potwierdzenie ze strony OpenAI, ale koreluje z relacjami użytkowników.

Kontekst / historia / powiązania

Według OpenAI, 9 listopada 2025 r. Mixpanel wykrył nieautoryzowany dostęp i eksport zbioru danych zawierającego ograniczone PII oraz metadane analityczne części klientów. 25 listopada Mixpanel przekazał OpenAI kopię dotkniętych danych, co umożliwiło notyfikacje i ocenę ryzyka. Następnego dnia OpenAI opublikowało komunikat i FAQ.

Równolegle Mixpanel opublikował własny wpis, wskazując na smishing (SMS phishing) jako wektor inicjujący incydent i opisując działania zaradcze (m.in. blokada IP, rejestracja IOC w SIEM, forensics).

Analiza techniczna / szczegóły luki

Wektor ataku: kampania smishingowa wymierzona w pracowników/użytkowników Mixpanel doprowadziła do naruszenia części systemów i eksportu danych customers’ analytics. (To typowy scenariusz „initial access” przez socjotechnikę → eskalacja → eksfiltracja).

Zakres danych: metadane analityczne z warstwy front-end dla kont API, czyli: identyfikatory organizacyjne/użytkownika i podstawowe atrybuty profilu (imię/nazwa, e-mail), informacje o urządzeniu/przeglądarce/OS, referrery i przybliżona geolokalizacja z przeglądarki. Nie obejmuje to treści promptów, usage logs API ani sekretów.

Łańcuch dostawców (vendor risk): incydent ilustruje ekspozycję ryzyka przez integracje telemetryczno-analityczne w produktach SaaS, gdzie dane PII i identyfikatory techniczne są rutynowo przetwarzane przez podmioty trzecie. Niezależne doniesienia branżowe (SecurityWeek, The Register) potwierdzają timeline i działania OpenAI (odpięcie Mixpanel, notyfikacje).

Praktyczne konsekwencje / ryzyko

  • Spear-phishing & impersonation: baza adresów e-mail + atrybuty kont organizacyjnych mogą posłużyć do precyzyjnego podszywania się (np. rzekome „pilne” komunikaty o rotacji kluczy API OpenAI, faktury, „security advisory”).
  • Rekonesans techniczny: informacje o przeglądarce/OS i refererach mogą ułatwić dobór payloadów lub łańcuchów exploitów webowych (fingerprinting).
  • Korelacja tożsamości: powiązanie e-mail ↔ org/user ID ułatwia mapowanie zespołów developerskich w organizacjach.
  • Ryzyko wtórne u innych klientów Mixpanel: jeżeli organizacja używa Mixpanel w wielu produktach, warto zbadać spójność konfiguracji i zasięg danych. Relacje o wpływie na CoinTracker sugerują efekt „multi-tenant blast radius”. (Uwaga: doniesienia zewnętrzne, nie komunikat OpenAI).

Rekomendacje operacyjne / co zrobić teraz

Dla właścicieli kont OpenAI API (org/admin):

  1. Utwierdź MFA/SSO & phishing-resistant MFA (WebAuthn/FIDO2) dla adminów i developerów.
  2. Wdroż policyjne kontrole anty-phishingowe: DMARC p=reject, DKIM, SPF; uzupełnij security banners i URL detonation/sandbox w secure email gateway.
  3. Ustaw reguły detekcji (SIEM/EDR/SOAR): IOC z komunikatu Mixpanel (jeśli udostępnił), alerty na tematy wiadomości: „OpenAI API key rotation”, „Mixpanel incident”, itp. oraz na domeny-lookalike.
  4. Komunikacja do developerów: jasny playbook – nie klikamy linków z e-maili dotyczących OpenAI/kluczy; panel odwiedzamy tylko przez ręczne wejście na platform.openai.com.
  5. Przegląd dostawców (TPRM): skataloguj wszystkie integracje analityczne/telemetryczne (Mixpanel, GA, PostHog itp.), zweryfikuj zakres PII/ID, okres retencji i mechanizmy anonimizacji.
  6. Monitoring nadużyć: szukaj kampanii spear-phishing do aliasów dev/API; rozważ tymczasowe wzmocnienie rate-limitów i kontroli anomalii dla zarządzania kluczami.
  7. Ocena prawna i notyfikacje: jeśli w twojej organizacji wyciekały dane PII użytkowników końcowych przez analogiczne integracje, skonsultuj obowiązki notyfikacyjne (RODO/UK GDPR/CCPA).

Dla zespołów SOC/IR: szybkie „hunt queries” (przykłady):

  • Telemetria poczty: subject contains ("Mixpanel" OR "OpenAI") AND body contains ("security incident" OR "key rotation" OR "API") w ostatnich 14–30 dniach.
  • DNS/Proxy: detekcja nowo zarejestrowanych domen typosquatting dla openai.com, platform.openai.com, mixpanel.com.
  • EDR: nietypowe uruchomienia przeglądarki z parametrami --disable-features=SafeBrowsing, „headless” itp. po kliknięciu w linki.

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

W przeciwieństwie do głośnych wycieków treści czatów lub danych billingowych, tutaj mamy klasyczny „vendor breach” w łańcuchu dostaw: ekspozycja metadanych i PII o niskiej/średniej wrażliwości, ale o dużej wartości do socjotechniki. Schemat przypomina incydenty u zewnętrznych procesorów (MarTech/Analytics), gdzie realne ryzyko wynika z łączności identyfikatorów technicznych z danymi kontaktowymi — paliwo dla spear-phishingu. Relacje branżowe (SecurityWeek, The Register) potwierdzają, że reakcją OpenAI było odpięcie dostawcy i przegląd całego ekosystemu vendors.

Podsumowanie / kluczowe wnioski

  • Najważniejsze ryzyko jest socjotechniczne, nie kryptograficzne: oczekuj falowych kampanii podszywania się pod OpenAI/„Security Team”.
  • Programy TPRM powinny traktować integracje analityczne jako procesory PII i mieć dla nich odrębne oceny ryzyka, retencję i zasady maskowania.
  • OpenAI zareagowało szybko (odpięcie Mixpanel, FAQ, notyfikacje), ale incydent przypomina, że telemetria front-end często niesie więcej PII niż zakładamy.

Źródła / bibliografia

  1. OpenAI — What to know about a recent Mixpanel security incident, 26–27 XI 2025. (OpenAI)
  2. Mixpanel — Our response to a recent security incident, 27 XI 2025. (mixpanel.com)
  3. BleepingComputer — OpenAI discloses API customer data breach via Mixpanel vendor hack, 27 XI 2025. (zawiera też wzmianki o CoinTracker) (BleepingComputer)
  4. SecurityWeek — OpenAI User Data Exposed in Mixpanel Hack, 27 XI 2025. (SecurityWeek)
  5. The Register — OpenAI dumps Mixpanel after analytics breach hits API users, 27 XI 2025. (The Register)

Polska zatrzymała obywatela Rosji podejrzanego o włamania do systemów firm. Co wiemy i jak się zabezpieczyć?

Wprowadzenie do problemu / definicja luki

27 listopada 2025 r. polskie służby zatrzymały w Krakowie obywatela Rosji podejrzanego o nieuprawnioną ingerencję w systemy teleinformatyczne polskich firm, w tym włamania do baz danych (co najmniej jednego sklepu internetowego). Sąd zastosował trzymiesięczny areszt tymczasowy. Sprawa ma charakter rozwojowy i wpisuje się w szerszy wzorzec rosyjskich operacji sabotażowo-szpiegowskich w regionie.

W skrócie

  • Miejsce i data: Kraków, zatrzymanie 16 listopada; publicznie ogłoszone 27 listopada 2025 r.
  • Podejrzenia: przełamywanie zabezpieczeń IT polskich firm i dostęp do baz danych (e-commerce).
  • Status prawny: 3 miesiące aresztu; śledztwo trwa.
  • Wątki poboczne: mężczyzna miał nielegalnie wjechać do Polski w 2022 r., a w 2023 r. uzyskać status uchodźcy (informacje operacyjne służb).
  • Szerszy kontekst: wzrost liczby incydentów sabotażowych i cyberataków powiązanych z Rosją w Polsce i UE.

Kontekst / historia / powiązania

Zatrzymanie nastąpiło równolegle do serii aktów sabotażu i kampanii cyberszpiegowskich w Europie, które władze w Warszawie wiążą z rosyjską „wojną hybrydową”. Premier i resorty siłowe w ostatnich tygodniach alarmują o eskalacji zagrożeń, m.in. po incydentach na infrastrukturze kolejowej. W reakcji państwo wzmacnia ochronę krytycznej infrastruktury i ogłasza inicjatywy techniczne (np. osłona anty-dronowa). Choć sprawa krakowska dotyczy firm prywatnych, narracja służb wskazuje na łączny efekt presji informacyjno-technicznej ze wschodu.

Analiza techniczna / szczegóły luki

Publicznie dostępne informacje są ograniczone — śledczy nie ujawnili TTPs (techniques, tactics and procedures) ani konkretnego wektora wejścia. Wiemy jednak, że mowa o „przełamywaniu zabezpieczeń” i nieuprawnionym dostępie do baz danych firm, w tym e-commerce. Na tym etapie należy rozważyć najbardziej typowe dla branży wektory ataku na aplikacje webowe i sklepy online:

  1. Błędy w warstwie aplikacji (OWASP Top 10):
    • SQLi/NoSQLi prowadzące do zrzutu tabel z danymi klientów, zamówień i tokenów sesyjnych.
    • Insecure Direct Object Reference (IDOR) i błędy uprawnień pozwalające na eskalację dostępu do paneli administracyjnych.
    • Deserializacja / RCE w wtyczkach CMS/commerce.
  2. Ataki na uwierzytelnianie i sesję:
    • Credential stuffing z paczek wyciekłych haseł, słabe MFA lub jego brak.
    • Session fixation / hijacking przy błędnej konfiguracji cookies i SSO.
  3. Łańcuch dostaw i dostęp uprzywilejowany:
    • Kompromitacja kont partnerów (agencje, software-house’y, hosting).
  4. Eksfiltracja:
    • Zrzut baz (logical backup dump), kopiowanie S3/Blob, lub transfer przez kanały C2 w HTTPS/DNS-over-HTTPS.

Podkreślamy: powyższe to uzasadnione scenariusze ryzyka, a nie potwierdzone fakty w tej konkretnej sprawie — organy ścigania nie podały publicznie technicznych detali.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieku danych klientów (PII, adresy, telefony, e-maile, skróty haseł) i fraud (przejęcia kont, chargebacki, phishing wtórny).
  • Ryzyko prawne: kary administracyjne (RODO), roszczenia klientów, obowiązki notyfikacyjne do UODO.
  • Ryzyko operacyjne: przestoje sklepów, konieczność rotacji sekretów (API keys, JWT, klucze płatności), audyty powdrożeniowe.
  • Ryzyko reputacyjne i regulacyjne: presja komunikacyjna w kontekście wojny hybrydowej zwiększa koszty incydentu.

Rekomendacje operacyjne / co zrobić teraz

Dla firm e-commerce i dostawców IT:

  1. Twarde minimum techniczne (48–72h):
    • Wymuś MFA wszędzie (panel admin, VPN, Git, helpdesk, CRM).
    • Rotacja haseł/sekretów i unieważnienie wszystkich tokenów sesyjnych.
    • Log review 30–90 dni: nietypowe logowania, masowe odczyty DB, eksporty, anomalia w łańcuchu zapytań (np. długie SELECTy).
    • Blokady WAF/IPS dla wzorców SQLi/XSS/Path Traversal; aktualizacja sygnatur.
    • Egress filtering: blokuj nieznane destynacje i tunelowanie DNS/DoH.
  2. Środki średnioterminowe (2–6 tygodni):
    • Testy penetracyjne i SAST/DAST kluczowych modułów sklepu; przegląd wtyczek CMS (usunięcie porzuconych).
    • Segregacja uprawnień (least privilege) + JIT access dla administracji.
    • Backup & restore drill: test odtwarzania bazy i plików (RPO/RTO realne, nie „na papierze”).
    • Monitoring behawioralny: reguły w SIEM/EDR (np. masowe SELECT, mysqldump/pg_dump, nieplanowane snapshoty).
  3. Procesy i zgodność:
    • Gotowy plan komunikacji kryzysowej (szablony RODO, Q&A dla klientów).
    • Threat intel: subskrypcje wskaźników kompromitacji (IOC) i TTP grup atakujących e-commerce; korelacja z własnymi logami.
  4. Współpraca ze służbami:
    • Incydenty o cechach przestępstwa zgłaszaj do CBZC/Policji i prokuratury; zabezpieczaj dowody (image dysków, chain of custody).

Różnice / porównania z innymi przypadkami

  • Sabotaż infrastrukturalny vs. cyberwłamania do firm: ostatnie głośne sprawy dot. infrastruktury (np. kolej) mają inny profil techniczny i cel (destabilizacja, presja polityczna). W opisywanym przypadku wektor jest „cyber-przestępczy” z możliwymi implikacjami wywiadowczymi, a celem są dane biznesowe i systemy przedsiębiorstw.
  • Transgraniczność: e-commerce i SaaS sprzyjają operacjom prowadzonym z terytorium RP, ale dotykającym firm także poza granicami — media branżowe wspominają o możliwych europejskich wątkach baz danych (na razie bez szczegółów oficjalnych).

Podsumowanie / kluczowe wnioski

  • Sprawa krakowska to konkret: zatrzymany obywatel Rosji, zarzut włamań do systemów firm, areszt na 3 miesiące.
  • Szczegóły techniczne nie zostały ujawnione — firmy nie powinny czekać na komunikaty, tylko samoocenić ekspozycję i wdrożyć środki redukcji ryzyka typowe dla ataków na e-commerce.
  • Zjawisko wpisuje się w szerszą eskalację działań hybrydowych w regionie; oczekujmy większej presji na bezpieczeństwo aplikacji webowych i łańcucha dostaw IT.

Źródła / bibliografia

  • The Record: „Poland detains Russian citizen suspected of hacking local firms” (27 XI 2025). (The Record from Recorded Future)
  • Reuters: „Poland arrests Russian suspected of hacking Polish companies” (27 XI 2025). (Reuters)
  • CyberDefence24: „Ataki na polskie firmy. Rosjanin zatrzymany przez CBZC” (27 XI 2025). (cyberdefence24.pl)
  • Rzeczpospolita: „Rosyjski haker zatrzymany w Krakowie. CBZC: sprawa jest rozwojowa” (27–28 XI 2025). (Rzeczpospolita)
  • Polskie Radio (EN): „Russian national arrested in Kraków over alleged cyberattacks on Polish firms” (27 XI 2025). (Polskie Radio online)

CVE-2019-18935 — Progress Telerik UI for ASP.NET AJAX RCE (RadAsyncUpload / .NET deserialization)

TL;DR

Krytyczna podatność w Telerik UI for ASP.NET AJAX (do 2019.3.1023) pozwala na zdalne wykonanie kodu poprzez niezabezpieczoną deserializację JSON w komponencie RadAsyncUpload, zwykle w kontekście procesu w3wp.exe. Często wymaga znajomości kluczy szyfrujących (np. MachineKey) — możliwych do pozyskania m.in. przez starsze luki CVE‑2017‑11317/11357 — i jest powszechnie wykorzystywana w łańcuchach ataku (CISA KEV). Zalecenie: aktualizacja co najmniej do R1 2020 (2020.1.114), rotacja kluczy, włączenie WAF oraz proaktywna detekcja ruchu do Telerik.Web.UI.WebResource.axd?type=rau i procesów potomnych w3wp.exe.


Krótka definicja techniczna

CVE‑2019‑18935 to luka typu .NET deserialization w RadAsyncUpload (Telerik UI for ASP.NET AJAX), prowadząca do RCE po dostarczeniu specjalnie przygotowanych danych do endpointu m.in. Telerik.Web.UI.WebResource.axd?type=rau. Od wersji 2020.1.114 domyślne ustawienie łagodzi błąd; w 2019.3.1023 istnieje ustawienie niefabryczne ograniczające wektor. Często wykorzystywana łącznie z CVE‑2017‑11317/11357, które ułatwiają pozyskanie kluczy szyfrujących uploadera.


Gdzie występuje / przykłady platform

  • Windows / IIS – typowe środowisko dla aplikacji ASP.NET korzystających z Telerik UI (komponenty front‑end na serwerze).
  • Aplikacje firm trzecich (np. platformy CMS/CRM, jak Sitecore w starszych buildach, które pakowały Telerik UI) – ryzyko pośrednie, gdy komponent jest zależnością.
  • Chmura (IaaS/PaaS) – instancje IIS za ALB/WAF (AWS) lub Application Gateway/WAF (Azure); sama luka jest aplikacyjna, ale ślady widać w dziennikach WAF/ALB.

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

  • Wektor: żądanie HTTP (zwykle POST) do /Telerik.Web.UI.WebResource.axd?type=rau z ładunkiem, który po stronie serwera trafia do deserializacji przez JavaScriptSerializer, umożliwiając wstrzyknięcie obiektu prowadzące do RCE.
  • Warunek sprzyjający: atak jest trivialny, gdy napastnik zna/odzyska klucze szyfrowania uploadera (MachineKey, parametry RadAsyncUpload) — często poprzez wcześniejsze błędy CVE‑2017‑11317/11357 (słaba kryptografia RAU) lub wyciek web.config.
  • Efekt: wykonanie kodu w kontekście IIS Worker Process (w3wp.exe), często skutkujące uruchomieniem cmd.exe/powershell.exe, zrzutem webshella lub ściągnięciem narzędzi.
  • Dlaczego skuteczna:
    1. komponent szeroko rozpowszechniony (często “ukryty” jako zależność),
    2. endpoint RAU bywa rzadko monitorowany,
    3. łatwo ukryć się w normalnym ruchu HTTP(S),
    4. luka jest w KEV, więc aktywnie skanowana/wykorzystywana przez wiele grup.
  • Remediacja producenta: w R1 2020 (2020.1.114) dodano bezpieczne domyślne ustawienia, starsze łatki nie wystarczają — zalecana aktualizacja do ≥ 2020.1.114.

Artefakty i logi

ŹródłoCo szukaćPrzykłady pól / EIDUwaga
IIS W3CŻądania do Telerik.Web.UI.WebResource.axd?type=rau, nietypowe POST z dużym cs-bytes, 4xx/5xx przy próbachcs-uri-stem, cs-uri-query, cs-method, sc-status, time-taken, c-ipACSC wskazuje, że ruch do ...WebResource.axd?type=rau jest wart analizy.
Windows SecurityProcesy potomne w3wp.execmd.exe/powershell.exeEID 4688 (Process Creation)Koreluj z kontem serwisowym aplikacji.
SysmonUtworzenie podejrzanych plików w webroot (np. *.aspx, *.ashx), potomne procesy w3wp.exeEID 1 (ProcessCreate), EID 11 (FileCreate)Szukaj plików w C:\inetpub\wwwroot\ lub App_Data\RadUploadTemp\.
WAF/ALB (AWS)HTTP do ...WebResource.axd z type=rauWAF logs (httpRequest.uri,httpRequest.args)CloudTrail nie loguje treści HTTP — analizuj WAF/ALB.
Azure WAF / AppGWJak wyżejrequestUri_s, requestQuery_s, httpMethod_sWłącz diagnostykę do Log Analytics.
EDR (MDE/Elastic/…)w3wp.exe spawnuje interpreterynazwy procesów, dow. rodz.Wysoka wartość korelacyjna.
K8s audit / M365 UAL / ESXi[nie dotyczy]Aplikacyjna luka .NET na IIS.

Detekcja (praktyczne reguły)

Sigma (IIS – próby RAU)

title: Telerik RAU Endpoint POST Indicative of CVE-2019-18935
id: 7f2a3e27-2e2c-4b8a-9c9f-rau-iis
status: experimental
description: Wykrywa POST na Telerik.Web.UI.WebResource.axd?type=rau (RadAsyncUpload)
references:
  - https://www.cyber.gov.au/.../advisory-2020-004-remote-code-execution...  # ACSC
logsource:
  category: webserver
  product: iis
detection:
  sel_uri:
    cs-uri-stem|contains: 'Telerik.Web.UI.WebResource.axd'
  sel_query:
    cs-uri-query|contains: 'type=rau'
  sel_method:
    cs-method: 'POST'
  condition: sel_uri and sel_query and sel_method
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - cs-uri-query
  - sc-status
  - time-taken
falsepositives:
  - Legalny RadAsyncUpload w aplikacjach używających Telerik (zwłaszcza stare wersje)
level: high

Sigma (Windows – potomne procesy w3wp.exe)

title: Suspicious Interpreter Spawned by w3wp.exe
id: e6b6b494-8c6e-4c22-9e63-w3wp-spawn
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\w3wp.exe'
  child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\cscript.exe'
      - '\wscript.exe'
  condition: parent and child
fields:
  - UtcTime
  - User
  - CommandLine
  - ParentCommandLine
  - Image
  - ParentImage
level: high

Splunk (SPL)

IIS / WAF – próby RAU:

(index=web OR sourcetype=iis* OR sourcetype="aws:waf" OR sourcetype="azure:appgw")
| eval method=coalesce(cs_method, httpMethod_s, httpRequest.httpMethod, method)
| eval uri_stem=coalesce(cs_uri_stem, uri, requestUri_s, httpRequest.uri)
| eval uri_query=coalesce(cs_uri_query, query, requestQuery_s, httpRequest.args)
| search uri_stem="*Telerik.Web.UI.WebResource.axd*" (uri_query="*type=rau*" OR uri_stem="*DialogHandler.aspx*") method=POST
| stats count min(_time) as first max(_time) as last by method uri_stem uri_query src c_ip httpRequest.clientIp sc_status

Windows Security (4688) – potomne interpretery:

source="WinEventLog:Security" EventCode=4688
ParentProcessName="*\\w3wp.exe"
(NewProcessName="*\\cmd.exe" OR NewProcessName="*\\powershell.exe" OR NewProcessName="*\\mshta.exe" OR NewProcessName="*\\rundll32.exe" OR NewProcessName="*\\cscript.exe" OR NewProcessName="*\\wscript.exe")
| stats count by ComputerName, SubjectUserName, ParentProcessName, NewProcessName, CommandLine, ParentCommandLine

KQL (Defender for Endpoint / Azure)

MDE – procesy potomne:

DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

Azure WAF / AppGW (Log Analytics):

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where requestUri_s has "Telerik.Web.UI.WebResource.axd"
| where requestQuery_s has "type=rau" and httpMethod_s == "POST"
| project TimeGenerated, clientIp_s, httpMethod_s, requestUri_s, requestQuery_s, ruleSetType_s, action_s

CloudTrail / CloudWatch (AWS)

Uwaga: CloudTrail nie rejestruje treści HTTP aplikacji. Do detekcji użyj AWS WAF logs (CloudWatch Logs) lub ALB access logs.
CloudWatch Logs Insights (WAF):

fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, httpRequest.httpMethod, action
| filter httpRequest.uri like /Telerik\.Web\.UI\.WebResource\.axd/ 
  and httpRequest.args like /type=rau/ 
  and httpRequest.httpMethod = "POST"
| sort @timestamp desc
| limit 200

Elastic (KQL/EQL)

HTTP (Elastic APM / ingest):

url.path:"/Telerik.Web.UI.WebResource.axd" and url.query:*type\=rau* and http.request.method:POST

EQL – potomne procesy:

process where process.parent.name == "w3wp.exe" and
        process.name in ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")

Heurystyki / korelacje

  • Korelacja 1: IIS RAU POST(±5 min)w3wp.exe -> cmd.exe/powershell.exe(±5 min) ➜ nowe pliki .aspx/.ashx w webroot.
  • Korelacja 2: Ten sam IP źródłowy generuje wiele 4xx/5xx na RAU i inne ścieżki eksploracyjne.
  • Korelacja 3: Nowe połączenia wychodzące z serwera WWW (który normalnie nie inicjuje ruchu) po RAU‑POST.
  • Korelacja 4: RAU‑POST + znany User‑Agent skanera + rzadkie geolokalizacje.
  • Korelacja 5: W środowiskach z WAF – zdarzenia “allowed but matched rule” dla WebResource.axd + POST.

ACSC i CISA opisują użycie CVE‑2019‑18935 w kampaniach, gdzie po eksploatacji dochodziło do dalszych etapów (webshelle, narzędzia).


False positives / tuning

  • FP: legalne użycie RadAsyncUpload w Twojej aplikacji (stary Telerik), testy QA.
  • Tuning:
    • Ogranicz do method=POST + type=rau.
    • Biała lista znanych klientów (adresy IP, CIDR) lub kont użytkowników aplikacji.
    • Podnieś priorytet, gdy sc-status ∈ {500, 400, 404} lub time‑taken & cs-bytes nienaturalnie duże.
    • W procesach – alertuj tylko, gdy rodzicem jest w3wp.exe i dzieckiem interpreter/skryptor.

Playbook reagowania (IR)

  1. Triage i izolacja: odizoluj host IIS z ruchu wychodzącego (segmentacja/egress filter).
  2. Zabezpieczenie dowodów:
    • zrzut pamięci w3wp.exe i kopia logów IIS/WAF/EDR,
    • kopia webroot (hashy) i web.config.
  3. Szybka analiza:
    • wyszukaj artefakty wg sekcji 6 (procesy potomne, nowe pliki w webroot),
    • przejrzyj żądania ...WebResource.axd?type=rau (czas, źródła).
  4. Eradykacja: usuń webshelle, backdoory, zaplanuj aktualizację Telerik ≥ 2020.1.114, rotację MachineKey, wymuś redeploy.
  5. Hunting w domenie: sprawdź lateral movement od konta serwisowego aplikacji.
  6. Hardening:
    • WAF reguły na RAU, blokada publicznego dostępu do uploadów,
    • minimalne uprawnienia konta aplikacyjnego, App_Data bez exec,
    • monitoring w3wp.exe ➜ interpretery.
  7. Zgłoszenie i lessons learned: KEV/CSIRT, aktualizacja runbooków.

Przydatne polecenia (PowerShell, bezpieczne):

# Nowe pliki skryptowe w webroot z ostatnich 7 dni
Get-ChildItem -Recurse "C:\inetpub\wwwroot" -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } | Select FullName,Length,LastWriteTime

# Procesy potomne w3wp.exe (MDE lub lokalnie)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 |
  Where-Object { $_.Properties[1].Value -like '*\w3wp.exe' } |
  Select TimeCreated, @{n='NewProcess';e={$_.Properties[5].Value}}, @{n='Cmd';e={$_.Properties[8].Value}}

Przykłady z kampanii / case studies

  • CISA AA23‑074A: aktorzy APT eksploatowali CVE‑2019‑18935 w środowisku rządowym USA (IIS), często łącząc z CVE‑2017‑11317/11357.
  • Blue Mockingbird (Red Canary): w logach IIS widoczny RAU; po eksploatacji uruchamiano cmd.exe/powershell.exe, kończąc na kopaniu kryptowalut.
  • Raporty 2025 (eSentire): luka nadal popularnym wektorem wejścia do dostarczenia reverse shelli i eskalacji uprawnień.
  • ACSC (2020): wskazówki detekcyjne i dowody aktywnej eksploatacji — analiza ruchu do ...WebResource.axd?type=rau.

Lab (bezpieczne testy)

Tylko w odizolowanym środowisku testowym i na załatanych instancjach:

  1. Symulacja hałasu detekcyjnego (IIS/WAF): curl -X POST "https://twoj-serwer.test/Telerik.Web.UI.WebResource.axd?type=rau" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data "probe=1" Sprawdź, czy pipeline logów/warnów (IIS/WAF/SIEM) wyłapuje zdarzenie (bez żadnej próby eksploatacji).
  2. Symulacja anomalii procesów:
    Uruchom prosty skrypt deployu aplikacji, który nie powinien generować w3wp.exe -> cmd.exe. Zweryfikuj, że reguła z 7.2 nie alarmuje (kalibracja FP).
  3. Testy WAF: utwórz regułę blokującą WebResource.axd + type=rau, potwierdź zadziałanie w logach.

Mapowania (Mitigations, Powiązane techniki)

Technika główna: T1190 Exploit Public‑Facing Application (Initial Access).

Powiązane techniki po eksploatacji:

  • T1505.003 – Web Shell (utrwalenie/remote admin przez .aspx).
  • T1059.001 – PowerShell.
  • T1059.003 – Windows Command Shell.
  • T1105 – Ingress Tool Transfer.

Mitigations (ATT&CK):

  • M1051 – Update Software (patchowanie komponentu do ≥ 2020.1.114).
  • M1050 – Exploit Protection (OS mitigation, hardening, DEP/CFG, itd.).
  • M1037 – Filter Network Traffic (WAF; filtrowanie warstwy 7).
  • M1047 – Audit (systematyczny przegląd konfiguracji i logów).

Źródła / dalsza literatura

  • NVD CVE‑2019‑18935 – opis, wersje, noty o ustawieniach w 2019.3.1023/2020.1.114. (NVD)
  • Telerik KBAllows JavaScriptSerializer Deserialization; Unrestricted File Upload (RAU); rekomendacja upgrade do R1 2020. (Telerik.com)
  • CISA AA23‑074A – kampanie wykorzystujące CVE‑2019‑18935 (IIS w agencji FCEB). (CISA)
  • ACSC 2020‑004 – wskazówki detekcyjne dla ...WebResource.axd?type=rau. (Cyber.gov.au)
  • Red Canary (Blue Mockingbird) – wskazówki huntingowe (IIS + potomne procesy). (Red Canary)
  • Bishop Fox – przegląd techniczny deserializacji w Telerik UI. (Bishop Fox)
  • CISA Top Routinely Exploited Vulns / KEV – kontekst operacyjny i priorytetyzacja. (CISA)
  • MITRE ATT&CK v18 – wersjonowanie i matryca Enterprise. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC:

  • Reguły na WebResource.axd?type=rau + POST w IIS/WAF/ALB.
  • Korelacja: w3wp.exe → interpretery (cmd/PowerShell/mshta/rundll32).
  • Monitoring nowych plików w webroot (rozszerzenia .aspx/.ashx).
  • Blokady WAF + alerty “match but allow” dla RAU.
  • Threat hunting na źródła z KEV i znane UA skanerów.

CISO / właściciel usługi:

  • Upgrade Telerik ≥ 2020.1.114, weryfikacja zależności pośrednich.
  • Rotacja MachineKey i tajemnic aplikacji po incydencie.
  • WAF w trybie blokującym dla uploadów; brak exec w katalogach upload.
  • Minimalne uprawnienia konta aplikacji IIS.
  • Testy regresyjne i skany zewnętrzne po patchu.

Fluent Bit: 5 nowych luk pozwala przejąć usługi w chmurze (CVE-2025-12969/70/72/77/78)

Wprowadzenie do problemu / definicja luki

Oligo Security opisało łańcuch pięciu podatności we Fluent Bit – popularnym, lekkim agencie telemetrii do logów/metryk/tras – który może prowadzić do przejęcia usług chmurowych. Luki obejmują m.in. path traversal z zapisem plików, przepełnienie bufora w wtyczce Docker, fałszowanie i korupcję tagów oraz bypass uwierzytelniania w protokole forward. Producent wydał poprawki w gałęziach 4.1.x i 4.0.x.


W skrócie

  • CVE-2025-12972 – brak sanityzacji tagów przy generowaniu nazw plików w out_filepath traversal i potencjalny RCE.
  • CVE-2025-12970stack buffer overflow w wejściu Docker przy ekstremalnie długich nazwach kontenerów → DoS/RCE.
  • CVE-2025-12978 – częściowe porównanie Tag_Keyspoofing tagów i obchodzenie filtrów/routingu.
  • CVE-2025-12977 – niewłaściwa walidacja wejścia dla tagów z pól użytkownika → korupcja logów/atak na wyjścia.
  • CVE-2025-12969bypass uwierzytelniania w in_forward, gdy ustawiono tylko Security.Users.
  • Wersje naprawcze: zaktualizuj do Fluent Bit 4.1.1 lub 4.0.12 (LTS) – poprawki backportowane.

Kontekst / historia / powiązania

Fluent Bit jest szeroko wykorzystywany (AI-labsy, bankowość, dostawcy chmury). To nie pierwsze problemy bezpieczeństwa: w 2024 r. głośna była luka CVE-2024-4323 „Linguistic Lumberjack” w wbudowanym serwerze HTTP (DoS/ujawnienie informacji/RCE). Nowy zestaw CVE uderza w inną powierzchnię ataku (tagowanie, plikowe wyjścia, wejścia Docker/forward/Splunk/Elasticsearch) i może być łączony w łańcuchy do pełnego przejęcia pipeline’u logów.


Analiza techniczna / szczegóły luki

1) CVE-2025-12972 – Path traversal w out_file

  • Błąd: tag (często kontrolowany przez klienta) jest używany do budowy nazwy pliku, gdy brak klucza File; brak filtracji ../.
  • Skutek: zapis/nadpisanie dowolnych ścieżek → tampering logów lub RCE (np. przez zapis pliku konfig./skryptu w wykonywalnej lokalizacji).
  • Dotyczy: konfiguracji z dynamicznymi tagami + out_file bez File.

2) CVE-2025-12970 – Przepełnienie bufora w wejściu Docker

  • Błąd: kopiowanie nazwy kontenera do stałego bufora 256B bez weryfikacji długości.
  • Skutek: DoS agenta lub RCE na hostowym procesie Fluent Bit.
  • Warunek: atakujący może utworzyć kontener / wpływać na jego nazwę.

3) CVE-2025-12978 – Częściowe dopasowanie Tag_Key

  • Błąd: porównanie tylko pierwszego znaku klucza pola JSON skonfigurowanego w Tag_Key (HTTP/Splunk/Elasticsearch).
  • Skutek: spoofing tagów, obchodzenie filtrów i przekierowanie strumieni.

4) CVE-2025-12977 – Niewłaściwa walidacja wejścia dla tagów

  • Błąd: tagi tworzone z pól użytkownika omijają sanityzację (wstrzyknięcia znaków sterujących, sekwencji).
  • Skutek: korupcja logów lub ataki na wyjścia downstream.

5) CVE-2025-12969 – Bypass uwierzytelniania w in_forward

  • Błąd: przy konfiguracji tylko Security.Users uwierzytelnianie nie jest egzekwowane; dopiero Shared_Key +/- Security.Users działa poprawnie.
  • Skutek: nieautoryzowana injekcja logów, flood alertów, zatruwanie telemetrii.

Wersje z poprawkami

Wydania 4.1.1 i 4.0.12 zawierają m.in. poprawki: „sanitize incoming Tag to prevent path traversal”, „fix tag_key lookup”, „Fix user authentication…”, „add helper for container name parsing”.


Praktyczne konsekwencje / ryzyko

  • Ukrywanie śladów: nadpisywanie/usuwanie artefaktów w logach oraz przekierowanie do „bezpiecznych” destination.
  • Eskalacja węzłowa: RCE w kontekście agenta → pivot do hosta/pods.
  • Ataki na procesy bezpieczeństwa: zalew fałszywych zdarzeń, zatruwanie źródeł danych SIEM/UEBA.
  • Wpływ na SLO/observability: DoS na agencie → utrata widoczności/monitoringu w krytycznych usługach.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacje (priorytet krytyczny)

  • Produkcja: natychmiast 4.1.1 (gałąź 4.1) lub 4.0.12 (gałąź 4.0).
  • Dla obrazów AWS aws-for-fluent-bit: użyj wersji wskazanej przez AWS po migracji do 4.1.1.

2) Twarde zabezpieczenie konfiguracji

  • out_file: zawsze ustawiaj File (konkretna nazwa), nie opieraj nazwy pliku na tagu; rozważ separację katalogów i brak uprawnień do wykonywania.
  • Wejścia HTTP/Splunk/Elasticsearch: ogranicz Tag_Key lub wyłącz dynamiczne tagowanie od klienta; filtruj dopuszczalne wartości (regex allow-list).
  • in_forward: wymuś Shared_Key oraz – jeśli potrzebne – dopiero Security.Users dodatkowo; nigdy Security.Users solo.
  • in_docker: polityka nazw kontenerów (np. długość < 128, zestaw znaków), walidacja po stronie orkiestratora/CI.

3) Redukcja powierzchni ataku

  • Ogranicz dostęp sieciowy do portów wejściowych Fluent Bit (np. HTTP/forward/Splunk/Elasticsearch) do zaufanych CIDR/ServiceAccount/Namespace; w K8s egzekwuj NetworkPolicy.
  • Uruchamiaj agenta z least privilege (read-only FS, no-new-privileges, seccomp, ograniczone capabilities).
  • Oddziel dane/konfigurację w wolumenach nie-wykonywalnych.

4) Monitoring i detekcja (pod rękę dla SOC)

  • Szukaj tagów z ../, znakami sterującymi, nowymi liniami, lub podejrzanie długich nazw kontenerów.
  • Alertuj na nieoczekiwane tworzenie plików przez proces Fluent Bit poza ścieżką docelową (FIM/eBPF).
  • Telemetria: wzrost błędów routingu/tagowania, skoki 5xx w wejściu HTTP, nagłe przełączenia destination.
  • Logika korelacyjna: burst zdarzeń z in_forward bez poprawnego Shared_Key. (zob. opisy błędów i fixów)

5) Hardening łańcucha dostaw

  • „Pin” obrazy Fluent Bit do konkretnych tagów (4.1.1/4.0.12+) i digestów; skanuj SBOM; egzekwuj PodSecurityStandards.

Różnice / porównania z innymi przypadkami

  • vs. CVE-2024-4323 (Linguistic Lumberjack): tam rdzeniem był błąd parsera HTTP i pamięci w serwerze wbudowanym; obecny zestaw uderza w logikę tagów/IO oraz autoryzację i może zostać złączony w łańcuch prowadzący do trwałej manipulacji pipeline’em (m.in. przez out_file).

Podsumowanie / kluczowe wnioski

  • Pięć nowych CVE we Fluent Bit umożliwia RCE, DoS, spoofing tagów i bypass auth – realne ryzyko przejęcia i ukrycia działań atakującego.
  • Patch now: 4.1.1 / 4.0.12 + twarde zasady konfiguracji (File w out_file, Shared_Key w in_forward, ograniczenie Tag_Key).
  • Zaimplementuj monitoring anomalii tagów/plików i politykę nazw kontenerów.
  • Potraktuj agenta logów jako komponent wysokiego ryzyka, nie „neutralną rurę”.

Źródła / bibliografia

  1. SecurityWeek – omówienie 5 CVE, wersje naprawcze i wpływ na chmurę. (SecurityWeek)
  2. Oligo Security – raport techniczny z PoV, wektory ataku i porady. (Oligo Security)
  3. GitHub (Fluent Bit v4.1.1) – changelog zawierający poprawki: sanitacja tagów, fix tag_key, auth w in_forward, zmiany dla Docker. (GitHub)
  4. Fluent Bit – Release Notes v4.0.12 (gałąź 4.0.x z backportami poprawek). (fluentbit.io)
  5. The Hacker News – dodatkowy kontekst i wpływ (RCE, DoS, manipulacja tagami). (The Hacker News)

CrowdStrike: „insider” pomógł przestępcom sfabrykować rzekome włamanie. Co naprawdę się stało?

Wprowadzenie do problemu / definicja incydentu

CrowdStrike potwierdził, że rozwiązał współpracę z „podejrzanym insiderem”, który udostępnił przestępcom zrzuty ekranu ze swojego firmowego komputera. Obrazy (m.in. panel Okta SSO) trafiły na kanał Telegram grupy „Scattered Lapsus$ Hunters” i zostały wykorzystane do fałszywego sugerowania włamania do systemów CrowdStrike. Firma zaprzecza jakiejkolwiek kompromitacji oraz informuje, że sprawę przekazano organom ścigania.

W skrócie

  • Nie było włamania do systemów CrowdStrike – to, co obiegło media społecznościowe, to zrzuty ekranu udostępnione przez osobę z dostępem, a nie ślady intruzów w infrastrukturze.
  • Insider miał sprzedać zrzuty i – według relacji przestępców – oferować ciasteczka SSO; pada kwota 25 000 USD. CrowdStrike utrzymuje, że dostęp insidera został wcześniej zablokowany.
  • Hakerzy wiązali tę sprawę z rzekomym łańcuchem nadużyć wokół Gainsight/Salesforce, co firma określiła jako nieprawdziwe w kontekście CrowdStrike.

Kontekst / historia / powiązania

„Scattered Lapsus$ Hunters” to sojusz znanych grup (m.in. ShinyHunters, Scattered Spider i Lapsus$) nastawionych na socjotechnikę, wyłudzanie dostępów i ekshibicjonizm medialny. W ostatnich miesiącach przypisywali sobie fale kradzieży danych u klientów ekosystemu Salesforce i prowadzili głośne publikacje „dowodów” na Telegramie. W tym samym nurcie znalazła się narracja o Gainsight, która miała posłużyć do zbudowania wiarygodnej — ale w tym przypadku fałszywej — historii o kompromitacji CrowdStrike.

Analiza techniczna / szczegóły incydentu

Co pokazują zrzuty? Według opisów mediów, obrazy przedstawiały wewnętrzne pulpity i link do panelu Okta SSO, czyli punktu wejścia do aplikacji wewnętrznych. Same w sobie nie stanowią dowodu intruzji, a jedynie potwierdzają, że autor zrzutów miał autoryzowany dostęp (insider). To klasyczny przykład, gdy artefakt wizualny zostaje użyty jako narzędzie dezinformacji.

Wątek ciasteczek SSO i dostępu: Przestępcy twierdzili, że otrzymali ciasteczka uwierzytelniające SSO i próbowali kupować dodatkowe materiały (np. raporty dotyczące samych grup). BleepingComputer zaznacza, że zanim doszło do eskalacji, CrowdStrike już zidentyfikował insidera i odciął dostęp. To ograniczyło potencjalne skutki operacyjne.

Czym to nie jest: Brak potwierdzeń o ruchu lateralnym, wyciekach danych klientów czy uruchamianiu złośliwego kodu w środowiskach CrowdStrike. Firma konsekwentnie podkreśla brak kompromitacji systemów.

Praktyczne konsekwencje / ryzyko

  • Reputacyjne i rynkowe ryzyko „teatru włamania”: pojedyncze obrazki z paneli wewnętrznych mogą posłużyć do budowania fałszywych narracji o hacku, wywołując presję na ofiarę i jej klientów.
  • Ryzyko insiderów: nawet bez „prawdziwego” włamania, niewłaściwe ujawnienie widoku systemów (UI, nazwy zasobów, integracje) może ułatwiać przyszły OSINT, phishing ukierunkowany i sprzęganie socjotechniki (np. pod Okta/SSO).
  • Eskalacja przez łańcuch dostaw: równoległe kampanie przeciw organizacjom w ekosystemie Salesforce/Gainsight pokazują, że kontekst third-party bywa wykorzystywany do uwiarygadniania fałszywych roszczeń wobec firm trzecich.

Rekomendacje operacyjne / co zrobić teraz

  1. Twarde higieny SSO/IdP (Okta/ADFS/Azure AD):
    • Wymuś MFA odporne na phishing (FIDO2/WebAuthn, klucze sprzętowe).
    • Włącz reauth przy wrażliwych akcjach i krótkie TTL dla ciasteczek sesyjnych.
    • Ustaw detekcję anomalii sesji (geolokacja, nietypowe urządzenia, „impossible travel”).
  2. Program Insider Threat (HR + SecOps + Legal):
    • Sygnalizacja behawioralna w EDR/SIEM (masowe zrzuty ekranu, nietypowe narzędzia, przesyłki do komunikatorów).
    • Zasada najmniejszych uprawnień + szybkie offboarding i rotacja tokenów po zmianach personalnych.
  3. DLP i kontrola ekranu:
    • Blokady/ostrzeżenia dla narzędzi przechwytywania ekranu na stacjach z dostępem do systemów krytycznych.
    • Znak wodny i tagowanie środowiska (by łatwiej identyfikować źródło wycieku obrazów).
  4. Playbook na „fałszywe włamanie”:
    • Procedura szybkiego dementi z faktami technicznymi (czasy, zakres, brak IOC), koordynacja z PR i prawnikami.
    • Zabezpieczenie dowodów i notyfikacja organów ścigania – nawet jeśli incydent nie spełnia progu „breach”.
  5. Monitoring łańcucha dostaw (SaaS-to-SaaS):
    • Inwentaryzacja integracji (np. Gainsight/Salesforce) i warunkowe tokeny z minimalnymi scopes.
    • Kontrole kontraktowe: obowiązkowe MFA, logowanie, czasowe klucze, testy socjotechniki u dostawcy.

(Rekomendacje wynikają z charakteru incydentu opisanego w źródłach oraz dobrych praktyk zarządzania tożsamością i zagrożeniami insiderskimi).

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

  • Prawdziwe naruszenie: ślady włamywacza w telemetrii (IOC/TTP), nieautoryzowane sesje, exfiltracja, zmiany konfiguracyjne.
  • „Teatr włamania” (jak tutaj): autoryzowane ekrany sfotografowane przez insidera + narracja przestępców (np. „wykorzystaliśmy Gainsight”), bez potwierdzonych śladów w systemach ofiary. Takie operacje mają cel propagandowy i wymuszeniowy.

Podsumowanie / kluczowe wnioski

  • Sprawa CrowdStrike to insider misuse, a nie „external breach”. Zrzuty ekranu stały się narzędziem dezinformacji.
  • Sojusze typu „Scattered Lapsus$ Hunters” budują wiarygodne opowieści wokół realnych kampanii (np. Gainsight/Salesforce), by windować presję i żądania — nawet jeśli fakty nie potwierdzają ich roszczeń wobec konkretnej firmy.
  • Dyscyplina tożsamości (SSO/MFA), programy Insider Threat i playbook komunikacyjny to dziś obowiązkowe elementy cyberodporności.

Źródła / bibliografia

  • SecurityWeek: potwierdzenie działań CrowdStrike, opis zrzutów, dementi kompromitacji. (SecurityWeek)
  • TechCrunch: oświadczenie rzecznika CrowdStrike, kontekst Gainsight/Salesforce, charakter zrzutów. (TechCrunch)
  • BleepingComputer: szczegóły o rzekomej płatności 25 tys. USD i ciasteczkach SSO, tło „Scattered Lapsus$ Hunters”. (BleepingComputer)
  • CSO Online: zwięzłe potwierdzenie kluczowych faktów i odwołanie do materiału TechCrunch. (CSO Online)