Windows 11 nie ufa nawet administratorowi. Jak Protected Process Light chroni najważniejsze procesy systemu
Windows 11 nie ufa nawet administratorowi. Jak Protected Process Light chroni najważniejsze procesy systemu
Windows przez lata opierał bezpieczeństwo procesów głównie na klasycznym modelu uprawnień.
Masz konto.
Masz grupy.
Masz token dostępu.
Masz określone przywileje.
Proces dziedziczy kontekst bezpieczeństwa.
Administrator może więcej niż zwykły użytkownik.
SYSTEM może jeszcze więcej.
Problem pojawia się wtedy, gdy atakujący już został administratorem.
W tym momencie klasyczny model zaczyna się robić niewygodny.
Jeżeli proces ma odpowiednie uprawnienia, może próbować otwierać inne procesy, uzyskiwać uchwyty, odczytywać ich pamięć, manipulować wątkami albo kończyć procesy.
A co, jeśli system bezpieczeństwa musi działać nawet wtedy, gdy zwykłe konto administratora jest już skompromitowane?
Microsoft odpowiedział na ten problem mechanizmem Protected Process Light — PPL.
To jedna z ciekawszych granic bezpieczeństwa współczesnego Windows 11.
Administrator nie oznacza pełnej kontroli nad każdym procesem
W uproszczonym modelu można założyć:
USER
↓
STANDARD
↓
ADMINISTRATOR
↓
SYSTEM
Im wyżej, tym większe możliwości.
PPL wprowadza dodatkową warstwę.
Możemy myśleć o niej tak:
WINDOWS
│
┌──────────────┴──────────────┐
│ │
normal processes protected processes
│ │
Administrator PPL
SYSTEM LSA / Security
│ │
└──────────────┬──────────────┘
│
stricter access
Proces chroniony nie jest po prostu kolejnym procesem uruchomionym jako SYSTEM.
Windows traktuje go według dodatkowego poziomu ochrony.
To fundamentalna różnica.
Czym właściwie jest PPL?
Protected Process Light jest mechanizmem ochrony procesu.
Microsoft udostępnia strukturę PROCESS_PROTECTION_LEVEL_INFORMATION, która pozwala określić poziom ochrony procesu. Wśród zdefiniowanych poziomów znajdują się m.in.:
PROTECTION_LEVEL_NONE
PROTECTION_LEVEL_LSA_LIGHT
PROTECTION_LEVEL_ANTIMALWARE_LIGHT
PROTECTION_LEVEL_WINDOWS_LIGHT
PROTECTION_LEVEL_PPL_APP
Nie wszystkie poziomy są przeznaczone do dowolnego wykorzystania przez aplikacje.
Nie chodzi również o to, że każdy program może po prostu ustawić sobie PPL.
Windows wiąże ochronę z modelem zaufania i odpowiednim poziomem podpisywania komponentów.
To bardzo ważne.
PPL nie jest zwykłą opcją:
Protected = TRUE
którą developer włącza w konfiguracji.
Po co w ogóle chronić proces?
Wyobraźmy sobie klasyczny scenariusz.
Atakujący uruchamia malware:
malware.exe
│
▼
Administrator
│
▼
próba otwarcia procesu bezpieczeństwa
│
▼
odczyt pamięci / manipulacja
Jeżeli proces bezpieczeństwa zachowuje się jak zwykły proces, atakujący posiadający wystarczające uprawnienia może próbować wejść z nim w interakcję.
To jest dokładnie ten problem, który PPL ma ograniczać.
Microsoft w dokumentacji dotyczącej bezpieczeństwa sterowników zwraca uwagę, że procesy chronione i PPL, w tym procesy używane przez rozwiązania antymalware, nie powinny być możliwe do arbitralnego zakończenia przez sterownik. Udostępnienie sterownikowi takiej funkcji może umożliwić atakującemu wyłączenie ochrony.
Czyli:
PPL nie ma przede wszystkim utrudniać życia użytkownikowi.
Ma utrudnić życie kodowi, który próbuje manipulować komponentem bezpieczeństwa.
PPL i LSASS
Najbardziej interesującym przykładem jest Local Security Authority.
LSASS:
lsass.exe
jest jednym z najważniejszych procesów Windows odpowiedzialnych za bezpieczeństwo logowania i mechanizmy uwierzytelniania.
Jeżeli atakujący może bez ograniczeń manipulować LSASS, sytuacja robi się bardzo zła.
Dlatego Windows może uruchamiać LSA jako chroniony proces.
W modelu:
WINDOWS 11
│
▼
lsass.exe
│
▼
LSA Protection
│
▼
PPL
│
┌───────┴────────┐
│ │
access checks signing
│ │
└───────┬────────┘
▼
protected process
PPL nie oznacza jednak, że LSASS staje się całkowicie nietykalny.
To dodatkowa granica bezpieczeństwa.
A granica bezpieczeństwa może mieć własne błędy.
PPL a Credential Guard
Tutaj łatwo pomylić dwie technologie.
PPL ≠ Credential Guard.
To różne mechanizmy.
Można to przedstawić tak:
Windows 11
│
├── LSA Protection / PPL
│ └── chroni proces LSA
│
└── VBS
└── Credential Guard
└── izoluje określone sekrety
PPL chroni proces i ogranicza interakcję z nim.
Credential Guard wykorzystuje VBS do izolowania określonych danych uwierzytelniających.
W efekcie mamy dwie różne warstwy.
To ważne, ponieważ kompromitacja jednego mechanizmu nie powinna automatycznie oznaczać kompromitacji całego modelu bezpieczeństwa.
PPL nie zastępuje VBS
Można spotkać się z błędnym założeniem:
„Mam VBS, więc PPL jest zbędne.”
Nie.
To różne mechanizmy.
VBS wykorzystuje hypervisor i izolowane środowisko bezpieczeństwa.
PPL dotyczy ochrony procesu.
W praktyce współczesny Windows 11 buduje bezpieczeństwo z wielu warstw:
UEFI
│
Secure Boot
│
▼
Windows Boot
│
▼
Hypervisor / VBS
│
├──────────────┐
│ │
HVCI Credential Guard
│ │
└───────┬──────┘
│
Windows
│
PPL / LSA
│
Defender / EDR
│
Applications
Nie jest to jeden mur.
To zestaw granic.
Dlaczego zwykły Administrator nie powinien móc wszystkiego?
Bo administrator jest nadal częścią środowiska operacyjnego.
Jeżeli użytkownik kliknie złośliwy dokument, uruchomi malware, a malware odziedziczy jego kontekst, system nie powinien zakładać:
ADMIN = TRUST EVERYTHING
Właśnie dlatego Windows wykorzystuje między innymi:
- access tokens,
- integrity levels,
- UAC,
- ACL,
- PPL,
- LSA Protection,
- VBS,
- HVCI,
- WDAC,
- Defender.
Każdy mechanizm odpowiada na inny problem.
Microsoft opisuje access token jako obiekt określający kontekst bezpieczeństwa procesu lub wątku. Token zawiera m.in. SID użytkownika, członkostwo w grupach i informacje o przywilejach.
PPL dodaje kolejny wymiar:
nie tylko „kim jesteś?”, ale również „jaki jest poziom ochrony procesu, z którym próbujesz się komunikować?”
Integrity Level to jeszcze inna warstwa
Windows posiada również Mandatory Integrity Control.
Proces może działać na poziomie:
Low
Medium
High
System
W uproszczeniu:
Low
│
├── ograniczony
│
▼
Medium
│
▼
High
│
▼
System
Microsoft opisuje integralność jako dodatkowy mechanizm ograniczający możliwość modyfikowania obiektów o wyższym poziomie integralności. Proces o niższej integralności nie powinien po prostu zapisywać do obiektów znajdujących się wyżej.
Ale PPL to nie to samo.
Możemy mieć:
Integrity Level
+
Access Token
+
Privileges
+
PPL
i dopiero ich kombinacja opisuje rzeczywisty kontekst procesu.
Najciekawszy problem: handle do procesu
Windows wykorzystuje uchwyty — handles — do komunikacji z obiektami systemowymi.
Proces może próbować uzyskać uchwyt do innego procesu z określonymi prawami.
Przykładowo:
Process A
│
│ OpenProcess()
▼
Process B
W normalnej sytuacji kernel sprawdza, czy żądane prawa są dopuszczalne.
Można więc próbować:
PROCESS_VM_READ
PROCESS_VM_WRITE
PROCESS_VM_OPERATION
PROCESS_TERMINATE
PROCESS_DUP_HANDLE
Problem polega na tym, że proces bezpieczeństwa nie może być traktowany tak samo jak zwykły proces.
Jeżeli złośliwy kod otrzyma możliwość:
PROCESS_TERMINATE
dla procesu ochronnego, może próbować po prostu go zakończyć.
Jeżeli otrzyma możliwość manipulowania jego pamięcią, sytuacja jest jeszcze gorsza.
Dlatego mechanizmy ochrony procesów mają znaczenie nawet wtedy, gdy atakujący ma już bardzo wysoki poziom uprawnień.
Sterownik kernel-mode zmienia reguły gry
Tutaj dochodzimy do najważniejszego problemu.
PPL nie może być analizowany wyłącznie z perspektywy user-mode.
Kernel-mode jest innym światem.
Sterownik działa z bardzo wysokimi uprawnieniami.
Jeżeli sterownik ma błąd, może udostępnić użytkownikowi niebezpieczne operacje:
user-mode malware
│
▼
vulnerable driver
│
▼
kernel-mode
│
▼
security boundary
│
▼
protected process
Dlatego BYOVD jest tak poważnym problemem.
Atakujący nie musi znaleźć błędu bezpośrednio w PPL.
Może próbować znaleźć słaby sterownik, który posiada niebezpieczne możliwości.
Microsoft jako przykłady niebezpiecznych zachowań sterowników wymienia m.in.:
- odczyt/zapis MSR,
- kończenie dowolnych procesów,
- dostęp do portów I/O,
- odczyt i zapis pamięci kernela,
- dostęp do pamięci fizycznej.
To pokazuje coś fundamentalnego:
najlepsza ochrona procesu nie pomoże, jeśli inny uprzywilejowany komponent dostanie zbyt szerokie możliwości manipulowania systemem.
PPL jest więc elementem większej granicy zaufania
Możemy narysować to tak:
USER MODE
│
┌───────▼───────┐
│ Malware │
└───────┬───────┘
│
Access Token
│
┌───────▼───────┐
│ UAC / MIC │
└───────┬───────┘
│
Process Access
│
┌───────▼───────┐
│ PPL │
└───────┬───────┘
│
LSA / AV
│
────────┼────────
│
KERNEL MODE
│
┌───────▼───────┐
│ Drivers │
└───────┬───────┘
│
HVCI / CI / VBS
│
▼
HARDWARE
Jeżeli malware zostanie zatrzymane na pierwszej warstwie — świetnie.
Jeżeli przejdzie przez UAC — pozostaje PPL.
Jeżeli próbuje wykorzystać sterownik — pojawia się HVCI, Code Integrity i polityka sterowników.
Jeżeli próbuje zaatakować poświadczenia — może napotkać Credential Guard.
To właśnie jest defense in depth.
Jak sprawdzić, czy system korzysta z ochrony LSA?
Windows udostępnia informacje dotyczące konfiguracji LSA Protection.
W praktycznym audycie warto sprawdzić przede wszystkim:
Windows Security
→ Device security
→ Local Security Authority protection
oraz informacje systemowe:
msinfo32
W środowisku firmowym stan ochrony powinien być dodatkowo monitorowany centralnie.
Nie wystarczy założyć, że:
„To jest Windows 11, więc na pewno wszystko jest włączone.”
Konfiguracja zależy od wersji systemu, sprzętu, polityk organizacji i historii aktualizacji.
PowerShell i diagnostyka
Do podstawowego audytu procesów można wykorzystać PowerShell:
Get-Process |
Sort-Object ProcessName |
Select-Object ProcessName, Id
Bardziej zaawansowana analiza powinna korzystać z narzędzi Sysinternals i mechanizmów diagnostycznych Windows.
Szczególnie interesujące są:
Process Explorer
Process Monitor
Autoruns
WinDbg
Event Viewer
Windows Defender / MDE telemetry
Code Integrity logs
Nie chodzi o to, aby administrator codziennie ręcznie analizował każdy proces.
Chodzi o możliwość odpowiedzi na pytanie:
czy proces, który powinien być chroniony, rzeczywiście jest chroniony?
PPL a EDR
To również ciekawy przypadek.
EDR musi obserwować system.
Jednocześnie sam staje się komponentem, który powinien być trudny do wyłączenia przez malware.
Dlatego rozwiązania bezpieczeństwa mogą wykorzystywać mechanizmy ochrony procesów.
Schemat:
Malware
│
├── próba zatrzymania EDR
│
├── próba otwarcia procesu
│
├── próba manipulacji pamięcią
│
└── próba wykorzystania sterownika
│
▼
Windows Security Model
│
┌─────┴─────┐
│ │
PPL HVCI
│ │
└─────┬─────┘
▼
Security Stack
To bardzo ważny trend.
Antywirus nie może być tylko programem, który skanuje pliki.
Musi również być trudny do wyłączenia przez już działające malware.
Czy PPL jest nie do obejścia?
Nie.
I tutaj trzeba zachować precyzję.
PPL jest mechanizmem ochronnym, a nie dowodem matematycznym, że proces jest nietykalny.
Możliwe klasy problemów obejmują:
podatność w kernelu
podatny sterownik
błąd w implementacji ochrony
błąd w zaufaniu do podpisu
kompromitację boot chain
błąd w komponencie security
Dlatego nie należy pisać:
„PPL uniemożliwia atakującemu dostęp do LSASS.”
Lepsze stwierdzenie brzmi:
PPL znacząco ogranicza możliwość uzyskania niepożądanego dostępu do chronionego procesu i utrudnia klasyczne techniki manipulacji procesem.
To jest różnica między marketingiem a analizą techniczną.
Dlaczego PPL jest ważniejszy, niż wygląda?
Bo pokazuje ewolucję modelu bezpieczeństwa Windows.
Stary model:
permissions
↓
administrator
↓
system
Nowy model:
identity
↓
access token
↓
integrity level
↓
privileges
↓
UAC
↓
process protection
↓
VBS
↓
HVCI
↓
kernel security
↓
hardware trust
Microsoft nie zakłada już, że jedna warstwa wystarczy.
To dobra wiadomość.
Atakujący również nie mają jednego celu.
Dlatego Windows potrzebuje wielu niezależnych granic.
PPL kontra klasyczny model „Administrator”
To chyba najlepszy sposób na zrozumienie całego mechanizmu.
Administrator:
ADMINISTRATOR
│
├── access token
├── privileges
├── groups
└── elevated processes
PPL:
PROTECTED PROCESS
│
├── access restrictions
├── protection level
├── signing trust
└── restricted process interaction
Administrator określa kto działa.
PPL określa dodatkowo jak bardzo chroniony jest proces.
To dwie różne osie bezpieczeństwa.
Co powinien zrobić administrator Windows 11?
Nie należy próbować „włączać wszystkiego” bez zrozumienia zależności.
Lepszy model:
1. Nie pracuj stale na pełnym koncie administracyjnym
UAC powinno pozostać aktywne.
Microsoft wskazuje, że UAC ogranicza możliwość uruchamiania kodu z pełnymi uprawnieniami administratora bez interakcji użytkownika.
2. Włącz ochronę LSA tam, gdzie jest wymagana
Szczególnie w środowiskach biznesowych.
3. Nie lekceważ sterowników
Sterownik jest częścią kernel attack surface.
4. Utrzymuj HVCI i VBS
Jeżeli kompatybilność środowiska na to pozwala.
5. Kontroluj Code Integrity
Nie chodzi wyłącznie o antywirusa.
Chodzi o to, jaki kod może zostać uruchomiony.
6. Monitoruj procesy bezpieczeństwa
EDR powinien wykrywać próby manipulowania procesami ochronnymi.
7. Nie traktuj SYSTEM jako „końca bezpieczeństwa”
To szczególnie ważne.
Uzyskanie SYSTEM to ogromny problem.
Ale współczesny Windows posiada dodatkowe granice, które mają ograniczać skutki kompromitacji normalnego środowiska.
Najważniejsza lekcja
Protected Process Light jest ciekawy nie dlatego, że jest kolejną funkcją Windows.
Jest ciekawy dlatego, że pokazuje zmianę całej filozofii bezpieczeństwa.
Windows 11 nie może już zakładać:
Administrator = pełne zaufanie
Bo współczesne ataki często zaczynają się od:
browser
↓
user process
↓
malware
↓
privilege escalation
↓
SYSTEM
A następnie próbują:
SYSTEM
↓
disable security
↓
dump credentials
↓
tamper with EDR
↓
kernel / driver
PPL próbuje postawić dodatkową granicę właśnie pomiędzy:
SYSTEM
a:
najbardziej wrażliwym procesem bezpieczeństwa
To bardzo ważny element współczesnej architektury Windows.
Podsumowanie
Windows 11 nie opiera bezpieczeństwa wyłącznie na użytkownikach, grupach i ACL.
System wykorzystuje wiele niezależnych mechanizmów:
WINDOWS 11 SECURITY
Hardware
│
Secure Boot
│
VBS
│
HVCI
│
Kernel CI
│
┌──────────┴──────────┐
│ │
PPL LSA
│ │
└──────────┬──────────┘
│
Access Tokens
│
UAC
│
User Apps
PPL nie zastępuje VBS.
Nie zastępuje HVCI.
Nie zastępuje Credential Guard.
Nie zastępuje Defendera.
I nie zastępuje poprawnej konfiguracji uprawnień.
Jego wartość polega na czymś innym:
dodaje kolejną granicę między skompromitowanym środowiskiem Windows a procesami, których atakujący nie powinien móc swobodnie manipulować.
Właśnie tak powinno wyglądać bezpieczeństwo systemu operacyjnego w 2026 roku.
Nie jeden wielki mur.
Wiele małych granic, które atakujący musi przełamać jedna po drugiej.
Autor
Marek „Netbe” Lampart — Inżynier Informatyki
Ponad 25 lat doświadczenia w systemach Windows i Linux, administracji, bezpieczeństwie IT oraz analizie mechanizmów ochrony systemów operacyjnych.
Źródła techniczne
- Microsoft Learn — Protected Process Light i
PROCESS_PROTECTION_LEVEL_INFORMATION. - Microsoft Learn — najlepsze praktyki bezpieczeństwa sterowników kernel-mode.
- Microsoft Learn — Access Tokens.
- Microsoft Learn — Mandatory Integrity Control.
- Microsoft Learn — User Account Control i mechanizm podnoszenia uprawnień.
Dlaczego warto znać narzędzia diagnostyczne wbudowane w Windows 11 Windows 11 — jak wcześniejsze wersje — zawiera kilka wbudowanych narzędzi Czytaj dalej
Problemy z uruchamianiem aplikacji w Windows 11: Od błędów zgodności po uszkodzone pliki 🧠 Wprowadzenie: Dlaczego aplikacje przestają działać w Czytaj dalej
