Archiwa: SIEM - Strona 28 z 46

Fałszywe zaproszenia „Calendly” podszywają się pod topowe marki. Celem: przejęcie kont menedżerów reklam (Google Ads/Facebook)

Wprowadzenie do problemu / definicja luki

Trwa ukierunkowana kampania phishingowa wykorzystująca fałszywe zaproszenia do spotkań w stylu Calendly, która podszywa się pod rozpoznawalne marki (m.in. LVMH, Lego, Mastercard, Uber, Unilever, Disney). Atak ma na celu kradzież sesji i haseł do Google Workspace oraz przejęcie kont menedżerów reklam (Google Ads MCC) i/lub Facebook Business — co umożliwia szybkie uruchamianie malvertisingu i dalsze łańcuchy ataków. Kampanię jako pierwsi rozebrali badacze Push Security; szczegóły opisał też BleepingComputer.

W skrócie

Wejście w relację: przestępcy zaczynają od profesjonalnie przygotowanego wątku rekrutacyjnego (podszycie pod realnego pracownika), dopiero potem wysyłają link do „umówienia rozmowy” (fałszywy Calendly).
Kradzież sesji: po CAPTCHA ofiara trafia na AiTM (Attacker-in-the-Middle) lub wariant Browser-in-the-Browser (BitB), który wyłudza dane/ciasteczka logowania do Google/Facebooka i obchodzi 2FA.
Cel finansowy i zasięgowy: przejęte MCC daje kontrolę nad wieloma kontami klientów i budżetami — idealne do malvertisingu i „watering hole” z precyzyjnym targetowaniem.
Obserwowane TTPs: blokady VPN/proxy, blokowanie DevTools, parametryzacja pod domenę ofiary, rotacja dziesiątek URL-i, hosting na Odoo/Kartra.

Kontekst / historia / powiązania

Wykorzystywanie legalnych usług (calendaring, formularze, SaaS) w phishingu nie jest nowe; podobne wektory z Calendly raportowano już wcześniej. Nowością jest skala podszywania pod marki i skupienie na ekosystemach reklamowych (MCC/Business Manager), co współgra z równoległymi kampaniami malvertisingu obserwowanymi przez Push Security w Google Search.

Analiza techniczna / szczegóły luki

Łańcuch ataku:

Mail „od rekrutera” znanej marki → 2) „Zaproszenie Calendly” → 3) CAPTCHA → 4) AiTM strona logowania (Google/Facebook) → 5) przechwycenie sesji i eskalacja do kont reklamowych. W nowszych próbkach użyto BitB (fałszywe okno logowania, które sprawia wrażenie prawdziwego, wraz z „prawdziwym” URL-em w pasku pop-upu).

Techniki anty-analizy:

whitelisting domen e-mail ofiary (zablokowanie funkcji dla „nieautoryzowanych” domen),
blokowanie ruchu z VPN/proxy,
blokowanie otwarcia DevTools,
szybkie gaszenie i rotacja hostów (Odoo/Kartra).

Dlaczego BitB jest skuteczny: imituje natywne okno logowania (SSO) w przeglądarce, przez co ofiara często ufa wyglądowi i nie weryfikuje rzeczywistego origin/URL. (Patrz: materiały wyjaśniające BitB).

Praktyczne konsekwencje / ryzyko

Spalenie budżetów reklamowych w godziny, utrata dostępu do kont klientów/agencji, zły PR i chargebacki.
Malvertising w skali (precyzyjne targetowanie po kraju, domenie, urządzeniu) — „watering hole” do AiTM/malware/ClickFix.
Ryzyko wtórne: jeśli Google Workspace pełni rolę IdP/SSO, kompromitacja konta reklamowego może być trampoliną do danych i aplikacji całej organizacji.

Rekomendacje operacyjne / co zrobić teraz

Google Ads (MCC)

Włącz powiadomienia/alerty w Manager Account (np. gdy dodawane jest nowe konto/UZ), monitoruj nietypowe linkowania, ustaw reguły SIEM/SOAR na te zdarzenia.
Wymuś klucze sprzętowe (FIDO2/WebAuthn) dla kont o wysokiej wartości; AiTM obchodzi kody 2FA, ale hardware keys znacząco podnoszą poprzeczkę. (Rekomendacja także w materiałach branżowych).
Zasada „tylko z zakładek”: dostęp do Ads/Business Managera wyłącznie z firmowych zakładek/SSO portal, nigdy z reklamy czy wyników wyszukiwania. Blokuj sponsorowane wyniki dla słów typu „google ads login”.
Least privilege: zrewiduj role w MCC/Business Manager, włącz zatwierdzanie dodawania użytkowników/kont, logi zmian i dzienniki rozliczeń.

