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

Microsoft Patch Tuesday (styczeń 2026): 114 poprawek i 3 luki zero-day – jedna aktywnie wykorzystywana (CVE-2026-20805)

Wprowadzenie do problemu / definicja luki

Styczniowy Patch Tuesday 2026 od Microsoftu to duża paczka poprawek bezpieczeństwa: 114 luk, w tym 3 podatności typu zero-day (jedna potwierdzona jako aktywnie wykorzystywana) oraz 8 luk o randze Critical. W praktyce oznacza to, że organizacje powinny potraktować ten cykl jako „priorytetowy” – szczególnie tam, gdzie Windows jest rdzeniem środowiska (stacje robocze, serwery, VDI).


W skrócie

  • Łącznie: 114 luk (Microsoft) oraz dodatkowe elementy/aktualizacje opisane w analizach vendorów.
  • Zero-day (3):
    • CVE-2026-20805 (Desktop Window Manager) – aktywnie wykorzystywana, information disclosure.
    • CVE-2026-21265 – obejście Secure Boot związane z wygasaniem certyfikatów z 2011 r. (publicznie ujawniona).
    • CVE-2023-31096 – eskalacja uprawnień w sterownikach Agere Soft Modem; Microsoft usuwa podatne sterowniki.
  • Największe kategorie: 57 EoP, 22 RCE, 22 Info Disclosure (wg zestawień).

Kontekst / historia / powiązania

Microsoft klasyfikuje „zero-day” jako lukę publicznie ujawnioną lub aktywnie wykorzystywaną w momencie braku oficjalnej poprawki. W styczniu 2026 w tę definicję wpadają trzy podatności, z których najważniejsza operacyjnie jest CVE-2026-20805 (potwierdzone wykorzystanie).

Na osobną uwagę zasługuje wątek wygasania łańcucha zaufania Secure Boot: Microsoft opublikował wcześniej (2025) obszerną dokumentację o certyfikatach z 2011 r. i konieczności aktualizacji do nowych certyfikatów z 2023 r. przed terminami wygaśnięcia w 2026 r.


Analiza techniczna / szczegóły luki

1) CVE-2026-20805 – Desktop Window Manager (DWM) Information Disclosure (aktywnie wykorzystywana)

To „wyciek informacji” lokalnie, ale realnie bywa kluczowym elementem łańcucha ataku: wycieki adresów/fragmentów pamięci potrafią zwiększać niezawodność exploitów (np. omijanie mechanizmów ochronnych). W opisach pojawia się wątek ujawnienia adresu sekcji z „remote ALPC port”, co może wspierać kolejne etapy eksploatacji.

2) CVE-2026-21265 – Secure Boot Certificate Expiration (Security Feature Bypass)

Sedno problemu nie jest klasycznym RCE, tylko ryzykiem „rozjechania się” zaufania w Secure Boot, jeśli urządzenia nie dostaną na czas nowych certyfikatów. Microsoft wskazuje, że oryginalne certyfikaty obecne na urządzeniach od czasu wprowadzenia Secure Boot w Windows są bliskie wygaśnięcia i wymagają aktualizacji (KEK i DB/DBX) do wersji z 2023 r.

Konkrety z dokumentacji Microsoftu:

  • certyfikaty z 2011 r. wygasają m.in. w czerwcu 2026 oraz w październiku 2026 (w zależności od CA/roli), a brak aktualizacji może wpłynąć na zdolność do dalszego zaufanego uruchamiania/aktualizowania komponentów pre-boot.

3) CVE-2023-31096 – Agere Soft Modem Driver (EoP)

Ta podatność dotyczy sterowników modemowych dostarczanych z Windows. W praktyce Microsoft rozwiązuje problem „twardo”: usuwa podatne sterowniki (np. wskazywane jako agrsm64.sys/agrsm.sys w analizach). To może mieć efekt uboczny: bardzo stare urządzenia/komponenty zależne od tych sterowników mogą przestać działać.

Krytyczne podatności (przykłady z analiz)

Wśród „Critical” przewijają się m.in. komponenty Windows i Office, w tym scenariusze RCE przez pliki (Word/Excel/Office) oraz krytyczne elementy systemu (np. grafika, VBS enclave, LSASS).


Praktyczne konsekwencje / ryzyko

  • Najwyższy priorytet ma CVE-2026-20805, bo mamy potwierdzone wykorzystanie „in the wild” (nawet jeśli to „tylko” information disclosure). Takie luki często wspierają niezawodne obejście zabezpieczeń w łańcuchu exploitów.
  • Ryzyko operacyjne: usunięcie sterowników Agere Soft Modem może powodować incydenty kompatybilności w niszowych/legacy środowiskach.
  • Ryzyko długiego ogona: Secure Boot cert expiry to problem „zegarowy” – jeśli urządzenia nie zostaną przygotowane przed terminami w 2026 r., mogą pojawić się trudne do diagnozy problemy z zaufaniem rozruchu i aktualizacjami komponentów pre-boot.

Rekomendacje operacyjne / co zrobić teraz

  1. Zrób szybkie priorytetyzowanie (triage)
    • „P1”: systemy Windows (stacje/serwery) narażone na lokalną eskalację/łańcuch exploitów → pilne wdrożenie poprawek pod CVE-2026-20805.
  2. Wdróż aktualizacje etapami, ale szybko
    • Pilot (IT/Power Users) → produkcja; szczególnie dla środowisk z dużą liczbą endpointów.
  3. Secure Boot: zacznij projekt przygotowania do wygasania certyfikatów (już teraz)
    • Zidentyfikuj flotę z włączonym Secure Boot i sprawdź, czy proces aktualizacji certyfikatów (KEK + DB) jest realizowany przez mechanizmy Microsoft-managed, czy wymaga działań IT-managed (GPO/Intune/registry – wg dokumentacji Microsoftu).
  4. Sprawdź wpływ na legacy sprzęt (Agere Soft Modem)
    • Jeśli masz niszowe urządzenia wymagające sterowników modemowych: testy regresji przed szerokim rolloutem, bo poprawka polega na usunięciu podatnych komponentów.
  5. Wzmocnij detekcję i telemetrię na czas patchowania
    • Monitoruj nietypowe ciągi zdarzeń po aktualizacjach (crashe DWM, anomalie w logowaniu, nietypowe uruchomienia procesów po otwarciu dokumentów Office w kontekście krytycznych RCE opisywanych przez vendorów).

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

  • Nietypowe w tym miesiącu jest to, że aktywnie wykorzystywana jest podatność typu information disclosure (a nie bezpośrednie RCE). Z perspektywy ofensywnej to nadal bardzo wartościowe – wycieki informacji często „domykają” exploit chain.
  • Secure Boot cert expiry to z kolei przykład ryzyka, które bardziej przypomina zarządzanie cyklem życia zaufania kryptograficznego niż klasyczne „łatamy CVE i po temacie”.

Podsumowanie / kluczowe wnioski

  • Styczeń 2026 to duży Patch Tuesday: 114 luk i 3 zero-day, z czego CVE-2026-20805 jest aktywnie wykorzystywana.
  • Secure Boot wymaga planu – terminy wygaśnięcia certyfikatów w 2026 r. to potencjalna mina operacyjna, jeśli organizacja tego nie uprzedzi.
  • Oprócz „patch now”, potrzebne są testy kompatybilności (Agere Soft Modem) i sensowna kolejność wdrożeń, bo w paczce są też krytyczne scenariusze RCE/EoP w Windows/Office.

