Archiwa: Windows - Strona 40 z 65 - Security Bez Tabu

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)

Inotiv: kradzież danych osobowych po ataku ransomware. 9 542 osób objętych powiadomieniami

Wprowadzenie do problemu / definicja incydentu

Inotiv, amerykańska firma badawczo-rozwojowa (CRO) dla sektora farmaceutycznego i biotech, potwierdziła, że w wyniku ataku ransomware z sierpnia 2025 r. doszło do wykradzenia danych osobowych. Zgłoszenia do regulatorów wskazują na łącznie 9 542 osoby, których informacje mogły zostać ujawnione (m.in. imię i nazwisko, adres, numery SSN i prawa jazdy, dane finansowe oraz informacje medyczne/ubezpieczeniowe). Firma zakończyła dochodzenie i przywróciła dostęp do systemów, nadal oceniając pełen wpływ zdarzenia.

W skrócie

  • Data zdarzenia: dostęp atakującego między 5–8 sierpnia 2025 r.; wykrycie 8 sierpnia.
  • Skala naruszenia: 9 542 osób według zgłoszenia do prokuratora generalnego stanu Maine.
  • Potencjalnie wykradzione dane: identyfikacyjne, finansowe i medyczne (w zależności od osoby).
  • Sprawcy i modus operandi: grupa Qilin (double extortion: szyfrowanie + kradzież danych), twierdziła, że ukradła ~176 GB (ok. 162 tys. plików).
  • Status operacyjny: dostęp do sieci/systemów przywrócony; wpływ finansowy nadal oceniany.

Kontekst / historia / powiązania

Inotiv pierwszy raz ujawnił incydent w zgłoszeniu do SEC, informując, że część systemów i danych zaszyfrowano, co wywołało przerwy operacyjne oraz migrację procesów na tryby „offline”. Później, 3 grudnia 2025 r., w raporcie wynikowym spółka podała, że przywróciła dostęp i zakończyła dochodzenie, identyfikując zakres zdarzenia oraz realizując ustawowe notyfikacje.
W tym samym czasie Qilin opublikował wpis na stronie w Torze, przypisując sobie atak i wskazując na ~176 GB wykradzionych danych; wpis został później usunięty. Niezależne media branżowe również odnotowały roszczenia grupy.

Analiza techniczna / szczegóły luki

Choć Inotiv nie upublicznił wektorów wejścia ani szczegółowych TTP, obraz incydentu odpowiada schematowi double extortion stosowanemu przez Qilin:

  1. Intruzja i eskalacja uprawnień,
  2. Szyfrowanie wybranych systemów (zakłócenie operacji),
  3. Eksfiltracja danych i presja publikacją próbek.
    SEC-owe materiały i relacje prasowe wskazują, że dotknięte były „wybrane bazy i aplikacje biznesowe” oraz wewnętrzne repozytoria danych, a procesy przenoszono na obejścia offline. To spójne z wcześniejszymi kampaniami Qilin, które koncentrują się na środowiskach Windows/VMware i uderzają w kluczowe systemy biznesowe.

Zakres danych: wg zgłoszeń regulatorom (Maine/Texas) pakiet zawierał dane PII, finansowe i zdrowotne, co znacząco podnosi ryzyko nadużyć tożsamości i fraudów ubezpieczeniowych.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla osób: kradzież tożsamości (SSN, data urodzenia), otwieranie rachunków kredytowych, wyłudzenia na podstawie polis zdrowotnych, doxing. Okres ważności takich danych jest wieloletni (nie wygasają jak hasła).
  • Ryzyko dla Inotiv / łańcucha dostaw: możliwy wyciek umów B2B, dokumentacji projektowej i materiałów R&D (Qilin deklarował setki tysięcy plików), co może prowadzić do szpiegostwa korporacyjnego i erozji przewagi konkurencyjnej.
  • Zgodność i koszty: koszty IR, doradztwa, kredytowania monitoringu tożsamości (24 miesiące), potencjalne roszczenia cywilne oraz dług ogonowy kosztów bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla osób powiadomionych przez Inotiv:

  1. Aktywuj monitoring kredytowy (zaoferowane 24 mies.) i włącz alerty/„credit freeze”.
  2. Zmień pytania weryfikacyjne i hasła w serwisach finansowych; włącz MFA wszędzie.
  3. Obserwuj EOB (Explanation of Benefits) z ubezpieczenia zdrowotnego pod kątem nadużyć medycznych.
  4. Zgłaszaj próby socjotechniki (smishing, vishing) – przestępcy często „dogrywają” atak falą phishingu po ujawnieniach.

