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

LockBit 5: „nowa, bezpieczna domena bloga” i… błyskawiczny wyciek infrastruktury

Wprowadzenie do problemu / definicja luki

LockBit 5.0 ogłosił „nową, bezpieczną domenę bloga z wielowarstwową ochroną przed wszechmocnym FBI”. Zaledwie kilkadziesiąt godzin później OSINT-owcy i media branżowe powiązali tę infrastrukturę z konkretną domeną i adresem IP, ujawniając wrażliwe szczegóły konfiguracji serwera. To kolejny przykład kompromitacji higieny operacyjnej (opsec) gangu po jego powrocie na scenę.

W skrócie

  • Nowa infrastruktura LockBit 5.0 została powiązana z domeną karma0[.]xyz oraz adresem IP 205.185.116.233 (AS53667 – PONYNET/FranTech).
  • Serwer wykazywał otwarte porty wysokiego ryzyka (m.in. 3389/TCP – RDP, 5985 – WinRM), co przeczy narracji o „wielowarstwowej ochronie”.
  • Na nowym DLS (data leak site) pojawiły się recyklingowane wpisy ofiar – część ofiar miała pochodzić z wcześniejszych wycieków i innych grup (Weyr0/RansomHouse).
  • Równolegle monitorujący leak-sitów odnotowali nowy onion dla „bezpiecznego bloga”.
  • W szerszym tle: po Operation Cronos (luty 2024) gang odbudował się i w 2025 r. wypuścił LockBit 5.0 z technicznymi usprawnieniami.

Kontekst / historia / powiązania

Operacja służb „Cronos” w lutym 2024 r. uderzyła w infrastrukturę i panele LockBit, co znacząco ograniczyło jego możliwości – ale nie zakończyło działalności afiliantów. W 2025 r. gang ogłosił wersję 5.0 i stopniowo odbudował ekosystem RaaS. Dzisiejsza wpadka z domeną i IP wpisuje się w pasmo problemów opsec po serii wcześniejszych ekspozycji zaplecza grupy.

Analiza techniczna / szczegóły luki

  • Punkty wiązania (pivoty): badacze powiązali „nowy bezpieczny blog” z domeną karma0[.]xyz (zwracała stronę z brandingiem „LOCKBITS.5.0”) oraz adresem 205.185.116.233 w AS53667 (PONYNET/FranTech). Dane te zostały publicznie opublikowane na X (Twitter) przez analityka OSINT i następnie opisane w serwisach branżowych.
  • Konfiguracja usług: skany zewnętrzne wskazywały na wiele otwartych portów, m.in. 21/FTP, 80/HTTP (Apache/2.4.58 + PHP 8.0.30), 3389/RDP, 5000/HTTP, 5985/WinRM, 47001/HTTP i 49666 (usługa plików). Obecność RDP/3389 i WinRM/5985 na hostach przestępczych to rzadko spotykany błąd opsec, ułatwiający identyfikację, fingerprinting i potencjalne zakłócenia. (Uwaga: lista portów pochodzi z publikacji branżowej; nie stanowi niezależnie zweryfikowanego skanu.)
  • Metadane rejestracyjne: w materiałach pojawia się rozbieżność dat WHOIS (część źródeł podaje rejestrację 2 listopada 2025, inne – 12 kwietnia 2025 i użycie nameserverów Cloudflare). To typowe w przypadku prywatności WHOIS i zmian rejestratora; należy traktować te daty jako niejednoznaczne.
  • Nowy onion / DLS: wpis monitorujący leak-sity wskazuje nowy adres .onion opisany przez LockBit jako „new secure blog domain with a multi-layered protection system”.

Praktyczne konsekwencje / ryzyko

  • Ryzyko eskalacji DDoS i ingerencji: publiczne powiązanie adresu IP i domeny zwiększa szansę na działania obronne (blokady, zgłoszenia nadużyć) oraz kolizję z innymi gangami/crowd-sourcowanymi atakami.
  • Podważona wiarygodność DLS: sygnały o recyklingu ofiar podkopują presję negocjacyjną LockBit (ofiary i negocjatorzy mogą uznać nowe „publikacje” za blef).
  • Wymierne IOCs dla obrony: karma0[.]xyz, 205.185.116.233, AS53667 i nowy onion to artefakty do blokowania i korelacji w telemetrii SOC/TI.
  • Nieprzerwany rozwój narzędzi TTP: mimo wpadek opsec, LockBit 5.0 pozostaje technicznie dojrzały (wieloplatformowość: Windows/Linux/ESXi, obfuscation, utrudnianie analizy, szybkie szyfrowanie), co przekłada się na wciąż wysokie ryzyko dla organizacji.