Źródła / bibliografia

  1. BleepingComputer – „Microsoft January 2026 Patch Tuesday fixes 3 zero-days, 114 flaws” (BleepingComputer)
  2. CrowdStrike – „January 2026 Patch Tuesday: 114 CVEs Patched Including 3 Zero-Days” (CrowdStrike)
  3. Zero Day Initiative (Trend Micro) – „The January 2026 Security Update Review” (Zero Day Initiative)
  4. Qualys – „Microsoft and Adobe Patch Tuesday, January 2026 Security Update Review” (Qualys)
  5. Microsoft Support – „Windows Secure Boot certificate expiration and CA updates” (Microsoft Support)

Krytyczna luka SQL Injection w produktach Advantech (CVE-2025-52694) – co wiemy i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Cyber Security Agency of Singapore (CSA) opublikowała 12 stycznia 2026 alert dotyczący krytycznej podatności w wybranych produktach Advantech, oznaczonej jako CVE-2025-52694. To klasyczny scenariusz wysokiego ryzyka: SQL Injection możliwy do wykorzystania zdalnie i bez uwierzytelnienia, jeśli usługa jest wystawiona do Internetu.


W skrócie

  • CVE: CVE-2025-52694
  • Typ: SQL Injection (SQLi)
  • Skutki: możliwość wykonania dowolnych zapytań SQL przez atakującego bez logowania (gdy endpoint jest dostępny z Internetu)
  • Ocena: CVSS 3.1 = 10.0 (Critical); wektor: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Zalecenie: natychmiastowa aktualizacja do wersji naprawionych

Kontekst / historia / powiązania

W przypadku systemów z rodziny IoTSuite / IoT Edge problem jest szczególnie istotny, bo te komponenty często stoją na styku IT/OT (integracje, telemetria, panele webowe, API). CSA wskazuje, że podatność została skoordynowanie ujawniona, a odkrycie przypisano badaczowi z HCMUTE Information Security Club.


Analiza techniczna / szczegóły luki

SQL Injection oznacza, że aplikacja w pewnym miejscu buduje zapytania do bazy danych w sposób umożliwiający „wstrzyknięcie” fragmentu SQL przez dane wejściowe (np. parametr HTTP). W tym przypadku CSA/NVD opisują scenariusz, w którym:

  • atakujący nie musi być uwierzytelniony (PR:N),
  • atak jest zdalny przez sieć (AV:N) i zwykle możliwy do automatyzacji,
  • konsekwencją jest wykonanie dowolnych poleceń SQL na usłudze (o ile jest wystawiona do Internetu).

Wektor CVSS ze zmianą zasięgu (S:C) sugeruje, że skutki mogą „wychodzić” poza bezpośredni komponent (np. wpływ na inne elementy środowiska, zależnie od architektury i uprawnień DB).

Produkty i wersje podatne (wg CSA):

  • IoTSuite SaaSComposer – wersje < 3.4.15
  • IoTSuite Growth (Linux docker) – wersje < V2.0.2
  • IoTSuite Starter (Linux docker) – wersje < V2.0.2
  • IoT Edge (Linux docker) – wersje < V2.0.2
  • IoT Edge (Windows) – wersje < V2.0.2

Praktyczne konsekwencje / ryzyko

W praktyce SQLi w komponentach webowych / API może prowadzić m.in. do:

  • wycieku danych z bazy (telemetria, konfiguracje, dane operacyjne),
  • manipulacji danymi (fałszowanie odczytów, zmiana konfiguracji, sabotaż procesów),
  • eskalacji wpływu: w niektórych wdrożeniach SQLi bywa krokiem do przejęcia kont aplikacyjnych lub dalszego ruchu lateralnego (zależy od uprawnień konta DB i architektury).

Największe ryzyko pojawia się wtedy, gdy:

  • panel/usługa jest wystawiona bezpośrednio do Internetu,
  • brak jest segmentacji sieci i kontroli dostępu,
  • środowisko jest „płaskie” (łatwy pivot do innych systemów).

Rekomendacje operacyjne / co zrobić teraz

Priorytet: patch management + ograniczenie ekspozycji.

  1. Zidentyfikuj ekspozycję
  • Sprawdź, czy instancje IoTSuite/IoT Edge są dostępne z Internetu (DNS, reverse proxy, publiczne IP, reguły firewall/WAF).
  • Zweryfikuj, które wersje są uruchomione (porównaj z progami podatności powyżej).
  1. Zastosuj poprawki
  • CSA zaleca natychmiastową aktualizację do wersji naprawionych.
  • Dla IoTSuite SaaSComposer, IoTSuite Growth (Linux docker) i IoT Edge (Windows) CSA wskazuje konieczność kontaktu z Advantech w celu uzyskania oficjalnej wersji naprawionej.
  • Dla IoTSuite Starter (Linux docker) oraz IoT Edge (Linux docker) CSA kieruje do stron pobrania aktualizacji (mogą wymagać dostępu/portalu).
  1. Mitigacje „na już” (jeśli patch nie jest natychmiast możliwy)
  • Wycofaj usługę z Internetu: VPN/ZTNA + allowlist, dostęp tylko z sieci administracyjnej.
  • Włącz/zaostrz reguły WAF pod kątem SQLi (to nie zastąpi patcha, ale może kupić czas).
  • Ogranicz uprawnienia konta bazy danych używanego przez aplikację (zasada najmniejszych uprawnień).
  • Monitoruj logi aplikacji/proxy/WAF pod kątem anomalii w parametrach żądań i błędów DB (wzrost 4xx/5xx, charakterystyczne payloady SQLi).
  1. Detekcja i reakcja
  • Jeśli system był wystawiony do Internetu: potraktuj jako potencjalnie narażony, rozważ przegląd logów i artefaktów (zapytania, nietypowe konta, zmiany konfiguracji, dumpy tabel).
  • W środowiskach OT: skoordynuj działania z utrzymaniem ruchu, aby aktualizacja nie wpłynęła na ciągłość procesów.

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

W porównaniu do wielu podatności wymagających logowania lub interakcji użytkownika, ten przypadek ma „zły zestaw cech”:

  • brak uwierzytelnienia i zdalna osiągalność,
  • wysoka przewidywalność wektora ataku (SQLi bywa łatwe do skanowania i automatyzacji),
  • potencjalnie wysoki wpływ w środowiskach przemysłowych, gdzie dane i konfiguracje mają bezpośrednie przełożenie na operacje.

Podsumowanie / kluczowe wnioski

  • CVE-2025-52694 to krytyczna podatność typu SQL Injection w wybranych produktach Advantech, z oceną CVSS 10.0.
  • Największe ryzyko dotyczy instalacji wystawionych do Internetu.
  • Działanie rekomendowane: pilny patch oraz równolegle ograniczenie ekspozycji i wzmocnienie kontroli dostępu.

Źródła / bibliografia

  1. Alert CSA Singapore: „Critical Vulnerability in Advantech Products” (12 stycznia 2026). (Cyber Security Agency of Singapore)
  2. NVD (NIST): rekord CVE-2025-52694 (opis + wektor CVSS od CSA). (NVD)

Microsoft testuje politykę „RemoveMicrosoftCopilotApp”. IT będzie mogło odinstalować Copilota na urządzeniach zarządzanych

Wprowadzenie do problemu / definicja zmiany

Microsoft rozpoczął testy nowej polityki systemowej, która ma dać administratorom IT możliwość odinstalowania aplikacji Microsoft Copilot na urządzeniach zarządzanych (np. w środowiskach firmowych z MDM). Zmiana jest istotna dla organizacji, które chcą ograniczać „konsumenckie” doświadczenia AI na stacjach roboczych, uporządkować powierzchnię ataku i zmniejszyć zamieszanie użytkowników między Copilotem konsumenckim a Microsoft 365 Copilot.


