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

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)

CVE‑2019‑0708 „BlueKeep”

TL;DR

BlueKeep (CVE‑2019‑0708) to przed‑autentykacyjna podatność RCE w usłudze Remote Desktop Services/TermService (RDP) w starszych Windows (XP, Vista, 7; Server 2003/2008/2008 R2). Umożliwia zdalne wykonanie kodu bez interakcji użytkownika i ma potencjał „wormowalny”. NLA redukuje ryzyko automatycznej propagacji, ale nie eliminuje RCE jeśli atakujący ma ważne poświadczenia — łatka jest obowiązkowa (np. KB4499164/KB4499175, KB4499180, KB4500331). CVSS v3.1: 9.8 (Critical).


Krótka definicja techniczna

CVE‑2019‑0708 to błąd w implementacji RDP w komponencie jądra (m.in. termdd.sys/RDS), który pozwala niezalogowanemu napastnikowi na wysłanie specjalnie przygotowanych PDU w fazie zestawiania kanałów RDP i osiągnięcie zdalnego wykonania kodu w kontekście systemowym. W praktyce umożliwia to wejście (Initial Access) lub ruch boczny (Lateral Movement) przez RDP.


Gdzie występuje / przykłady platform

  • Windows XP SP3 (x86/x64/Embedded), Server 2003 (SP2/R2), Vista SP2, Windows 7 SP1, Windows Server 2008 / 2008 R2 — podatne bez aktualizacji. Microsoft wydał poprawki, łącznie dla systemów EoL. Windows 8/10/11 nienarażone.
  • Środowiska chmurowe (AWS/Azure/GCP) — ryzyko ekspozycji dotyczy głównie instancji z otwartym 3389/TCP na Internet (Security Groups/NSG). To mapuje się do T1190/T1021.001 i wymaga kontroli reguł sieciowych. (Źródło ogólne — ATT&CK).
  • AD/ESXi/K8s/M365 — sama podatność dotyczy Windows; dla tych platform istotne są punkty ekspozycji RDP (jump/bastion), polityki segmentacji i bram RDP.

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

BlueKeep wykorzystuje błąd w przetwarzaniu kanałów/strumienia RDP podczas handshake’u (przed uwierzytelnieniem). Atakujący nawiązuje połączenie do 3389/TCP i wysyła sekwencję PDU, które prowadzą do korupcji pamięci jądra i przejęcia kontroli nad wykonaniem. Skuteczność wynika z:

  • Pre‑auth RCE (brak logowania / brak interakcji),
  • Wormowalności (możliwa automatyczna propagacja),
  • Powszechnej ekspozycji RDP w sieciach firmowych oraz często w Internecie.
    NLA wymaga uwierzytelnienia przed dotarciem do podatnej ścieżki i utrudnia automatyczne rozprzestrzenianie, ale nie chroni, jeśli napastnik ma ważne poświadczenia (np. z wycieku). Dlatego aktualizacja pozostaje jedyną trwałą mitigacją.

Artefakty i logi (tabela)

ŹródłoArtefakt / poleCo obserwowaćWartość dla detekcji
Windows/SystemEvent ID 56, Provider: TermDD„The Terminal Server security layer detected an error in the protocol stream…”; skoki liczby błędów z jednego źródłowego IPIndykator skanów/nieudanych exploitów BlueKeep; korelować z 3389/TCP i restartami usług.
Windows/Security4624/4625 (LogonType=10)Udane/nieudane logowania RDP; źródłowe IPDo odróżnienia legalnych adminów od zewnętrznych adresów; koreluj z ekspozycją portu.
Windows/TerminalServices‑RemoteConnectionManager/Operational1149„User authentication succeeded” (i czasem niektóre nieudane)Linia czasu sesji RDP; łączyć z 4624 i źródłowym IP.
Windows/System7031 (Service Control Manager)Nieoczekiwane restarty Remote Desktop ServicesCzęsto przy niestabilnych exploitach/handshake’ach; korelować z Event 56 i portem 3389.
EDR„RDP service spawning child”svchost.exe (TermService) → nietypowe dzieci (cmd/powershell)Rzadkie w admin rutynie; mocny sygnał post‑exploitation. (wiedza ogólna)
Sieć/Firewall/ProxyPołączenia TCP/3389 z InternetuNowe źródła, wysokie wolumeny, nietypowe ASNWczesne ostrzeżenie o skanach/atakach.
AWS CloudTrailAuthorizeSecurityGroupIngress (EC2)Reguły SG z 3389 do 0.0.0.0/0Ekspozycja RDP w chmurze (Initial Access/T1190).
Azure ActivityMICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITENSG otwierające 3389 na „Internet/Any”Jak wyżej (chmura).
K8s audit / M365[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (gotowe reguły)

A) TermDD burst — możliwy skan/eksploit BlueKeep