Rekomendacje operacyjne / co zrobić teraz

Blokady i detekcje (prewencja):

  • Dodać do polityk blokowania: karma0[.]xyz, 205.185.116.233, segmenty AS53667; monitorować ewentualne rotacje IP/domen.
  • Aktualizować listy domen/URL DLS/CS w secure web gateway/EDR/NDR.
  • W regułach IDS/IPS oraz SIEM dodać korelację na nowy onion (jeśli telemetrycznie widoczny w ruchu TOR).

Twardnienie środowisk:

  • Egzekwować MFA + restrykcje sieciowe na RDP/WinRM/SSH/VPN; dla RDP – preferować RD Gateway + Just-In-Time + przesiadka na tunelowane połączenia bastionowe.
  • Wyłączyć SMB v1, ograniczyć „shadow copy” i włączyć tamper protection w EDR.
  • Wdrożyć application allowlisting dla hostów serwerowych, segmentację sieci (zwłaszcza ESXi/hiperwizory) i kopie zapasowe 3-2-1 z testem odtwarzania.

Detekcje TTP (przykłady):

  • Wykrywanie masowego rename + nietypowe rozszerzenia plików, wyłączenia ETW, zabijania usług AV/EDR, zrzutów LSASS, eksfiltracji poprzez tunelowanie HTTP(S)/TOR.
  • Korelowanie artefaktów LockBit 5.0 ze wskaźnikami znanymi z badań (np. obfuskacja, dynamiczne rozwiązywanie API, wsparcie ESXi).

Reakcja i komunikacja:

  • Przy incydentach z „LockBit 5.0” ocenić autentyczność wpisu na DLS – weryfikować, czy nie jest to recykling. Nie płacić za „stare” dane.

Różnice / porównania z innymi przypadkami

W przeszłości wycieki infrastruktury dotyczyły m.in. paneli afiliańckich i czatów LockBit (2025), ale obecny incydent jest nietypowy, bo uderza w „nową, wzmocnioną” domenę PR-owo reklamowaną przez gang – i to niemal natychmiast po starcie. W materialne technicznym 5.0 widać progres po stronie malware’u, podczas gdy opsec i warstwa publikacyjna pozostają piętą achillesową operacji.

Podsumowanie / kluczowe wnioski

  • LockBit 5.0 traci narrację o „nietykalności”: domena karma0[.]xyz i 205.185.116.233 szybko trafiły do publicznych IOCs, a serwer wyglądał na słabo utwardzony.
  • Recykling ofiar dodatkowo podważa presję szantażową gangu.
  • Dla obrońców to moment na blokady, korelacje i hunting z użyciem świeżych wskaźników, pamiętając, że technicznie LockBit 5.0 pozostaje niebezpieczny.

Źródła / bibliografia

  1. DataBreaches.net: „LockBit 5’s ‘new secure blog domain’ infra leaked already” (07.12.2025). (DataBreaches.Net)
  2. CyberSecurityNews: „LockBit 5.0 Infrastructure Exposed in New Server, IP, and Domain Leak” (07.12.2025). (Cyber Security News)
  3. Ransomware.live: wpis „new blog domain lockbit 5.0” (05.12.2025). (Ransomware Live)
  4. Europol: „Law enforcement disrupt world’s biggest ransomware operation” (20.02.2024). (Europol)
  5. Trend Micro Research: „New LockBit 5.0 Targets Windows, Linux, ESXi” (25.09.2025). (www.trendmicro.com)

Korea zaostrzy audyty ISMS po wycieku danych w Coupang. Co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Rząd Korei Południowej ogłosił, że zaostrzy proces certyfikacji i nadzoru nad państwowym systemem zarządzania bezpieczeństwem informacji (ISMS) oraz ISMS-P po masywnym wycieku danych w platformie e-commerce Coupang. W agendzie są m.in. obowiązkowe stosowanie ISMS dla kluczowych sektorów, dogłębne kontrole po-incydentowe oraz możliwość unieważniania certyfikatów w razie poważnych naruszeń. Decyzję zakomunikowano po międzyresortowym spotkaniu Personal Information Protection Commission (PIPC) i Ministerstwa Nauki i ICT (MSIT).