W skrócie

  • Polityka nazywa się RemoveMicrosoftCopilotApp i pojawiła się w Windows 11 Insider Preview Build 26220.7535 (KB5072046) (kanały Dev/Beta).
  • Po włączeniu polityki Microsoft Copilot zostanie odinstalowany „jednorazowo” (a użytkownik nadal może go ponownie zainstalować).
  • Ma to działać w scenariuszach urządzeń zarządzanych m.in. przez Microsoft Intune oraz SCCM.
  • Polityka jest „targetowana” – uruchomi się tylko, jeśli urządzenie/użytkownik spełnia warunki (m.in. brak uruchomień Copilota przez 28 dni).

Kontekst / historia / powiązania

W ostatnich kilkunastu miesiącach Microsoft intensywnie przebudowywał doświadczenie Copilota w Windows i w środowiskach komercyjnych. W dokumentacji Microsoft wskazuje m.in., że konsumencka aplikacja Microsoft Copilot nie obsługuje logowania Entra i w praktyce kieruje użytkownika do Microsoft 365 Copilot Chat w przeglądarce, co dodatkowo komplikuje „kto z czego ma korzystać” w firmie.

Warto też pamiętać, że w 2025 r. Microsoft musiał reagować na błąd aktualizacji Windows 11, który przypadkowo odinstalowywał Copilota na części urządzeń i odpinał go z paska zadań — to pokazało, jak wrażliwy jest ten element ekosystemu na zmiany w dystrybucji i politykach.


Analiza techniczna / szczegóły polityki

Gdzie pojawiła się polityka

Nowa opcja została opisana przez Windows Insider Team w ogłoszeniu buildu 26220.7535. Administrator może ją włączyć w edytorze zasad grupy pod ścieżką:

User Configuration → Administrative Templates → Windows AI → Remove Microsoft Copilot App

Jak działa (logika warunkowa)

Polityka ma zastosowanie tylko wtedy, gdy spełnione są jednocześnie warunki:

  • Microsoft 365 Copilot i Microsoft Copilot są zainstalowane,
  • Microsoft Copilot nie został zainstalowany przez użytkownika,
  • Microsoft Copilot nie był uruchamiany przez ostatnie 28 dni.

Po włączeniu: aplikacja Microsoft Copilot zostanie odinstalowana „once” (jednorazowo). Użytkownik nadal może ją potem ponownie zainstalować, jeśli będzie chciał.

Zakres edycji Windows

Microsoft wskazuje dostępność polityki na Enterprise, Pro i EDU.

Zarządzanie z Intune / SCCM

BleepingComputer podaje, że odinstalowanie ma następować na endpointach zarządzanych przez Microsoft Intune lub System Center Configuration Manager (SCCM) po włączeniu tej polityki.


Praktyczne konsekwencje / ryzyko

Co to daje bezpieczeństwu i zgodności

  • Redukcja „konsumenckiego” punktu wejścia do AI na firmowych stacjach — mniej ryzyka, że użytkownik będzie próbował używać niewłaściwego kanału (np. niezgodnego z polityką organizacji) lub mylił Copilot konsumencki z kontrolowanym M365 Copilot. Kontekst rozróżnienia consumer vs commercial opisuje Microsoft.
  • Porządek w standardzie obrazu (golden image) i w audytach: łatwiej udowodnić, że aplikacja nie jest obecna na zarządzanych urządzeniach (choć uwaga: polityka jest „once”, a użytkownik może reinstalować).

Ograniczenia, o których trzeba pamiętać

  • Skoro użytkownik może ponownie zainstalować aplikację, sama polityka nie jest „twardą blokadą” — to raczej mechanizm porządkowy/porządkujący niż finalne egzekwowanie.
  • Polityka działa tylko dla scenariuszy spełniających warunki (np. „nieuruchamiane 28 dni”) — w praktyce część środowisk może nie zobaczyć efektu na wszystkich stacjach.

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj, które „Copilot-y” masz w organizacji
    Microsoft rozdziela doświadczenia: konsumencki Microsoft Copilot vs komercyjny Microsoft 365 Copilot/M365 Copilot Chat. To ma znaczenie dla polityk, komunikacji do użytkowników i helpdesku.
  2. Jeśli celem jest trwałe ograniczenie uruchamiania/instalacji, rozważ AppLocker
    Microsoft wprost rekomenduje AppLocker jako właściwy mechanizm kontroli tej aplikacji (blokowanie instalacji/uruchomienia), zamiast polegać na starszych ustawieniach.
  3. Przygotuj plan egzekwowania (nie tylko „cleanup”)
    • „RemoveMicrosoftCopilotApp” może posprzątać aplikację, ale ponieważ użytkownik może ją przywrócić, w praktyce potrzebujesz warstwy egzekwującej (np. AppLocker) tam, gdzie wymagają tego polityki bezpieczeństwa.
  4. Pilot na małej grupie (szczególnie jeśli masz środowiska mieszane Pro/Enterprise/EDU)
    Polityka jest na razie w Insiderach, więc potraktuj ją jako zapowiedź kierunku i testuj wpływ na UX oraz zgłoszenia do service desku.

Różnice / porównania z innymi przypadkami

  • Odinstalowanie (RemoveMicrosoftCopilotApp): „sprzątanie” aplikacji — jednorazowe usunięcie, możliwa reinstalacja przez użytkownika; dodatkowo warunki targetowania.
  • AppLocker: podejście „policy enforcement” — potrafi zablokować instalację i/lub uruchomienie Copilota konsumenckiego na urządzeniu.
  • PowerShell: opcja manualna/skryptowa do usuwania pakietu aplikacji (Microsoft opisuje kroki w dokumentacji), ale to zwykle „operacyjne narzędzie” do remediacji, a nie mechanizm zarządzania polityką na dłuższą metę.
  • Historyczny incydent z 2025 r. (błąd aktualizacji): tam usunięcie Copilota było nieintencjonalne; tutaj Microsoft wprowadza kontrolowany mechanizm administracyjny.

Podsumowanie / kluczowe wnioski

  • Microsoft idzie w stronę większej sterowalności Copilota w firmach: nowa polityka ma umożliwić adminom odinstalowanie aplikacji Copilot na urządzeniach zarządzanych.
  • Mechanizm jest warunkowy i jednorazowy, więc nie zastępuje twardego egzekwowania — do tego sensowniejsze są narzędzia typu AppLocker.
  • Dla cyberbezpieczeństwa i compliance to dobra wiadomość: łatwiej ustandaryzować środowisko i ograniczać niepożądane „konsumenckie” powierzchnie AI, ale trzeba to domknąć warstwą polityk i komunikacji do użytkowników.

Źródła / bibliografia

  1. Windows Insider Blog – Announcing Windows 11 Insider Preview Build 26220.7535 (Dev & Beta Channels) (Windows Blog)
  2. BleepingComputer – Microsoft may soon allow IT admins to uninstall Copilot (BleepingComputer)
  3. Microsoft Learn – Updated Windows and Microsoft 365 Copilot Chat experience (Microsoft Learn)
  4. The Verge – Microsoft has fixed the Copilot automatic uninstall bug (kontekst historyczny) (The Verge)

CISA zamyka 10 Emergency Directives: co oznacza „sunset” i dlaczego wygrywa model KEV + BOD 22-01

Wprowadzenie do problemu / definicja luki

