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.
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 / komponent
Co szukać (wzorzec)
Przykład / uwagi
EID / CloudTrail / K8s / M365
ADC /var/log/httpaccess.log
Sekwencja: 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. (200
304)’ /var/log/httpaccess.log`
ADC filesystem
Nowe/zaskakujące pliki *.xml i skompilowane *.ttc2 w /netscaler/portal/templates/
Artefakt po udanym zapisie oraz renderowaniu szablonu
—
Procesy
Procesy uruchamiane przez użytkownika nobody (poza typowym httpd)
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)
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.
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.
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 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):
Utwierdź MFA/SSO & phishing-resistant MFA (WebAuthn/FIDO2) dla adminów i developerów.
Wdroż policyjne kontrole anty-phishingowe: DMARC p=reject, DKIM, SPF; uzupełnij security banners i URL detonation/sandbox w secure email gateway.
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.
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.
Przegląd dostawców (TPRM): skataloguj wszystkie integracje analityczne/telemetryczne (Mixpanel, GA, PostHog itp.), zweryfikuj zakres PII/ID, okres retencji i mechanizmy anonimizacji.
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.
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
OpenAI — What to know about a recent Mixpanel security incident, 26–27 XI 2025. (OpenAI)
Mixpanel — Our response to a recent security incident, 27 XI 2025. (mixpanel.com)
BleepingComputer — OpenAI discloses API customer data breach via Mixpanel vendor hack, 27 XI 2025. (zawiera też wzmianki o CoinTracker) (BleepingComputer)
SecurityWeek — OpenAI User Data Exposed in Mixpanel Hack, 27 XI 2025. (SecurityWeek)
The Register — OpenAI dumps Mixpanel after analytics breach hits API users, 27 XI 2025. (The Register)
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:
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.
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.
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.
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).
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.
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)
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:
komponent szeroko rozpowszechniony (często “ukryty” jako zależność),
endpoint RAU bywa rzadko monitorowany,
łatwo ukryć się w normalnym ruchu HTTP(S),
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ło
Co szukać
Przykłady pól / EID
Uwaga
IIS W3C
Żądania do Telerik.Web.UI.WebResource.axd?type=rau, nietypowe POST z dużym cs-bytes, 4xx/5xx przy próbach
(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).
Hunting w domenie: sprawdź lateral movement od konta serwisowego aplikacji.
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.
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:
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).
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).
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_file → path traversal i potencjalny RCE.
CVE-2025-12970 – stack buffer overflow w wejściu Docker przy ekstremalnie długich nazwach kontenerów → DoS/RCE.
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-12969 – bypass 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
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
SecurityWeek – omówienie 5 CVE, wersje naprawcze i wpływ na chmurę. (SecurityWeek)
Oligo Security – raport techniczny z PoV, wektory ataku i porady. (Oligo Security)
GitHub (Fluent Bit v4.1.1) – changelog zawierający poprawki: sanitacja tagów, fix tag_key, auth w in_forward, zmiany dla Docker. (GitHub)
Fluent Bit – Release Notes v4.0.12 (gałąź 4.0.x z backportami poprawek). (fluentbit.io)
The Hacker News – dodatkowy kontekst i wpływ (RCE, DoS, manipulacja tagami). (The Hacker News)
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
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”).
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.
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).
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”.
Monitoring łańcucha dostaw (SaaS-to-SaaS):
Inwentaryzacja integracji (np. Gainsight/Salesforce) i warunkowe tokeny z minimalnymi scopes.
(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)