W skrócie

  • Skala: ujawniono dane ok. 33–33,7 mln kont klientów Coupang; incydent miał pozostawać niewykryty przez kilka miesięcy.
  • Wektor: w śledztwie analizowany jest wątek insiderski oraz wykorzystanie skradzionego klucza prywatnego/uprzywilejowanego dostępu.
  • Regulacje: rząd planuje obowiązkowość ISMS dla telekomów i platform oraz ostrzejsze audyty i kontrole terenowe; możliwe zmiany ustawowe.
  • Działania PIPC: nadzwyczajne posiedzenie PIPC nałożyło na Coupang środki zaradcze i obowiązek rozszerzonej notyfikacji.

Kontekst / historia / powiązania

Koreański ISMS/ISMS-P to państwowe reżimy certyfikacyjne pokrywające ogólne bezpieczeństwo informacji (ISMS) oraz ochronę danych osobowych (ISMS-P). Dotąd uzyskanie certyfikatów często następowało na wniosek operatora; władze zapowiadają przejście na model obowiązkowy dla wybranych branż i wzmocnienie nadzoru „po fakcie”. Impulsem stał się wyciek w Coupang — największy od lat — oraz rosnąca presja polityczna i społeczna.

Analiza techniczna / szczegóły luki

Dostępne raporty śledcze wskazują na kilka krytycznych obszarów kontroli, które mogły zawieść:

  1. Zarządzanie kluczami i tożsamościami – pojawiły się doniesienia o wykorzystaniu skradzionego klucza prywatnego oraz możliwym zaangażowaniu osoby związanej wcześniej z systemami uwierzytelniania i IAM w Coupang. To sugeruje niedostatki w HSM/KMS, rotacji kluczy i monitoringu użycia kluczy.
  2. Detekcja i czas ujęcia incydentu (MTTD) – naruszenie mogło trwać od czerwca do listopada, co wskazuje na luki w telemetryce i korelacji zdarzeń (SIEM/UEBA) oraz w alertingu anomalii egress.
  3. Segmentacja i najmniejsze uprawnienia – skoro możliwe było długotrwałe pobieranie rekordów PII, segmentacja danych, kontrole DLP i polityki just-in-time access musiały być niewystarczające. (Wniosek analityczny oparty na dotychczasowych ustaleniach śledztwa).

Praktyczne konsekwencje / ryzyko

  • Regulator „po drugiej stronie kabla”: firmy działające w Korei (lub obsługujące klientów/kontenery danych w KR) mogą spodziewać się częstszych kontroli, audytów na miejscu i testów skuteczności — nie tylko weryfikacji dokumentów.
  • Ryzyko łańcucha dostaw: dostawcy i BPO z dostępem do PII klientów koreańskich będą włączani w zakres wymogów ISMS/ISMS-P.
  • Koszt naruszeń: po incydencie politycy wzywają do wyższych kar i odszkodowań karnych, co podnosi ryzyko finansowe.

Rekomendacje operacyjne / co zrobić teraz

Dla CISO i działów bezpieczeństwa (także poza Koreą, jeśli obsługujesz użytkowników z KR):

  1. Zamroź i przeglądnij łańcuch zaufania: inwentaryzacja kluczy, weryfikacja ochrony KMS/HSM, natychmiastowa rotacja kluczy o podniesionym ryzyku, wdrożenie key-use attestation i alertingu nadużyć.
  2. Wzmocnij IAM: przegląd ról uprzywilejowanych, JIT + MFA hardware, sesje krótkotrwałe, ciągły behavioral UEBA dla adminów i developerów.
  3. Telemetryka i czas ujęcia: reguły detekcji exfiltracji (DNS, S3, BigQuery, Object Storage), eBPF/EDR na hostach przetwarzających PII, korelacja z DLP. Incydent pokazał, że miesiące „ciszy” są realne.
  4. Kontrola dostawców: rozszerz GRC o dowody skuteczności, nie tylko certyfikaty (logi z testów odzyskiwania, wyniki purple-team, wyniki TTP-based controls).
  5. Ćwiczenia insider-risk: scenariusze z nadużyciem kluczy i offboardingiem pracowników (revoke, rotation, break-glass review).
  6. Komunikacja i zgodność: przygotuj playbook PIPC (wzory notyfikacji, kanały komunikacji, FAQ), aby spełnić wymagania rozszerzonej notyfikacji i działań naprawczych.

