Archiwa: Linux - Strona 29 z 43

Anubis RaaS: niedoceniane zagrożenie dla sektora medycznego. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

W czasie gdy część grup ransomware ogranicza się do podwójnego wymuszenia (exfiltracja + publikacja danych), Anubis pozostaje wierny klasycznej enkrpycji systemów – a dodatkowo dorzuca funkcję niszczenia danych (wiper). Ten Ransomware-as-a-Service (RaaS) coraz częściej pojawia się na leak-sitach z ofiarami z sektora ochrony zdrowia w USA, co potwierdzają najnowsze doniesienia o ataku na praktykę Mid South Pulmonary & Sleep Specialists (MSPS) w Tennessee.

W skrócie

Anubis RaaS łączy szyfrowanie z opcjonalnym /WIPEMODE, który trwale usuwa zawartość plików – znacząco obniżając szanse odzysku.
Grupa działa od końca 2024 r., wywodzi się z projektu „Sphinx”, celuje m.in. w Windows/Linux/NAS/ESXi, a wśród branż figuruje ochrona zdrowia.
Na leak-site Anubisa w listopadzie pojawiło się co najmniej pięć podmiotów medycznych z USA, z ujawnionym PHI; w wielu przypadkach brak publicznych notyfikacji i wpisów w narzędziu HHS.
Atak na MSPS: dostęp uzyskany 10 listopada, tydzień rekonesansu, szyfrowanie środowiska Nutanix, exfiltracja ~860 GB danych, część już wyciekła. (Deklaracje gangu, potwierdzane przez przegląd drzewa plików).
Obrona: segmentacja i EDR/XDR, niezmienne kopie (immutable) z 3-2-1-1-0, hardening hypervisorów i konsol, MFA wszędzie, plan IR zgodny z CISA Stop Ransomware.

Kontekst / historia / powiązania

Według analiz, Anubis to nowa operacja RaaS aktywna od grudnia 2024 r., która w warstwie technicznej i brandingowej ewoluowała z „Sphinx”. Rozwija elastyczny program afiliacyjny i – w przeciwieństwie do „exfil-only” – regularnie szyfruje zasoby ofiar.

Analiza techniczna / szczegóły luki

Łańcuch ataku i TTPs (wybrane):

Wejście: spear-phishing z linkami/załącznikami; użycie ważnych kont (T1566, T1078).
Wykonanie: parametry uruchomieniowe, m.in. "/KEY=", "/elevated", "/WIPEMODE", "/PATH=", "/PFAD=".
Eskalacja i unikanie: sprawdzanie uprawnień admina, próby podniesienia do SYSTEM, manipulacja tokenami (T1134.002).
Uderzenie: kasowanie VSS (vssadmin delete shadows), zatrzymywanie usług backup/DB/AV, szyfrowanie ECIES (Golang), opcjonalne wipowanie zawartości, rozszerzenie .anubis, notatka RESTORE FILES.html.

Specyfika „wipera”: przełącznik /WIPEMODE umożliwia zniszczenie treści plików po (lub zamiast) szyfrowania – utrwalając szkodę i wymuszając zapłatę nawet przy poprawnych procedurach backupu, jeśli kopie nie są odporne na modyfikacje.

Praktyczne konsekwencje / ryzyko

Bezpośrednie ryzyko dla ciągłości opieki: paraliż HIS/EHR, laboratoria, grafiki zabiegowe, systemy billingowe; przy wiperze – długotrwała utrata danych.
Ryzyko regulacyjne (HIPAA/HITECH): wyciek PHI ⇒ obowiązki notyfikacyjne; brak szybkich zgłoszeń uwypukla lukę komunikacyjną pomiędzy ofiarami a HHS/OCR.
Ryzyko reputacyjne i prawne: dług ogłoszeń, pozwy zbiorowe, presja płatników i ubezpieczycieli.
Ryzyko infrastrukturalne: ataki na hypervisor/VM/NAS/ESXi/Nutanix i systemy kopii zapasowych – jeżeli nie są izolowane/niemodyfikowalne, wiper je unieszkodliwi.