Dla organizacji (w szczególności CRO/farma/biotech):

  • Segmentacja i kontrola dostępu do danych wrażliwych (dane osobowe + medyczne) z zasadą least privilege; izolacja sieciowa środowisk R&D.
  • Egress monitoring i DLP na krytycznych węzłach (serwery plików, repozytoria badań).
  • Backupy 3-2-1 z immutable storage i regularnymi ćwiczeniami odtwarzania.
  • EDR/XDR + detekcje behawioralne dla typowego łańcucha Qilin (eskalacja, shadow copy deletion, szyfrowanie wsadowe).
  • Zarządzanie kluczami i tajemnicami (HSM/KMS), pełne szyfrowanie danych „at rest” i „in transit”.
  • Plan komunikacji kryzysowej i prawnej (SEC/AG, pacjenci/pracownicy/kontrahenci), gotowe szablony notyfikacji zgodne z prawem stanowym. (Texas/Maine mają specyficzne wymogi raportowe i katalogi danych).

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

Qilin w 2025 r. atakował wiele sektorów (media, automotive, administracja). Wzorzec w Inotiv (szyfrowanie + eksfiltracja ~176 GB i publikacja próbek) jest spójny z innymi ich ofiarami. Dodatkowo w farmacji ekspozycja danych zdrowotnych i R&D podnosi ryzyko ponad typowe skutki finansowe.

Podsumowanie / kluczowe wnioski

  • Atak z sierpnia 2025 r. na Inotiv ma wymiar długofalowy: PII + dane zdrowotne zwiększają persystencję ryzyka.
  • 9 542 osób objętych notyfikacją to liczba oficjalna (Maine AG).
  • Qilin stosuje double extortion, a deklarowana skala (176 GB) wskazuje na szeroką penetrację systemów plików.
  • Priorytetem dla organizacji pokrewnych jest ochrona danych wysoko wrażliwych, segmentacja oraz gotowość IR/BCP.

Źródła / bibliografia

  1. SecurityWeek — „Inotiv Says Personal Information Stolen in Ransomware Attack”, 4 grudnia 2025 r. (szczegóły dot. typów danych, liczby osób, wsparcia dla poszkodowanych). (SecurityWeek)
  2. SEC (Exhibit 99.1) — Raport wynikowy Inotiv z aktualizacją o incydencie, 3 grudnia 2025 r. (oś czasu, status operacyjny). (SEC)
  3. Maine Attorney General — rejestr zgłoszeń o naruszeniach danych: wpis Inotiv (liczba osób: 9 542). (Maine)
  4. BleepingComputer — „Pharma firm Inotiv says ransomware attack impacted operations”, 19 sierpnia 2025 r. (roszczenia Qilin: ~176 GB/162 tys. plików). (BleepingComputer)

Microsoft „po cichu” łagodzi zero-day w Windows (.LNK) aktywnie wykorzystywany przez APT i cyberprzestępców

Wprowadzenie do problemu / definicja luki

Microsoft w listopadowych aktualizacjach 2025 r. wprowadził ciche zmiany w sposobie wyświetlania właściwości skrótów Windows (.LNK), co ogranicza skuteczność aktywnie wykorzystywanej luki CVE-2025-9491. Błąd pozwalał atakującym ukrywać złośliwe argumenty poleceń w polu Target tak, by użytkownik (lub analityk) nie widział rzeczywiście wykonywanego łańcucha polecenia. Microsoft wcześniej twierdził, że z uwagi na wymaganą interakcję użytkownika i ostrzeżenia „Mark of the Web”, problem „nie spełnia progu dla serwisowania”, ale mimo to w systemie pojawiła się mitygacja interfejsowa.


W skrócie

  • Identyfikator: CVE-2025-9491 (wcześniej ZDI-CAN-25373 / ZDI-25-148), CWE-451 (UI Misrepresentation). CVSS: 7.0 (High).
  • Wektor: złośliwe pliki .LNK z ukrytymi argumentami poleceń; zwykle dostarczane w archiwach ZIP/RAR w kampaniach phishingowych.
  • Eksploatacja: potwierdzona od co najmniej 2017 r. przez 11 grup APT i gangi cyberprzestępcze (m.in. Mustang Panda/UNC6384, Kimsuky/APT43, APT37, RedHotel, SideWinder, Evil Corp).
  • „Patch” Microsoftu: zmiana UI – teraz okno Właściwości pokazuje cały łańcuch Target (nie tylko pierwsze 260 znaków), co utrudnia ukrycie złośliwych argumentów. Nie jest to pełny „kodowy” fix.
  • Micropatch 0patch: dodatkowa, nieoficjalna mitygacja skracająca Target >260 znaków i ostrzegająca użytkownika; dostępna głównie dla starszych/niewspieranych wersji Windows.

