Archiwa: Linux - Strona 38 z 53 - 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)

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

  1. 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).
  2. Segmentacja i zasada najmniejszych uprawnień
    • Mikrosegmentacja sieci klinicznych (EHR/PACS/IoMT) i odseparowanie konsol zarządczych (Nutanix/VMware/NAS).
  3. 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”.
  4. EDR/XDR + telemetria
    • Polowania na wskaźniki: nietypowe vssadmin, masowe Stop-Service, procesy z parametrami "/WIPEMODE"/"/elevated", nietypowe operacje na \\.\PHYSICALDRIVE0.
  5. Twarde MFA i higiena kont
    • Wyłącz konta lokalne, klucze FIDO2 dla administratorów, „Privileged Access Workstations” dla operacji na hypervisorach.
  6. E-mail i tożsamość
    • Zaawansowana filtracja (DMARC/DKIM/SPF), izolacja URL/załączników, szkolenia o spear-phishingu.
  7. 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

  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.

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

  1. Natychmiastowa weryfikacja ekspozycji
    • Zidentyfikuj instancje OpenPLC ScadaBR (Windows/Linux) i ich wersje; sprawdź bezpośrednią ekspozycję do Internetu (Shodan/asset inventory).
  2. 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.
  3. 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).
  4. 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”).
  5. 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.
  6. 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

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