title: Windows RDP TermDD Protocol Errors Burst (BlueKeep/Scan)
id: 2f2f8e8a-6a1a-45d2-9b6f-td56-burst
status: experimental
description: Wykrywa nagłe skoki błędów TermDD (EventID 56) sugerujące skany lub nieudane próby eksploatacji CVE-2019-0708.
author: Badacz CVE
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 56
    Provider_Name: 'TermDD'
  timeframe: 5m
  condition: selection
# Uwaga: Agregacje zależą od backendu. Zalecane korelowanie: >=20 zdarzeń/5min z jednego SourceIP/hostu.
level: medium
tags:
  - attack.T1210
  - attack.T1021.001
  - cve.2019-0708

B) Wyłączenie NLA — modyfikacja rejestru (Sysmon)

title: RDP NLA Disabled via Registry
id: 3a6eaeee-1f6b-4592-a1a1-nla-off
status: stable
description: Wykrywa ustawienie UserAuthentication=0 dla RDP-Tcp (wyłączenie NLA).
author: Badacz CVE
logsource:
  product: windows
  service: sysmon
detection:
  sel_path:
    EventID: 13
    TargetObject|endswith: '\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication'
  sel_val:
    Details|contains: 'DWORD (0x00000000)'
  condition: sel_path and sel_val
level: high
tags:
  - attack.T1021.001
  - attack.T1112
falsepositives:
  - Rzadkie legalne zmiany GPO/Intune

(NLA/UserAuthentication = 1 włącza NLA; 0 ją wyłącza).


Splunk (SPL)

A) Skoki TermDD (Event 56):

index=wineventlog sourcetype="WinEventLog:System" EventCode=56 SourceName=TermDD
| stats count by host, Message, _time, ComputerName, dest
| timechart span=5m count by host

B) RDP sukcesy spoza prywatnych adresów (4624, LogonType=10):

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=10
| eval isPublic=if(cidrmatch("10.0.0.0/8", Source_Network_Address) OR cidrmatch("172.16.0.0/12", Source_Network_Address) OR cidrmatch("192.168.0.0/16", Source_Network_Address), 0, 1)
| search isPublic=1
| stats count values(Source_Network_Address) as src_ip by ComputerName, Target_User_Name
| where count>0

KQL (Azure/Microsoft Sentinel)

A) Udane logowania RDP spoza prywatnych podsieci:

SecurityEvent
| where EventID == 4624 and LogonType == 10
| extend SrcIp = iff(isempty(IpAddress), tostring(parse_xml(EventData).EventData.Data[?(@.Name=="IpAddress")][0]."#text"), IpAddress)
| where SrcIp !startswith "10." and SrcIp !startswith "172.16." and SrcIp !startswith "192.168."
| summarize dcount(SrcIp) by Computer, TargetUserName, bin(TimeGenerated, 1h)

B) Zmiany NSG otwierające 3389 na Internet (Azure Activity):

AzureActivity
| where OperationNameValue =~ "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE"
| extend p=parse_json(Properties)
| extend src=tostring(p.responseBody.properties.sourceAddressPrefix),
         dport=tostring(p.responseBody.properties.destinationPortRange),
         access=tostring(p.responseBody.properties.access)