Kontekst / historia / powiązania

Trend Micro ZDI opublikowało w marcu 2025 r. analizę, dokumentując prawie 1000 złośliwych skrótów .LNK i szerokie wykorzystanie luki przez aktorów sponsorowanych przez państwa. Microsoft – po kilku rundach komunikacji – uznał wówczas, że problem „nie spełnia progu” na łatkę bezpieczeństwa. Jesienią 2025 r. Arctic Wolf Labs opisało świeże kampanie UNC6384 (Mustang Panda) przeciw europejskim dyplomatom, dystrybuujące PlugX przez spreparowane .LNK. W efekcie temat wrócił, a w listopadzie interfejs Windows został zmieniony.


Analiza techniczna / szczegóły luki

  • Sedno podatności: UI misrepresentation – Windows w Właściwościach skrótu wyświetlał tylko pierwsze 260 znaków pola Target. Atakujący wypełniali początek długiego łańcucha białymi znakami (spacje, tabulatory), spychając właściwe, złośliwe argumenty poza widoczny fragment. Użytkownik mógł więc zobaczyć „niewinne” powershell.exe/cmd.exe bez realnych parametrów wywołujących pobranie i uruchomienie malware.
  • Wejście do ekosystemu LOLBins: Parametry często uruchamiały living-off-the-land binaria (PowerShell, rundll32, cmd, conhost) do pobrania i uruchomienia ładunku (np. PlugX, Gh0st RAT, Ursnif).
  • „Cicha” zmiana w Windows: po aktualizacjach z listopada 2025 UI pokazuje cały łańcuch Target (teoretycznie do ~32k znaków). To utrudnia socjotechniczne ukrycie argumentów, ale nie blokuje wykonania polecenia per se.

Praktyczne konsekwencje / ryzyko

  • Ataki phishingowe z archiwami zawierającymi .LNK, często stylizowane na dokumenty konferencyjne/urzędowe (tematy NATO/KE itp.), pozostają skuteczne, jeśli użytkownicy nadal uruchamiają skróty.
  • Eskalacja i utrzymanie dostępu: po kliknięciu skrótu następuje łańcuch pobrania i uruchomienia RAT/loadera, często z mechanizmami trwałości.
  • Widoczność w SOC: sama zmiana UI pomaga człowiekowi to zauważyć, ale nie zastępuje kontroli technicznych – IOC/telemetria EDR nadal kluczowe.

Rekomendacje operacyjne / co zrobić teraz

  1. Polityki poczty i bramek: blokuj załączniki .LNK oraz archiwa zawierające .LNK (ZIP/RAR/7z). Włącz sandboxing i detekcję zawartości w archiwach.
  2. Kontrola uruchamiania skrótów:
    • GPO/AppLocker/WDAC: ogranicz uruchamianie .LNK z lokalizacji użytkownika (Downloads, %TEMP%, %AppData%).
    • Blokuj uruchomienia PowerShell/cmd/rundll32 z argumentami z niezaufanych ścieżek. (Technika mapowana do MITRE ATT&CK T1204/T1059).
  3. Defender/EDR:
    • Włącz ASR (blokowanie procesów child z Office/niezaufanych miejsc, blokowanie podejrzanych skryptów PowerShell).
    • Monitoruj zdarzenia „process creation” z bardzo długimi łańcuchami poleceń i obecnością nietypowych białych znaków.
  4. Higiena plików z Internetu: enforce’uj Mark-of-the-Web i blokuj znane MOTW bypassy w Twojej flocie przeglądarek/klientów archiwów.
  5. Sygnatury/YARA: skorzystaj z reguł opublikowanych przez Trend Micro ZDI do wykrywania „padded LNK”. (Dostosuj do własnych pipeline’ów skanowania plików).
  6. Aktualizacje systemu: zainstaluj listopadowe aktualizacje 2025 na wspieranych wydaniach Windows, by uzyskać pełne wyświetlanie Target. Dla starszych wersji rozważ 0patch (micropatch: limit 260 znaków + alert) – po ocenie ryzyka i zgodności.
  7. Szkolenia i playbooki SOC: uaktualnij runbooki analityczne: przy incydentach z plikami .LNK zawsze sprawdzaj cały Target i historię pochodzenia pliku (strefa Internet/MOTW).