8 stycznia 2026 r. CISA (amerykańska agencja ds. cyberbezpieczeństwa) zamknęła jednorazowo aż 10 Emergency Directives (ED) wydanych w latach 2019–2024. W praktyce to „sunset” oznacza, że dyrektywy zostały oznaczone jako zamknięte, bo spełniły swój cel, a wymagane działania są już zrealizowane albo zostały „wchłonięte” przez stały mechanizm zarządzania ryzykiem podatności: KEV (Known Exploited Vulnerabilities) + BOD 22-01.

Warto to czytać szerzej niż jako porządkowanie archiwum: to sygnał, że CISA coraz częściej preferuje ciągły model priorytetyzacji podatności (KEV), zamiast utrzymywania wielu osobnych, kryzysowych nakazów.


W skrócie

  • CISA zamknęła 10 Emergency Directives (2019–2024).
  • Powód: wymagania z dyrektyw są zrealizowane lub zastąpione przez obowiązki wynikające z BOD 22-01 i katalogu KEV.
  • Zamknięte ED dotyczyły m.in. głośnych incydentów/podatności: DNS tampering, SolarWinds Orion, Exchange on-prem, Pulse Connect Secure, Print Spooler, VMware, a także kompromitacji korporacyjnej poczty Microsoft.

Kontekst / historia / powiązania

Emergency Directive to tryb „awaryjny” — narzędzie do szybkiego wymuszenia działań w sytuacji pilnego ryzyka dla amerykańskich agencji federalnych (FCEB). Binding Operational Directive (BOD) jest natomiast mechanizmem „systemowym”: obowiązkową dyrektywą dla agencji federalnych, porządkującą działania w skali całego rządu USA.

Kluczowa zmiana ostatnich lat to przeniesienie ciężaru z reakcji „incydent → osobna dyrektywa” na model „ciągła lista realnie wykorzystywanych podatności + terminy remediacji”. Ten model spina BOD 22-01 i katalog KEV, gdzie priorytetem jest to, co jest faktycznie eksploatowane.


4. Analiza techniczna / szczegóły luki

Jakie 10 ED zostało zamkniętych?

Lista zamkniętych Emergency Directives (wg publikacji podsumowującej zamknięcie):

  1. ED 19-01: Mitigate DNS Infrastructure Tampering
  2. ED 20-02: Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday
  3. ED 20-03: Mitigate Windows DNS Server Vulnerability from July 2020 Patch Tuesday
  4. ED 20-04: Mitigate Netlogon Elevation of Privilege Vulnerability from August 2020 Patch Tuesday
  5. ED 21-01: Mitigate SolarWinds Orion Code Compromise
  6. ED 21-02: Mitigate Microsoft Exchange On-Premises Product Vulnerabilities
  7. ED 21-03: Mitigate Pulse Connect Secure Product Vulnerabilities
  8. ED 21-04: Mitigate Windows Print Spooler Service Vulnerability
  9. ED 22-03: Mitigate VMware Vulnerabilities
  10. ED 24-02: Mitigating the Significant Risk from Nation-State Compromise of Microsoft Corporate Email System

Co je łączy technicznie?

To zestaw dyrektyw skupionych na dwóch klasach ryzyka:

A) „Powszechna technologia + szybka eksploatacja”
Windows/AD (Netlogon), DNS, Print Spooler, Exchange, Pulse Secure, VMware — czyli komponenty, które są masowo wdrażane i często bywają „single point of failure” w środowiskach enterprise.

B) „Incydenty o charakterze kampanii / supply chain / APT”
SolarWinds Orion i kompromitacja systemów pocztowych to przykłady zdarzeń, które wymuszają nie tylko patchowanie, ale też: triage, hunting, segmentację i zmianę praktyk operacyjnych.

Rola KEV: przeniesienie „co robić” do katalogu eksploatowanych CVE

CISA wskazała, że część zamykanych dyrektyw stała się redundantna, bo podatności trafiły do KEV (a więc podlegają reżimowi BOD 22-01). W artykułach o zamknięciu ED wymieniono m.in.: CVE-2020-0601, CVE-2020-1350, CVE-2020-1472, CVE-2021-26855, CVE-2021-34527, CVE-2021-22893 oraz wątek podatności VMware.

W praktyce: zamiast utrzymywać osobną „akcję specjalną” dla każdej dużej podatności, CISA woli dziś dopinać ją do mechanizmu KEV, gdzie kluczowe są terminy remediacji i ciągłe raportowanie postępu.


Praktyczne konsekwencje / ryzyko

Dla agencji federalnych USA: zamknięcie ED nie oznacza „temat nieaktualny”, tylko że działania zostały wykonane albo przechodzą na trwalszy reżim BOD/KEV.

Dla organizacji spoza FCEB (w tym w Polsce): to mocny sygnał trendu:

  • priorytetem nie jest „najwyższy CVSS”, tylko podatność z realną eksploatacją (KEV jako heurystyka ryzyka),
  • procesy bezpieczeństwa powinny działać ciągle, a nie falami po medialnych incydentach.

Ryzyko biznesowe pozostaje takie samo jak w latach, gdy wydawano ED: te klasy podatności (Exchange, VPN, AD/Netlogon, drukowanie, hypervisor/virtualization) regularnie wracają w kampaniach ransomware i APT, bo dają szybki efekt: dostęp, eskalację, lateral movement i trwałość.


Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, który „mapuje się” na logikę KEV/BOD, nawet jeśli nie podlegasz CISA:

  1. Zasada 1: KEV jako „fast lane” w VM
    Wprowadź osobny tor obsługi podatności „known exploited”: krótsze SLA, automatyczne eskalacje, raportowanie do właścicieli usług.
  2. Zasada 2: inwentaryzacja > skanowanie
    Większość ED dotyczyła technologii, które często żyją poza standardowym VM (appliance VPN, stare serwery Exchange, klastry vSphere). Upewnij się, że masz rzetelną listę: co mam, gdzie jest, kto jest właścicielem, jak patchuję.
  3. Zasada 3: kompensacje, gdy patch nie wchodzi
    Jeśli nie możesz patchować: odcięcie ekspozycji, segmentacja, WAF/IPS reguły, twarde ograniczenie adminów, monitoring anomalii (np. nietypowe logowania, nowe konta, eksport skrzynek, podejrzane usługi).
  4. Zasada 4: „security hygiene” dla tożsamości i zdalnego dostępu
    ED-y historycznie często dotykały wejść do sieci (VPN, poczta) — wymuś MFA, ogranicz dostęp administracyjny, wprowadź JIT/JEA, przegląd ról, alerty na niestandardowe tokeny/sesje.
  5. Zasada 5: ćwiczenia IR pod scenariusze z listy ED
    Zrób tabletop/blue-team exercise dla: kompromitacji poczty, łańcucha dostaw (SolarWinds), przejęcia AD (Netlogon), RCE w appliance VPN, eskalacji przez Print Spooler.

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

Model „ED” to reakcja punktowa: szybki nakaz na konkretny problem i konkretne wymagania. Model „KEV + BOD 22-01” to reakcja ciągła: stały katalog exploitable + terminy + raportowanie, które skaluje się lepiej niż utrzymywanie wielu równoległych dyrektyw.

To jest dojrzałościowo podobne do ewolucji SOC:

  • od „gaszenia pożarów po alertach”
  • do „zarządzania ryzykiem i ekspozycją w trybie ciągłym”.

Podsumowanie / kluczowe wnioski

  • 8 stycznia 2026 r. CISA zamknęła 10 Emergency Directives z lat 2019–2024.
  • Najważniejsza zmiana to przesunięcie ciężaru na KEV + BOD 22-01 jako stały mechanizm priorytetyzacji i egzekwowania remediacji.
  • Dla organizacji komercyjnych to czytelna wskazówka: w VM i patchingu warto formalnie wyróżniać „known exploited” jako kategorię o najwyższym priorytecie, niezależnie od samego CVSS.

