Archiwa: Windows - Strona 23 z 68

SAP usuwa krytyczne luki w FS-QUO i NetWeaver w ramach marcowego Security Patch Day 2026

Wprowadzenie do problemu / definicja

SAP opublikował marcowy pakiet poprawek bezpieczeństwa na 2026 rok, usuwając szereg podatności wpływających na środowiska enterprise. Najpoważniejsze z nich dotyczą komponentów FS-QUO oraz NetWeaver Enterprise Portal Administration i mogą prowadzić do wykonania dowolnego kodu, co stwarza ryzyko pełnego przejęcia podatnego systemu.

Ze względu na rolę platform SAP w obsłudze procesów finansowych, logistycznych, zakupowych i kadrowych, nawet pojedyncza krytyczna luka może przełożyć się na istotne zakłócenia operacyjne oraz wysokie ryzyko biznesowe.

W skrócie

W ramach marcowego Security Patch Day 2026 SAP opublikował 15 nowych not bezpieczeństwa. Najwyższą wagę mają dwie krytyczne podatności: CVE-2019-17571 w FS-QUO z oceną 9.8 w skali CVSS oraz CVE-2026-27685 w NetWeaver Enterprise Portal Administration z oceną 9.1.

CVE-2019-17571 w FS-QUO wiąże się z code injection oraz deserializacją niezaufanych danych w Apache Log4j.
CVE-2026-27685 w NetWeaver Enterprise Portal Administration może prowadzić do zdalnego wykonania kodu, eskalacji uprawnień lub odmowy usługi.
SAP zaadresował również inne problemy, w tym DoS, SSRF, SQL injection, XSS, braki kontroli autoryzacji, niebezpieczne przechowywanie danych i DLL hijacking.

Kontekst / historia

Regularne cykle aktualizacji SAP mają kluczowe znaczenie dla bezpieczeństwa systemów biznesowych, ponieważ obejmują platformę wykorzystywaną do obsługi najbardziej krytycznych procesów organizacji. Marcowy zestaw poprawek pokazuje, że ryzyko nie ogranicza się do nowych funkcji, lecz obejmuje również zależności bibliotek, starsze komponenty i rozbudowane integracje.

Szczególnie istotny jest fakt, że jedna z omawianych luk odnosi się do problemu znanego wcześniej w kontekście Apache Log4j. To przypomina, że podatności obecne w komponentach pośrednich mogą pozostawać realnym zagrożeniem przez długi czas, jeśli organizacje nie prowadzą systematycznego przeglądu zależności i ekspozycji usług.

Marcowe poprawki objęły również inne elementy ekosystemu, takie jak NetWeaver, Business One, Business Warehouse, S/4HANA, Customer Checkout 2.0, GUI for Windows oraz Solution Tools Plug-In. Potwierdza to szeroką powierzchnię ataku w środowiskach SAP i konieczność ciągłego zarządzania podatnościami.

Analiza techniczna

Najpoważniejsza luka w FS-QUO, oznaczona jako CVE-2019-17571, została opisana jako problem code injection powiązany z deserializacją niezaufanych danych w Apache Log4j. Tego typu błędy są wyjątkowo niebezpieczne, ponieważ aplikacja przetwarza dane wejściowe w sposób umożliwiający uruchomienie nieautoryzowanej logiki. W praktyce, jeśli komponent jest osiągalny i spełnione są odpowiednie warunki, atakujący może doprowadzić do wykonania dowolnego kodu na serwerze.

Druga luka, CVE-2026-27685, dotyczy NetWeaver Enterprise Portal Administration i również wynika z niebezpiecznej deserializacji. Scenariusz ataku może polegać na dostarczeniu spreparowanych danych, które podczas przetwarzania aktywują niepożądany łańcuch wykonania. Konsekwencją może być zdalne wykonanie kodu, eskalacja uprawnień albo zakłócenie dostępności usługi.

SAP usunął także lukę wysokiego ryzyka w Supply Chain Management, oznaczoną jako CVE-2026-27689. Problem umożliwia wielokrotne wywoływanie funkcji z ekstremalnie dużym parametrem sterującym pętlą, co może prowadzić do wyczerpania zasobów systemowych i skutecznego ataku na dostępność.

Pozostałe poprawki obejmują szerokie spektrum klas błędów, takich jak SSRF, SQL injection, XSS, brak właściwej kontroli autoryzacji, niebezpieczne przechowywanie danych oraz DLL hijacking. Taki zestaw wskazuje, że zagrożenia w ekosystemie SAP dotyczą zarówno warstwy aplikacyjnej, jak i narzędzi administracyjnych oraz komponentów klienckich.

Konsekwencje / ryzyko

Krytyczne luki w systemach SAP przekładają się bezpośrednio na ryzyko operacyjne i biznesowe. Skuteczne wykorzystanie podatności typu RCE może dać napastnikowi możliwość uruchamiania poleceń na serwerze, modyfikacji danych, instalacji backdoora, poruszania się lateralnego w sieci oraz dalszej kompromitacji połączonych systemów.

Ryzyko rośnie szczególnie wtedy, gdy podatne komponenty są dostępne z sieci korporacyjnej lub internetu, a organizacja nie wdrożyła segmentacji, monitoringu i silnych mechanizmów kontroli dostępu administracyjnego. W środowiskach SAP skutki incydentu mogą obejmować przestoje, utratę poufności danych biznesowych, problemy ze zgodnością regulacyjną oraz zakłócenie kluczowych procesów finansowych i logistycznych.

Nawet jeśli producent nie wskazał aktywnego wykorzystywania omawianych luk, ich charakter i poziom krytyczności uzasadniają pilne wdrożenie aktualizacji. W praktyce przestępcy często analizują nowe poprawki po to, aby szybko odtworzyć mechanizm błędu i przygotować exploity dla organizacji, które opóźniają patchowanie.

Rekomendacje

Organizacje korzystające z rozwiązań SAP powinny w pierwszej kolejności zidentyfikować wszystkie instancje FS-QUO, NetWeaver Enterprise Portal Administration oraz pozostałych komponentów objętych marcowymi poprawkami. Następnie należy niezwłocznie wdrożyć odpowiednie noty bezpieczeństwa zgodnie z procedurami testowymi i polityką change management.

Nadać najwyższy priorytet systemom narażonym na zdalny dostęp.
Zweryfikować, które interfejsy administracyjne są wystawione poza segmenty zaufane.
Ograniczyć dostęp do paneli administracyjnych wyłącznie do sieci zarządzających i zabezpieczyć go MFA.
Monitorować logi pod kątem anomalii związanych z deserializacją, błędami aplikacyjnymi i nietypowymi żądaniami.
Przeprowadzić przegląd reguł WAF, IDS/IPS oraz polityk segmentacji wokół krytycznych serwerów SAP.
Zweryfikować integralność systemów po aktualizacji, aby wykluczyć wcześniejszą kompromitację.
Przejrzeć zależności bibliotek i komponentów pośrednich, zwłaszcza tam, gdzie używana jest serializacja i deserializacja danych.

W organizacjach o wyższej dojrzałości bezpieczeństwa warto uzupełnić działania o hunting pod kątem oznak wykonania nieautoryzowanego kodu, tworzenia nowych kont uprzywilejowanych oraz nieplanowanych zmian konfiguracyjnych.

Podsumowanie