| where dport in ("3389","*") and src in ("Internet","0.0.0.0/0","Any") and access == "Allow"
| project TimeGenerated, Caller, ResourceGroup, Resource, src, dport, access

CloudTrail query (CloudWatch Logs Insights)

Otwieranie 3389/TCP na 0.0.0.0/0 (EC2 Security Groups):

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName, requestParameters
| filter eventSource="ec2.amazonaws.com"
| filter eventName in ["AuthorizeSecurityGroupIngress","ModifySecurityGroupRules","UpdateSecurityGroupRuleDescriptionsIngress"]
| filter requestParameters like /3389/ and requestParameters like /0\.0\.0\.0\/0/
| sort @timestamp desc

Elastic / EQL

A) Wyłączenie NLA w rejestrze (Elastic EQL):

registry where
  registry.path :
    "*\\System\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication" and
  registry.data.strings : ("0","0x00000000")

B) RDP z Internetu (Elastic Query DSL – Beats flow):

network where destination.port == 3389 and
  not cidrmatch(source.ip, ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"])

Heurystyki / korelacje (co łączyć)

  • Wejście → błąd protokołu → restart usługi: Inbound 3389 z nowego publicznego IP + TermDD/56 burst + SCM/7031 dla TermService ⇒ podejrzenie skanów/nieudanych exploitów BlueKeep.
  • Wejście → sukces logowania → nietypowe procesy: 3389 z Internetu + 4624/LogonType=10 + svchost.exe (TermService) spawnujący cmd.exe/powershell.exe ⇒ post‑exploitation.
  • Chmura: zdarzenia SG/NSG otwierające 3389 ⇒ natychmiastowe skanowanie Internetu; łączyć z logami RDP.
  • NLA: zmiana UserAuthentication na 0 + wzrost 4625/LogonType=10 ⇒ próby brute‑force lub przygotowanie do eksploatacji (chociaż BlueKeep jest pre‑auth, wyłączenie NLA bywa celem operatorów, aby ułatwić dalsze działania).

False positives / tuning

  • Event 56 (TermDD) może wynikać z błędów sieciowych/starych klientów RDP — filtrować progiem (np. ≥20/5min per źródłowe IP) i utrzymywać listę zaufanych skanerów.
  • 4624/10: legalne logowania adminów/jumphostów — whitelisty dla źródeł ASN/VPN, kont serwisowych i okien serwisowych.
  • 7031: restart różnych usług — koreluj wąsko z TermService i 56.
  • Zmiany rejestru: wdrożenia GPO/Intune — taguj „change windows” i weryfikuj źródło (PID/Signer).

Playbook reagowania (IR)

  1. Triaging & izolacja
  • Odłącz host od sieci lub przełącz do VLAN kwarantanny.
  • Zanotuj netstat -ano | find ":3389" oraz tasklist /svc | find /I "TermService".
  1. Weryfikacja podatności/łatek
  • Sprawdź OS i łatki:
    • Windows 7/2008 R2: Get-HotFix -Id KB4499164,KB4499175
    • Vista/2008: Get-HotFix -Id KB4499180
    • XP/2003: wmic qfe | find "4500331"
      Jeśli brak — patch ASAP (odpowiednie KB dla wydania).
  1. Twardnienie
  • Włącz NLA:
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 (restart RDS).
  • Ogranicz 3389 do VPN/jumphost (SG/NSG/Firewall), wyłącz ekspozycję 0.0.0.0/0.
  1. Hunting
  • Przejrzyj Event 56/7031 (skoki), 4624/10 (źródła publiczne), 1149 (osi czasu).
  • Sprawdź anomalia procesów od svchost.exe -k termsvcs i autostarty.
  1. Eradykacja & recovery
  • Zastosuj poprawki, wymuś restart RDS/hosta, zmień hasła adminów, wymuś MFA do zdalnych dostępl.
  1. Lessons learned
  • Segmentacja, JIT RDP (Azure), bastiony, skanowanie podatności.

Przykłady z kampanii / case studies

  • Listopad 2019 — pierwsze potwierdzone wykorzystanie BlueKeep in‑the‑wild do kryptominera (kampania masowa, niestabilne exploity).
  • Fortinet/Microsoft potwierdzają ataki oraz apelują o natychmiastowe łatanie.
  • Szacunki ekspozycji: setki tysięcy hostów publicznie podatnych po publikacji (2019). (kontekst historyczny)

Lab (bezpieczne testy)

Wyłącznie w odizolowanym labie. Brak exploitów. Celem jest weryfikacja ekspozycji i telemetrii.

  • Sprawdzenie stanu RDP/NLA na hoście:
# Czy RDP jest włączone
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

# Czy NLA jest włączona
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
  • Weryfikacja łatek (Win7/2008 R2):
Get-HotFix -Id KB4499164,KB4499175
  • Skan bezpieczny z zewnątrz (wersja RDP, bez exploitów):
nmap -Pn -p3389 --script rdp-enum-encryption,rdp-ntlm-info <cel>
  • Generowanie zdarzeń do detekcji: krótka sesja RDP z jump‑hosta (udane/nieudane logowania) → potwierdź 4624/4625(LogonType=10), 1149, brak nadmiarowych 56.

Mapowania (Mitigations, powiązane techniki)

Mitigations (wg MITRE, powiązane z T1210):

  • M1051 Update Software (patch management), M1042 Disable or Remove Feature or Program (wyłącz/ogranicz RDP), M1030 Network Segmentation, M1035 Limit Access to Resource Over Network (gateway/JIT), M1048 Application Isolation/Sandboxing, M1050 Exploit Protection, M1016 Vulnerability Scanning, M1026 Privileged Account Management.

Powiązane techniki ATT&CK:

  • T1133 External Remote Services (ekspozycja zewnętrzna), T1562 (Defense Evasion — wyłączanie zabezpieczeń/NLA), T1112 (Modify Registry), T1021 (Remote Services — rodzina). (mapowanie merytoryczne na podstawie opisów ATT&CK).

Źródła / dalsza literatura

  • Microsoft MSRC: Prevent a worm by updating RDS (CVE‑2019‑0708) — o NLA i „wormowalności”. (Microsoft)
  • Microsoft Support: Customer guidance for CVE‑2019‑0708 — listy platform i KB (w tym EoL). (Microsoft Support)
  • Microsoft KB: KB4499164 (Monthly Rollup Win7/2008 R2), KB4499175 (Security‑only). (Microsoft Support)
  • NVD: CVE‑2019‑0708 (CVSS 9.8, zmiany 2024). (NVD)
  • CISA Advisory AA19‑168A. (CISA)
  • MITRE ATT&CK (v18): T1210, T1021.001, T1190 (wersje i daty). (MITRE ATT&CK)
  • Microsoft Tech Community: TermDD Event ID 56 — protokół RDP error. (TECHCOMMUNITY.MICROSOFT.COM)
  • Unit 42: analiza wewnętrzna RDP/BlueKeep. (Unit 42)
  • Tenable/Microsoft/Kryptos Logic: pierwsze ataki i telemetria. (Tenable®)
  • Informacja kontekstowa o nienarażonych Windows 8/10/11. (Wikipedia)

Checklisty dla SOC / CISO

SOC – codzienna kontrola

  • Alerty na Event 56 (TermDD) bursty + korelacja z 3389/TCP.
  • Monitor 4624/10 i 1149 z publicznych IP; whitelisty dla jump‑hostów.
  • Wykrywanie NLA=OFF (UserAuthentication=0) i zmian SG/NSG otwierających 3389.
  • Regularne skany podatności/asset inventory dla hostów z RDP.

CISO – decyzje i governance

  • Polityka: RDP tylko przez VPN/jumphost/JIT; brak 0.0.0.0/0.
  • SLA na Patch Tuesday + raport KB (KB4499164/KB4499175/KB4499180/KB4500331).
  • NLA wymagane (GPO/Intune), MFA dla zdalnego dostępu.
  • Segmentacja (M1030), regularny red/blue tabletop dla RDP‑borne incydentów.

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

TL;DR

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


Krótka definicja techniczna

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


Gdzie występuje / przykłady platform

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

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

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


Artefakty i logi

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

Detekcja (praktyczne reguły)

Sigma (web / reverse proxy / WAF)

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

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

Splunk (SPL)

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

KQL (Microsoft Sentinel / Log Analytics)

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

AWS CloudWatch Logs Insights (AWS WAF)

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

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

Elastic (KQL + EQL)

KQL (http logs / ecs):

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

EQL (sieć/HTTP):

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

Heurystyki / korelacje

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

False positives / tuning

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

Playbook reagowania

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

Przykłady z kampanii / case studies

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

Lab (bezpieczne testy) — przykładowe komendy

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

  1. Symulacja logów na NGINX (Docker)
docker run -d --name nginx -p 8080:80 nginx:alpine
# Generowanie „szumu” traversal + słowo-klucz (log only):
for p in "/test/guacamole/../../etc/hosts" "/dana-na/../test/guacamole/..%2F..%2Ffile" ; do
  curl -s "http://127.0.0.1:8080${p}?q=check" >/dev/null
done
  1. Weryfikacja detekcji — załaduj logi access.log do SIEM i uruchom reguły z §7.
  2. Test WAF — utwórz regułę blokującą sekwencje traversal i sprawdź, czy zapisy AWS WAF rejestrują akcję BLOCK oraz terminatingRuleId.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

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

Powiązane techniki:

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

Źródła / dalsza literatura

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

Checklisty dla SOC / CISO

SOC (operacyjne):

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

CISO (strategiczne):

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

“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)