Rekomendacje operacyjne / co zrobić teraz

Kopie niemodyfikowalne i odseparowane (immutable + air-gap)
- Zastosuj 3-2-1-1-0 (co najmniej jedna kopia offline/immutable, weryfikacja odzysku bez błędów).
- Testuj DR pod scenariusz „ransomware + wiper” (RTO/RPO).
Segmentacja i zasada najmniejszych uprawnień
- Mikrosegmentacja sieci klinicznych (EHR/PACS/IoMT) i odseparowanie konsol zarządczych (Nutanix/VMware/NAS).
Hardening hypervisorów i konsol
- MFA na SSH/API/konsolach, rotacja i escrow kluczy, zamrożenie ścieżek administracyjnych „break-glass”, blokada dostępu zdalnego „z internetu”.
EDR/XDR + telemetria
- Polowania na wskaźniki: nietypowe vssadmin, masowe Stop-Service, procesy z parametrami "/WIPEMODE"/"/elevated", nietypowe operacje na \\.\PHYSICALDRIVE0.
Twarde MFA i higiena kont
- Wyłącz konta lokalne, klucze FIDO2 dla administratorów, „Privileged Access Workstations” dla operacji na hypervisorach.
E-mail i tożsamość
- Zaawansowana filtracja (DMARC/DKIM/SPF), izolacja URL/załączników, szkolenia o spear-phishingu.
Plan reagowania (IR) zgodny z CISA Stop Ransomware
- Gotowe playbooki: triage, izolacja, powiadomienia, ścieżka prawna/HIPAA, komunikacja z pacjentami/regulatorami.

Różnice / porównania z innymi przypadkami

LockBit/BlackCat/BianLian często kładą nacisk na exfiltrację i presję medialną; Anubis dodatkowo eskaluje presję przez wiper – co przy braku immutable-backupów czyni incydent bardziej destrukcyjnym. (Wniosek na podstawie porównań TTP i funkcji technicznych opisanych przez badaczy).
Targeting: w ostatnich tygodniach Anubis wyraźnie listuje podmioty medyczne z USA (przykład: MSPS), co odróżnia go od grup polujących szerzej w sektorach przemysłowych.

Podsumowanie / kluczowe wnioski

Anubis to „hybrydowy” RaaS z wiperem – zagraża ciągłości opieki i odzyskowi danych nawet w dobrze prowadzonych środowiskach, jeśli kopie nie są niezmienialne.
W listopadzie leak-site gangu wypełnił się podmiotami ochrony zdrowia z USA, a komunikacja kryzysowa bywa opóźniona.
Priorytetem są: immutable backupy, hardening warstwy wirtualizacji/NAS, EDR/XDR z detekcją „wiperowych” TTP, MFA wszędzie oraz playbook CISA.

Źródła / bibliografia

DataBreaches.net — They’ve escaped a lot of media attention, but Anubis RaaS is a threat to the medical sector (MSPS, listopadowe listingi HPH, PHI). (DataBreaches.Net)
Trend Micro — Anubis: A Closer Look at an Emerging Ransomware with Built-in Wiper (TTP, parametry, ECIES, profil ofiar). (www.trendmicro.com)
KPMG CTI — Anubis Ransomware – Weaponizing Wipers for Extortion (pochodzenie „Sphinx”, /WIPEMODE, platformy, branże).
Ransomware.live — wpis ofiary Mid South Pulmonary & Sleep Specialists (claim Anubis, data). (Ransomware Live)
CISA — Stop Ransomware: Ransomware Guide (prewencja i checklisty reakcji). (CISA)

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

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.
Weryfikacja kanału Extended Stable – jeśli używasz, upewnij się, że wersja to 142.0.7499.226 (Windows/macOS).
Polityka rozszerzeń: ogranicz instalację wyłącznie do zatwierdzonych rozszerzeń (allow-list) i zablokuj sideloading, by ograniczyć ryzyko nadużyć DevTools.
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.
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