Marcowy Security Patch Day 2026 od SAP przyniósł poprawki dla 15 podatności, w tym dwóch krytycznych luk w FS-QUO i NetWeaver Enterprise Portal Administration. Największe zagrożenie wynika z możliwości wykonania dowolnego kodu poprzez błędy związane z deserializacją niezaufanych danych.

Dla organizacji korzystających z SAP oznacza to konieczność szybkiego patchowania, ograniczenia ekspozycji usług administracyjnych oraz wzmocnienia monitoringu i kontroli dostępu. Opóźnienie wdrożenia poprawek może przełożyć się na realne ryzyko kompromitacji kluczowych procesów biznesowych.

Źródła

SecurityWeek — SAP Patches Critical FS-QUO, NetWeaver Vulnerabilities — https://www.securityweek.com/sap-patches-critical-fs-quo-netweaver-vulnerabilities/
SAP Security Patch Day — https://support.sap.com/en/my-support/knowledge-base/security-notes-news/march-2026.html
NIST NVD — CVE-2019-17571 — https://nvd.nist.gov/vuln/detail/CVE-2019-17571
Apache Logging Services — Log4j Security Vulnerabilities — https://logging.apache.org/log4j/2.x/security.html

FortiGate jako punkt wejścia do sieci: kradzież kont usługowych i kompromitacja Active Directory

Wprowadzenie do problemu / definicja

Urządzenia FortiGate od lat stanowią kluczowy element ochrony styku sieci wewnętrznej z internetem. Problem pojawia się jednak wtedy, gdy sama zapora staje się celem skutecznego ataku, ponieważ jej przejęcie może otworzyć napastnikom drogę nie tylko do zarządzania ruchem sieciowym, ale również do konfiguracji, danych uwierzytelniających oraz informacji o architekturze środowiska.

W analizowanych incydentach FortiGate nie było jedynie pojedynczym punktem naruszenia. Po uzyskaniu dostępu do urządzenia atakujący wykorzystywali je jako przyczółek do dalszej penetracji infrastruktury Windows, przejmowania kont usługowych oraz operacji wymierzonych w Active Directory.

W skrócie

Badacze opisali scenariusze, w których FortiGate był wykorzystywany jako wektor wejścia do sieci. Napastnicy uzyskiwali dostęp administracyjny przez podatności lub słabe dane logowania, a następnie eksportowali konfigurację urządzenia, odzyskiwali poświadczenia kont usługowych i pozyskiwali informacje o topologii środowiska.

tworzenie nowych kont administratora na FortiGate,
modyfikacja reguł firewall w celu ułatwienia ruchu bocznego,
dołączanie nieautoryzowanych stacji roboczych do domeny,
wdrażanie narzędzi zdalnego zarządzania,
próby pozyskania pliku NTDS.dit z kontrolerów domeny.

Kontekst / historia

Kampania została zaobserwowana na przełomie końca 2025 i początku 2026 roku. W tym okresie szczególne znaczenie miały luki CVE-2025-59718, CVE-2025-59719 oraz CVE-2026-24858, powiązane z mechanizmami FortiCloud SSO i błędami w procesie uwierzytelniania.

W praktyce problem nie ograniczał się do samego urządzenia brzegowego. FortiGate w wielu organizacjach współpracuje z LDAP i Active Directory, używając kont usługowych do mapowania użytkowników, grup i polityk dostępu. To sprawia, że kompromitacja zapory może stać się bezpośrednim pomostem do naruszenia tożsamości domenowych.

Analiza techniczna

W opisywanych przypadkach atakujący uzyskiwali dostęp administracyjny do FortiGate na dwa główne sposoby: poprzez aktywnie wykorzystywane podatności albo w wyniku błędnej konfiguracji i słabych haseł. Następnie eksportowali konfigurację FortiOS, która mogła zawierać zaszyfrowane poświadczenia kont usługowych wykorzystywanych do integracji z LDAP lub Active Directory.

Po wyeksportowaniu konfiguracji napastnicy odzyskiwali hasła i wykorzystywali je do logowania w środowisku domenowym. W jednym z incydentów zdobyte konto usługowe posłużyło do uwierzytelnienia w Active Directory i dołączenia dwóch nieautoryzowanych stacji roboczych do domeny. Taki ruch umożliwia obejście części mechanizmów kontroli dostępu i stanowi skuteczną bazę do dalszych działań.

Atak obejmował również utrwalenie dostępu na samym urządzeniu brzegowym. Tworzono lokalne konta administracyjne oraz dodawano nowe reguły firewall, które ułatwiały komunikację między segmentami sieci. W drugim przypadku napastnicy bardzo szybko przeszli do logowania na serwery z użyciem przejętych poświadczeń uprzywilejowanych, wdrożyli legalne narzędzia zdalnego zarządzania oraz uruchomili złośliwy ładunek z wykorzystaniem techniki DLL side-loading.

Końcowym celem była próba pozyskania pliku NTDS.dit i gałęzi SYSTEM z kontrolera domeny. Taki zestaw danych pozwala na dalsze łamanie skrótów haseł, eskalację uprawnień i rozszerzenie kompromitacji na całą organizację.

Istotnym problemem okazał się również ograniczony poziom widoczności. Krótka retencja logów na urządzeniach brzegowych utrudniała ustalenie dokładnego momentu wejścia, przebiegu ataku oraz rzeczywistej skali naruszenia.

Konsekwencje / ryzyko

Kompromitacja FortiGate wiąże się z wysokim ryzykiem operacyjnym. Urządzenie znajduje się na styku internetu i sieci wewnętrznej, a jednocześnie często posiada relacje z systemami tożsamości, co czyni je szczególnie wartościowym celem.

utrata poufności danych uwierzytelniających,
manipulacja politykami bezpieczeństwa i ruchem sieciowym,
możliwość nieautoryzowanego dołączania hostów do domeny,
szybki ruch boczny do serwerów i kontrolerów domeny,
utrwalenie dostępu przez konta lokalne i narzędzia RMM,
kradzież danych z Active Directory i pełna eskalacja uprawnień.

Dodatkowym zagrożeniem jest fakt, że urządzenia brzegowe nie zawsze są objęte równie rozbudowanym monitoringiem jak stacje końcowe i serwery. Ograniczona telemetria, brak EDR oraz niewystarczająca retencja logów wydłużają czas niewykrytej obecności napastnika.

Rekomendacje

Organizacje powinny traktować FortiGate jako system krytyczny nie tylko z perspektywy sieci, ale także bezpieczeństwa tożsamości i domeny. Samo aktualizowanie urządzenia nie wystarczy, jeśli równolegle nie zostaną zabezpieczone konta usługowe, interfejsy administracyjne i procesy monitorowania.

zweryfikować wersję FortiOS i niezwłocznie wdrożyć poprawki dla wskazanych podatności,
wyłączyć FortiCloud SSO tam, gdzie nie jest niezbędne,
ograniczyć dostęp administracyjny wyłącznie do zaufanych segmentów i zabezpieczyć go MFA,
przeprowadzić rotację haseł wszystkich kont usługowych powiązanych z LDAP i AD,
przejrzeć lokalne konta administratorów oraz historię zmian polityk firewall,
monitorować eksport konfiguracji i nietypowe logowania administracyjne,
zwiększyć retencję logów urządzeń NGFW do co najmniej kilkunastu dni, a najlepiej do 60–90 dni,
centralizować logi w systemie SIEM,
analizować zdarzenia domenowe związane z nowymi komputerami, nietypowymi logowaniami i zmianami w katalogu,
zweryfikować ustawienia umożliwiające dołączanie maszyn do domeny bez ścisłej kontroli.