Różnice / porównania z innymi przypadkami

  • ISMS/ISMS-P vs ISO/IEC 27001/27701: ISO kładzie nacisk na system zarządzania i cykl PDCA, natomiast ISMS/ISMS-P w Korei – oprócz elementów systemowych – w praktyce jest bardziej operacyjny i sektorowy (telekom, platformy), a po zmianach ma mocniejszy nadzór po-incydentowy z sankcją unieważnienia certyfikatu. Zapowiedzi idą w kierunku obowiązkowego zakresu dla wybranych branż, podczas gdy ISO pozostaje dobrowolne (choć rynkowo wymagane).
  • RODO (UE): podobnie jak w UE, rośnie presja finansowa i oczekiwanie „efektywności” środków, nie samej zgodności formalnej; koreańskie władze – wzorem praktyk EOG – naciskają na real-world security outcomes i szybkie notyfikacje.

Podsumowanie / kluczowe wnioski

  • Korea przechodzi od „checklist compliance” do „assurance of effectiveness”: audyty, kontrole terenowe i realna odpowiedzialność (włącznie z utratą certyfikatu).
  • Incydent w Coupang podkreśla, że największe ryzyko często siedzi „wewnątrz”: ochrona i monitoring kluczy, IAM i telemetria muszą być priorytetem.
  • Organizacje działające w KR (lub przetwarzające dane Koreańczyków) powinny zacząć przygotowania już dziś: przegląd kluczy, inspekcje dostawców, scenariusze insider-risk i gotowe szablony notyfikacji do PIPC.

Źródła / bibliografia

  1. Korea JoongAng Daily: „Gov’t to toughen certification screening for information security system amid Coupang data breach”, 7 grudnia 2025. (Korea Joongang Daily)
  2. The Korea Times: „Gov’t to toughen certification screening for information security system…”, 6 grudnia 2025. (The Korea Times)
  3. Reuters: „South Korea’s Lee calls for tougher penalties after Coupang data breach”, 2 grudnia 2025. (Reuters)
  4. Reuters: „Coupang apologises over massive data breach (33.7m accounts)”, 29 listopada 2025. (Reuters)
  5. Digital Policy Alert: „PIPC required Coupang to implement corrective notification and strengthened mitigation”, 3 grudnia 2025. (Digital Policy Alert)

PRC „Brickstorm”: chińskie grupy APT z backdoorem na vSphere i Windows. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

4 grudnia 2025 r. CISA, NSA i kanadyjski Cyber Centre opublikowały raport analizy złośliwego oprogramowania (MAR) opisujący BRICKSTORM – niestandardowy backdoor (Go/ELF) używany przez państwowo wspieranych aktorów z ChRL do długotrwałej obecności w sieciach ofiar. Główne cele to sektor publiczny (Government Services & Facilities) oraz firmy IT. Malware obsługuje środowiska VMware vSphere (vCenter/ESXi) i ma również warianty dla Windows.

W skrócie

  • Wejście i trwałość: implant na hostach vCenter/ESXi, modyfikacja plików startowych, watchdog autorestartu/reinstalacji. Średnia „dwell time” w wykrytych operacjach liczona była w miesiącach, a w niektórych przypadkach przekraczała rok.
  • C2 i ukrywanie: wielowarstwowe szyfrowanie (HTTPS/WebSockets/nested TLS), DNS-over-HTTPS do rozwiązywania adresów C2, imitacja ruchu serwerów.
  • Cele i skala: rząd i IT w USA/Kanadzie; media i badacze informują o dziesiątkach organizacji i działaniach o charakterze szpiegowskim z potencjałem sabotażu.
  • Środowiska wirtualne: po przejęciu vCenter napastnicy klonują snapshoty VM (ekstrakcja poświadczeń) i mogą tworzyć ukryte, „rogue” VM.

Kontekst / historia / powiązania

Kampania wpisuje się w długofalową aktywność APT z Chin opisywaną wspólnie przez CISA/NSA (np. wcześniejsze CSA nt. kompromitacji sieci krytycznych), ale BRICKSTORM to świeży komponent zwiększający trwałość w warstwie wirtualizacji. Niezależnie, Google Threat Intelligence (GTIG) i Mandiant raportowały jesienią 2025 r. aktywność „Brickstorm”/pokrewnych narzędzi z długim czasem utrzymania dostępu (~393 dni), szczególnie w branżach prawnej, SaaS i BPO.

Analiza techniczna / szczegóły luki