Źródła / bibliografia

  1. The Record (Recorded Future News): informacje o zamknięciu 10 ED, kontekst KEV i lista przykładowych CVE.
  2. BleepingComputer: lista 10 zamkniętych ED oraz opis powiązania z BOD 22-01 i KEV.
  3. NIST (CSRC) – prezentacja dot. BOD 22-01: definicja BOD, obowiązkowość dla agencji federalnych i opis podejścia „katalog KEV + terminy”.

Trend Micro łata krytyczną lukę RCE w Apex Central (CVE-2025-69258) – pilna aktualizacja do Build 7190

Wprowadzenie do problemu / definicja luki

Trend Micro wydało krytyczną poprawkę dla Apex Central (on-premise) na Windows, usuwając podatność umożliwiającą zdalne wykonanie kodu (RCE) bez uwierzytelnieniaCVE-2025-69258. To szczególnie istotne, bo Apex Central jest centralną konsolą zarządzania (m.in. konfiguracją, dystrybucją polityk i aktualizacji) dla innych komponentów bezpieczeństwa Trend Micro, więc kompromitacja serwera zarządzającego często oznacza “dźwignię” do przejęcia większej części środowiska.


W skrócie

  • CVE-2025-69258: krytyczne RCE związane z mechanizmem LoadLibraryEx, pozwalające atakującemu załadować kontrolowaną DLL do kluczowego procesu i uruchomić kod z uprawnieniami SYSTEM.
  • Podatność jest pre-auth (brak wymaganego logowania) i ma CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • Poprawka: Critical Patch Build 7190 (i nowsze). Dotyczy instalacji poniżej Build 7190.
  • Wraz z RCE załatano też dwie luki DoS: CVE-2025-69259 i CVE-2025-69260 (obie CVSS 7.5, również możliwe bez uwierzytelnienia).
  • Tenable opublikowało szczegóły techniczne (oraz kontekst podatności), co zwykle zwiększa ryzyko szybkiego pojawienia się prób masowego skanowania i ataków na wystawione instancje.

Kontekst / historia / powiązania

Według informacji producenta, biuletyn bezpieczeństwa dla tej paczki poprawek został zaktualizowany 7 stycznia 2026, a sam wpis CVE w NVD pojawił się 8 stycznia 2026.
Tenable (jako podmiot, któremu Trend Micro dziękuje w biuletynie) przedstawiło też oś czasu odpowiedzialnego ujawnienia – ważne z perspektywy oceny dojrzałości procesu disclosure oraz tego, kiedy informacje techniczne mogły stać się szerzej dostępne.


Analiza techniczna / szczegóły luki

Na czym polega CVE-2025-69258?

W uproszczeniu: podatność dotyczy sytuacji, w której zdalny atakujący może doprowadzić do załadowania kontrolowanej biblioteki DLL do jednego z kluczowych komponentów Apex Central, a w konsekwencji do wykonania kodu w kontekście SYSTEM. Mechanizm jest powiązany z wykorzystaniem LoadLibraryEx.

Gdzie “siedzi” wektor ataku?

Z doniesień branżowych wynika, że istotną rolę odgrywa proces MsgReceiver.exe, który w typowej konfiguracji nasłuchuje na TCP/20001. To istotny szczegół z perspektywy obrony, bo w praktyce wiele organizacji nieświadomie wystawia usługi pomocnicze/agentskie albo pozostawia zbyt szerokie reguły między segmentami.

Co jeszcze załatano w Build 7190?

Trend Micro wskazuje, że Build 7190 usuwa również dwie podatności typu denial of service (CVE-2025-69259 oraz CVE-2025-69260), które także mogą być wyzwalane bez uwierzytelnienia. Choć DoS bywa postrzegany jako “mniej groźny” niż RCE, w systemach zarządzających bezpieczeństwem może prowadzić do realnych przestojów operacyjnych (np. brak dystrybucji polityk/aktualizacji, utrata telemetrii).


Praktyczne konsekwencje / ryzyko

  1. Pełne przejęcie serwera zarządzającego
    RCE wykonywane jako SYSTEM oznacza potencjalnie natychmiastowy “admin-level” na hoście Apex Central, a dalej możliwość kradzieży poświadczeń, lateral movement i manipulacji konfiguracją narzędzi ochronnych.
  2. Wysokie ryzyko dla instancji wystawionych (nawet pośrednio)
    Jeśli port/usługa związana z MsgReceiver.exe jest osiągalna z sieci mniej zaufanych (WAN, DMZ, szerokie VLAN-y, partnerzy), rośnie prawdopodobieństwo ataku “z marszu” – zwłaszcza po publikacji analiz technicznych.
  3. Ryzyko wtórne: sabotaż i “wyłączenie ochrony”
    Kompromitacja konsoli zarządzającej bywa wykorzystywana do: wyłączenia modułów ochronnych, dodania wyjątków, zmiany polityk, a nawet dystrybucji złośliwych artefaktów “zaufanym kanałem” w dół do endpointów (w zależności od architektury i uprawnień integracji).
  4. Sygnały ostrzegawcze dla SOC
    Nawet bez pełnych IOC warto traktować nietypowe: połączenia do TCP/20001, anomalie w zachowaniu procesu MsgReceiver.exe, nietypowe ładowanie DLL, oraz podejrzane połączenia SMB/UNC jako sygnały do triage (szczególnie w oknie tuż po ujawnieniu i publikacji szczegółów).

Rekomendacje operacyjne / co zrobić teraz

Poniżej “checklista”, która jest realistyczna dla zespołów IT/SecOps i pomaga szybko obniżyć ryzyko.

1) Patch management – absolutny priorytet

  • Zaktualizuj Apex Central (on-premise) do Critical Patch Build 7190 lub nowszego.
  • Zweryfikuj wersję po aktualizacji (nie tylko “zainstalowano paczkę”, ale faktyczny build).
  • Jeżeli masz środowiska rozproszone (oddziały/regiony), wymuś kontrolę zgodności (compliance) – ta luka jest wystarczająco poważna, by traktować ją jako “change emergency”.

2) Ogranicz ekspozycję sieciową (szczególnie TCP/20001)

  • Zablokuj dostęp do TCP/20001 z sieci nieadministracyjnych, a najlepiej ogranicz do ściśle wyznaczonych segmentów/hostów (allow-list).
  • Jeśli to możliwe: dostęp administracyjny wyłącznie przez VPN + MFA, z jump hostów (PAW/SAW).

3) Hardening i segmentacja “konsoli zarządzającej”

  • Traktuj serwer Apex Central jak Tier-0 (analogicznie do kontrolerów domeny): osobny segment, minimalne reguły, ograniczony ruch wychodzący.
  • Zredukuj możliwość inicjowania połączeń SMB/UNC do nieznanych zasobów (w praktyce: ograniczenia egress, kontrola DNS, reguły firewall).

4) Monitoring / detekcja (SIR / SOC)

  • Dodaj w SIEM reguły na: nietypowe połączenia do hosta Apex Central (zwłaszcza do usług pomocniczych), nagłe restarty usług, błędy aplikacyjne, oraz anomalie w ładowaniu modułów przez procesy Apex Central.
  • Ustal punkt odniesienia (baseline) dla ruchu sieciowego serwera Apex Central i wykrywaj odchylenia.