W środowiskach, gdzie istnieje podejrzenie naruszenia, warto dodatkowo sprawdzić, czy nie doszło do eksportu konfiguracji z FortiGate, utworzenia nowych kont lokalnych, logowań z adresów powiązanych z VPN zapory do serwerów domenowych oraz instalacji narzędzi zdalnego zarządzania.

Podsumowanie

Opisane incydenty pokazują, że nowoczesna zapora sieciowa może stać się nie tylko narzędziem ochrony, ale również wyjątkowo skutecznym punktem wejścia do środowiska firmowego. Kompromitacja FortiGate może prowadzić do przejęcia kont usługowych, obejścia segmentacji, ruchu bocznego i pełnego naruszenia Active Directory.

Dla obrony kluczowe znaczenie mają szybkie łatanie podatności, ścisła kontrola dostępu administracyjnego, regularna rotacja poświadczeń oraz pełna widoczność telemetryczna z urządzeń brzegowych. Bez tych działań firewall może przestać pełnić funkcję bariery i sam stać się najgroźniejszym elementem łańcucha ataku.

Źródła

Phishing przez Microsoft Teams i Quick Assist prowadzi do wdrożenia A0Backdoor

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej odchodzą od klasycznych kampanii e-mailowych i wykorzystują narzędzia, które w środowisku firmowym uchodzą za całkowicie normalne. Jednym z takich kanałów jest Microsoft Teams, używany na co dzień do komunikacji wewnętrznej, współpracy projektowej i kontaktu z działem wsparcia IT.

W opisywanej kampanii napastnicy podszywali się pod pracowników pomocy technicznej, a następnie przekonywali ofiary do uruchomienia Quick Assist, legalnego narzędzia zdalnego wsparcia dostępnego w systemie Windows. Celem było wdrożenie malware A0Backdoor i uzyskanie trwałego dostępu do zainfekowanego systemu.

W skrócie

Kampania była wymierzona między innymi w organizacje z sektora finansowego i ochrony zdrowia. Atak rozpoczynał się od działań socjotechnicznych, w tym zasypywania ofiary spamem, po czym następował kontakt przez Teams pod pretekstem pomocy technicznej.

napastnicy wykorzystywali Microsoft Teams do budowania wiarygodności,
ofiary były nakłaniane do uruchomienia Quick Assist,
po uzyskaniu dostępu instalowano podpisane pakiety MSI podszywające się pod legalne komponenty,
malware stosował DLL sideloading i odszyfrowywał ładunek w pamięci,
komunikacja z serwerem sterującym była ukrywana w zapytaniach DNS MX.

Kontekst / historia

Ten przypadek wpisuje się w szerszy trend nadużywania legalnych narzędzi administracyjnych i komunikacyjnych. Współczesne środowiska pracy opierają się na komunikatorach biznesowych, platformach współpracy i zdalnym wsparciu, dlatego użytkownicy są bardziej skłonni ufać wiadomościom otrzymanym przez znane aplikacje niż tradycyjnym e-mailom phishingowym.

Atak odzwierciedla także podejście living-off-the-land, czyli wykorzystywanie zaufanych aplikacji i natywnych mechanizmów systemowych do ukrycia złośliwej aktywności. Dzięki temu operatorzy mogą ograniczyć liczbę oczywistych artefaktów i utrudnić wykrycie incydentu przez klasyczne narzędzia bezpieczeństwa.

Badacze zwracają uwagę, że część zastosowanych metod przypomina techniki obserwowane wcześniej w operacjach powiązanych z grupami ransomware, zwłaszcza w obszarze socjotechniki i nadużywania legalnych narzędzi dostępowych. Jednocześnie połączenie podpisanych instalatorów MSI, A0Backdoor oraz komunikacji C2 przez rekordy DNS MX pokazuje rozwój bardziej wyspecjalizowanych technik operacyjnych.

Analiza techniczna

Łańcuch ataku zaczynał się od przygotowania psychologicznego ofiary. Napastnicy generowali presję i dezorientację poprzez zalew niechcianymi wiadomościami, a następnie kontaktowali się przez Teams jako rzekomy dział IT. Taki scenariusz zwiększał szansę, że pracownik uzna rozmowę za uzasadnioną interwencję techniczną.

Następnie ofiara była nakłaniana do uruchomienia Quick Assist. Po zestawieniu sesji zdalnej operator wdrażał zestaw złośliwych komponentów hostowanych w infrastrukturze chmurowej Microsoft. Wśród nich znajdowały się podpisane cyfrowo pakiety MSI, które podszywały się pod elementy Microsoft Teams oraz legalne usługi systemowe Windows.

Kluczową rolę odgrywała technika DLL sideloading. Napastnicy używali zaufanych binariów Microsoft do załadowania złośliwej biblioteki hostfxr.dll. Biblioteka zawierała zaszyfrowane lub skompresowane dane, które były odszyfrowywane bezpośrednio w pamięci i uruchamiane jako shellcode, co ograniczało liczbę łatwo wykrywalnych śladów na dysku.

Analiza wskazuje również na wykorzystanie funkcji CreateThread w sposób, który mógł utrudniać analizę malware. Nadmierne tworzenie wątków mogło destabilizować środowiska debugowania i spowalniać pracę analityków, jednocześnie nie zakłócając istotnie działania samego złośliwego kodu podczas normalnej infekcji.

Po uruchomieniu shellcode wykonywał kontrole środowiska, w tym mechanizmy wykrywania sandboxów. Jeśli system nie wyglądał na środowisko analityczne, generowany był klucz oparty na SHA-256, służący do odszyfrowania właściwego ładunku A0Backdoor zaszyfrowanego przy użyciu AES.

Sam backdoor relokował się do nowego obszaru pamięci, odszyfrowywał własne procedury i rozpoczynał rozpoznanie hosta. W tym celu korzystał z wywołań API systemu Windows, aby zebrać informacje o komputerze i użytkowniku. Taki fingerprint mógł służyć do oceny wartości ofiary, selekcji dalszych działań oraz przygotowania kolejnych poleceń operatorskich.

Szczególnie interesująca była komunikacja z infrastrukturą sterującą. A0Backdoor ukrywał dane sterujące w zapytaniach DNS MX, osadzając zakodowane metadane w subdomenach o wysokiej entropii kierowanych do publicznych resolverów rekurencyjnych. Odpowiedzi przyjmowały postać rekordów MX zawierających zakodowane polecenia, co mogło utrudniać detekcję w organizacjach monitorujących głównie rekordy TXT.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ opiera się ona na legalnych kanałach komunikacji i narzędziach natywnie obecnych w systemie operacyjnym. To sprawia, że użytkownicy rzadziej rozpoznają zagrożenie, a część zabezpieczeń może uznać aktywność za zgodną z normalnym wsparciem technicznym.

Wykorzystanie Quick Assist zmniejsza potrzebę dostarczania klasycznych załączników lub linków phishingowych. Z kolei podpisane pakiety MSI i DLL sideloading zwiększają szanse na obejście mechanizmów opartych wyłącznie na reputacji plików, prostych allowlistach i powierzchownych kontrolach aplikacyjnych.

Dodatkowym problemem jest kanał C2 oparty na DNS MX, który może pozostać niezauważony, jeśli organizacja nie analizuje pełnego kontekstu ruchu DNS. W praktyce skutki mogą obejmować trwały dostęp do stacji roboczej, eskalację uprawnień, ruch boczny w sieci, kradzież danych oraz przygotowanie gruntu pod kolejne etapy ataku, w tym wdrożenie ransomware.