Wejście i ruch boczny. W incydencie IR opisanym przez CISA napastnicy:

  • dostali się na serwer web w DMZ (poprzez web shell),
  • użyli kont usługowych do RDP na kontrolery domeny (kopie NTDS.dit),
  • zdobyli poświadczenia MSP i przeszli do vCenter,
  • eskalowali uprawnienia (sudo), zrzucili BRICKSTORM do /etc/sysconfig/ i zmodyfikowali plik init rozruchu vSphere, aby uruchamiać implant przy starcie,
  • uzyskali dostęp do dwóch DC oraz serwera ADFS (eksport kluczy kryptograficznych). Z persystencją co najmniej od kwietnia 2024 do 3 września 2025.

Funkcje BRICKSTORM.

  • Backdoor (Go/ELF): interaktywny shell, operacje na plikach (upload/download/list/create/delete), tryb SOCKS proxy do tunelowania i ruchu bocznego.
  • C2 i maskowanie: HTTPS/WebSockets + DoH do rozwiązywania C2, „web server mimicry” do wtapiania się w normalny ruch.
  • Trwałość: watchdog samonaprawy (restart/reinstalacja po zakłóceniu).
  • Warianty: próbki dla vSphere; istnieją raporty o wersjach Windows.
  • Reguły detekcji: pakiet YARA/Sigma do pobrania z MAR.

Cele specyficzne dla wirtualizacji. Po wejściu do vCenter aktorzy:

  • klonują snapshoty wrażliwych VM dla ekstrakcji haseł/kluczy,
  • tworzą ukryte VM, które bywają pomijane przez standardowe monitorowanie,
  • utrwalają obecność modyfikując ścieżki startowe usług vSphere.

Praktyczne konsekwencje / ryzyko

  • Ryzyko utraty integralności tożsamości (eksport kluczy ADFS, kradzież biletów/claims) i długotrwałe „życie w chmurze” atakującego w środowiskach wirtualnych.
  • Utrata widoczności SOC: DoH, WebSockets i „mimikra” HTTP utrudniają klasyczne IOCs/IDS.
  • Potencjał sabotażu: dostęp uprzywilejowany do warstwy wirtualizacji umożliwia szybkie, szerokie skutki (np. wyłączanie klastrów, manipulacja storage). Organy USA i Kanady ostrzegają, że operacje mają wymiar szpiegowski, ale niosą ryzyko zakłóceń.

Rekomendacje operacyjne / co zrobić teraz

Detekcja i polowanie

  1. Wdróż reguły z MAR (YARA/Sigma); przejrzyj wyniki retro (24+ m-ce) w SIEM/EDR/NDR.
  2. Analityka DoH: wyłapuj nietypowe zapytania DoH (destynacje niezwiązane z Twoim resolverem), koreluj z WebSockets i długimi połączeniami TLS.
  3. Telemetry vSphere:
    • zmiany w /etc/sysconfig/ i skryptach init na ESXi/vCenter,
    • nietypowe operacje clone/snapshot VM,
    • tworzenie nierejestrowanych/ukrytych VM,
    • użycie sudo na appliance’ach vCenter.
  4. AD/ADFS: hunting pod kątem kopiowania NTDS.dit, dostępu do ADFS i eksportu kluczy.

Hardening i kontrola powierzchni ataku

  1. Segmentacja i zasada „rzadkich rąk” do vCenter (MFA, PAM/JIT, brak stałych kont usługowych MSP w prod).
  2. Monitoring i kontrola DoH: preferuj własne, autoryzowane resolvery DoH/DNS; blokuj „dzikie” endpointy DoH na brzegu.
  3. Zasady snapshotów: ogranicz prawo do clone/snapshot, alertuj o masowych/pozaschematowych operacjach.
  4. Łatanie i konfiguracja vSphere/Windows, w tym aktualne appliance’y, rotacja certyfikatów i HSTS/TLS hardening na brzegach proxy. (Inference na bazie wytycznych CISA/NSA dot. krytycznej infrastruktury.)

Odpowiedź na incydent (IR) – minimalny playbook

  • Izolacja vCenter/ESXi (odseparowane sieci zarządzające, odcięcie dostępu z kont zewnętrznych/MSP).
  • Zrzuty i triage: pamięć + dysk vCenter/ESXi; weryfikacja plików init i ścieżek w /etc/sysconfig/.
  • AD/ADFS: natychmiastowa rotacja kluczy ADFS, przegląd trustów, audyt kont usługowych i SPN.
  • Korekta polityk DoH/HTTP proxy, wymuszanie resolwera korporacyjnego.
  • Zgłoszenie do CISA/Cyber Centre; użycie udostępnionych IOC/Sigma.

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