Chrome Releases – Stable Channel Update for Desktop (Dec 2, 2025) – wersje, lista CVE, nagrody. (Chrome Releases)
SecurityWeek: “Chrome 143 Patches High-Severity Vulnerabilities” (Dec 3, 2025) – podsumowanie, status braku exploitów w dziczy, zestawienie wersji. (SecurityWeek)
Chrome Releases – Chrome for Android Update (Dec 2, 2025) – wersja 143.0.7499.52, informacje o rollout. (Chrome Releases)
Chrome Releases – December 2025 (wpisy iOS/Extended Stable) – iOS 143.0.7499.92 oraz Extended Stable 142.0.7499.226. (Chrome Releases)
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

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

TL;DR

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

Krótka definicja techniczna

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

Gdzie występuje / przykłady platform

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

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

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

Artefakty i logi (co i gdzie szukać)

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

Detekcja (praktyczne reguły)

Sigma (webserver)

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

Splunk (SPL)

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

KQL (Azure / CEF w Sentinel)

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

AWS — CloudWatch Logs Insights (AWS WAF)

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

Elastic (Kibana KQL)

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

Heurystyki / korelacje

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

False positives / tuning

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

Playbook reagowania (IR)

Triage & containment

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

Analiza

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

Eradykacja & naprawa

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

Lessons learned

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

Przykłady z kampanii / case studies

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

Lab (bezpieczne testy)

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

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

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

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

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

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

Powiązane techniki:

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

Źródła / dalsza lektura

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

Checklisty dla SOC / CISO

SOC

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

CISO / OT Lead

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

CISA dodaje do KEV aktywnie wykorzystywaną lukę XSS (CVE-2021-26829) w OpenPLC ScadaBR

Wprowadzenie do problemu / definicja luki

28 listopada 2025 r. CISA dodała do katalogu KEV (Known Exploited Vulnerabilities) lukę CVE-2021-26829 w OpenPLC ScadaBR – podatność typu stored XSS (Cross-Site Scripting), która umożliwia wstrzyknięcie kodu JavaScript poprzez stronę system_settings.shtm. Afera jest istotna dla środowisk OT/ICS, bo błąd dotyczy paneli HMI używanych do nadzoru i sterowania procesami. Wpis w KEV oznacza potwierdzoną eksploatację w środowisku rzeczywistym i dla agencji FCEB wyznacza termin wdrożenia środków zaradczych do 19 grudnia 2025 r.

W skrócie

CVE-2021-26829: stored XSS w OpenPLC ScadaBR (Windows ≤ 1.12.4, Linux ≤ 0.9.1), CVSS 3.1: 5.4 (Medium).
Status: dodane do CISA KEV 28.11.2025 r. z obowiązkiem działań do 19.12.2025 r. dla FCEB.
Eksploatacja: m.in. przez grupę hacktywistyczną TwoNet w incydencie na wabiku (honeypot) stylizowanym na oczyszczalnię wody – defacement HMI, manipulacja ustawieniami, wyłączanie logów i alarmów.
Trend: skoordynowane skanowanie i eksploatacja setek CVE z wykorzystaniem prywatnej infrastruktury OAST działającej w Google Cloud, z regionalnym ukierunkowaniem na Brazylę.

Kontekst / historia / powiązania

Badacze Forescout/Vedere Labs opisali we wrześniu 2025 r. atak grupy TwoNet na ich pułapkę OT – agresorzy najpierw zalogowali się na HMI domyślnymi danymi, a następnie użyli CVE-2021-26829 do osadzenia złośliwego skryptu wyświetlającego komunikat „HACKED BY BARLATI” oraz modyfikowali ustawienia systemu (w tym wyłączenie logów i alarmów). To potwierdza realny wpływ XSS na bezpieczeństwo operacji, mimo że formalnie ma on „średni” rating.

