Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
LegacyHive to nowo ujawniona podatność typu local privilege escalation w systemie Windows, powiązana z usługą User Profile Service. Błąd pozwala na załadowanie gałęzi rejestru należących do innych użytkowników, w tym kont o podwyższonych uprawnieniach, co może zostać wykorzystane po wcześniejszym uzyskaniu dostępu do systemu.
Problem jest szczególnie istotny, ponieważ dotyczy mechanizmu zarządzania profilami użytkowników. W praktyce oznacza to możliwość naruszenia separacji między profilami oraz przygotowania gruntu pod dalsze etapy ataku na host.
W skrócie
LegacyHive została opisana jako niezałatana podatność zero-day w Windows i opublikowana wraz z ograniczonym kodem proof-of-concept. Według dostępnych informacji exploit działa także na systemach wyposażonych w poprawki z lipca 2026 roku.
Mechanizm nadużycia koncentruje się na montowaniu hive’ów innych użytkowników, zwłaszcza pliku usrclass.dat. To może prowadzić do obejścia izolacji między profilami, a następnie ułatwić eskalację uprawnień, manipulację ustawieniami użytkownika lub budowę bardziej złożonego łańcucha kompromitacji.
Kontekst / historia
Podatność ujawniono publicznie 16 lipca 2026 roku, w okresie przypadającym na lipcowy Patch Tuesday Microsoftu. Za disclosure odpowiada badacz działający pod pseudonimem Nightmare Eclipse, kojarzony z wcześniejszym ujawnianiem niezałatanych błędów dotyczących produktów Microsoftu.
Publikacja wpisuje się w szerszy trend publicznego ujawniania podatności jeszcze przed pojawieniem się oficjalnej poprawki. Taka sytuacja zwiększa presję na producenta, ale jednocześnie skraca czas reakcji po stronie administratorów i zespołów bezpieczeństwa, które muszą wdrażać działania kompensacyjne bez pełnego wsparcia dokumentacyjnego.
Analiza techniczna
Z technicznego punktu widzenia LegacyHive dotyczy usługi Windows User Profile Service i umożliwia załadowanie hive’a innego użytkownika do bieżącego kontekstu. Publicznie opisany scenariusz zakłada użycie standardowych poświadczeń użytkownika oraz wskazanie trzeciego konta, którego hive ma zostać zamontowany.
Jeżeli operacja się powiedzie, hive docelowego użytkownika trafia do bieżącej przestrzeni klas użytkownika. Może to dać możliwość odczytu lub modyfikacji wybranych danych związanych z profilem, a więc obszaru istotnego dla konfiguracji środowiska, preferencji aplikacji i działania procesów uruchamianych w określonym kontekście bezpieczeństwa.
Najważniejszym aspektem błędu jest naruszenie granicy separacji pomiędzy profilami użytkowników. Załadowanie hive’a administratora lub innego uprzywilejowanego użytkownika nie musi od razu oznaczać pełnego przejęcia systemu, ale może ułatwić kolejne działania ofensywne.
- modyfikację ustawień uruchamiania aplikacji,
- utrwalenie dostępu w profilu użytkownika,
- wpływ na skojarzenia COM,
- zmiany wybranych kluczy rejestru wykorzystywanych przez procesy logowania i środowisko użytkownika.
Dodatkowo badacz wskazał, że pierwotna wersja exploita miała szersze możliwości. Według opisu nie wymagała poświadczeń użytkownika i pozwalała ładować nie tylko usrclass.dat, ale również inne hive’y. Opublikowany kod został jednak celowo ograniczony, co oznacza, że publiczny PoC może nie odzwierciedlać pełnego potencjału podatności.
Konsekwencje / ryzyko
Najważniejsze ryzyko związane z LegacyHive dotyczy środowisk, w których atakujący posiada już dostęp do zwykłego konta lokalnego lub domenowego. W takim modelu podatność może pełnić rolę skutecznego mechanizmu post-exploitation, wspierającego przejście z niskich uprawnień do bardziej uprzywilejowanego dostępu.
W praktyce skutki mogą obejmować:
- zwiększenie skuteczności lateral movement po przejęciu pojedynczego endpointu,
- obejście części mechanizmów separacji użytkowników,
- modyfikację ustawień profilu kont uprzywilejowanych,
- przygotowanie łańcucha ataku prowadzącego do pełnej kompromitacji hosta,
- utrudnienie analizy incydentu przez manipulację w obszarach rejestru rzadziej monitorowanych operacyjnie.
Ryzyko rośnie szczególnie w środowiskach wieloużytkownikowych, na serwerach terminalowych, systemach administracyjnych oraz wszędzie tam, gdzie konta uprzywilejowane logują się na tych samych hostach co użytkownicy standardowi. Sama obecność profilu administratora na stacji może zwiększać użyteczność exploita.
Rekomendacje
Do czasu publikacji oficjalnej poprawki organizacje powinny wdrożyć działania ograniczające skutki ewentualnego wykorzystania podatności.
- Ograniczyć współdzielenie systemów między kontami uprzywilejowanymi i zwykłymi użytkownikami.
- Korzystać z dedykowanych stacji administracyjnych dla administratorów.
- Zwiększyć monitoring operacji związanych z profilami użytkowników oraz ładowaniem hive’ów rejestru.
- Zwrócić szczególną uwagę na nietypowe odwołania do plików profilu innych użytkowników i anomalie dotyczące usrclass.dat.
- Przeprowadzić przegląd uprawnień lokalnych oraz zasad dostępu interaktywnego.
- Wzmocnić telemetrykę EDR i reguły detekcyjne pod kątem dostępu do artefaktów profili innych kont oraz zmian per-user poza standardowym cyklem logowania.
- Utrzymywać gotowość do szybkiego wdrożenia poprawek producenta i śledzić komunikaty dotyczące obejść oraz wskaźników kompromitacji.
Podsumowanie
LegacyHive pokazuje, że podatność lokalna może stanowić bardzo poważne zagrożenie operacyjne nawet bez zdalnego wykonania kodu. W nowoczesnych atakach eskalacja uprawnień pozostaje jednym z kluczowych etapów po uzyskaniu początkowego dostępu, a błędy w usługach systemowych Windows są szczególnie atrakcyjne dla napastników.
Nawet ograniczony publiczny proof-of-concept sugeruje, że separacja profili użytkowników może zostać naruszona. Do czasu opublikowania poprawki najważniejsze będą działania kompensacyjne, ścisła separacja kont uprzywilejowanych, monitoring oraz szybka reakcja zespołów SOC i IR.
Źródła
- SecurityWeek — Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day — https://www.securityweek.com/nightmare-eclipse-drops-legacyhive-windows-zero-day/