W porównaniu do wcześniejszych kampanii PRC opisywanych przez CISA/NSA (routery, urządzenia brzegowe), BRICKSTORM celuje w warstwę wirtualizacji i tożsamość (AD/ADFS), łącząc długą persystencję z trudnym do wykrycia C2 (DoH/WebSockets). To przesunięcie „w dół” stosu (hypervisor/zarządzanie) zwiększa wpływ i utrudnia odzyskanie środowiska.

Podsumowanie / kluczowe wnioski

  • BRICKSTORM to ukierunkowany backdoor na vSphere/Windows pozwalający APT z ChRL na wielo-miesięczną obecność.
  • Operacje na vCenter/ESXi (clone/snapshot, rogue VM) i kradzież kluczy ADFS podnoszą ryzyko eskalacji domenowej i łańcuchowych kompromitacji.
  • Widoczność na DoH/WebSockets i telemetria vSphere to teraz krytyczne obszary detekcji.
  • Wdrożenie reguł YARA/Sigma z MAR, hardening tożsamości i segmentacji vCenter to „must-do” dla SOC/IT.

Źródła / bibliografia

  1. CISA/NSA/Cyber CentreMalware Analysis Report: BRICKSTORM Backdoor, 4 grudnia 2025 (TLP:CLEAR). Najpełniejszy opis próbek, TTP, IOC, reguły YARA/Sigma.
  2. CISA – komunikat: CISA, NSA and Cyber Centre Warn Critical Infrastructure of BRICKSTORM malware…, 4 grudnia 2025. (cisa.gov)
  3. Google Threat IntelligenceBrickstorm espionage campaign (analiza GTIG/Mandiant), 24 września 2025. (Google Cloud)
  4. CyberScoopExpansive, ongoing China espionage threat riding on Brickstorm, 4 grudnia 2025. (CyberScoop)
  5. ReutersChinese-linked hackers use ‘Brickstorm’ back door…, 4 grudnia 2025 (kontekst medialny i skala). (Reuters)

Bliźniacy z Virginii aresztowani za skasowanie ~96 rządowych baz FOIA. Co wiemy i jak się przed tym bronić

Wprowadzenie do problemu / definicja luki

3–4 grudnia 2025 r. w stanie Wirginia aresztowano braci bliźniaków, Muneeba i Sohaiba Akhterów (34 l.), którym zarzucono nadużycie uprawnień wykonawcy federalnego do skasowania ok. 96 baz danych z informacjami rządowymi – m.in. rejestrów wniosków FOIA (Freedom of Information Act) oraz danych śledczych kilku agencji. Według Departamentu Sprawiedliwości, do incydentu miało dojść w lutym 2025 r., a zatrzymania dokonano 3 grudnia.

W skrócie

  • Typ zdarzenia: sabotaż/insider threat po stronie podwykonawcy (byli/zwalniani pracownicy).
  • Skala: ~96 baz danych związanych z obsługą FOIA i sprawami śledczymi (w tym systemy powiązane z DHS).
  • Wektor: pozostawione aktywne konto i uprawnienia po rozmowie HR dot. zakończenia współpracy.
  • Maskowanie śladów: zapytania do narzędzia AI o instrukcje czyszczenia logów (SQL Server/Windows).
  • Tło sprawców: wcześniejsze wyroki za włamania (2015 r., m.in. Departament Stanu).

Kontekst / historia / powiązania

Akhterowie byli już wcześniej skazani w 2015 r. za spiskowanie w celu uzyskania nieautoryzowanego dostępu do systemów rządowych i prywatnych. Mimo tej historii mieli pracować przy kontrakcie federalnym; według relacji prasowych działania destrukcyjne nastąpiły tuż po zakomunikowaniu im przez HR zakończenia współpracy, gdy dostęp nie został natychmiast wyłączony. Sprawa unaocznia klasyczny problem offboardingu w ekosystemie wykonawców i podwykonawców administracji publicznej.

Analiza techniczna / szczegóły luki

Publicznie dostępne dokumenty i relacje wskazują na następujące elementy techniczne:

  • Uprawnienia i tożsamość: wykorzystanie niewycofanego konta oraz nadanych wcześniej ról/permission sets do ingerencji w produkcyjne instancje baz danych. Wątek ten pada w materiałach prasowych i streszczeniach akt sprawy.
  • Zakres szkód: usunięto ~96 baz (SQL) związanych z FOIA i sprawami dochodzeniowymi; co najmniej jedna baza należała do środowiska związanego z DHS.
  • Antyforensics: w minutę po skasowaniu jednej z baz (DHS) padło zapytanie do narzędzia AI o czyszczenie logów SQL Server/Windows Server 2012, co może świadczyć o próbie utrudnienia dochodzenia (time correlation).
  • Łańcuch zdarzeń: według DOJ – nadużycie pozycji wykonawcy federalnego, kradzież/wyprowadzenie danych i sabotaż systemów w lutym 2025 r.; aresztowania 3 grudnia, akt oskarżenia ogłoszony 4 grudnia.