Microsoft ukrywa ikonę hasła na ekranie blokady po aktualizacjach Windows 11 — co to oznacza i jak reagować

Wprowadzenie do problemu / definicja luki

Microsoft potwierdził błąd w Windows 11, który sprawia, że ikona logowania hasłem (password sign-in) na ekranie blokady staje się niewidoczna po zainstalowaniu aktualizacji wydawanych od sierpnia 2025 r. (począwszy od KB5064081). Sam przycisk nadal działa — jest po prostu „niewidzialny” — co może dezorientować użytkowników, zwłaszcza gdy mają skonfigurowane wiele metod logowania (PIN, klucz bezpieczeństwa, odcisk palca, hasło). Microsoft pracuje nad trwałą poprawką.

W skrócie

  • Problem dotyczy urządzeń z Windows 11 24H2 i 25H2, które zainstalowały KB5064081 (29.08.2025, preview) lub późniejsze zbiorcze aktualizacje.
  • Ikona hasła nie jest wyświetlana, ale obszar przycisku nadal reaguje na kliknięcie/hover — umożliwia normalne wpisanie hasła.
  • Na dziś Microsoft nie publikuje obejścia poza użyciem „niewidzialnego” przycisku; trwa praca nad poprawką.

Kontekst / historia / powiązania