Higiena przeglądarki i hardening

Wykrywaj BitB/AiTM: szkolenia (przeciągnij okno pop-upu do krawędzi — jeśli to wciąż „wewnątrz karty”, to BitB), egzekwuj pokazywanie pełnych URL/origin, ostrzegaj przed pop-upami logowania w „nieoczekiwanych” domenach.
EDR/rozszerzenia bezpieczeństwa z detekcją anomalii w DOM i blokadą złośliwych skryptów; polityki blokujące uruchamianie DevTools nie powinny wyłączać telemetrii bezpieczeństwa.
Zasady sieciowe: blokuj kategorie hostingu współdzielonego używane w kampanii (np. Odoo/Kartra) jeśli nieużywane biznesowo; w przeciwnym razie — sandbox/isolated browsing.

Procesy SOC/IR

Playbook „MCC takeover”: natychmiastowe wylogowanie wszystkich sesji, reset kluczy/2FA, weryfikacja metod płatności, przegląd delegacji i linkowań kont, pauza wszystkich kampanii do czasu oceny szkód.
Threat hunting: szukaj świeżych logowań z nieznanych AS, nagłych zmian w kampaniach/limitach, dodanych użytkowników/aplikacji OAuth. (Push Security wskazuje, że IoC-based detections są tu mało skuteczne — liczy się TTP/behaviour).

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

W porównaniu z „zwykłym” phishingiem na konta reklamowe, obecna kampania:

Mocniej personalizuje socjotechnikę (podszycie pod konkretnego rekrutera, wieloetapowa rozmowa).
Używa AiTM/BitB do ominięcia 2FA i przejęcia sesji, a nie tylko hasła.
Łączy wektor e-mail (Calendly) z malvertisingiem w Google Search, co poszerza lejek ofiar.

Podsumowanie / kluczowe wnioski

To nie „kolejny” kalendarzowy phish — to spięcie socjotechniki z nowoczesnymi TTP (AiTM/BitB), ukierunkowane na kontrolę nad budżetami reklamowymi i zasięgami.
Agencje i działy performance powinny traktować konta MCC/Business Manager jak kontrolowane uprzywilejowane — z hardware MFA, alertami i ciągłym nadzorem zmian.
Zasada zero zaufania dla linków do logowania: tylko zakładki lub wewnętrzny portal SSO.

Bonus: mini-checklista dla SOC/IT (do wdrożenia dziś)

Wymuś FIDO2 na wszystkich kontach MCC/Business Manager.
Skonfiguruj alerty MCC i reguły w SIEM (dodanie konta, nowy user, zmiany płatności).
Zablokuj sponsorowane wyniki dla „login” w przeglądarkach firmowych/DNS.
Przeprowadź szkolenie BitB + procedurę „przeciągnij pop-up do krawędzi”.
Dodaj kontrolę odcięcia sesji i resetu 2FA dla incydentów Ads/Business.

Źródła / bibliografia

BleepingComputer — „Fake Calendly invites spoof top brands to hijack ad manager accounts”, 2 grudnia 2025. (BleepingComputer)
Push Security — „Uncovering a Calendly-themed phishing campaign targeting business ad manager accounts”, 2 grudnia 2025. (Push Security)
Push Security — „Analysing a malvertising attack targeting business Google accounts”, 2 grudnia 2025. (Push Security)
Google Ads Help — „About notifications in manager accounts (MCC)”. (Google Help)
Bolster — „Browser-in-the-Browser (BitB) phishing attacks — wyjaśnienie”. (Bolster AI)

CVE-2021-26829 — OpenPLC ScadaBR (stored XSS w system_settings.shtm)

TL;DR

CVE‑2021‑26829 to stored XSS w ScadaBR pozwalający zapisać złośliwy JavaScript w ustawieniach systemu (system_settings.shtm). W praktyce bywa wykorzystywany do deface’u HMI, manipulacji widokiem oraz wyłączania logów/alertów – CISA dodała go do KEV z dowodami aktywnej eksploatacji. Monitoruj żądania do /ScadaBR/system_settings.shtm z podejrzanymi ładunkami (<script, onerror=, javascript:), alarmuj zmiany konfiguracji/alarms, egzekwuj WAF/IPS i ogranicz ekspozycję HMI.

Krótka definicja techniczna

Stored XSS w ScadaBR polega na zapisaniu złośliwego kodu JS (np. w polu opisu/ustawień), który uruchamia się w przeglądarce operatora przy otwarciu strony. Wektor według NVD: AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, co oznacza atak z sieci, niski nakład, wymagane niskie uprawnienia i interakcja użytkownika; wpływ dotyczy gł. poufności i integralności.