5) Przygotuj plan reagowania

  • Jeśli konsola była wystawiona szerzej niż powinna: rozważ szybki przegląd potencjalnych oznak kompromitacji (konto SYSTEM, nowe usługi, scheduled tasks, podejrzane binaria, nietypowe połączenia wychodzące).
  • W razie podejrzeń: izolacja hosta, zrzuty pamięci/logów, i standardowy IR playbook.

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

  • Konsola zarządzająca ≠ zwykły serwer aplikacyjny: podatności w systemach klasy “central management” mają zwykle większy blast radius, bo konsola ma uprawnienia do zarządzania agentami, politykami i aktualizacjami.
  • Pre-auth + wysoki kontekst uprawnień (SYSTEM) to jeden z najbardziej niebezpiecznych duetów: nie wymaga kradzieży poświadczeń, a efekt końcowy bywa równoważny pełnemu przejęciu hosta.
  • Publikacja szczegółów technicznych przez zewnętrzny zespół badawczy (tu: Tenable) często powoduje “drugą falę ryzyka”: nawet jeśli wcześniej nie było informacji o aktywnym wykorzystaniu, to po ujawnieniu rośnie aktywność skanerów i oportunistycznych ataków.

Podsumowanie / kluczowe wnioski

  • CVE-2025-69258 to krytyczna podatność RCE w Trend Micro Apex Central (on-premise) na Windows, z możliwością wykonania kodu jako SYSTEM i bez logowania.
  • Aktualizacja do Build 7190 (lub nowszego) jest działaniem “na już” – zwłaszcza jeśli serwer ma szeroką łączność sieciową.
  • W pakiecie są też dwie podatności DoS, również pre-auth, co dodatkowo wzmacnia argument za szybką aktualizacją.
  • Oprócz patchowania, realną redukcję ryzyka daje segmentacja, ograniczenie ekspozycji usług i monitoring anomalii na serwerze konsoli.

Źródła / bibliografia

  1. Trend Micro – CRITICAL SECURITY BULLETIN: Apex Central (on-premise) January 2026 Multiple Vulnerabilities (KA-0022071)
  2. NIST NVD – CVE-2025-69258 (Źródło)
  3. Tenable Research Advisory – TRA-2026-01 (Apex Central Multiple Vulnerabilities)
  4. BleepingComputer – Trend Micro fixes critical RCE flaw in Apex Central console
  5. Help Net Security – PoC released for unauthenticated RCE in Trend Micro Apex Central (CVE-2025-69258)

Veeam Backup & Replication: poprawki na luki RCE w wersji 13 (CVE-2025-59470 i inne) — co oznaczają i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Veeam Backup & Replication (VBR) to jeden z kluczowych elementów „kręgosłupa” odporności organizacji: jeśli backup pada, ransomware ma łatwiej, a odtwarzanie po incydencie potrafi zamienić się w wielodniowy kryzys. Dlatego każda podatność prowadząca do wykonania kodu (RCE) w środowisku backupowym jest traktowana priorytetowo.

Na początku stycznia 2026 Veeam wydał aktualizację, która łata kilka błędów umożliwiających wykonanie kodu lub nadużycia uprawnień w Veeam Backup & Replication v13. Co ważne: w tym pakiecie mówimy głównie o scenariuszach wymagających wysokich uprawnień (role operatorskie/administracyjne w VBR), ale to wciąż realny problem — bo atakujący często najpierw kradną tożsamości i dopiero potem „dojeżdżają” systemy kopii zapasowych.


W skrócie

  • Dotyczy: Veeam Backup & Replication 13.0.1.180 i wcześniejsze buildy v13.
  • Naprawiono w: Veeam Backup & Replication 13.0.1.1071.
  • Najważniejsze CVE (v13):
    • CVE-2025-59470 — RCE jako postgres przez złośliwe parametry (CVSS 9.0; Veeam „koryguje” ocenę operacyjną ze względu na wymagane role).
    • CVE-2025-55125 — RCE jako root przez złośliwy plik konfiguracji backupu.
    • CVE-2025-59469 — możliwość zapisu plików jako root (nadużycie prowadzące do dalszej eskalacji/utrwalenia).
    • CVE-2025-59468 — RCE jako postgres przy uprawnieniach Backup Administrator (wejście przez parametr hasła).
  • Status exploitacji: brak publicznych informacji o wykorzystaniu tych konkretnych CVE „in the wild” w momencie publikacji komunikatów, ale VBR bywa regularnie celem kampanii ransomware.
  • Rekomendacja: patch ASAP, bo po ujawnieniu poprawek rośnie ryzyko „reverse engineering” i polowania na niezałatane instancje.

Kontekst / historia / powiązania

Backup infrastructure jest atrakcyjnym celem, bo:

  1. daje wgląd w kluczowe systemy i poświadczenia,
  2. pozwala niszczyć kopie lub utrudniać odtwarzanie,
  3. bywa „uprzywilejowana” sieciowo (dużo wyjątków firewall, szeroki dostęp do serwerów).

Nie jest to teoria. W przeszłości podatności w Veeam VBR były wiązane z incydentami ransomware, a media branżowe podkreślają, że atakujący często celują w serwery Veeam jako element „zamykania ofiary w klatce” przed uruchomieniem szyfrowania.

Dobrym przykładem jest CVE-2024-40711 (krytyczne RCE), które NVD opisuje jako podatność umożliwiającą nieautoryzowane wykonanie kodu i odnotowuje jej obecność w katalogu KEV (Known Exploited Vulnerabilities).


Analiza techniczna / szczegóły luki

1) CVE-2025-59470 (CVSS 9.0): RCE jako postgres przy roli Backup/Tape Operator

Veeam opisuje scenariusz jako wykonanie kodu poprzez przesłanie złośliwych parametrów (m.in. „interval”/„order”), co finalnie prowadzi do RCE w kontekście użytkownika postgres.
Istotny niuans: choć metryka CVSS wychodzi „krytyczna”, Veeam operacyjnie obniża „severity response”, bo wymagane role są traktowane jako wysoce uprzywilejowane i powinny być szczególnie chronione.

2) CVE-2025-55125: RCE jako root przez złośliwą konfigurację backupu

W tym przypadku wektorem jest możliwość przygotowania złośliwego pliku konfiguracji backupu, co — przy uprawnieniach Backup/Tape Operator — może dać wykonanie kodu jako root.

3) CVE-2025-59469: zapis plików jako root (nadużycie uprawnień)

Możliwość zapisu plików jako root bywa „półproduktem” do pełnego przejęcia hosta: pozwala np. podmienić skrypty/konfiguracje, dołożyć klucze, zmienić elementy startowe usług, przygotować persistence lub ułatwić późniejsze RCE. Veeam wskazuje, że to scenariusz dostępny dla Backup/Tape Operator.

4) CVE-2025-59468: RCE jako postgres przy roli Backup Administrator

Ten wektor opiera się o złośliwy parametr hasła i wymaga roli Backup Administrator.

Wspólny mianownik: to nie są typowe „pre-auth RCE z internetu”. To raczej podatności, które stają się krytyczne w praktyce, gdy atakujący ma już foothold (skradzione konta, nadużycia uprawnień, kompromitacja AD) i próbuje domknąć przejęcie środowiska.


Praktyczne konsekwencje / ryzyko

Nawet jeśli wymagane są role uprzywilejowane, ryzyko jest wysokie z trzech powodów:

  1. „Privileged access” to częsty etap ataku. W wielu incydentach ransomware napastnicy dochodzą do kont domenowych i ról administracyjnych zanim uderzą w backup.
  2. Kompromitacja VBR to dźwignia na całą organizację. Backup serwer ma zwykle szerokie uprawnienia do systemów produkcyjnych, repozytoriów, hypervisorów i kont serwisowych.
  3. Po publikacji poprawek rośnie presja czasu. Veeam wprost wskazuje, że po ujawnieniu podatności atakujący mogą próbować odtworzyć zmiany i szukać niezałatanych instalacji.