Praktyczne konsekwencje / ryzyko

  • Dostępność i przejrzystość państwa: utrata/zakłócenie obsługi wniosków FOIA wpływa na jawność życia publicznego i terminowość odpowiedzi organów.
  • Ryzyko prawne i zgodność: potencjalne naruszenie przepisów dot. przechowywania dokumentacji publicznej, retencji danych i łańcucha dowodowego (agencje śledcze).
  • Koszty odtworzenia: przy RPO/RTO > 0 może dojść do utraty danych między backupami, długich przestojów oraz konieczności ręcznego odtworzenia rekordów. (Wniosek analityczny na bazie opisanej skali kasacji).
  • Reputacja i zaufanie: sabotaż dokonany przez wykonawcę podważa zaufanie do całego łańcucha dostaw IT w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Dla instytucji publicznych i wykonawców:

  1. Zero-delay offboarding: automatyczne, atomowe odebranie dostępu (IdP/PAM/DB) w trakcie rozmowy offboardingowej; “break glass” tylko z rejestracją i zgodą 4-oczu.
  2. Zasada najmniejszych uprawnień + JIT: role time-boxed, dostępy Just-In-Time do środowisk prod, bound by ticket.
  3. Kontrola zmian w DB: egzekwowanie DDL/DML przez change data capture, database activity monitoring (DAM), wymóg trybu SAFE/DRY RUN dla destrukcyjnych poleceń i approval gates dla DROP DATABASE.
  4. Backupy niezmienialne: kopie immutable/WORM (S3 Object Lock, Azure Immutable Blob) + air-gap; regularne testy przywracania (game days) i wskaźniki RPO/RTO na poziomie wymagań FOIA.
  5. Detekcja antyforensics: reguły SIEM/EDR na wzorce „czyszczenia logów” wkrótce po operacjach DDL/DROP; korelacja czasowa z IdP (login), CMDB i HRMS (status pracownika).
  6. Segregacja obowiązków: osobne konta do administrowania, osobne do pracy deweloperskiej; MFA hardware dla kont uprzywilejowanych; rotacja tajemnic (PAM) po każdym zdarzeniu HR.
  7. Kontrakty i due diligence: weryfikacja dostawców (background checks), clause’y o natychmiastowej deprowizji i karach umownych; audyty uprawnień kwartalnie.
  8. Kill switch w środowisku DB: polityki, które automatycznie blokują destrukcyjne operacje, gdy status pracownika = „terminated” w HRMS.

Dla zespołów PR/FOIA/Legal: przygotujcie plan ręcznego odtwarzania rekordów FOIA z kopii offline i logów transakcyjnych; komunikaty dla wnioskodawców dot. możliwych opóźnień.

Różnice / porównania z innymi przypadkami

  • Insider vs. APT: w przeciwieństwie do ataków APT, tu wektor to legalny dostęp wykonawcy (insider). Skuteczność obrony zależy więc bardziej od governance i procesów HR/IdP niż od klasycznej detekcji perymetrycznej.
  • Motyw sabotażu po offboardingu: schemat podobny do innych incydentów „last-day sabotage”, ale rzadko spotyka się tak dużą liczbę skasowanych baz w sektorze publicznym. (Wniosek na bazie przeglądu sprawy i relacji prasowych).

Podsumowanie / kluczowe wnioski

  • Kluczowe było opóźnienie w deprowizji dostępu po rozmowie HR – to wystarczyło, by w krótkim czasie skasować dziesiątki baz krytycznych dla przejrzystości państwa (FOIA) i działań śledczych.
  • Próba maskowania śladów z użyciem narzędzi AI to dziś realny pattern antyforensics – warto mieć na to gotowe reguły detekcyjne.
  • Silne procesy offboardingu, PAM, immutable backupy i automatyka w IdP to najskuteczniejsze „tarcze” na podobne przypadki.