Pierwsze raporty wiążą błąd z opcjonalną aktualizacją KB5064081 (preview) z 29 sierpnia 2025 r., a następnie z kolejnymi pakietami zbiorczymi. Zagadnienie zostało ujęte w dokumentacji Microsoftu jako znany problem po stronie Windows Release Health/stron KB. Równolegle w tym okresie Microsoft adresował inne usterki po aktualizacjach (m.in. DRM/EHV), co potwierdza, że zmiany z końca lata–jesieni 2025 miały szerszy wpływ na funkcje logowania/mediów.

Analiza techniczna / szczegóły luki

  • Warunek wyzwolenia: system z wieloma metodami logowania (co normalnie pokazuje zestaw ikon opcji logowania). Po instalacji KB5064081 lub nowszych, ikonie hasła nie towarzyszy renderowana grafika, ale element UI nadal istnieje i ma aktywny „hitbox”.
  • Zachowanie domyślne Windows: jeśli jedyną metodą jest hasło, system zwykle pokazuje pole hasła bez konieczności wyboru ikony — w takim scenariuszu problem może nie być zauważalny.
  • Status naprawy: zgodnie z kartą KB, Microsoft pracuje nad rozwiązaniem; brak publicznej daty dostarczenia fixu w momencie publikacji.

Praktyczne konsekwencje / ryzyko

  • Użyteczność i dostępność: użytkownicy mogą uznać, że logowanie hasłem zostało wyłączone lub usunięte, co zwiększa liczbę zgłoszeń do helpdesku. Ryzyko eskalacji błędnych operacji (np. reset haseł, niepotrzebne odzyskiwanie kont).
  • Środowiska zarządzane: w organizacjach, gdzie część kont nadal wymaga hasła (np. z powodów zgodności lub migracji z Hello/kluczy), zniknięcie ikony może utrudnić procedury dostępu awaryjnego.
  • Percepcja bezpieczeństwa: brak widocznej ikony może wywoływać niepewność co do stanu polityk sign-in i błędne interpretacje (np. „zniknęło hasło”).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników końcowych

  1. Na ekranie logowania wybierz Opcje logowania i najeźdź kursorem/kliknij puste miejsce, gdzie zwykle jest ikona klucza — powinno aktywować pole hasła.
  2. Alternatywnie użyj Ctrl+Alt+Del → Opcje logowania i wybierz ostatnią opcję (zwykle hasło) — rozwiązanie potwierdzone w wątkach społeczności Microsoft.