Równolegle VulnCheck wykrył długotrwale działającą, atakującą infrastrukturę OAST (*.i-sh.detectors-testing[.]com na IP 34.136.22.26) hostowaną w Google Cloud. Zarejestrowano ok. 1,4 tys. prób dotyczących ponad 200 CVE, kierowanych głównie przeciw systemom w Brazylii, co wskazuje na skanowanie „masowe, ale ukierunkowane”. Taki model ułatwia sprawcom weryfikację skuteczności exploitów i maskowanie ruchu w chmurze.

Analiza techniczna / szczegóły luki

Wektor: stored XSS w system_settings.shtm – użytkownik o uprawnieniach aplikacyjnych może wprowadzić treść, która zostanie renderowana w HMI i wykona skrypt w przeglądarce operatora. S: Changed, PR: Low, UI: Required.
Zakres dotkniętych wersji: Windows ≤ 1.12.4, Linux ≤ 0.9.1. Brak dowodów, że starsze forki lub niestandardowe buildy są odporne.
Skutki techniczne:
- Defacement interfejsu HMI i wstrzyknięcie złośliwych treści (np. pop-upy, przekierowania).
- Kradzież sesji/CSRF lub pułapki operatorskie (ang. UI redressing), które mogą prowadzić do błędnych decyzji operatorskich.
- Modyfikacja widoków i formularzy skutkująca np. fałszywymi parametrami procesu. (W incydencie TwoNet mix: defacement + manipulacja ustawieniami i wyłączenie alarmów).

Praktyczne konsekwencje / ryzyko

W środowiskach OT/ICS skutki XSS wykraczają poza klasyczne „phishing UI”. Manipulacja widokiem HMI może:

ukryć rzeczywiste alarmy,
zafałszować setpointy/telemetrię,
skłonić operatora do niebezpiecznych działań (np. zmiany parametrów).

Incydent Forescout pokazał, że od pierwszego dostępu do działań destrukcyjnych minęło ~26 godzin, a atakujący skoncentrował się wyłącznie na warstwie webowej HMI, bez eskalacji na hosta – co czyni tego typu ataki ciche, szybkie i możliwe do przeoczenia przez klasyczne EDR.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa weryfikacja ekspozycji
- Zidentyfikuj instancje OpenPLC ScadaBR (Windows/Linux) i ich wersje; sprawdź bezpośrednią ekspozycję do Internetu (Shodan/asset inventory).
Aktualizacje i środki tymczasowe
- Jeśli dostępne łatki/vendor-fix – wdrożyć; w przeciwnym wypadku filtracja treści, encoding output i sanityzacja pól konfiguracyjnych system_settings.shtm.
- Dla środowisk FCEB: dotrzymaj terminu 19.12.2025 z wpisu KEV.
Twardnienie interfejsów HMI (zalecenia Vedere Labs):
- Eliminacja słabych/dom yślnych haseł, MFA dla adminów.
- Segmentacja (oddzielenie strefy HMI od IT/Internetu), przepływy jednokierunkowe tam, gdzie to możliwe.
- Usunięcie zbędnej ekspozycji (VPN z mTLS zamiast publicznego HMI).
Monitoring i detekcja specyficzna dla OT
- DPI z rozumieniem Modbus/S7 i regułami na: próby exploitów, nieautoryzowane zapisy, zmiany w HMI, tworzenie kont (np. „BARLATI”).
Blokowanie i hunting na wskaźniki OAST
- Monitoruj/blokuj wywołania do domen *.i-sh.detectors-testing.com i aktywność z adresów Google Cloud wymienionych przez VulnCheck (np. 34.136.22.26 dla hosta OAST). Uważaj na fałszywie dodatnie – kontekst sieci i geolokalizacja są kluczowe.
Bezpieczne SDLC dla HMI/SCADA
- Systematyczny output encoding, CSP, sanitizacja danych, testy DAST/SAST i testy XSS (stored/reflected/DOM) w pipeline.

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