Źródła / bibliografia

  • U.S. Department of Justice – komunikat o aresztowaniu (3–4 grudnia 2025 r.). (Department of Justice)
  • The Record (Recorded Future News): „Virginia brothers charged with hacking, deleting federal databases holding FOIA info” (4 grudnia 2025 r.). (The Record from Recorded Future)
  • CyberScoop: „Twins with hacking history charged in insider data breach…” (3 grudnia 2025 r.). (CyberScoop)
  • BleepingComputer: „Contractors with hacking records accused of wiping 96 govt databases” (4 grudnia 2025 r.). (BleepingComputer)
  • Axios: „Virginia brothers arrested for allegedly tampering with government databases” (3 grudnia 2025 r.). (Axios)

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:

  1. 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

  1. BleepingComputer — „Fake Calendly invites spoof top brands to hijack ad manager accounts”, 2 grudnia 2025. (BleepingComputer)
  2. Push Security — „Uncovering a Calendly-themed phishing campaign targeting business ad manager accounts”, 2 grudnia 2025. (Push Security)
  3. Push Security — „Analysing a malvertising attack targeting business Google accounts”, 2 grudnia 2025. (Push Security)
  4. Google Ads Help — „About notifications in manager accounts (MCC)”. (Google Help)
  5. 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łoCo szukać (przykłady wzorców)Lokalizacja / produktUwagi / 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.outBłędy JSP/stacktrace po wpisaniu HTML/JS (walidacja), restart kontekstuLinux: /var/log/tomcat*/catalina.out; Windows: ...\Tomcat\logs\Ścieżki zależne od OS/pakietu.
Log aplikacji ScadaBRZmiany 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/ProxyReguły XSS, signatures na <script>, svg/onload, javascript:AWS WAF, Azure WAF, ModSecurityDobre 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.
CloudTrailN/D (brak bezpośrednich zdarzeń) – zamiast tego: AWS WAF / ALB/CloudFront logiCloudWatch Logs / S3Użyj Insights/Athena do zapytań (patrz sekcja 7).
K8s AuditZmiany Ingress/ConfigMap/Secret dot. publicznej ekspozycji HMIkube-apiserver-audit.logPośrednio – redukcja ekspozycji na T1190.
M365N/DBrak 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)

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

  1. 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'
  1. Weryfikacja logów: sprawdź localhost_access_log*.txt/catalina.out i uruchom reguły z sekcji 7.
  2. 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łoPole/artefaktWskaźnikKomentarz
Pulse Secure syslog (Events/User/Admin)log message / URInietypowe żądania do endpointów HTML5 + sekwencje traversalUpewnij się, że eksportujesz syslog (WELF/Custom).
Reverse proxy / WAFURI, query, status, UA, src IPobecność wzorców path traversal, słowa‑klucze związane z HTML5 gatewayDobre miejsce do korelacji i rate‑limitu.
AWS WAF (CloudWatch Logs)httpRequest.uri, action, terminatingRuleIdżądania z ../ i słowami kluczowymi; akcja ALLOW/BLOCKPola wg dokumentacji AWS WAF.
ALB Access Logs (S3)request, elb_status_code, target_status_code200/206 dla nietypowych żądańW połączeniu z WAF daje pełny obraz.
SIEM parsers (Chronicle/QRadar/itd.)Normalizowane pola URLdopasowania na tokenach ścieżki i traversalPrzykłady konfiguracji dla PCS.
ICT (Integrity Checker Tool)wynik skanunowe/zmodyfikowane pliki na urządzeniuDo potwierdzenia kompromitacji obrazu urządzenia.
EID / K8s audit / M365n/dPodatność 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

  1. 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.
  2. Weryfikacja stanu PCS: uruchom Ivanti Integrity Checker Tool (ICT) (wbudowany lub zewnętrzny) i zarchiwizuj wynik.
  3. Forensyka: zgraj logi (Events/User/Admin), eksport syslog z SIEM, logi WAF/ALB. (Dokumentacja logowania PCS.)
  4. 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.
  5. Reset/rotacja: wymuś reset haseł VPN/AD, rotuj certyfikaty/klucze używane przez PCS, unieważnij aktywne sesje. (Powiązanie z T1552.*).
  6. Hunting post‑exploitation: szukaj logowań z nowych ASN, użycia skradzionych ciasteczek/tokens (T1539), nietypowych mapowań ról.
  7. Twardnienie: stałe reguły WAF blokujące traversal, MFA wszędzie, segmentacja i ograniczenie dostępu do konsoli administracyjnej PCS.
  8. 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.

  1. 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
  1. Weryfikacja detekcji — załaduj logi access.log do SIEM i uruchom reguły z §7.
  2. 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).