W efekcie: to klasyczna sytuacja „nie ma exploitów teraz” → „ale może się szybko pojawić”, szczególnie w ekosystemie, w którym presja finansowa (ransomware) jest duża.


Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista w stylu „incident-ready” — do wdrożenia nawet bez pełnego programu hardeningu.

1) Patch management (priorytet #1)

  • Zaktualizuj Veeam Backup & Replication v13 do 13.0.1.1071.
  • Zweryfikuj build po aktualizacji (nie zakładaj, że „Windows Update/installer zrobił swoje”).

2) Natychmiastowy przegląd ról i uprawnień w VBR

  • Sprawdź, kto ma Backup Operator / Tape Operator / Backup Administrator. Te role w tym kontekście są „near-admin”.
  • Zmniejsz liczbę kont z tymi rolami (least privilege), wprowadź zasadę „czasowego dostępu” (JIT/JEA) tam, gdzie to możliwe.

3) Kontrola dostępu i segmentacja

  • Ogranicz dostęp sieciowy do serwera VBR (panel/komponenty zarządzające) do stacji administracyjnych i segmentu admin.
  • Wdróż reguły typu „deny by default” z wyjątkami, zamiast szerokich dopuszczeń.

4) Monitoring i detekcja nadużyć

  • Alerty na: dodawanie/zmiany ról w VBR, nietypowe operacje na konfiguracjach backupów, anomalie w usługach i procesach na serwerze Veeam.
  • Korelacja z AD: logowania uprzywilejowane do VBR, zmiany członkostwa grup, nowe konta/klucze.

5) Odporność na ransomware (nie tylko „patch”)

  • Przetestuj odtwarzanie (restore) i scenariusz „backup server compromised”.
  • Upewnij się, że masz kopie „nie do ruszenia” (immutability / offline / air-gap) oraz że proces odtwarzania nie zależy od jednego kompromitowalnego komponentu.

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

Warto zestawić styczniowe CVE (v13) z wcześniejszymi głośnymi podatnościami:

  • Teraz (CVE-2025-59470 i spółka): głównie scenariusze „post-auth” wymagające ról operatorskich/administracyjnych w VBR. To podnosi poprzeczkę, ale nie eliminuje ryzyka, bo przejęcie takich ról jest częstym etapem kampanii ransomware.
  • Wcześniej (np. CVE-2024-40711): NVD opisuje podatność jako umożliwiającą nieautoryzowane RCE i wskazuje jej obecność w KEV, co w praktyce oznacza udokumentowane wykorzystanie w rzeczywistych atakach.
  • CVE-2023-27532: Veeam opisywał ją jako błąd pozwalający nieautoryzowanemu użytkownikowi w obrębie „perymetru infrastruktury backupowej” uzyskać zaszyfrowane poświadczenia z bazy konfiguracyjnej (co bywa krokiem do przejęcia dalszych elementów).

Wniosek praktyczny: nawet jeśli nowe luki nie są „internet-facing pre-auth”, to organizacje nadal powinny traktować je jako wysokopilne, bo konsekwencje kompromitacji backupu są nieproporcjonalnie duże.


Podsumowanie / kluczowe wnioski

  • Veeam załatał cztery podatności w VBR v13, w tym scenariusze prowadzące do RCE (m.in. CVE-2025-59470) oraz nadużyć uprawnień.
  • Poprawka to Veeam Backup & Replication 13.0.1.1071 — jeśli masz v13, to jest update „na już”.
  • Wymagane role są uprzywilejowane, ale to nie „zmniejsza problemu do zera” — w realnych kampaniach atakujący często i tak dochodzą do takich uprawnień, a backup jest jednym z głównych celów.
  • Dodatkowo historia Veeam pokazuje, że podatności bywały wykorzystywane w praktyce (np. CVE-2024-40711).

Źródła / bibliografia

  • Veeam KB: Vulnerabilities Resolved in Veeam Backup & Replication 13.0.1.1071 (Veeam Software)
  • SecurityWeek: Several Code Execution Flaws Patched in Veeam Backup & Replication (SecurityWeek)
  • BleepingComputer: New Veeam vulnerabilities expose backup servers to RCE attacks (BleepingComputer)
  • NVD (NIST): CVE-2024-40711 Detail (NVD)
  • Veeam KB: CVE-2023-27532 (Veeam Software)

ClickFix z fałszywym BSOD: jak kampania na Booking.com zmusza ofiary do uruchomienia malware (PHALT#BLYX / DCRat)

Wprowadzenie do problemu / definicja luki

ClickFix to nie „luka” w sensie CVE, tylko wzorzec socjotechniczny: atakujący wyświetla ofierze wiarygodnie wyglądającą usterkę (np. błąd przeglądarki, CAPTCHA, „aktualizację”, a nawet ekran awarii), po czym prowadzi ją krok po kroku do samodzielnego uruchomienia polecenia (PowerShell/Terminal/Run). Kluczowy trik polega na tym, że to użytkownik staje się „launcherem” – omijając część automatycznych barier bezpieczeństwa.

Na początku stycznia 2026 r. opisano świeżą odsłonę tej techniki: kampanię wymierzoną w sektor hotelarski w Europie, gdzie przynętą jest fałszywa wiadomość o anulowaniu rezerwacji Booking.com, a elementem „wow” – fałszywy BSOD (Blue Screen of Death) odpalany w przeglądarce.


W skrócie

  • Cel: firmy z branży hospitality w Europie; przynęta „anulowanie rezerwacji” z kwotą zwrotu, która buduje presję czasu.
  • Mechanika: link z phishingu → klon Booking.com → fałszywy błąd/„CAPTCHA” → przejście w fullscreen → fałszywy BSOD → instrukcja Win+R i wklejenie komendy → uruchomienie łańcucha infekcji.
  • Technika „living off the land”: wykorzystanie legalnego MSBuild.exe do kompilacji/uruchomienia payloadu z pliku projektu .proj.
  • Payload: zmodyfikowany DCRat (RAT) + możliwości dalszego doładowania (w obserwacji: m.in. miner).

Kontekst / historia / powiązania

ClickFix został szerzej opisany jako rosnący trend od 2024 r. – pojawia się w kampaniach wykorzystujących phishing, malvertising i skompromitowane strony. Często kończy się infekcjami typu infostealer (np. Lumma) lub RAT/loaderami, a sam „fix” wymaga od użytkownika kopiowania-wklejania i uruchamiania poleceń.

W obserwacjach Microsoftu powtarza się też motyw wstrzykiwania/uruchamiania ładunków w pamięci oraz nadużywania narzędzi systemowych (LOLBins) – w tym m.in. msbuild.exe czy powershell.exe – co utrudnia detekcję opartą o klasyczne sygnatury plików.

Opisywana kampania (PHALT#BLYX) wpisuje się w ten trend, ale wyróżnia się „opakowaniem” (BSOD) oraz dopasowaniem do specyficznego kontekstu biznesowego (hotelarstwo + sezonowość + presja rozliczeń).


Analiza techniczna / szczegóły ataku

1) Wejście: phishing „Booking.com – anulowanie rezerwacji”

Atak startuje od e-maila podszywającego się pod informację o anulowaniu rezerwacji. Element psychologiczny jest prosty: „gość anuluje, jest zwrot (często znaczący), trzeba działać szybko”.

2) Klon serwisu i przynęta w przeglądarce