Gdzie występuje / przykłady platform

Windows / Linux: ScadaBR (HMI/SCADA) uruchamiane zazwyczaj na Apache Tomcat (aplikacja Java/JSP).
Środowiska OT/ICS: panele HMI, wizualizacja procesu, często błędnie wystawiane do Internetu lub z dostępem zdalnym. (Mapowanie ATT&CK ICS poniżej).
Ślady/logi: logi Tomcata (localhost_access_log*.txt, catalina.out) oraz logi WAF/IPS/proxy.

Szczegółowy opis techniki (jak działa, cele, skuteczność)

Atakujący z niskimi uprawnieniami loguje się do ScadaBR (często z domyślnymi danymi) i wprowadza payload JS w polach renderowanych później w interfejsie (np. opis na stronie ustawień systemu). Gdy operator otwiera stronę (system_settings.shtm), przeglądarka wykonuje złośliwy skrypt, co pozwala m.in. na deface, manipulację widokiem, kradzież sesji (jeśli brak HttpOnly), czy uruchamianie akcji w imieniu operatora (CSRF‑like). W prawdziwym incydencie 2025 r. (honeypot OT) operatorzy Forescout obserwowali: deface loginu („Hacked by …”), usuwanie źródeł PLC, zmianę setpointów i wyłączenie logów/alarmów – część działań zrealizowano właśnie przez możliwość uruchomienia skryptu w HMI.

Artefakty i logi (co i gdzie szukać)