Rekomendacje

Organizacje powinny formalnie uregulować sposób korzystania z Quick Assist i innych narzędzi zdalnego wsparcia. Każda sesja pomocy technicznej powinna być powiązana z autoryzowanym zgłoszeniem i poprzedzona jednoznaczną weryfikacją tożsamości pracownika IT.

W praktyce warto wdrożyć następujące działania:

monitorowanie uruchomień Quick Assist i korelowanie ich z aktywnością w Microsoft Teams,
analizę instalacji MSI wykonywanych bezpośrednio po sesjach zdalnych,
detekcję nietypowego ładowania bibliotek DLL przez zaufane binaria,
reguły wykrywające anomalie DNS, zwłaszcza zapytania MX o wysokiej entropii,
ograniczenie uruchamiania nieautoryzowanych instalatorów z lokalizacji chmurowych,
stosowanie EDR zapewniającego widoczność zdarzeń pamięciowych, wątków i wywołań API,
szkolenia użytkowników z phishingu prowadzonego przez komunikatory i fałszywy helpdesk.

Z perspektywy zespołów SOC kluczowe znaczenie ma korelacja telemetrii z wielu źródeł. Pojedynczy alert może nie wzbudzić podejrzeń, jednak ciąg zdarzeń obejmujący spam, kontakt przez Teams, start Quick Assist, uruchomienie MSI i nietypowy ruch DNS powinien być traktowany jako silny sygnał możliwej kompromitacji.

Podsumowanie

Kampania wykorzystująca Microsoft Teams i Quick Assist pokazuje, jak cienka stała się granica między legalną administracją a nadużyciem tych samych mechanizmów przez napastników. A0Backdoor łączy klasyczną socjotechnikę z nowoczesnymi technikami ukrywania ładunku, utrudniania analizy i nieoczywistej komunikacji C2.

Dla organizacji oznacza to konieczność rozszerzenia strategii obronnej poza pocztę elektroniczną. Skuteczna detekcja i reakcja wymagają objęcia monitoringiem komunikatorów firmowych, narzędzi zdalnego wsparcia, pamięci procesów oraz nietypowych wzorców w ruchu DNS.

Źródła

BleepingComputer — Microsoft Teams phishing targets employees with A0Backdoor malware — https://www.bleepingcomputer.com/news/security/microsoft-teams-phishing-targets-employees-with-backdoors/
BlueVoyant — Threat Intelligence and technical analysis referenced in the campaign report — https://www.bluevoyant.com/

Windows 11 KB5079473 i KB5078883: marcowe aktualizacje wzmacniają bezpieczeństwo, telemetrykę i odzyskiwanie systemu

Wprowadzenie do problemu / definicja

Microsoft opublikował marcowe, obowiązkowe aktualizacje zbiorcze dla Windows 11: KB5079473 dla gałęzi 24H2 i 25H2 oraz KB5078883 dla wersji 23H2. Pakiety są częścią cyklu Patch Tuesday i obejmują zarówno poprawki bezpieczeństwa, jak i zmiany funkcjonalne istotne z perspektywy administracji, monitorowania oraz odporności stacji roboczych.

Dla zespołów bezpieczeństwa oznacza to konieczność szybkiej oceny wpływu nowych buildów na środowiska produkcyjne, polityki zgodności i telemetrykę. To wydanie jest ważne nie tylko z powodu łatek bezpieczeństwa, ale również ze względu na rozwój natywnych mechanizmów ochronnych i odzyskiwania systemu.

W skrócie

Marcowe aktualizacje Windows 11 są obowiązkowe i dostarczają poprawki zabezpieczeń usuwające luki objęte cyklem Patch Tuesday.
Po instalacji systemy 24H2 i 25H2 przechodzą odpowiednio na build 26100.8037 oraz 26200.8037, a Windows 11 23H2 na build 22631.6783.
Microsoft rozszerzył mechanizmy związane z Secure Boot oraz odzyskiwaniem urządzeń po awarii.
Do systemu trafiła natywna obsługa Sysmon jako funkcji Windows, co może uprościć standaryzację telemetrii.
Pakiet obejmuje także poprawki wpływające na WDAC, stabilność logowania, wyszukiwanie i zarządzanie urządzeniami.

Kontekst / historia

Aktualizacje zbiorcze Windows 11 publikowane w drugi wtorek miesiąca pozostają jednym z najważniejszych momentów operacyjnych dla administratorów i zespołów SOC. Oprócz eliminacji bieżących podatności stanowią także kanał dostarczania zmian architektonicznych, które stopniowo wpływają na sposób twardnienia systemu, gromadzenia logów i odtwarzania urządzeń po incydentach.

W marcu 2026 Microsoft utrzymał model wspólnego pakietu dla platform 24H2 i 25H2, co upraszcza utrzymanie zgodności pomiędzy nowszymi wydaniami Windows 11. Jednocześnie aktualizacja dla 23H2 nadal funkcjonuje jako odrębny pakiet, co ma znaczenie dla organizacji zarządzających zróżnicowaną flotą urządzeń.

Na tle wcześniejszych wydań marcowy pakiet wyróżnia się wbudowaniem natywnej funkcjonalności Sysmon do systemu operacyjnego. To ważna zmiana strategiczna, ponieważ wzmacnia natywny stos telemetryczny Windows i może ograniczyć zależność od oddzielnej dystrybucji narzędzia.

Analiza techniczna

Aktualizacje KB5079473 i KB5078883 usuwają podatności ujęte w marcowym Patch Tuesday oraz poprawiają wiele elementów związanych ze stabilnością i zarządzaniem systemem. Z perspektywy cyberbezpieczeństwa szczególnie istotne są trzy obszary.

Pierwszym z nich jest rozszerzenie danych wykorzystywanych do kwalifikowania urządzeń do automatycznej aktualizacji certyfikatów Secure Boot. W praktyce zwiększa to zasięg urządzeń, które mogą otrzymać odświeżenie komponentów zaufanego rozruchu, co ma znaczenie dla ochrony łańcucha startowego systemu.

Drugim kluczowym elementem jest natywna funkcja Sysmon dostępna jako składnik Windows. Narzędzie rejestruje między innymi tworzenie procesów, połączenia sieciowe, ładowanie sterowników, zmiany w rejestrze oraz wybrane techniki iniekcji kodu. Integracja z systemem może uprościć standaryzację telemetrii, choć nadal wymaga starannej konfiguracji i filtrowania zdarzeń.

Trzecim obszarem jest rozwój Quick Machine Recovery. Mechanizm ten wspiera odzyskiwanie urządzeń po problematycznych zmianach systemowych, co może ograniczyć skutki nieudanych aktualizacji, błędnych konfiguracji i innych incydentów wpływających na dostępność stacji roboczych.

Dodatkowo pakiet obejmuje poprawki wpływające na niezawodność wyszukiwania w Eksploratorze plików, działanie Windows Defender Application Control względem obiektów COM, stabilność ekranu logowania, wydajność usług drukowania oraz obsługę RSAT na urządzeniach Arm64. Szczególnie ważne są tu ulepszenia WDAC, ponieważ mechanizm ten pozostaje jednym z filarów kontroli uruchamiania kodu i egzekwowania polityk aplikacyjnych.

Konsekwencje / ryzyko

