Pass-the-Hash — dlaczego atakujący nie musi znać Twojego hasła, żeby zalogować się do Windows
Pass-the-Hash — dlaczego atakujący nie musi znać Twojego hasła, żeby zalogować się do Windows
Silne hasło nie zawsze wystarczy.
W środowisku Windows istnieje technika Pass-the-Hash (PtH), w której atakujący może wykorzystać przejęty hash hasła do uwierzytelnienia bez poznania właściwego hasła użytkownika. To szczególnie istotny problem w sieciach firmowych, gdzie jedno przejęte konto może zostać wykorzystane do dalszego przemieszczania się pomiędzy komputerami.
Właśnie dlatego kradzież poświadczeń jest często większym problemem niż samo złamanie hasła.
Czym jest Pass-the-Hash?
Pass-the-Hash to technika polegająca na wykorzystaniu wartości skrótu hasła jako materiału uwierzytelniającego.
Atakujący nie musi więc wykonać klasycznego schematu:
hasło → złamanie → dostęp
Może próbować wykorzystać:
hash hasła → uwierzytelnienie → dostęp
Problem dotyczy przede wszystkim środowisk korzystających z NTLM.
Szczegółowo mechanizm oraz jego wpływ na Active Directory opisano w artykule Pass-the-Hash – mechanizm działania i ochrona Active Directory przed kradzieżą hashy.
Dlaczego hash może być tak cenny?
Hash hasła nie jest tym samym co hasło.
Jeżeli użytkownik posiada hasło:
MojeHaslo2026!
system nie musi przechowywać go w takiej postaci. W określonych mechanizmach Windows wykorzystywany jest jego odpowiedni materiał kryptograficzny.
Problem pojawia się wtedy, gdy atakujący zdobędzie taki materiał i może wykorzystać go w mechanizmie uwierzytelniania.
Dlatego założenie:
„Nie zna mojego hasła, więc nic nie zrobi”
może być błędne.
Jak wygląda typowy scenariusz?
Wyobraźmy sobie komputer pracownika:
PC-01
│
▼
użytkownik
│
▼
kompromitacja systemu
│
▼
kradzież poświadczeń
│
▼
hash NTLM
│
▼
Pass-the-Hash
│
├──► PC-02
├──► PC-03
└──► SERVER-01
Jeżeli przejęte konto ma odpowiednie uprawnienia na innych urządzeniach, atakujący może próbować wykorzystać zdobyte poświadczenia do dalszego ruchu.
To właśnie lateral movement — przemieszczanie się po środowisku po uzyskaniu początkowego dostępu.
Na Netbe.pl znajduje się również osobny materiał Ataki Pass-the-Hash (PtH) – przejęcie tożsamości bez hasła, który opisuje ten mechanizm oraz przykładowe ścieżki ataku.
Największy problem: konta administratorów
Pass-the-Hash staje się szczególnie istotny, gdy przejęte zostanie konto posiadające wysokie uprawnienia.
Przykład:
lokalny administrator
│
▼
przejęty hash
│
▼
inne komputery
│
▼
serwer
│
▼
konto domenowe
Nie oznacza to, że każdy przejęty hash automatycznie zapewnia dostęp do całej domeny.
Zakres ataku zależy od uprawnień konta, konfiguracji systemów, dostępnych protokołów oraz zabezpieczeń wdrożonych w organizacji.
Ale im większy zakres uprawnień posiada konto, tym większe konsekwencje może mieć jego kompromitacja.
Wspólne hasło lokalnego administratora pogarsza sytuację
To bezpośrednio łączy się z naszym poprzednim tematem dotyczącym Windows LAPS.
Załóżmy, że firma ma 100 komputerów:
PC01 → Administrator → hasło X
PC02 → Administrator → hasło X
PC03 → Administrator → hasło X
...
PC100 → Administrator → hasło X
Atakujący kompromituje PC01 i uzyskuje materiał uwierzytelniający lokalnego administratora.
Jeżeli identyczne hasło obowiązuje również na pozostałych komputerach, problem przestaje dotyczyć tylko jednego urządzenia.
Znacznie lepszym modelem jest:
PC01 → hasło A
PC02 → hasło B
PC03 → hasło C
...
PC100 → hasło Z
Właśnie tutaj Windows LAPS ogranicza jeden z istotnych problemów związanych z ponownym wykorzystywaniem tych samych lokalnych poświadczeń.
Credential Guard jako dodatkowa warstwa
Jednym ze sposobów ograniczania ryzyka kradzieży poświadczeń jest Credential Guard.
Mechanizm wykorzystuje VBS do izolowania określonych informacji uwierzytelniających od normalnego środowiska Windows.
W praktyce chodzi o stworzenie dodatkowej granicy:
Normal Windows
│
├── aplikacje
├── sterowniki
└── potencjalnie malware
X
Isolated Environment
│
└── chronione poświadczenia
Więcej informacji o tym mechanizmie znajduje się w artykule Credential Guard i izolacja poświadczeń – jak Windows 11 chroni hasła.
Dlaczego LSASS jest ważny?
W kontekście kradzieży poświadczeń często pojawia się proces:
lsass.exe
LSASS, czyli Local Security Authority Subsystem Service, odpowiada za istotne elementy uwierzytelniania i polityk bezpieczeństwa Windows.
Dlatego proces ten jest interesującym celem dla narzędzi próbujących pozyskać dane uwierzytelniające.
W starszym i mniej zabezpieczonym modelu atakujący, który uzyska odpowiedni poziom dostępu do systemu, może próbować pozyskiwać dane z pamięci procesów związanych z uwierzytelnianiem.
Współczesne zabezpieczenia Windows próbują ograniczyć tę możliwość poprzez izolację i ochronę procesów.
VBS tworzy dodatkową granicę
Credential Guard nie działa w próżni.
Jednym z fundamentów tej architektury jest VBS — Virtualization-Based Security.
VBS wykorzystuje sprzętową wirtualizację oraz hypervisor Windows do utworzenia izolowanego środowiska bezpieczeństwa.
Schemat można uprościć:
Hardware
│
▼
Hypervisor
│
├──────────────┐
▼ ▼
Windows VBS
│
├── Credential Guard
└── inne mechanizmy bezpieczeństwa
Na Netbe.pl dokładnie opisano VBS – Virtualization-Based Security w Windows, w tym jego związek z HVCI, Credential Guard, hypervisorem oraz izolacją VTL.
VBS nie jest antywirusem
To ważne rozróżnienie.
VBS nie zastępuje programu antywirusowego.
Nie skanuje plików w taki sposób jak Defender i nie jest mechanizmem wykrywania phishingu.
Jego zadaniem jest przede wszystkim izolacja i ochrona określonych elementów systemu.
Można więc traktować go jako warstwę architektoniczną:
Defender
+
VBS
+
Credential Guard
+
HVCI
+
Secure Boot
+
TPM
Każdy z tych mechanizmów rozwiązuje inny fragment problemu.
HVCI i ochrona integralności kodu
Drugim ważnym elementem VBS jest HVCI — Hypervisor-Protected Code Integrity.
Mechanizm ten ma chronić integralność kodu wykonywanego w krytycznych obszarach systemu.
W uproszczeniu:
Kod
│
▼
Code Integrity
│
├── zaufany → uruchom
│
└── niezgodny → zablokuj
VBS pozwala odizolować mechanizmy związane z integralnością kodu od zwykłego środowiska Windows.
To utrudnia atakującemu manipulowanie nimi po uzyskaniu wysokich uprawnień w systemie.
Pass-the-Hash a NTLM
Pass-the-Hash jest silnie związany z NTLM.
W uproszczeniu mechanizm NTLM wykorzystuje model challenge-response.
Serwer wysyła wyzwanie, a klient odpowiada na jego podstawie, wykorzystując odpowiedni materiał uwierzytelniający.
Problem pojawia się wtedy, gdy atakujący zdobędzie materiał umożliwiający wygenerowanie prawidłowej odpowiedzi.
Nie musi wtedy znać pierwotnego hasła.
Dlatego ograniczanie niepotrzebnego użycia NTLM jest jednym z elementów strategii ograniczania ryzyka Pass-the-Hash.
Kerberos nie oznacza końca problemu
W środowiskach Active Directory ważną rolę odgrywa Kerberos.
Nie oznacza to jednak, że po wdrożeniu Kerberos temat kradzieży poświadczeń znika.
Organizacje często posiadają starsze aplikacje, urządzenia lub scenariusze, w których nadal występuje NTLM.
Dlatego bezpieczeństwo należy oceniać na poziomie całej infrastruktury, a nie tylko jednego protokołu.
Jak ograniczyć ryzyko Pass-the-Hash?
Nie istnieje jeden przełącznik, który rozwiązuje cały problem.
W praktyce warto połączyć kilka mechanizmów.
Unikalne hasła administratorów lokalnych
Nie należy używać jednego hasła administratora lokalnego na wszystkich komputerach.
Automatyzacja za pomocą Windows LAPS ogranicza ten problem.
Minimalizacja uprawnień
Konto administratora powinno być używane tylko wtedy, gdy jest to rzeczywiście konieczne.
Credential Guard
W środowiskach, które go obsługują, warto rozważyć wdrożenie Credential Guard.
VBS
VBS zapewnia architekturę izolacji wykorzystywaną przez część nowoczesnych mechanizmów bezpieczeństwa Windows.
HVCI
Integralność kodu może być dodatkowo chroniona przez mechanizmy oparte na hypervisorze.
Ograniczenie NTLM
Tam, gdzie jest to technicznie możliwe i bezpieczne dla infrastruktury, warto ograniczać zależność od starszych mechanizmów uwierzytelniania.
Segmentacja sieci
Nawet jeżeli jedno urządzenie zostanie przejęte, nie powinno ono mieć nieograniczonego dostępu do całej infrastruktury.
Najważniejsza zasada: nie ufaj jednemu sekretowi
Cały problem Pass-the-Hash można sprowadzić do jednej zasady:
poświadczenia nie powinny być traktowane jako pojedynczy klucz otwierający całą infrastrukturę.
Jeżeli administrator używa tych samych danych na wielu komputerach, zakres potencjalnego ataku rośnie.
Jeżeli poświadczenia są unikalne, odpowiednio chronione i ograniczone uprawnieniami, przejęcie jednego urządzenia nie musi automatycznie oznaczać kompromitacji kolejnych.
To właśnie dlatego bezpieczeństwo Windows coraz bardziej opiera się na izolacji, segmentacji i ograniczaniu zaufania.
Pass-the-Hash a model Defense in Depth
Najbardziej rozsądny model wygląda mniej więcej tak:
Użytkownik
│
▼
Windows 11
│
┌─────────┴─────────┐
▼ ▼
Defender VBS
│
┌─────────┴─────────┐
▼ ▼
Credential Guard HVCI
│ │
└─────────┬─────────┘
▼
chronione środowisko
│
▼
ograniczone ryzyko
Jeżeli malware przełamie jedną warstwę, pozostałe nadal mogą ograniczyć jego możliwości.
To właśnie jest sens podejścia Defense in Depth.
Co sprawdzić w firmowej sieci?
Administrator powinien odpowiedzieć sobie na kilka prostych pytań:
- Czy lokalne konta administratorów mają unikalne hasła?
- Czy hasła są automatycznie rotowane?
- Kto może je odczytać?
- Czy administratorzy logują się na zwykłych stacjach roboczych?
- Czy Credential Guard jest aktywny?
- Czy VBS jest wykorzystywane?
- Czy HVCI jest skonfigurowane?
- Gdzie w środowisku nadal używany jest NTLM?
- Czy stacje robocze mogą bez ograniczeń komunikować się z serwerami?
- Czy nietypowe logowania są monitorowane?
Jeżeli odpowiedzi na kilka z tych pytań brzmią „nie wiemy”, problemem nie jest tylko Pass-the-Hash.
Problemem jest brak widoczności nad własnym środowiskiem.
Podsumowanie
Pass-the-Hash pokazuje, dlaczego samo pytanie „czy hasło jest wystarczająco silne?” jest niewystarczające.
Atakujący może próbować wykorzystać przejęty hash bez poznania hasła w jawnej postaci.
Dlatego ochrona powinna obejmować kilka poziomów:
unikalne poświadczenia → ograniczone uprawnienia → Credential Guard → VBS → HVCI → segmentacja → monitoring.
Szczególnie istotne jest wyeliminowanie wspólnych haseł lokalnych administratorów. Jeżeli ten sam sekret występuje na wielu komputerach, kompromitacja jednego urządzenia może ułatwić kolejne etapy ataku.
Właśnie dlatego bezpieczeństwo Windows nie powinno być budowane wokół pytania:
„Jak mocne jest nasze hasło?”
Lepsze pytanie brzmi:
„Co stanie się z całą siecią, jeżeli to hasło albo jego materiał uwierzytelniający zostanie przejęty?”
I to jest właściwy punkt wyjścia do projektowania ochrony przed Pass-the-Hash.