W przeciwieństwie do typowych XSS w aplikacjach biurowych, XSS w HMI/SCADA:

oddziałuje na proces przemysłowy przez interakcję z operatorem,
bywa „wystarczający” do manipulacji setpointami i wyłączenia alarmów, nawet bez RCE na hoście,
częściej jest łączony z domyślnymi hasłami i błędną segmentacją sieci (co pokazał przypadek TwoNet).

Z kolei kampania opisana przez VulnCheck obrazuje industrializację skanowania – prywatne OAST na chmurze, stare i nowe szablony Nuclei, szeroka lista CVE i regionalne ukierunkowanie. To inny wektor niż ręczny atak na HMI, ale oba trendy się uzupełniają: masowe wykrywanie podatnych hostów + celowana eksploatacja w OT.

Podsumowanie / kluczowe wnioski

CVE-2021-26829 w OpenPLC ScadaBR trafiła do CISA KEV z powodu realnej eksploatacji – to nie tylko „estetyczny” XSS.
Incydent TwoNet pokazuje, że XSS w HMI może prowadzić do defacementu, manipulacji i ukrycia alarmów w ciągu ~26 godzin od pierwszego dostępu.
OAST w chmurze (Google Cloud) napędza skalowalną eksploatację setek CVE – to trend, który ułatwia przeciwnikom maskowanie aktywności.
Organizacje OT/ICS powinny natychmiast zidentyfikować instancje ScadaBR, wdrożyć łatki/mitigacje, utwardzić HMI i wprowadzić monitoring DPI z regułami pod XSS/OAST.

Źródła / bibliografia

NVD: CVE-2021-26829 (opis, wersje, CVSS, informacja o włączeniu do CISA KEV z datami 28.11.2025 / 19.12.2025) – National Vulnerability Database. (nvd.nist.gov)
VulnCheck: The Mystery OAST Host Behind a Regionally Focused Exploit Operation (OAST na Google Cloud, ~1400 prób, >200 CVE, 27.11.2025). (VulnCheck)
The Hacker News: CISA Adds Actively Exploited XSS Bug CVE-2021-26829 in OpenPLC ScadaBR to KEV (kontext i agregacja informacji, 30.11.2025). (The Hacker News)

“Contagious Interview” rozszerza kampanię: 197 złośliwych paczek npm rozprowadza nowy wariant malware OtterCookie

Wprowadzenie do problemu / definicja luki

Zespół Socket Threat Research opisał nową falę kampanii “Contagious Interview” przypisywanej aktorom powiązanym z DPRK. Od 10 października 2025 r. do końca listopada aktorzy wprowadzili co najmniej 197 kolejnych złośliwych paczek npm, zwiększając łączną liczbę pobrań o >31 tys. Najnowszy łańcuch ataku wykorzystuje npm → Vercel → GitHub do dostarczenia świeżego wariantu OtterCookie – narzędzia łączącego funkcje infostealera i RAT z naciskiem na kradzież aktywów krypto oraz danych deweloperów.

MITRE ATT&CK klasyfikuje Contagious Interview (G1052) jako grupę aktywną od 2023 r., celującą w użytkowników Windows, macOS i Linux – szczególnie w deweloperów oraz osoby powiązane z blockchain/Web3.

W skrócie

Skala: +197 złośliwych paczek npm w najnowszej fali; co najmniej 15 w momencie publikacji Socket pozostawało dostępnych (zablokowanych następnie przez zespół npm).
Łańcuch: paczka npm z backdoorem → Vercel jako stager → kod z GitHub → uruchomienie OtterCookie i zestawienie C2.
Zdolności: fingerprinting, unikanie sandboxów/VM, keylogging globalny, screenshoty multi-monitor, kradzież schowka, skanowanie systemu i przeglądarek (Chrome/Brave, rozszerzenia walletów), zdalny shell.
TTPs: postinstall + eval odpowiedzi z sieci, typosquatting (np. tailwind-magic jako fork tailwind-merge), socjotechnika „fałszywi rekruterzy” i „zadania testowe”.