Najważniejszym ryzykiem pozostaje opóźnienie wdrożenia obowiązkowych aktualizacji bezpieczeństwa. Każdy cykl Patch Tuesday skraca czas między ujawnieniem problemów a próbami ich wykorzystania przez atakujących, dlatego zwłoka zwiększa ekspozycję organizacji na ataki wykorzystujące znane luki.

Natywna obsługa Sysmon to jednocześnie korzyść i wyzwanie operacyjne. Ułatwia ujednolicenie telemetrii w środowisku Windows, ale przy nieprawidłowej konfiguracji może prowadzić do nadmiernego wolumenu logów, wzrostu kosztów retencji oraz pogorszenia stosunku sygnału do szumu w systemach SIEM.

Zmiany związane z Secure Boot i odzyskiwaniem systemu należy oceniać pozytywnie, jednak powinny one zostać zweryfikowane pod kątem zgodności z istniejącymi procesami operacyjnymi. Dotyczy to szczególnie środowisk korzystających z niestandardowych obrazów systemu, starszego firmware oraz restrykcyjnych polityk hardeningu.

W organizacjach utrzymujących równolegle wersje 23H2, 24H2 i 25H2 dodatkowym wyzwaniem pozostaje precyzyjne mapowanie buildów, pakietów KB i wyników testów. Błędy na tym etapie mogą prowadzić do niepełnego wdrożenia lub fałszywego poczucia zgodności.

Rekomendacje

Organizacje powinny traktować KB5079473 i KB5078883 jako aktualizacje priorytetowe i wdrażać je zgodnie z ustalonym procesem zarządzania poprawkami. Najlepszym podejściem pozostaje model pierścieniowy, obejmujący najpierw środowiska testowe i grupę pilotażową, następnie systemy o niższym krytycyzmie biznesowym, a dopiero później pozostałą infrastrukturę.

Zweryfikować, które urządzenia pracują na 23H2, 24H2 i 25H2, oraz potwierdzić właściwe buildy po instalacji.
Sprawdzić stan Secure Boot i potwierdzić poprawne odbieranie aktualizacji komponentów rozruchowych.
Ocenić możliwość wykorzystania wbudowanego Sysmon zamiast lub obok dotychczasowych wdrożeń.
Przetestować wpływ nowych zdarzeń na SIEM, reguły detekcyjne, retencję i koszty przetwarzania logów.
Zweryfikować polityki WDAC, zwłaszcza w środowiskach stosujących restrykcyjną kontrolę aplikacji i komponentów COM.
Sprawdzić gotowość procedur odzyskiwania urządzeń i zgodność Quick Machine Recovery z używanymi narzędziami EPM oraz UEM.

W przypadku Sysmon warto rozpocząć od ograniczonego zestawu reguł i stopniowo rozszerzać zakres telemetrii. Szczególną uwagę należy zwrócić na zdarzenia związane z tworzeniem procesów, połączeniami sieciowymi, modyfikacjami rejestru, dostępem do pamięci procesów oraz uruchamianiem sterowników.

Podsumowanie

Marcowe aktualizacje Windows 11 KB5079473 i KB5078883 to nie tylko standardowy pakiet poprawek bezpieczeństwa, ale również wydanie o istotnym znaczeniu operacyjnym dla zespołów cyberbezpieczeństwa. Najważniejsze elementy obejmują obowiązkowe łatki Patch Tuesday, rozszerzenia Secure Boot, rozwój Quick Machine Recovery oraz natywną integrację Sysmon.

Dla organizacji oznacza to potrzebę szybkiego wdrożenia, ale także świadomej walidacji nowych możliwości w obszarze telemetryki, kontroli aplikacji i odzyskiwania systemów. Z perspektywy defensywnej jest to aktualizacja, którą warto analizować nie tylko jako zestaw łatek, lecz także jako kolejny krok w kierunku głębszej integracji funkcji bezpieczeństwa bezpośrednio w platformie Windows 11.

Źródła

Microsoft domyślnie włączy Hotpatch w Windows Autopatch od maja 2026

Wprowadzenie do problemu / definicja

Microsoft zapowiedział istotną zmianę w modelu dostarczania poprawek bezpieczeństwa dla zarządzanych urządzeń z Windows. Od maja 2026 r. mechanizm Hotpatch ma być domyślnie aktywowany dla kwalifikujących się urządzeń obsługiwanych przez Microsoft Intune i Windows Autopatch. Oznacza to możliwość instalowania części miesięcznych aktualizacji zabezpieczeń bez konieczności restartu systemu.

Z perspektywy bezpieczeństwa i operacji IT jest to ważny krok w kierunku skrócenia czasu potrzebnego do osiągnięcia zgodności aktualizacyjnej. Mniejsza zależność od restartów użytkowników końcowych może ograniczyć okres, w którym urządzenie formalnie ma już dostępną poprawkę, ale nadal pozostaje podatne na atak.

W skrócie

Microsoft planuje domyślnie włączyć Hotpatch dla kwalifikujących się urządzeń zarządzanych przez Intune i Windows Autopatch od maja 2026 r.
Hotpatch pozwala instalować wybrane poprawki bezpieczeństwa bez restartu urządzenia.
Funkcja nie zastępuje całkowicie klasycznych aktualizacji skumulowanych, ponieważ miesiące bazowe nadal wymagają ponownego uruchomienia systemu.
Organizacje zachowają możliwość wyłączenia tej opcji na poziomie dzierżawy lub ograniczenia wdrożenia do wybranych grup urządzeń.
Nowy model ma przyspieszyć wdrażanie łatek i zmniejszyć okno ekspozycji na zagrożenia.

Kontekst / historia

Jednym z najczęstszych problemów w enterprise patch management pozostaje konieczność restartowania stacji roboczych po wdrożeniu aktualizacji bezpieczeństwa. W praktyce wiele organizacji dopuszcza kilkudniowe opóźnienie między dostarczeniem poprawki a wymuszeniem restartu. To z kolei wydłuża czas narażenia i utrudnia szybkie zamknięcie luk bezpieczeństwa.

Windows Autopatch został zaprojektowany jako usługa upraszczająca i automatyzująca zarządzanie aktualizacjami w środowiskach firmowych. Domyślne rozszerzenie tego modelu o Hotpatch wpisuje się w strategię ograniczania przestojów użytkowników, poprawy doświadczenia końcowego oraz zwiększania skuteczności wdrożeń zabezpieczeń na dużą skalę.

Zmiana jest także odpowiedzią na realne wyzwania operacyjne, w których to nie samo udostępnienie poprawki jest problemem, lecz jej skuteczne zastosowanie na urządzeniu. W modelu bezrestartowym organizacje mogą szybciej zbliżać się do stanu pełnej zgodności, zwłaszcza w miesiącach, w których aktualizacja nie wymaga klasycznego cyklu ponownego uruchomienia systemu.

Analiza techniczna

Hotpatch w Windows 11 działa jako model comiesięcznych aktualizacji bezpieczeństwa typu B, które w określonych miesiącach mogą zostać zastosowane bez restartu urządzenia. Nie oznacza to jednak całkowitego odejścia od tradycyjnych aktualizacji zbiorczych. Mechanizm opiera się na cyklu kwartalnym, w którym miesiąc bazowy dostarcza standardową aktualizację baseline wymagającą restartu, a kolejne miesiące mogą korzystać z modelu bezrestartowego.