Różnice / porównania z innymi przypadkami

  • Stuxnet (CVE-2010-2568) vs CVE-2025-9491: Stuxnet wykorzystywał RCE w parserze .LNK (brak interakcji). Tu problemem jest ukrycie informacji w UI, a RCE wynika z uruchomienia „zaufanego” skrótu przez użytkownika. Inne klasy zagrożeń; wspólny mianownik: .LNK jako nośnik.
  • Nowsze kampanie APT: bieżące operacje (UNC6384) to spear-phishing + .LNK + PlugX i motyw szpiegowski, a nie masowa cyberprzestępczość.

Podsumowanie / kluczowe wnioski

  • CVE-2025-9491 to realny wektor w rekonesansie i intruzjach APT – wykorzystywany od lat, często niezauważany przez człowieka, bo UI wprowadzało w błąd.
  • Microsoft nie wydał klasycznej poprawki bezpieczeństwa, ale zmienił UI tak, by ujawniać pełen łańcuch poleceń. To pomaga, ale nie eliminuje ryzyka – twarde polityki wykonania, EDR i bramki pocztowe pozostają kluczowe.
  • Organizacje powinny wdrożyć warstwowe mitygacje: kontrolę .LNK w mailu/endpointach, ASR/WDAC, monitoring długich command lines i edukację użytkowników.

Źródła / bibliografia

  1. BleepingComputer: „Microsoft ‘mitigates’ Windows LNK flaw exploited as zero-day” (03.12.2025). (BleepingComputer)
  2. Trend Micro ZDI: „ZDI-CAN-25373: Windows Shortcut Exploit Abused as Zero-Day in Widespread APT Campaigns” (18.03.2025, aktualizacje). (www.trendmicro.com)
  3. Zero Day Initiative – Advisory ZDI-25-148 (CVE-2025-9491) i timeline korespondencji z Microsoft. (zerodayinitiative.com)
  4. Arctic Wolf Labs: „UNC6384 Weaponizes ZDI-CAN-25373 to Deploy PlugX Against European Diplomatic Entities” (30.10.2025). (Arctic Wolf)
  5. 0patch (ACROS Security): „Microsoft Silently Patched CVE-2025-9491 – We Think Our Patch Provides More Security” (02.12.2025). (blog.0patch.com)

Chrome 143 łata luki wysokiego ryzyka: co nowego i jak szybko się zaktualizować

Wprowadzenie do problemu / definicja luki

Google udostępniło stabilną wersję Chrome 143 dla Windows, macOS i Linuksa, naprawiając 13 luk bezpieczeństwa, w tym 4 o wysokiej ważności (High). Aktualizacja obejmuje także Androida (143.0.7499.52) i iOS (143.0.7499.92). Google nie poinformowało o aktywnej eksploatacji tych błędów w momencie wydania.

W skrócie

  • Wersje: 143.0.7499.40 (Linux), 143.0.7499.40/41 (Windows/macOS), Android 143.0.7499.52, iOS 143.0.7499.92.
  • Liczba poprawek: 13, w tym CVE-2025-13630 (Type Confusion w silniku V8) oraz m.in. błędy w Google Updater, DevTools i Digital Credentials.
  • Bug bounty: $11 000 za V8 (CVE-2025-13630) i $3 000 za Google Updater (CVE-2025-13631).
  • Extended Stable: zaktualizowany do 142.0.7499.226 dla Windows i macOS.

Kontekst / historia / powiązania

Chrome od lat pozostaje jednym z najczęściej aktualizowanych przeglądarek. Cykl wydawniczy zakłada szybkie łatanie podatności zgłaszanych przez zewnętrznych badaczy oraz zespół Chromium. Wydanie 143 kontynuuje tę praktykę i – jak zwykle – część szczegółów technicznych w trackerze Chromium pozostaje tymczasowo ograniczona do czasu, aż większość użytkowników zaktualizuje przeglądarkę.

Analiza techniczna / szczegóły luki

W ramach Chrome 143 Google wyróżniło następujące luki o wysokiej ważności (High):

  • CVE-2025-13630 – Type Confusion w V8/WebAssembly: błąd klasyfikacji typów może prowadzić do korupcji pamięci i potencjalnego wykonania kodu. Zgłoszona 2025-10-31; nagroda $11 000.
  • CVE-2025-13631 – Inappropriate implementation w Google Updater: błąd implementacyjny w mechanizmie aktualizatora; nagroda $3 000.
  • CVE-2025-13632 – Inappropriate implementation w DevTools: podatność umożliwiająca potencjalny sandbox escape w scenariuszu złośliwego rozszerzenia Chrome (wymagana interakcja użytkownika – instalacja rozszerzenia).
  • CVE-2025-13633 – Use-after-free w Digital Credentials.