Dla IT/administratorów

  • Komunikat serwisowy: poinformuj użytkowników o „niewidzialnej” ikonie i sposobie kliknięcia/hover.
  • Monitoruj Release Health/KBy: śledź aktualizacje dla 24H2/25H2 (w szczególności linie znanych problemów przy KB z października–listopada).
  • Walidacja obrazu referencyjnego: jeśli budujesz obrazy z najnowszymi zbiorczymi aktualizacjami, uwzględnij test ścieżek logowania.
  • Plan awaryjny: zapewnij dostęp alternatywny (PIN/Hello/klucz), ale nie wyłączaj haseł na siłę, by nie utrudnić scenariuszy break-glass.
  • Ewentualny rollback? W środowiskach krytycznych rozważ tymczasowy rollback tylko po ocenie ryzyka i zgodności (błąd jest kosmetyczny — UI).

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

W 2025 r. Windows 11 notował więcej niż jeden incydent jakościowy wokół logowania/multimediów (np. problemy z DRM po KB5064081, rozwiązywane w kolejnych pakietach). W odróżnieniu od tamtych usterek, problem z ikoną hasła nie blokuje faktycznego logowania — dotyczy wyłącznie renderowania elementu interfejsu.

Podsumowanie / kluczowe wnioski

  • Błąd sprawia, że ikona hasła jest niewidoczna, ale funkcja działa — kliknij „puste” miejsce.
  • Dotknięte są systemy 24H2/25H2 po KB5064081 i nowszych.
  • Microsoft pracuje nad poprawką; do tego czasu skup się na komunikacji do użytkowników i prostych obejściach.

Źródła / bibliografia

  1. BleepingComputer — „Microsoft: Windows updates make password login option invisible”. (28 listopada 2025). (BleepingComputer)
  2. Microsoft Support — „KB5064081 (Windows 11 24H2/25H2) — znane problemy”. (29 sierpnia 2025, aktualizowane). (Microsoft Support)
  3. Microsoft Support — „KB5070773 (OOB, 20 października 2025) — sekcja Known issues”. (status: „Microsoft is working to resolve this issue”). (Microsoft Support)
  4. Microsoft Q&A — „Windows 11 24H2 October update breaks lock screen sign-in options” (obejście z Ctrl+Alt+Del → Opcje logowania). (Microsoft Learn)

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 „Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0”

Bloody Wolf rozszerza kampanie z Java/JAR i NetSupport RAT na Kirgistan i Uzbekistan

Wprowadzenie do problemu / definicja luki