W praktyce dla 2026 r. oznacza to, że kwiecień pełni rolę miesiąca bazowego, natomiast maj i czerwiec mogą wykorzystywać Hotpatch. Jeśli urządzenie nie posiada aktualnego wydania bazowego, nie otrzyma wyłącznie poprawki bezrestartowej, lecz standardową aktualizację skumulowaną wymagającą ponownego uruchomienia.

Aby urządzenie kwalifikowało się do Hotpatch, musi spełnić określone wymagania techniczne i administracyjne. Znaczenie mają odpowiednia edycja systemu i licencjonowanie, Windows 11 w wersji 24H2 lub nowszej, zarządzanie przez Microsoft Intune oraz obecność aktualnej aktualizacji bazowej. Dodatkowo wymagana jest aktywna funkcja Virtualization-Based Security. W przypadku urządzeń Arm64 istotny jest również warunek związany z niezgodnością trybu CHPE z tym scenariuszem wdrożeniowym.

Ważne jest to, że włączenie Hotpatch nie zmienia istniejących ustawień pierścieni aktualizacji, opóźnień czy aktywnych godzin. Mechanizm działa równolegle do obecnej polityki aktualizacyjnej. Jeżeli urządzenie nie spełnia wymagań, pozostaje przy klasycznym modelu otrzymywania najnowszej skumulowanej aktualizacji, co zapewnia ochronę, ale nadal wymaga restartu.

Z punktu widzenia administratorów istotne będą także funkcje raportowania i kontroli w Intune. Microsoft przewiduje możliwość zarządzania ustawieniem na poziomie dzierżawy oraz monitorowania gotowości urządzeń za pomocą raportów jakości aktualizacji Hotpatch i weryfikacji obecności wymaganej wersji bazowej.

Konsekwencje / ryzyko

Najważniejszą korzyścią bezpieczeństwa jest skrócenie czasu między publikacją poprawki a jej faktycznym zastosowaniem na urządzeniu końcowym. Ma to szczególne znaczenie w przypadku podatności aktywnie wykorzystywanych lub szybko weaponizowanych po ujawnieniu. Im mniejsza zależność od restartu i działań użytkownika końcowego, tym mniejsze ryzyko utrzymania stacji roboczych w stanie częściowej zgodności.

Jednocześnie nowy model nie eliminuje wszystkich problemów operacyjnych. Miesiące bazowe nadal będą wymagały restartu, a więc organizacje nie mogą całkowicie zrezygnować z planowania okien serwisowych. Dodatkowe komplikacje mogą pojawić się w środowiskach heterogenicznych, obejmujących starsze konfiguracje, systemy bez aktywnego VBS lub urządzenia Arm64 zależne od określonych komponentów 32-bitowych.

Ryzyko dotyczy również widoczności i poprawnej interpretacji stanu floty. Domyślne włączenie funkcji może prowadzić do błędnego założenia, że wszystkie urządzenia korzystają z bezrestartowego modelu aktualizacji. W rzeczywistości część systemów może nadal pozostawać przy tradycyjnych aktualizacjach LCU, co bez odpowiedniego monitoringu utrudni standaryzację procesu patch management.

Rekomendacje

Organizacje korzystające z Intune i Windows Autopatch powinny już teraz przygotować środowisko na domyślne włączenie Hotpatch. Kluczowe będzie nie tylko spełnienie wymagań technicznych, ale również aktualizacja procedur operacyjnych i monitoringu.

Zidentyfikować urządzenia z Windows 11 24H2 lub nowszym oraz potwierdzić zgodność licencyjną.
Sprawdzić, które systemy posiadają aktualną aktualizację bazową przed wdrożeniem majowych poprawek 2026.
Zweryfikować stan Virtualization-Based Security i usunąć przypadki, w których funkcja nie jest aktywna.
Przeanalizować flotę Arm64 pod kątem zależności od CHPE oraz aplikacji 32-bitowych.
Przeprowadzić pilotaż w wybranych grupach urządzeń przed szerokim wdrożeniem.
Monitorować raporty gotowości, błędy instalacji i różnice między urządzeniami kwalifikującymi się i niekwalifikującymi do Hotpatch.
Zaktualizować procedury patch management tak, aby wyraźnie rozróżniały miesiące baseline i miesiące Hotpatch.
Zachować możliwość szybkiego wyłączenia funkcji na poziomie dzierżawy w razie problemów ze zgodnością.

Dobrą praktyką będzie także dostosowanie procesów zarządzania podatnościami. Skrócenie czasu wdrożenia poprawek bez restartu może poprawić wskaźniki bezpieczeństwa tylko wtedy, gdy organizacja utrzyma pełną widoczność stanu urządzeń i jasno wydzieli systemy, które nie spełniają warunków nowego modelu.

Podsumowanie

Domyślne włączenie Hotpatch w Windows Autopatch od maja 2026 r. to ważna zmiana w sposobie zabezpieczania zarządzanych urządzeń Windows. Dla zespołów bezpieczeństwa oznacza potencjalnie krótsze okno ekspozycji, szybsze wdrażanie łatek i mniejszą zależność od restartów inicjowanych przez użytkowników.

Nie jest to jednak rozwiązanie całkowicie bezobsługowe. Skuteczność modelu zależy od spełnienia wymagań technicznych, bieżącego monitoringu i świadomego zarządzania wyjątkami infrastrukturalnymi. Organizacje, które odpowiednio wcześnie przygotują swoje środowiska, mogą realnie zyskać na szybkości i jakości procesu aktualizacji zabezpieczeń.

Źródła

Microsoft to enable Windows hotpatch security updates by default — https://www.bleepingcomputer.com/news/microsoft/microsoft-to-enable-hotpatch-security-updates-by-default-in-may/
Windows message center — https://learn.microsoft.com/en-us/windows/release-health/windows-message-center
Hotpatch updates — https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates

Microsoft Entra wprowadza passkey do logowania w Windows i wzmacnia ochronę przed phishingiem

Wprowadzenie do problemu / definicja

Microsoft rozszerza strategię uwierzytelniania bezhasłowego, dodając obsługę passkey dla kont Microsoft Entra na urządzeniach z Windows. To rozwiązanie ma ograniczyć ryzyko phishingu oraz przejęcia poświadczeń, zastępując tradycyjne hasła mechanizmem opartym na kryptografii asymetrycznej i lokalnym potwierdzeniu tożsamości za pomocą Windows Hello.

W praktyce oznacza to, że użytkownik nie musi przekazywać hasła do usługi podczas logowania. Zamiast tego urządzenie wykorzystuje lokalnie chroniony klucz prywatny, a sama autoryzacja odbywa się w modelu odpornym na typowe kampanie wyłudzające dane logowania.

W skrócie

Microsoft uruchamia obsługę passkey dla kont Entra w środowisku Windows.
Nowa funkcja ma charakter opt-in i będzie udostępniana etapami.
Wsparcie obejmuje również urządzenia niezarządzane, co ma znaczenie dla modelu BYOD i pracy hybrydowej.
Passkey są powiązane z konkretnym urządzeniem i przechowywane lokalnie w kontenerze Windows Hello.
Rozwiązanie ma zwiększyć odporność organizacji na phishing i ataki wymierzone w hasła.

Kontekst / historia

Rozszerzenie obsługi passkey wpisuje się w długofalową strategię Microsoftu, której celem jest ograniczanie roli haseł w procesie uwierzytelniania. To odpowiedź na stale rosnącą liczbę ataków phishingowych, credential stuffing oraz technik omijania klasycznego MFA.