Kontekst / historia / powiązania

Kampania Contagious Interview została opisana m.in. przez Unit 42 (Palo Alto Networks) jako scenariusz, w którym napastnicy podszywają się pod rekruterów i przekonują ofiary do uruchomienia złośliwych narzędzi podczas „rozmów kwalifikacyjnych” lub zadań domowych. Wcześniejsze warianty dostarczały BeaverTail (downloader/infostealer) i InvisibleFerret (backdoor).

MITRE ATT&CK formalnie dodało grupę G1052 w październiku 2025 r., dokumentując m.in. wykorzystanie Vercel, GitHub, rejestrów pakietów oraz mechanizmów społecznościowych (LinkedIn itp.).

W styczniu 2025 r. analitycy NTT Security jako jedni z pierwszych nazwali nową rodzinę OtterCookie, opisując jej ewolucję (m.in. użycie Socket.IO do C2, kradzież „seedów” portfeli i zawartości schowka). Dzisiejsza fala na npm to rozwinięcie tej samej linii rozwojowej.

Analiza techniczna / szczegóły luki

Wejście do łańcucha

Paczki npm podszywające się pod popularne biblioteki (np. tailwind-magic imitujące tailwind-merge) zawierały postinstall uruchamiający loader. Loader wykonywał żądanie do stagera na Vercel (tetrismic[.]vercel[.]app), a odpowiedź była dynamicznie wykonywana (eval) w procesie Node.js. Repozytoria kodu i lury (np. projekty DEX/DeFi) utrzymywano na koncie stardev0914 na GitHub.

Stager i payload

Stager (Vercel) serwował aktualną zawartość pliku main.js w polu JSON (np. model), co pozwalało na rotację ładunków i modyfikację per cel. Drugi etap uruchamiał OtterCookie, który zestawiał kanał C2 i realizował zadania aktora.

Możliwości OtterCookie (najnowszy wariant)

Ewazja: detekcja środowisk wirtualnych/sandbox.
Rozpoznanie i kontrola: fingerprinting hosta, zdalny shell, długotrwała łączność C2.
Eksfiltracja: keylogging, screenshoty z wielu monitorów, kradzież schowka, rekursywne skanowanie systemu, wykradanie danych przeglądarek (Chrome/Brave) i rozszerzeń portfeli na Windows/macOS/Linux.
Cel: dokumenty, hasła, seed phrases, dane projektów krypto/Web3.

Techniki ATT&CK (wybrane)

T1195.002 (kompromitacja łańcucha dostaw), T1204.005 (złośliwa biblioteka), T1059.007 (JavaScript), T1497 (ewazja sandboxów), T1056.001 (keylogging), T1539/T1555.001 (ciasteczka sesyjne/Keychain), T1585/T1583.006 (tworzenie kont, usługi web).

Praktyczne konsekwencje / ryzyko

Zakażenia stanowisk deweloperskich → wyciek kluczy produkcyjnych, tokenów CI/CD, podpisów wydawniczych i seedów portfeli.
Ryzyko lateral movement z laptopa dev do środowisk chmurowych i pipelines (kradzież ciasteczek/przeglądarki).
Trwałość dzięki rotacji payloadów i rozproszonej infrastrukturze (npm + Vercel + GitHub).

Rekomendacje operacyjne / co zrobić teraz

1) Traktuj każdy npm install jak RCE

Odetnij CI/build od sekretów: brak dostępu do kluczy produkcyjnych, walletów, interfejsów admin chmury.
Wymuś egress filtering w czasie buildów; blokuj niespodziewane połączenia (np. .vercel.app spoza allowlisty).