Grupa zagrożeń „Bloody Wolf” prowadzi od co najmniej czerwca 2025 r. ukierunkowane kampanie spear-phishingowe w Azji Centralnej, których celem jest dostarczenie NetSupport RAT — komercyjnego narzędzia zdalnego zarządzania nadużywanego jako trojan. Od października 2025 r. aktywność rozszerzyła się z Kirgistanu na Uzbekistan, z silnym podszywaniem się pod ministerstwa sprawiedliwości i użyciem plików JAR (Java) jako loaderów. Kampania stosuje m.in. geofencing, by serwować złośliwe pliki wyłącznie ofiarom z określonego kraju.

W skrócie

  • Wejście: spear-phishing z załącznikami PDF udającymi korespondencję urzędową; linki prowadzą do JAR-ów i instrukcji instalacji JRE.
  • Łańcuch infekcji: JAR pobiera komponenty NetSupport, ustawia trwałość (Harmonogram zadań, RunKey, skrót w Startup).
  • Geofencing: w wątku uzbeckim żądania spoza kraju przekierowywane są do legalnej domeny data.egov[.]uz, a lokalnym ofiarom serwowany jest JAR.
  • Tło: wcześniej Bloody Wolf atakował Kazachstan i Rosję (STRRAT → NetSupport).
  • Szerszy trend: nadużywanie legalnych narzędzi RMM (NetSupport) rośnie — istotne w telemetrycznych rankingach zagrożeń.

Kontekst / historia / powiązania

Zgodnie z wcześniejszymi analizami BI.ZONE, klaster Bloody Wolf przeszedł w 2024/2025 r. z dystrybucji STRRAT na dostarczanie NetSupport Manager jako „RAT-a”, kompromitując setki organizacji w regionie (Kazachstan, następnie Rosja). Bieżące śledztwo Group-IB (przy współpracy z Ukuk, jednostką podległą Prokuraturze Generalnej KR) dokumentuje ekspansję na Kirgistan i Uzbekistan w 2025 r.

Analiza techniczna / szczegóły kampanii

Wejście i socjotechnika. E-maile z PDF-ami podszywają się pod lokalne ministerstwa sprawiedliwości. PDF zawiera odnośniki opisane jako „materiały sprawy”. Ofiary są instruowane, by zainstalować Java Runtime „niezbędne do otwarcia dokumentu”, po czym uruchamiają pobrany JAR.

Loader JAR.

  • Loader napisany dla Java 8 (2014) jest zróżnicowany wariantami (różne ścieżki pobrań, klucze rejestru, komunikaty błędów), co sugeruje generator JAR po stronie atakujących.
  • Po uruchomieniu JAR pobiera komponenty NetSupport z infrastruktury C2 i uruchamia je, symulując fałszywe okienka błędów.

Trwałość (Persistence). Atakujący utrwalają się trzema kanałami:

  1. Scheduled Task, 2) RunKey w rejestrze, 3) skrót w Startup (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup).

Selektor geograficzny (Uzbekistan). Infrastruktura delivery stosuje geofencing: ruch spoza Uzbekistanu przekierowuje do legalnego serwisu data.egov[.]uz, zaś ruch z kraju powoduje automatyczne pobranie JAR z linku osadzonego w PDF.

Mapowanie do MITRE ATT&CK (na podstawie wcześniejszych kampanii Bloody Wolf):

  • Initial Access: Spearphishing Attachment
  • Execution: Java JAR, Windows Command Shell
  • Persistence: Run Keys / Startup Folder
  • C2: HTTPS, Ingress Tool Transfer
  • Discovery: System Information Discovery
    Te taktyki i techniki zostały wcześniej udokumentowane dla tego klastra przez BI.ZONE.