Wcześniej firma rozwijała wsparcie dla logowania bezhasłowego w kontach osobistych oraz integrowała menedżera passkey z ekosystemem Windows. Teraz podobny model trafia szerzej do środowisk korporacyjnych zarządzanych przez Microsoft Entra, co ma szczególne znaczenie dla organizacji działających w modelu hybrydowym.

Nowa funkcja jest istotna zwłaszcza tam, gdzie użytkownicy korzystają z urządzeń prywatnych lub niezarejestrowanych w infrastrukturze przedsiębiorstwa. To właśnie takie scenariusze najczęściej pozostawały dotąd bardziej zależne od tradycyjnych haseł i przez to były łatwiejszym celem dla cyberprzestępców.

Analiza techniczna

Mechanizm passkey w Microsoft Entra dla Windows opiera się na standardach FIDO2 i WebAuthn. Zamiast tworzenia wspólnego sekretu w postaci hasła, urządzenie generuje parę kluczy kryptograficznych. Klucz prywatny pozostaje lokalnie na endpointcie i jest zabezpieczony przez Windows Hello, na przykład kodem PIN, odciskiem palca lub rozpoznawaniem twarzy. Klucz publiczny trafia do usługi tożsamości.

Podczas logowania użytkownik potwierdza swoją obecność na urządzeniu, a system podpisuje wyzwanie kryptograficzne. Dzięki temu żaden sekret możliwy do prostego skopiowania lub ponownego użycia nie jest przekazywany przez sieć. To fundamentalna różnica względem haseł, które można wyłudzić na fałszywej stronie lub przechwycić przez malware.

Istotnym elementem wdrożenia jest lokalny charakter passkey. Są one powiązane z konkretnym urządzeniem, co oznacza brak automatycznej przenośności między komputerami oraz konieczność oddzielnej rejestracji dla każdego konta Entra na każdym endpointcie. Zwiększa to bezpieczeństwo, ale jednocześnie podnosi wymagania operacyjne związane z onboardingiem, wymianą sprzętu i odzyskiwaniem dostępu.

Aby uruchomić funkcję, administratorzy muszą odpowiednio skonfigurować polityki Authentication Methods w Entra, włączyć Passkeys jako metodę FIDO2, przygotować profil passkey z właściwymi identyfikatorami AAGUID dla Windows Hello oraz przypisać konfigurację do wybranych grup użytkowników. Oznacza to, że skuteczne wdrożenie zależy nie tylko od samego systemu Windows, ale także od spójnej konfiguracji warstwy IAM.

Konsekwencje / ryzyko

Z perspektywy bezpieczeństwa najważniejszą korzyścią jest ograniczenie skuteczności phishingu oraz przejęć poświadczeń. Passkey utrudniają działanie fałszywych stron logowania, reverse proxy phishing kits i części ataków bazujących na ponownym wykorzystaniu danych uwierzytelniających.

Nie oznacza to jednak pełnej eliminacji ryzyka. Cyberprzestępcy nadal mogą próbować atakować sam endpoint, wykorzystywać socjotechnikę, nadużywać procesów rejestracji nowych metod logowania albo działać z poziomu złośliwego oprogramowania uruchomionego w kontekście użytkownika. Jeśli organizacja wdroży passkey tylko częściowo, pozostawiając równolegle słabsze ścieżki dostępu, realny poziom ochrony może być niższy od oczekiwanego.

Dodatkowym wyzwaniem jest zarządzanie cyklem życia urządzeń. W środowiskach korporacyjnych trzeba uwzględnić scenariusze utraty laptopa, wymiany sprzętu, reprovisioningu systemu oraz odwoływania dostępu. Bez dopracowanych procedur operacyjnych organizacja może zyskać większą odporność na phishing, ale jednocześnie zwiększyć złożoność obsługi użytkowników i helpdesku.

Rekomendacje

Organizacje planujące wdrożenie powinny rozpocząć od pilotażu obejmującego użytkowników o podwyższonym profilu ryzyka, takich jak administratorzy, kadra kierownicza oraz zespoły pracujące na danych wrażliwych. Równolegle warto przeanalizować istniejące polityki uwierzytelniania i upewnić się, że słabsze metody logowania nie pozostają aktywne bez uzasadnienia.

W środowiskach BYOD i pracy hybrydowej kluczowe będzie zdefiniowanie, z jakich urządzeń i na jakich warunkach można uzyskiwać dostęp do zasobów firmowych. Passkey powinny być wdrażane razem z politykami Conditional Access, kontrolą stanu urządzenia oraz monitoringiem zdarzeń tożsamościowych.

ograniczyć użycie haseł tam, gdzie passkey są dostępne,
monitorować rejestrację nowych metod uwierzytelniania,
wzmocnić procedury odzyskiwania dostępu do kont,
szkolić użytkowników z rozpoznawania socjotechniki,
utrzymywać telemetrię z endpointów i systemów IAM,
zaktualizować dokumentację helpdesku pod kątem modelu passwordless.

Podsumowanie

Wprowadzenie passkey dla Microsoft Entra w Windows to ważny krok w stronę ograniczenia jednej z najczęściej wykorzystywanych powierzchni ataku, czyli haseł. Rozszerzenie wsparcia na urządzenia niezarządzane może istotnie poprawić bezpieczeństwo organizacji działających w modelu hybrydowym i BYOD.

Jednocześnie samo wdrożenie technologii nie zastępuje kompleksowej strategii ochrony tożsamości. O skuteczności rozwiązania zdecydują dopracowane polityki dostępu, bezpieczeństwo endpointów, monitoring oraz gotowość operacyjna do obsługi nowego modelu logowania.

Źródła

Microsoft brings phishing-resistant Windows sign-ins via Entra passkeys — https://www.bleepingcomputer.com/news/microsoft/microsoft-entra-brings-phishing-resistant-sign-in-to-windows/
Microsoft 365 Message Center: Microsoft Entra passkeys on Windows — https://mc.merill.net/message/MC
Windows Hello overview — https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/
Passkeys developer and identity guidance — https://learn.microsoft.com/entra/identity/authentication/concept-authentication-passwordless
FIDO Alliance: Passkeys — https://fidoalliance.org/passkeys/

Microsoft publikuje KB5078885 dla Windows 10 ESU: poprawki bezpieczeństwa, dwa zero-day i naprawa problemu z zamykaniem

Wprowadzenie do problemu / definicja

Microsoft opublikował aktualizację KB5078885 dla systemu Windows 10 w ramach programu Extended Security Updates (ESU) oraz dla wybranych wydań LTSC. Pakiet ma charakter bezpieczeństwa i jakościowy, a jego głównym celem jest usunięcie podatności zaadresowanych w marcowym cyklu Patch Tuesday 2026 oraz naprawa błędu wpływającego na proces wyłączania i hibernacji części urządzeń.

Dla organizacji, które nadal utrzymują środowiska oparte na Windows 10 po zakończeniu standardowego wsparcia, jest to aktualizacja o dużym znaczeniu operacyjnym. Obejmuje ona zarówno istotne poprawki defensywne, jak i zmiany wpływające na stabilność oraz ciągłość działania systemów.

W skrócie

Aktualizacja KB5078885 została opublikowana 10 marca 2026 r.
Po instalacji Windows 10 osiąga kompilację 19045.7058, a Windows 10 Enterprise LTSC 2021 kompilację 19044.7058.
Pakiet zawiera marcowe poprawki bezpieczeństwa, obejmujące 79 podatności, w tym dwa aktywnie wykorzystywane błędy typu zero-day.
Usunięto również problem, przez który niektóre urządzenia restartowały się zamiast prawidłowo wyłączać lub przechodzić w hibernację.
Aktualizacja wspiera dalsze wdrażanie nowych certyfikatów Secure Boot przed wygaśnięciem starszych certyfikatów w czerwcu 2026 r.