Dodatkowo załatano błędy średniej ważności (m.in. Downloads, Loader, race w V8) oraz szereg problemów o niskiej ważności (Downloads, Split View, WebRTC, Passwords, Media Stream).

Praktyczne konsekwencje / ryzyko

  • V8 Type Confusion (CVE-2025-13630) zwiększa ryzyko zdalnego wykonania kodu (RCE) przez stronę WWW wykorzystującą subtelne sekwencje JS/Wasm – szczególnie groźne na desktopach, gdzie atakujący może połączyć błąd z innymi wektorami eskalacji.
  • DevTools (CVE-2025-13632): ryzyko ucieczki z piaskownicy po namówieniu użytkownika do instalacji złośliwego rozszerzenia – scenariusz realny w kampaniach phishingowo-malvertisingowych.
  • Brak sygnałów o exploitach „in the wild” w chwili publikacji – mimo to Chrome historycznie bywa celem szybkiego weaponization, więc opóźnienia w aktualizacji podnoszą ekspozycję.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja Chrome do 143 na wszystkich platformach; w środowiskach zarządzanych wymuś Help → About Google Chrome lub dystrybucję pakietów. Android/iOS: zaktualizuj z Google Play / App Store.
  2. Weryfikacja kanału Extended Stable – jeśli używasz, upewnij się, że wersja to 142.0.7499.226 (Windows/macOS).
  3. Polityka rozszerzeń: ogranicz instalację wyłącznie do zatwierdzonych rozszerzeń (allow-list) i zablokuj sideloading, by ograniczyć ryzyko nadużyć DevTools.
  4. Telemetria i detekcja: monitoruj anomalie przeglądarkowe (np. nieoczekiwane crashe rendererów, podejrzane rozszerzenia, nietypowe uprawnienia) oraz wdroż reguły EDR wykrywające znane techniki sandbox escape.
  5. Higiena aktualizacji JS/Wasm w aplikacjach webowych i testy regresyjne – błędy V8 bywają wyzwalane przez nieoczekiwane ścieżki wykonania.

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od wydań „reaktywnych” (z łatanymi zero-dayami), Chrome 143 nie zawiera informacji o exploitach aktywnie wykorzystywanych – co jednak nie zmniejsza pilności aktualizacji, biorąc pod uwagę klasę błędów w V8/DevTools.
  • Wersje mobilne Android 143.0.7499.52 i iOS 143.0.7499.92 dziedziczą poprawki bezpieczeństwa z desktopu i są udostępniane etapowo.

Podsumowanie / kluczowe wnioski

Chrome 143 to ważne wydanie wzmacniające bezpieczeństwo przeglądarki: krytyczne w praktyce błędy w V8 oraz ryzykowna ścieżka w DevTools wymagają szybkiej aktualizacji na desktopach i urządzeniach mobilnych. Administratorzy powinni przy okazji zaostrzyć polityki rozszerzeń, a zespoły SOC – dołożyć reguły i widoczność wokół zachowań przeglądarki.

Źródła / bibliografia

  1. Chrome Releases – Stable Channel Update for Desktop (Dec 2, 2025) – wersje, lista CVE, nagrody. (Chrome Releases)
  2. SecurityWeek: “Chrome 143 Patches High-Severity Vulnerabilities” (Dec 3, 2025) – podsumowanie, status braku exploitów w dziczy, zestawienie wersji. (SecurityWeek)
  3. Chrome Releases – Chrome for Android Update (Dec 2, 2025) – wersja 143.0.7499.52, informacje o rollout. (Chrome Releases)
  4. Chrome Releases – December 2025 (wpisy iOS/Extended Stable) – iOS 143.0.7499.92 oraz Extended Stable 142.0.7499.226. (Chrome Releases)
  5. NVD: CVE-2025-13632 (DevTools) – opis wektora ataku (złośliwe rozszerzenie, sandbox escape). (NVD)

Ukrywanie Procesów W Systemach Operacyjnych – Mechanizmy, Techniki i Przykłady

Jak system naprawdę widzi procesy i dlaczego to ważne przed analizą ukrywania

Czy da się ukryć działający proces przed administratorem systemu? Niestety tak – istnieją zaawansowane techniki pozwalające zataić obecność procesu zarówno w systemach Linux, jak i Windows. W tym artykule, omawiamy ukrywanie procesów krok po kroku: od metod działania w przestrzeni użytkownika (user-mode) po głębokie modyfikacje w jądrze systemu (kernel-mode).

Czytaj dalej „Ukrywanie Procesów W Systemach Operacyjnych – Mechanizmy, Techniki i Przykłady”

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.