2) Kontrola zależności i blokady wersji

Pinowanie wersji + lockfile; zakaz auto-aktualizacji „po cichu”.
Weryfikuj nowe/mało znane biblioteki, zwłaszcza „utility” plug-iny włączane globalnie.

3) Polityka kodu i przeglądy

Review każdego szablonu z GitHub (szczególnie Web3/DeFi).
Skanuj pull requesty pod kątem zachowań: import-time loaders, eval na odpowiedzi HTTP, dostęp do schowka/klawiatury. (Zwróć uwagę na znane paczki-przynęty jak tailwind-magic / „node-tailwind”.)

4) Twardnienie stacji dev

Odseparowane przeglądarki do pracy z walletami; menedżery haseł i polityka kluczy air-gapped do podpisywania.
Wykrywaj niecodzienne zachowania (global keylogging, multi-monitor screenshots, intensywne I/O na profilach przeglądarek).

5) Edukacja i „purple teaming”

Szkolenia dot. fałszywych rekruterów i „zadań testowych”.
Ćwiczenia ATT&CK dla technik dokumentowanych w G1052 (T1204.005, T1195.002, itd.).

6) Działania detekcyjno-reakcyjne (IoC/TTP-centric)

Przegląd instalacji npm z ostatnich 60–90 dni pod kątem postinstall, połączeń do .vercel.app, eval odpowiedzi JSON, artefaktów OtterCookie (np. aktywność Socket.IO, nietypowe procesy z uprawnieniami).
Korelacja z wcześniejszymi wariantami (BeaverTail/InvisibleFerret) – te często współwystępują.

Różnice / porównania z innymi przypadkami

OtterCookie vs. BeaverTail/InvisibleFerret: nowy wariant scala funkcje – zamiast łańcucha „downloader → backdoor” część zdolności (kradzież schowka/klawiatury, zdalny shell) jest w jednym module, co upraszcza operacje i utrudnia detekcję sygnaturową.
Infrastruktura: wyraźne operacjonalizowanie Vercel jako stagera oraz cykliczne odświeżanie payloadu (deploy’e na repo tetrismic). To odróżnia falę z 4Q’25 od wcześniejszych kampanii bazujących głównie na bezpośrednich serwerach C2.
Socjotechnika: stały motyw „rekrutacji” i zadań programistycznych – potwierdzony badaniami Unit 42 i ujęty w profilu MITRE G1052.

Podsumowanie / kluczowe wnioski

Kampania Contagious Interview pozostaje systematyczną, „fabryczną” operacją kompromitującą łańcuch dostaw JS: npm → Vercel → GitHub.
197 nowych paczek pokazało, że aktor konsekwentnie adaptuje TTPs, konsolidując możliwości w OtterCookie i optymalizując dystrybucję przez stager.
Organizacje muszą traktować instalację zależności jak egzekucję kodu obcego i wdrożyć kontrolę egress, pinowanie, review’y behawioralne oraz izolację sekretów.

Źródła / bibliografia

Socket Threat Research – Inside the GitHub Infrastructure Powering North Korea’s Contagious Interview npm Attacks (26 listopada 2025). (Socket)
MITRE ATT&CK – Contagious Interview (G1052) (utw. 19 października 2025; modyf. 24 października 2025). (attack.mitre.org)
Unit 42 (Palo Alto Networks) – Contagious Interview: DPRK Threat Actors Lure Tech Industry Job Seekers… (9 października 2024). (Unit 42)
NTT Security Japan – OtterCookie, new malware used in Contagious Interview campaign (16 stycznia 2025). (jp.security.ntt)
The Hacker News – North Korean Hackers Deploy 197 npm Packages to Spread Updated OtterCookie Malware (28 listopada 2025). (The Hacker News)

Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0

Czy backup to wystarczająca tarcza przed ransomware?

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

Czytaj dalej