Kontekst / historia

Po zakończeniu standardowego wsparcia dla Windows 10 w październiku 2025 r. wiele organizacji zostało zmuszonych do korzystania z modelu ESU lub utrzymywania środowisk LTSC. Oznacza to, że comiesięczne aktualizacje bezpieczeństwa stały się kluczowym elementem utrzymania zgodności, ograniczania ryzyka i ochrony systemów przed nowymi kampaniami ataków.

W ostatnich miesiącach Microsoft mierzył się także z problemem dotyczącym wybranych konfiguracji wykorzystujących zaawansowane mechanizmy ochrony rozruchu i izolacji. Część urządzeń z włączonymi funkcjami Secure Launch oraz Virtual Secure Mode po wcześniejszych aktualizacjach bezpieczeństwa nie wyłączała się poprawnie i zamiast tego wykonywała restart. W środowiskach korporacyjnych taki błąd może zaburzać harmonogramy serwisowe, procedury utrzymaniowe oraz automatyzację zadań administracyjnych.

Analiza techniczna

KB5078885 jest zbiorczą aktualizacją jakości i bezpieczeństwa. Nie wprowadza nowych funkcji użytkowych, lecz konsoliduje poprawki związane z bezpieczeństwem i niezawodnością systemu. Najważniejszym elementem pakietu jest integracja zabezpieczeń opublikowanych w ramach marcowego Patch Tuesday 2026.

Z perspektywy bezpieczeństwa kluczowe znaczenie ma usunięcie 79 podatności, w tym dwóch luk zero-day, które były aktywnie wykorzystywane. Taki zestaw zmian oznacza, że odkładanie wdrożenia może zwiększać ekspozycję na ataki wykorzystujące już znane i operacyjnie stosowane techniki.

Aktualizacja rozwiązuje również problem związany z mechanizmami OS Security w środowiskach wykorzystujących System Guard Secure Launch oraz VSM. Błąd powodował, że urządzenia zamiast zakończyć proces wyłączania lub przejść do hibernacji, uruchamiały się ponownie. W praktyce wskazuje to na konflikt w obszarze bezpiecznego rozruchu, logiki stanów energetycznych lub ochrony pamięci w systemach z podwyższonym poziomem hardeningu.

Istotna zmiana dotyczy także Secure Boot. Microsoft kontynuuje wdrażanie nowych certyfikatów rozruchowych, które mają zastąpić starsze certyfikaty z 2011 r. wygasające w czerwcu 2026 r. W aktualizacji uwzględniono dodatkowe dane targetowania urządzeń, aby zwiększyć liczbę systemów kwalifikujących się do automatycznego otrzymania nowych certyfikatów. To ważny krok dla utrzymania zaufanego łańcucha rozruchowego i ograniczania przyszłych problemów z walidacją komponentów startowych.

Poza bezpieczeństwem pakiet zawiera także poprawki jakościowe dotyczące między innymi File History, stabilności grafiki, zgodności z normą GB18030-2022A dla chińskich fontów oraz lokalizowanych nazw folderów opartych o plik desktop.ini w Eksploratorze plików. Choć są to zmiany drugoplanowe, mają znaczenie dla stabilności operacyjnej i redukcji incydentów po wdrożeniu.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dotyczy organizacji, które nadal korzystają z Windows 10 i opóźniają wdrożenie marcowej aktualizacji. Obecność dwóch aktywnie wykorzystywanych zero-day oznacza, że niezałatane systemy mogą pozostawać podatne na realne ataki prowadzone przez cyberprzestępców lub operatorów kampanii ukierunkowanych.

Drugim obszarem ryzyka są środowiska korzystające z funkcji takich jak Secure Launch, VSM i Secure Boot. Jeżeli urządzenia nie realizują poprawnie operacji wyłączania lub hibernacji, może to wpływać na okna serwisowe, procedury backupowe, zadania utrzymaniowe oraz skuteczność automatyzacji patch managementu.

Warto również uwzględnić ryzyko związane z nadchodzącym wygaśnięciem starszych certyfikatów Secure Boot. Brak przygotowania do ich wymiany może prowadzić do problemów kompatybilności, trudności z zarządzaniem zaufaniem do komponentów rozruchowych i komplikacji podczas wdrażania kolejnych aktualizacji związanych z łańcuchem zaufania.

Rekomendacje

Organizacje korzystające z Windows 10 w modelu ESU powinny potraktować KB5078885 jako aktualizację priorytetową. Dobrym podejściem jest rozpoczęcie wdrożenia od grupy pilotażowej obejmującej urządzenia z włączonymi funkcjami VBS, Secure Launch oraz niestandardowymi konfiguracjami UEFI i Secure Boot.

Zweryfikować, czy urządzenia po instalacji osiągają oczekiwane kompilacje systemu.
Przetestować scenariusze wyłączania, restartu i hibernacji na urządzeniach z podwyższonym poziomem zabezpieczeń.
Monitorować dzienniki zdarzeń związane z rozruchem, integralnością kodu, VSM i procesem aktualizacji.
Przeprowadzić przegląd gotowości środowiska do wdrożenia nowych certyfikatów Secure Boot.
Przyspieszyć cykl patch managementu i ograniczać ekspozycję systemów legacy poprzez segmentację oraz redukcję uprawnień administracyjnych.
Uaktualnić plan migracji z Windows 10 do platform objętych standardowym wsparciem.

Podsumowanie

KB5078885 to jedna z ważniejszych aktualizacji bezpieczeństwa dla organizacji utrzymujących Windows 10 w modelu ESU lub korzystających z wydań LTSC. Pakiet usuwa luki załatane w marcu 2026 r., w tym dwa aktywnie wykorzystywane zero-day, naprawia problem z nieprawidłowym zamykaniem części urządzeń oraz wspiera przygotowania do wymiany certyfikatów Secure Boot przed ich wygaśnięciem.

Z perspektywy zespołów bezpieczeństwa i administratorów jest to aktualizacja, której nie należy odkładać. Ma ona znaczenie zarówno dla odporności środowiska na bieżące zagrożenia, jak i dla stabilności operacyjnej w końcowej fazie cyklu życia Windows 10.

Źródła

Microsoft releases Windows 10 KB5078885 extended security update — https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-windows-10-kb5078885-extended-security-update/
March 10, 2026—KB5078885 (OS Builds 19045.7058 and 19044.7058) – Microsoft Support — https://support.microsoft.com/en-us/topic/march-10-2026-kb5078885-os-builds-19045-7058-and-19044-7058-5738282d-0b7f-426e-a42b-bd7698ab6dbb
Microsoft March 2026 Patch Tuesday fixes 2 zero-days, 79 flaws — https://www.bleepingcomputer.com/news/microsoft/microsoft-march-2026-patch-tuesday-fixes-2-zero-days-79-flaws/
Microsoft: Some Windows PCs fail to shut down after January update — https://www.bleepingcomputer.com/news/security/microsoft-some-windows-pcs-fail-to-shut-down-after-january-update/
Microsoft rolls out new Secure Boot certificates before June expiration — https://www.bleepingcomputer.com/news/microsoft/microsoft-rolls-out-new-secure-boot-certificates-before-june-expiration/