Kliknięcie prowadzi na stronę-klona Booking.com (w opisie wskazano m.in. domenę low-house[.]com), przygotowaną jako „high-fidelity clone” z odpowiednim brandingiem. Strona wyświetla błąd w stylu „Loading is taking too long” i zachęca do kliknięcia przycisku odświeżenia.

3) Fałszywy BSOD w trybie fullscreen = właściwy ClickFix

Po kliknięciu przycisku strona przechodzi w fullscreen i wyświetla fałszywy ekran BSOD. Następnie ofiara dostaje instrukcję:

  • otwórz Uruchom (Win+R),
  • wciśnij CTRL+V (w schowku jest już przygotowana komenda),
  • zatwierdź (Enter/OK).

To ważny szczegół: atakujący przenosi „punkt wykonania” na czynność użytkownika, co (w zależności od środowiska) może ominąć część kontroli, które lepiej działają na automatyczne pobrania/uruchomienia.

4) PowerShell + projekt MSBuild (v.proj) i kompilacja „na żywo”

W tej kampanii wklejone polecenie uruchamia PowerShell, który (równolegle do odwracania uwagi „wabikiem” w postaci strony administracyjnej) pobiera plik projektu .NET (v.proj) i wykorzystuje legalny MSBuild.exe do kompilacji oraz uruchomienia osadzonego payloadu.

Securonix podkreśla, że to ewolucja: wcześniejsze próbki powiązane z tym aktorem wykorzystywały prostsze łańcuchy oparte o .hta/mshta.exe, a przejście na MSBuild ma charakter „living off the land” (większa odporność na proste detekcje).

5) Eskalacja, persistencja i obrona przed obroną

W opisie kampanii pojawiają się m.in.:

  • dodawanie wyjątków w Windows Defender,
  • próby uzyskania uprawnień admina (UAC),
  • pobranie kolejnych komponentów przez BITS (Background Intelligent Transfer Service),
  • persistencja przez plik .url w folderze Startup.

6) Payload: DCRat + „hands-on-keyboard”

Końcowy ładunek to DCRat (zdalny dostęp), uruchamiany z technikami typu process hollowing oraz wstrzykiwaniem do procesu aspnet_compiler.exe (wskazywane jako wykonanie w pamięci). DCRat zapewnia m.in. zdalny pulpit, keylogger, reverse shell i możliwość doładowania kolejnych payloadów (w obserwowanym przypadku dołożono koparkę kryptowalut).


Praktyczne konsekwencje / ryzyko

Dla organizacji (szczególnie hotelarstwa) ryzyko nie kończy się na jednym zainfekowanym komputerze recepcji:

  • Kompromitacja kont i danych: keylogging + zdalny dostęp to prosta droga do kradzieży poświadczeń (poczta, PMS/CRM, systemy płatności, panele OTA).
  • Rozprzestrzenianie w sieci: RAT umożliwia rozpoznanie środowiska i ruch lateralny (zwłaszcza jeśli segmentacja jest słaba).
  • Dalsze payloady: miner jest „widoczny”, ale te same możliwości często służą do wdrożeń bardziej destrukcyjnych (np. kolejne narzędzia post-exploitation).
  • Koszty operacyjne i reputacyjne: incydent w sezonie wysokiego obłożenia oznacza chaos operacyjny, ryzyko wycieku danych gości oraz potencjalne konsekwencje regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  • Komunikat do pracowników: „Windows/Booking.com nigdy nie wymagają wklejania poleceń do Win+R/PowerShell. BSOD nie daje instrukcji naprawy w przeglądarce.” (to konkretnie adresuje mechanikę ataku).
  • Wzmocnij filtrację poczty: reguły na tematykę anulowania rezerwacji/zwrotów i linków do domen podobnych do Booking.com; izolacja linków (URL rewriting / sandbox).
  • Polityki ograniczające “Run” tam, gdzie nie jest potrzebne: Microsoft wprost wskazuje, że redukcja użycia okna Uruchom (Win+R) w rolach, które go nie wymagają, może ograniczać skuteczność ClickFix.

Twardnienie endpointów

  • Ogranicz/monitoruj LOLBins: msbuild.exe, powershell.exe, (często także inne narzędzia „systemowe” nadużywane w ClickFix). Microsoft opisuje msbuild.exe jako jeden z procesów, w które bywa wstrzykiwany kod w kampaniach ClickFix.
  • PowerShell logging: włącz Script Block Logging (4104), Module Logging oraz Process Creation (4688) i koreluj z wywołaniami Win+R / nietypowymi parametrami. (To praktyczny fundament do polowań na ClickFix, bo „fix” prawie zawsze zostawia ślad w telemetrii procesu).
  • Kontrola Defender exclusions + BITS: alerty na dodawanie wyjątków, nietypowe joby BITS inicjowane z kontekstu PowerShell oraz tworzenie plików .url w Startup.

Monitoring / hunting

Unit 42 zwraca uwagę, że skuteczne podejście to połączenie edukacji użytkowników z polowaniem w EDR/Windows Event Logs na charakterystyczne wzorce ClickFix. W praktyce: szukaj sekwencji „przeglądarka → Win+R → PowerShell → msbuild → połączenia wychodzące”. (


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

  • „Fałszywy BSOD” vs „fałszywa aktualizacja / CAPTCHA”: ClickFix często udaje drobne problemy (CAPTCHA, błąd strony, update). W tej kampanii BSOD ma zwiększyć autorytet komunikatu i poczucie awarii krytycznej.
  • MSBuild jako etap kompilacji: wiele kampanii ClickFix kończy się prostszym pobraniem i uruchomieniem komponentu; PHALT#BLYX idzie w stronę „build chain” (projekt .proj + MSBuild.exe), co jest spójne z trendem nadużywania LOLBins do uruchamiania ładunków w pamięci.
  • DCRat jako payload: Microsoft wskazuje, że ClickFix jest używany do dystrybucji zarówno infostealerów, jak i RAT-ów (oraz loaderów). Ten przypadek to klasyczny RAT z potencjałem dalszej eskalacji w sieci ofiary.

Podsumowanie / kluczowe wnioski

  • ClickFix działa, bo przerzuca odpowiedzialność za uruchomienie malware na użytkownika – a to bywa trudniejsze do zatrzymania samą automatyką.
  • Kampania PHALT#BLYX (grudzień 2025 / opis 5 stycznia 2026) pokazuje, że atakujący potrafią łączyć wysokiej jakości phishing + realistyczny klon serwisu + teatralny BSOD z technikami „living off the land” (MSBuild).
  • Najbardziej opłacalna obrona to miks: edukacja (zakaz wklejania komend), ograniczenie Win+R tam gdzie zbędne, twardnienie i monitoring PowerShell/MSBuild/BITS/Startup.

Źródła / bibliografia

  1. BleepingComputer – ClickFix attack uses fake Windows BSOD screens to push malware (5 stycznia 2026) (BleepingComputer)
  2. Securonix – Analyzing PHALT#BLYX: Fake BSODs and Trusted Build Tools… (Securonix)
  3. Microsoft Security Blog – Think before you Click(Fix): Analyzing the ClickFix social engineering technique (21 sierpnia 2025) (Microsoft)
  4. Palo Alto Networks Unit 42 – Fix the Click: Preventing the ClickFix Attack Vector (10 lipca 2025) (Unit 42)
  5. HHS HC3 (TLP:CLEAR) – ClickFix Attacks – Sector Alert (29 października 2024) (HHS)