Praktyczne konsekwencje / ryzyko

  • Uderzenie w sektor publiczny i finansowy: podszywanie się pod resorty sprawiedliwości zwiększa skuteczność socjotechniki w urzędach i instytucjach finansowych.
  • Utrudniona detekcja: NetSupport to legalne narzędzie RMM — jego binaria bywają podpisane i mieszczą się w dozwolonych regułach, co obniża sygnał anomalii i zwiększa dwell time. Telemetria branżowa pokazuje jego wysoką powszechność w nadużyciach.
  • Selektor kraju: geofencing zmniejsza widoczność kampanii w globalnych sandboxach i u analityków spoza regionu, utrudniając wymianę IOCs.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twardnienie stacji roboczych

  1. Blokada JAR: jeżeli Java nie jest wymagana biznesowo, zablokuj uruchamianie *.jar (AppLocker/SRP) i dystrybucję JRE poza kontrolą IT.
  2. Kontrola RMM: inwentaryzuj i dozwalaj tylko autoryzowane narzędzia zdalne (allow-list). Wykrywaj i blokuj nieautoryzowany NetSupport (klient/serwer) po cechach plików, nazwach usług i domenach C2. Telemetrię o NetSupport traktuj jako zdarzenie o podwyższonym priorytecie.
  3. Filtrowanie e-mail/URL: blokuj makra i osadzone linki w PDF, skanuj załączniki pod kątem odnośników do pobrania JAR oraz fraz instruujących instalację Javy.

Detekcja i reagowanie
4. Reguły na TTP:

  • Dostęp do Pastebin/Telegram/niezaufanych CDN z procesów innych niż przeglądarka.
  • Tworzenie zadań Harmonogramu, wpisów Run i plików w Startup korelowane z uruchomieniem java.exe.
  1. Hunting sieciowy: wykrywaj anomalię ruchu HTTPS z klienta NetSupport (nietypowe SNI/JA3, kierunki rzadkie dla organizacji).
  2. Weryfikacja geofencingu: testuj łańcuchy z lokalnym egress IP regionu (np. w bezpiecznej piaskownicy) — kampanie mogą ukrywać payloady poza docelowym krajem.
  3. Playbook IR: szybka izolacja hosta, odcięcie zadań NetSupport, unieważnienie poświadczeń używanych na zainfekowanym hoście, przegląd skrzynek ofiar spear-phishingu i łatanie M365/Exchange reguł przekierowań.

Edukacja
8. Szkolenie kontekstowe: ostrzegaj zespoły o podszywaniu się pod ministerstwa sprawiedliwości oraz o fałszywych komunikatach nakazujących instalację Javy lub „wyświetlacz dokumentów”.

Różnice / porównania z innymi przypadkami

W 2025 r. wiele grup używa NetSupport w łańcuchach z ClickFix i innymi wektorami socjotechnicznymi (Run dialog, fałszywe aktualizacje przeglądarki). Bloody Wolf wyróżnia się jednak Java-based loaderami (JAR) i podszywaniem pod resorty sprawiedliwości w Azji Centralnej, a także geofencingiem ograniczającym ekspozycję kampanii.

Podsumowanie / kluczowe wnioski

  • Bloody Wolf rozszerzył zasięg z Kirgistanu na Uzbekistan w październiku 2025 r., utrzymując skuteczność dzięki prostym, lecz sprytnym loaderom JAR i nadużyciu NetSupport.
  • Geofencing i podszywanie się pod instytucje publiczne zwiększają wiarygodność kampanii i obniżają widoczność dla analityków.
  • Organizacje powinny blokować JAR, radykalnie kontrolować RMM, ustawić hunting na TTP (RunKey/Startup/Scheduled Task + java.exe) i monitorować sygnatury/detekcje dla NetSupport.

Źródła / bibliografia

  1. The Hacker News: „Bloody Wolf Expands Java-based NetSupport RAT Attacks in Kyrgyzstan and Uzbekistan”, 27 listopada 2025. (The Hacker News)
  2. Group-IB: „Bloody Wolf: A Blunt Crowbar Threat To Justice”, 26 listopada 2025 (z Ukuk/Prokuratura KR). (Group-IB)
  3. BI.ZONE: „Bloody Wolf evolution: new targets, new tools”, 19 lutego 2025. (BI.ZONE)
  4. Red Canary: „NetSupport Manager — Threat Detection Report (trend i powszechność nadużyć)”. (Red Canary)
  5. eSentire: „Unpacking NetSupport RAT Loaders Delivered via ClickFix”, 23 października 2025 (dla porównania trendu nadużyć NetSupport). (esentire.com)