Źródło	Co szukać (przykłady wzorców)	Lokalizacja / produkt	Uwagi / mapowanie
Tomcat AccessLog	Żądania do `/ScadaBR/system_settings.shtm` z ładunkami `"<script"`, `"%3Cscript"`, `onerror=`, `javascript:`	`localhost_access_log.YYYY-MM-DD.txt` (AccessLogValve)	Warto monitorować `status`/`bytes` oraz Referer/User‑Agent.
Tomcat `catalina.out`	Błędy JSP/stacktrace po wpisaniu HTML/JS (walidacja), restart kontekstu	Linux: `/var/log/tomcat*/catalina.out`; Windows: `...\Tomcat\logs\`	Ścieżki zależne od OS/pakietu.
Log aplikacji ScadaBR	Zmiany ustawień/konfiguracji, operacje na HMI (np. System Settings updated)	typowo w katalogu aplikacji (np. `mango.log`)	Nazwy różne; w projektach ScadaBR/Mango spotyka się `mango.log`.
WAF/IPS/Proxy	Reguły XSS, signatures na `<script>`, `svg/onload`, `javascript:`	AWS WAF, Azure WAF, ModSecurity	Dobre do szybkiej blokady (virtual patching).
Windows EID (host HMI)	5156 (WFP – dopuszczenie HTTP/8080), 4624 (logon serwisu), 4688 (nietypowe procesy od Tomcata)	Dzienniki zabezpieczeń	Pośrednie – nie wykryją XSS, ale korelują późniejsze skutki.
CloudTrail	N/D (brak bezpośrednich zdarzeń) – zamiast tego: AWS WAF / ALB/CloudFront logi	CloudWatch Logs / S3	Użyj Insights/Athena do zapytań (patrz sekcja 7).
K8s Audit	Zmiany Ingress/ConfigMap/Secret dot. publicznej ekspozycji HMI	`kube-apiserver-audit.log`	Pośrednio – redukcja ekspozycji na T1190.
M365	N/D	—	Brak związku funkcjonalnego.

Detekcja (praktyczne reguły)

Sigma (webserver)

title: ScadaBR system_settings.shtm Stored XSS Attempt
id: 7b7a1a6b-0d7a-4c1b-9a78-7a8d9b7f4f21
status: experimental
description: Wykrywa próby XSS na stronie /ScadaBR/system_settings.shtm
logsource:
  category: webserver
detection:
  target:
    cs-uri-stem|contains: "/ScadaBR/system_settings.shtm"
  payload_query:
    cs-uri-query|contains:
      - "<script"
      - "%3Cscript"
      - "onerror="
      - "onload="
      - "javascript:"
  payload_body:
    request_body|contains:
      - "<script"
      - "%3Csvg%20onload"
  condition: target and (payload_query or payload_body)
fields:
  - src_ip
  - http_method
  - status
  - cs-useragent
  - cs-referrer
falsepositives:
  - testy administratorów/HMI z dozwolonym HTML (rzadkie)
level: high
tags:
  - attack.T1491.001
  - attack.T1190
  - ics.T0838

Splunk (SPL)

index=web sourcetype IN ("tomcat:access","apache:access","nginx:access")
uri_path="/ScadaBR/system_settings.shtm"
| eval q=coalesce(uri_query,request_body)
| where like(q,"%<script%") OR like(q,"%onerror=%") OR like(q,"%javascript:%")
   OR like(q,"%<svg%onload%") OR like(q,"%25%33%43script%") /* %3Cscript */
| stats count min(_time) max(_time) by src_ip, http_method, status, useragent, uri_query, request_body

KQL (Azure / CEF w Sentinel)

CommonSecurityLog
| where RequestURL has "/ScadaBR/system_settings.shtm"
| where RequestURL contains "<script" or RequestURL contains "%3Cscript"
   or RequestURL contains "onerror=" or RequestURL contains "javascript:"
| summarize cnt=count() by SourceIP, RequestMethod, RequestURL, DeviceVendor, bin(TimeGenerated, 5m)

AWS — CloudWatch Logs Insights (AWS WAF)

fields @timestamp, httpRequest.clientIp as src_ip, httpRequest.uri, httpRequest.args, httpRequest.httpMethod as method, action, terminatingRuleId
| filter httpRequest.uri like /\/ScadaBR\/system_settings\.shtm/
| filter httpRequest.args like /(<script|%3[cC]script|onerror=|javascript:)/
| stats count() by src_ip, method, httpRequest.uri, action, terminatingRuleId, bin(@timestamp, 5m)

Elastic (Kibana KQL)

(event.dataset:"tomcat.access" OR event.dataset:"apache.access" OR event.dataset:"nginx.access")
AND url.path:"/ScadaBR/system_settings.shtm"
AND (url.query:*"<script"* OR url.query:"*%3Cscript*" OR http.request.body.content:*"onerror="* OR url.full:*"javascript:"*)

Heurystyki / korelacje

Korelacja łańcucha: logowanie na HMI (często domyślne hasła) → zapis HTML/JS → nagłe wyłączenie alarmów/logów → deface/modyfikacje setpointów. (Mapuj: T1078 → T1491.001 → T0838/T0831).
User‑Agent / automaty: python-requests/nietypowe UA w krótkich odstępach vs sesje interaktywne operatorów. (por. obserwacje honeypota).
Źródła IP: hostingi/VPS (np. wzorce z raportu o TwoNet) + brak historycznego ruchu do HMI.
Anomalie konfiguracji: alerty na nagłe serie zmian ustawień HMI (alarmy, źródła PLC, opisy).

False positives / tuning

Administracyjne testy UI (rzadkie) – białe listy źródeł admina i godzin zmian; dopuszczalne są proste tagi HTML (np. <b>), ale nie script/onerror/javascript: – filtruj regexem.
Skrypty monitoringu generujące 4xx na ścieżce – odfiltrować status ≠ 200/302 dla attempt vs success.
Proxy zdrowia – wykluczyć User-Agent health‑checks.

Playbook reagowania (IR)

Triage & containment

Odłącz publiczną ekspozycję HMI / ogranicz do VPN/allowlist (NGFW/WAF block reguły XSS).
Wymuś log‑out wszystkich sesji ScadaBR; reset haseł i wyłącz konta nieznane (T1078).

Analiza

Przejrzyj AccessLogValve i catalina.out pod kątem żądań do /ScadaBR/system_settings.shtm z ładunkami XSS.
Zrzut bazy ScadaBR i skan na <script (przykład MySQL — lab only): SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE data_type IN ('text','varchar') AND table_schema LIKE 'scadabr%'; -- Dla każdej tabeli/kolumny tekstowej: SELECT * FROM <tbl> WHERE <col> LIKE '%<script%';
Zweryfikuj zmiany alarmów/setpointów (T0838/T0831) i kont z ostatnich 24–72 h.

Eradykacja & naprawa

Usuń payloady z pól UI, przywróć konfigurację alarmów i źródeł PLC z backupu.
Ustaw CSP, HttpOnly/Secure dla sesji, walidację/encoding pól (Server‑side).
Zaktualizuj ScadaBR/Tomcat/JDK, włącz WAF reguły XSS (virtual patch).

Lessons learned

Zmiana architektury dostępu (Zero Trust, segmentacja OT/DMZ).

Przykłady z kampanii / case studies

Honeypot OT (2025): napastnik (grupa TwoNet) zalogował się (m.in. domyślne poświadczenia), następnie wykorzystał CVE‑2021‑26829 do deface’u strony logowania (alert JS), usunął źródła PLC, zmienił parametry i wyłączył logi/alerty. Brak prób eskalacji na hosta – nacisk na warstwę HMI.
KEV: CISA formalnie dodała podatność do katalogu 11/28/2025 z wymaganiem zastosowania mitigacji/wycofania produktu do 12/19/2025.

Lab (bezpieczne testy)

Wyłącznie w odizolowanym środowisku testowym. Celem jest sprawdzenie detekcji/logowania, nie eksploatacja środowisk produkcyjnych.

Szybki generator logów Tomcata (bez prawdziwego ScadaBR):

docker run --name lab-tomcat -p 8080:8080 -d tomcat:9-jdk11
# Wygeneruj żądania przypominające XSS do ścieżki HMI:
curl 'http://localhost:8080/ScadaBR/system_settings.shtm?desc=%3Cscript%3Ealert(1)%3C%2Fscript%3E'
curl --data 'desc=<svg onload=alert(1)>' 'http://localhost:8080/ScadaBR/system_settings.shtm'

Weryfikacja logów: sprawdź localhost_access_log*.txt/catalina.out i uruchom reguły z sekcji 7.
WAF: jeżeli masz AWS WAF w labie, prześlij ruch przez ALB/CloudFront i uruchom Insights zapytanie (sekcja 7).

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

M1050 – Exploit Protection (IPS/WAF, wirtualne łatanie XSS; OS exploit guard).
M1048 – Application Isolation and Sandboxing (utwardzenie przeglądarek/odseparowanie stacji HMI).
M1030 – Network Segmentation (DMZ/Jump Host dla HMI/OT).
M1054 – Software Configuration (wyłączenie niepotrzebnych funkcji, poprawne encoding/validate).
M1042 – Disable or Remove Feature or Program (usunięcie nieużywanych modułów/komponentów web).

Powiązane techniki:

T1491.001 – Internal Defacement (efekt XSS w HMI).
T0838 – Modify Alarm Settings (wyciszanie alarmów po wejściu do HMI).
T0831 – Manipulation of Control (zmiany setpointów).
T1190 – Exploit Public‑Facing Application (gdy HMI jest dostępne publicznie).
T1078 – Valid Accounts (domyślne hasła).

Źródła / dalsza lektura

NVD – CVE‑2021‑26829 (opis, CVSS 3.1, KEV meta). (NVD)
CVE.org – rekord CVE (skrót opisu). (CVE)
CISA – KEV Catalog (wpis CVE‑2021‑26829). (CISA)
MITRE ATT&CK – T1491.001; T0838; T0831; T1190; aktualizacja v18. (MITRE ATT&CK)
Tomcat – AccessLogValve / logi (konfiguracja/ścieżki). (tomcat.apache.org)

Checklisty dla SOC / CISO

SOC

Alerty na /ScadaBR/system_settings.shtm + wzorce XSS (<script, %3Cscript, onerror=, javascript:).
Korelacja: zmiany ustawień HMI + wyciszenie alarmów (T0838) + deface (T1491.001).
Blokada w WAF/IPS, reguły virtual patch dla XSS. (M1050)
Telemetria z Tomcata (AccessLogValve) do SIEM; parsowanie pól zapytań/ciała.
Hunt: nietypowe UA, źródła VPS/hosting, krótkie sesje z wieloma POST/GET.

CISO / OT Lead

Eliminacja publicznej ekspozycji HMI (VPN/ZTNA, segmentacja OT). (M1030)
Domyślne hasła → wyłączone, MFA gdzie możliwe. (T1078)
Polityka aktualizacji ScadaBR/Tomcat/JDK; hardening CSP/HttpOnly/SameSite. (M1054)
Testy kontrolne: tabletop + lab z logami (sekcja 12).
Zgodność z CISA KEV – potwierdź wdrożenie mitigacji do 2025‑12‑19.

CVE-2019-11510 → pre‑auth arbitrary file read

TL;DR

CVE‑2019‑11510 to krytyczna podatność typu pre‑auth arbitrary file read w Ivanti/Pulse Connect Secure (PCS). Umożliwia niezalogowanemu napastnikowi odczyt plików z urządzenia VPN poprzez specjalnie przygotowane żądanie HTTP, co w praktyce prowadzi do kradzieży konfiguracji, kluczy i tokenów sesji oraz dalszych włamań z pominięciem MFA. Z punktu widzenia ATT&CK odpowiada to T1190 (Initial Access), a po eksfiltracji sekretów typowo obserwujemy *T1552. (Unsecured Credentials)**, T1539 (Steal Web Session Cookie) i później T1078 (Valid Accounts). Patching do wersji naprawiających (np. 8.2R12.1, 8.3R7.1, 9.0R3.4 i nowsze) jest obowiązkowy, a urządzenia należy weryfikować narzędziem Integrity Checker Tool (ICT) oraz logami WAF/ALB.

Krótka definicja techniczna

CVE‑2019‑11510: w Pulse Connect Secure (PCS) do wersji 8.2<8.2R12.1, 8.3<8.3R7.1 i 9.0<9.0R3.4 błąd w walidacji ścieżek umożliwia nieuwierzytelniony odczyt dowolnych plików poprzez spreparowany URI. CVSS v3.1 = 10.0 (CRITICAL).

Gdzie występuje / przykłady platform

Network/Appliance: Ivanti/Pulse Connect Secure (sprzęt/VM) — wektor pierwotny.
Windows / AD: po wycieku haseł/kluczy możliwy dalszy dostęp i lateral movement (T1078).
AWS: ślady/ochrona w AWS WAF (logi httpRequest.*) i ALB access logs.
Azure: Application Gateway WAF / Front Door — telemetryka wbicia i blokad. [brak oficjalnego cytatu — ogólna praktyka]
GCP: Cloud Armor / Chronicle parser dla Pulse Secure (syslog).
K8s / ESXi / M365: nie dotyczy bezpośrednio (pośredni wpływ poprzez kompromitację tożsamości).

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

Błąd pre‑auth file read umożliwia z poziomu Internetu pobieranie plików z urządzenia PCS. Atakujący używa spreparowanego żądania HTTP (z elementami przechodzenia po katalogach), aby ominąć autoryzację i uzyskać dostęp do zasobów urządzenia. Następnie eksfiltruje m.in. pliki konfiguracyjne, klucze i artefakty sesji, które mogą pozwolić na przejęcie aktywnych sesji, logowanie jak legalni użytkownicy (T1078) lub dalszą penetrację sieci. Podatność była szeroko wykorzystywana (CISA KEV), a technicznie wpisuje się w ATT&CK T1190.

Artefakty i logi

Źródło	Pole/artefakt	Wskaźnik	Komentarz
Pulse Secure syslog (Events/User/Admin)	log message / URI	nietypowe żądania do endpointów HTML5 + sekwencje traversal	Upewnij się, że eksportujesz syslog (WELF/Custom).
Reverse proxy / WAF	URI, query, status, UA, src IP	obecność wzorców path traversal, słowa‑klucze związane z HTML5 gateway	Dobre miejsce do korelacji i rate‑limitu.
AWS WAF (CloudWatch Logs)	`httpRequest.uri`, `action`, `terminatingRuleId`	żądania z `../` i słowami kluczowymi; akcja ALLOW/BLOCK	Pola wg dokumentacji AWS WAF.
ALB Access Logs (S3)	`request`, `elb_status_code`, `target_status_code`	200/206 dla nietypowych żądań	W połączeniu z WAF daje pełny obraz.
SIEM parsers (Chronicle/QRadar/itd.)	Normalizowane pola URL	dopasowania na tokenach ścieżki i traversal	Przykłady konfiguracji dla PCS.
ICT (Integrity Checker Tool)	wynik skanu	nowe/zmodyfikowane pliki na urządzeniu	Do potwierdzenia kompromitacji obrazu urządzenia.
EID / K8s audit / M365	—	n/d	Podatność dotyczy appliance, nie tych źródeł.

Detekcja (praktyczne reguły)

Sigma (web / reverse proxy / WAF)

title: Pulse Connect Secure — CVE-2019-11510 Attempt (Guacamole + Traversal)
id: 1c6d2c1a-7a4e-4b6c-9f0b-3a2c2f7a9f10
status: experimental
logsource:
  category: webserver
  product: proxy
detection:
  sel_dana:
    request|contains:
      - "/dana"
      - "dana-na"
  sel_guac:
    request|contains: "guacamole"
  sel_trav:
    request|contains:
      - "../"
      - "..%2f"
      - "%2e%2e"
  condition: sel_dana and sel_guac and sel_trav
falsepositives:
  - Ruch HTML5 gateway bez traversal (powinien nie zawierać '../')
level: high
tags:
  - attack.t1190
  - cve.2019-11510

Wzorzec „Guacamole” oraz traversal jest wskazywany w publicznych regułach Sigma dla CVE‑2019‑11510.

Splunk (SPL)

(index=web OR index=proxy OR index=waf OR sourcetype=pulse* OR sourcetype=aws:waf)
| eval uri=coalesce(cs_uri_stem, request, uri_path, url), q=coalesce(cs_uri_query, uri_query, query_string)
| where (like(uri, "%/dana%") OR like(uri, "%dana-na%"))
  AND (like(uri, "%guacamole%") OR like(q, "%guacamole%"))
  AND (like(uri, "%../%") OR like(q, "%../%") OR like(uri, "%..%2F%") OR like(q, "%..%2F%"))
| stats count dc(src) AS src_ips values(user) AS users by uri, q, user_agent, dest
| where count > 0

KQL (Microsoft Sentinel / Log Analytics)

let IOCUri = dynamic(["/dana", "dana-na"]);
let Kw = "guacamole";
(union isfuzzy=true
    CommonSecurityLog
    | extend uri = coalesce(RequestURL, RequestURI, concat(URL, URLQuery)), src = SourceIP, ua = RequestClientApplication
  , AzureDiagnostics
    | where Category has "ApplicationGatewayFirewallLog"
    | extend uri = requestUri_s, src = clientIp_s, ua = userAgent_s
)
| where uri has_any (IOCUri) and uri contains Kw and (uri contains "../" or uri contains "..%2F")
| summarize cnt=count(), make_set(src), make_set(ua) by bin(TimeGenerated, 5m), tostring(uri)

AWS CloudWatch Logs Insights (AWS WAF)

# Log Group: /aws/waf/<twoj-webacl>
fields @timestamp, httpRequest.clientIp, httpRequest.method, httpRequest.uri, action, terminatingRuleId
| filter httpRequest.uri like /dana/ and httpRequest.uri like /\.\./ and httpRequest.uri like /guacamole/
| stats count() as hits by httpRequest.clientIp, action, terminatingRuleId, httpRequest.uri
| sort hits desc

Pola httpRequest.*, action, terminatingRuleId pochodzą z oficjalnego schematu logów AWS WAF.

Elastic (KQL + EQL)

KQL (http logs / ecs):

url.path:/dana* AND url.path:*guacamole* AND (url.path:*../* OR url.query:*..%2F*)

EQL (sieć/HTTP):

network where network.protocol == "http"
  and wildcard(url.path, "/dana*")
  and stringcontains(url.path, "guacamole")
  and (stringcontains(url.path, "../") or stringcontains(url.query, "..%2F"))

Heurystyki / korelacje

URI + traversal + słowo‑klucz (HTML5 gateway) + HTTP 200/206 ⇒ wysoka pewność.
Seria prób z różnych IP/ASN + wspólny UA (skaner) ⇒ obniż priorytet lub taguj jako „scanner/bot”.
Po próbach: nowe sesje VPN z nieznanych ASN, nietypowa geografia (impossible travel), zmiana fingerprintu TLS → koreluj z logowaniem do AD/VPN. (CISA wskazywała takie objawy przy kampaniach na PCS.)

False positives / tuning

Legalny ruch HTML5 (Guacamole) bez traversal powinien być akceptowany — warunek na ../ / %2e%2e jest kluczowy.
Skany bezpieczeństwa / bug‑bounty generują podobne wzorce — whitelistuj znane zakresy.
Deduplikuj zdarzenia na 5–10 min, grupując po srcIP + UA + URI.

Playbook reagowania

Triaż i izolacja: jeśli reguły z §7 wskazują udane trafienia (200/206), natychmiast odetnij dostęp administracyjny do PCS / wstaw przed nim regułę WAF blokującą wzorce traversal.
Weryfikacja stanu PCS: uruchom Ivanti Integrity Checker Tool (ICT) (wbudowany lub zewnętrzny) i zarchiwizuj wynik.
Forensyka: zgraj logi (Events/User/Admin), eksport syslog z SIEM, logi WAF/ALB. (Dokumentacja logowania PCS.)
Patching / remediacja: zaktualizuj PCS do wersji naprawiających CVE‑2019‑11510 (≥8.2R12.1, ≥8.3R7.1, ≥9.0R3.4). Jeśli ICT wykrył modyfikacje — rozważ reinstalację obrazu i rotację kluczy/certyfikatów.
Reset/rotacja: wymuś reset haseł VPN/AD, rotuj certyfikaty/klucze używane przez PCS, unieważnij aktywne sesje. (Powiązanie z T1552.*).
Hunting post‑exploitation: szukaj logowań z nowych ASN, użycia skradzionych ciasteczek/tokens (T1539), nietypowych mapowań ról.
Twardnienie: stałe reguły WAF blokujące traversal, MFA wszędzie, segmentacja i ograniczenie dostępu do konsoli administracyjnej PCS.
Zgłoszenia i KEV: traktuj jako KEV i raportuj zgodnie z procesem (CISA KEV).

Przykłady z kampanii / case studies

REvil/Sodinokibi (2019–2020) — raporty łączyły wątki ransomware z wykorzystaniem PCS w wektorze wejścia.
„Fox Kitten” (APT z Iranu, 2019–2020) — szeroka eksploatacja VPN (w tym Pulse) jako początkowego dostępu; utrzymywanie backdoorów.
CISA alerty (2020+) — ostrzeżenia o kontynuowanej eksploatacji niezałatanych PCS; zalecenia aktualizacji i hardeningu.

Lab (bezpieczne testy) — przykładowe komendy

Tylko w odizolowanym labie. Celem jest wytworzenie logów do weryfikacji reguł, bez uderzania w realny PCS.

Symulacja logów na NGINX (Docker)

docker run -d --name nginx -p 8080:80 nginx:alpine
# Generowanie „szumu” traversal + słowo-klucz (log only):
for p in "/test/guacamole/../../etc/hosts" "/dana-na/../test/guacamole/..%2F..%2Ffile" ; do
  curl -s "http://127.0.0.1:8080${p}?q=check" >/dev/null
done

Weryfikacja detekcji — załaduj logi access.log do SIEM i uruchom reguły z §7.
Test WAF — utwórz regułę blokującą sekwencje traversal i sprawdź, czy zapisy AWS WAF rejestrują akcję BLOCK oraz terminatingRuleId.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

M1051 — Update Software (regularne aktualizacje/łaty).
M1016 — Vulnerability Scanning (ciągłe skanowanie i priorytetyzacja).
M1036 — Account Use Policies (zasady użycia kont, blokady, sesje).
M1031/M1037 — Network Intrusion Prevention / Filter Network Traffic (WAF/IPS przed PCS).

Powiązane techniki:

T1552.001 — Credentials in Files (wyciek haseł z plików).
T1552.004 — Private Keys (eksfiltracja kluczy).
T1539 — Steal Web Session Cookie (przejęcie sesji).
T1078 — Valid Accounts (logowanie prawdziwymi poświadczeniami).

Źródła / dalsza literatura

NVD: szczegóły CVE‑2019‑11510, wersje naprawiające, CVSS, wpis KEV. (NVD)
CISA Alert AA20‑010A/AA20‑107A: kontynuowana eksploatacja PCS. (CISA)
MITRE ATT&CK T1190: Exploit Public‑Facing Application (mapowanie i przykłady użycia przez grupy). (MITRE ATT&CK)
SigmaHQ: detekcja „Guacamole” dla CVE‑2019‑11510. (detection.fyi)
Ivanti (PCS/ICS) — logowanie i monitoring; syslog/filtry. (Ivanti Help)
AWS WAF — pola logów (httpRequest.*, action, terminatingRuleId). (AWS Documentation)
JPCERT/CC: podsumowanie kampanii na Pulse Connect Secure. (JPCERT/CC Eyes)
IBM X‑Force / Sophos: REvil/Sodinokibi a wektory VPN. (IBM)
Ivanti/CISA — Integrity Checker Tool (ICT) i użycie w dochodzeniach. (CISA)

Checklisty dla SOC / CISO

SOC (operacyjne):

Włączony eksport logów PCS (Events/User/Admin) do SIEM.
Reguły detekcji z §7 aktywne w web/WAF/ALB.
Korelacje: traversal + 200/206 + „Guacamole” + nowe logowania VPN.
Lista zaufanych skanerów/ASN w allowlist (redukcja FP).
Dashboard „PCS Exploit Attempts” (źródła, URI, status, ASN).

CISO (strategiczne):

Potwierdzony patch level PCS ≥ wersje naprawiające.
Procedura ICT po każdym incydencie/aktualizacji.
Polityka rotacji kluczy/certyfikatów i tokenów SSO przy incydencie (T1552.*).
WAF/IPS z regułami traversal przed PCS; dostęp admin tylko z sieci uprzywilejowanej.
Regularny VA/PT urządzeń brzegowych (M1016).

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

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 / 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`)	`ps aux	grep nobody` – wskazówka Mandiant dla triage
Crontab	Nieautoryzowane 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_ip`	Służy też do korelacji czasu ataku z sesjami użytkowników	—
WAF/ALB/Front Door	URI zawierające `/vpn/../vpns/portal` oraz odwołania do `*.xml`	Analiza AWS WAF/ALB, Azure WAF, appliance WAF	CloudTrail: 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)

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.
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
Skan IoC (oficjalny)
- Uruchom Citrix/Mandiant IoC Scanner na urządzeniu (tryb live). Zapisz wynik, zabezpiecz artefakty.
Eradykacja
- Zastosuj fixed buildy / przeinstaluj do wersji poprawionej; usuń pliki z /netscaler/portal/templates/; wyczyść crontab; sprawdź modyfikacje ns.conf.
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):

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)

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:

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.
Łańcuch dostaw i dostęp uprzywilejowany:
- Kompromitacja kont partnerów (agencje, software-house’y, hosting).
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:

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.
Ś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).
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)