Protected Users Group – specjalna grupa zabezpieczeń Active Directory przeciwko kradzieży poświadczeń

Współczesne ataki na środowiska Windows coraz rzadziej polegają na prostym łamaniu haseł. Znacznie częściej celem cyberprzestępców jest kradzież istniejących poświadczeń i wykorzystanie ich do poruszania się po sieci.

W Active Directory szczególnie cenne są konta:

• Domain Admin,
• administratorów serwerów,
• operatorów bezpieczeństwa,
• administratorów aplikacji.

Jeżeli atakujący zdobędzie dostęp do jednego z takich kont, może przejąć znaczną część infrastruktury.

Microsoft wprowadził mechanizm ograniczający ryzyko takich ataków:

Protected Users Security Group.

Jest to specjalna grupa Active Directory, która zmienia sposób uwierzytelniania należących do niej użytkowników i blokuje część starszych mechanizmów przechowywania oraz wykorzystywania poświadczeń.

Czym jest Protected Users Group?

Protected Users to wbudowana grupa zabezpieczeń Active Directory dostępna od:

• Windows Server 2012 R2,
• Windows 8.1.

Znajduje się w kontenerze:

Users
 └── Protected Users

Jej zadaniem jest zwiększenie ochrony kont uprzywilejowanych poprzez wymuszenie bardziej bezpiecznych metod uwierzytelniania.

Po dodaniu użytkownika do tej grupy system stosuje dodatkowe ograniczenia.

Nie jest to klasyczna grupa uprawnień.

Nie nadaje ona dostępu.

Nie daje administratorowi większych możliwości.

Jej działanie polega na ograniczeniu możliwości wykorzystania konta przez atakującego.

Dlaczego powstała grupa Protected Users?

Przez lata Active Directory było atakowane głównie przez techniki wykorzystujące przechowywane dane uwierzytelniające.

Przykłady:

• kradzież hashy NTLM,
• Pass-the-Hash,
• Pass-the-Ticket,
• wyciąganie poświadczeń z pamięci LSASS,
• wykorzystanie zapisanych haseł.

Typowy scenariusz:

1. Atakujący infekuje komputer administratora.
2. Uzyskuje dostęp do procesu LSASS.
3. Pobiera bilety Kerberos lub hashe NTLM.
4. Wykorzystuje je na innych komputerach.

Protected Users ogranicza część tych możliwości.

Jak działa Protected Users od strony technicznej?

Po dodaniu użytkownika do grupy system stosuje specjalne zasady:

• brak buforowania poświadczeń przy logowaniu,
• brak użycia NTLM,
• ograniczenia Kerberos,
• brak delegowania poświadczeń,
• wymuszenie silniejszych mechanizmów uwierzytelniania.

1. Wyłączenie NTLM

Jedną z najważniejszych zmian jest ograniczenie użycia NTLM.

Normalnie użytkownik może uwierzytelniać się:

• Kerberos,
• NTLM.

Po dodaniu do Protected Users:

preferowany i wymagany jest:

Kerberos

Dlaczego jest to ważne?

NTLM jest podatny między innymi na:

• Pass-the-Hash,
• NTLM Relay.

Przykład:

Zwykły użytkownik:

Logowanie SMB
        |
        ↓
Kerberos lub NTLM

Protected User:

Logowanie SMB
        |
        ↓
Kerberos

2. Brak przechowywania haseł w pamięci

Windows normalnie przechowuje pewne informacje uwierzytelniające w pamięci procesu LSASS.

Służy to między innymi do:

• szybkiego logowania,
• obsługi usług,
• funkcji jednokrotnego logowania.

Problem:

narzędzia takie jak Mimikatz potrafią próbować odzyskać te dane.

Protected Users ogranicza możliwość wykorzystania przechowywanych poświadczeń.

3. Ograniczenie Kerberos Delegation

Delegacja Kerberos pozwala usłudze działać w imieniu użytkownika.

Przykład:

Użytkownik:

Jan

łączy się z:

Serwer aplikacji

Serwer aplikacji może następnie uzyskać dostęp do:

SQL Server

w imieniu Jana.

To przydatna funkcja, ale niebezpieczna dla kont uprzywilejowanych.

Protected Users blokuje możliwość wykorzystania klasycznej delegacji.

4. Brak użycia starszych algorytmów szyfrowania

Konta Protected Users wymagają nowocześniejszych mechanizmów Kerberos.

Ograniczane są między innymi:

• DES,
• starsze warianty szyfrowania.

Protected Users a Kerberos

Grupa jest mocno związana z Kerberosem.

Wymagania:

• poprawny DNS,
• synchronizacja czasu,
• działający kontroler domeny,
• poprawne SPN.

Jeżeli środowisko ma problemy z Kerberos, użytkownik Protected Users może mieć problemy z logowaniem.

Praktyczny scenariusz – ochrona Domain Admin

Załóżmy:

Firma posiada konto:

admin.jan

które jest członkiem:

Domain Admins

Administrator dodaje konto do:

Protected Users

Efekt:

Atakujący infekuje komputer administratora.

Próbuje:

Mimikatz
sekurlsa::logonpasswords

Nie otrzymuje wartości, które mógłby łatwo wykorzystać.

Następnie próbuje:

Pass-the-Hash

NTLM jest niedostępny.

Próbuje:

Kerberos delegation abuse

delegacja jest ograniczona.

Konto jest znacznie trudniejsze do wykorzystania.

Kogo warto dodać do Protected Users?

Nie należy dodawać wszystkich użytkowników automatycznie.

Najczęściej:

Administratorzy domeny

Tak.

Przykłady:

• Domain Admins,
• Enterprise Admins,
• Schema Admins.

Administratorzy serwerów

Często tak.

Zwłaszcza:

• administratorzy produkcji,
• administratorzy baz danych,
• administratorzy infrastruktury.

Konta wysokiego ryzyka

Na przykład:

• osoby zarządzające bezpieczeństwem,
• administratorzy chmury,
• administratorzy backupów.

Kogo nie dodawać bez testów?

Ostrożność należy zachować dla:

Kont usługowych

Przykład:

svc_sql
svc_backup
svc_application

Mogą wymagać:

• delegacji,
• określonych metod uwierzytelniania.

Starych aplikacji

Starsze systemy mogą wymagać:

• NTLM,
• starszego Kerberos,
• zapisanych poświadczeń.

Protected Users a konta serwisowe

To częsty błąd projektowy.

Administrator widzi:

„Chcę chronić wszystkie ważne konta.”

Dodaje:

svc_database

do Protected Users.

Następnego dnia:

• aplikacja nie startuje,
• backup przestaje działać,
• monitoring traci dostęp.

Dlatego konta usług powinny być analizowane osobno.

Lepszym rozwiązaniem może być:

• gMSA (Group Managed Service Accounts),
• ograniczone uprawnienia,
• rotacja haseł.

Protected Users a Tiering administracyjny

Grupa bardzo dobrze uzupełnia model:

Active Directory Administrative Tiering.

Przykład:

Tier 0

Najważniejsze konta:

Domain Admin
Enterprise Admin

Zabezpieczenia:

• Protected Users,
• MFA,
• osobne stacje administracyjne.

Tier 1

Serwery:

• SQL,
• aplikacje,
• infrastruktura.

Tier 2

Komputery użytkowników.

Jak sprawdzić członków Protected Users?

PowerShell:

Get-ADGroupMember "Protected Users"

Dodanie użytkownika:

Add-ADGroupMember `
-Identity "Protected Users" `
-Members "admin.jan"

Usunięcie:

Remove-ADGroupMember `
-Identity "Protected Users" `
-Members "admin.jan"

Diagnostyka problemów

Jeżeli użytkownik po dodaniu do grupy nie może się logować, sprawdź:

Czy działa Kerberos?

klist

Czy istnieją bilety?

klist tickets

Czy komputer poprawnie widzi domenę?

nltest /dsgetdc:domain.local

Czy DNS działa?

nslookup domain.local

Protected Users kontra MFA

Protected Users nie zastępuje MFA.

To dwa różne poziomy ochrony.

Protected Users chroni przed:

• kradzieżą poświadczeń,
• wykorzystaniem hashy,
• wykorzystaniem biletów.

MFA chroni przed:

• użyciem samego hasła.

Najlepszy model:

Silne hasło
+
MFA
+
Protected Users
+
Tiering administracyjny

Najczęstsze błędy wdrożeniowe

Dodanie wszystkich administratorów bez testów

Może spowodować problemy ze starszymi systemami.

Brak osobnych kont administracyjnych

Zły model:

jan.kowalski
+
Domain Admin

Lepszy:

jan.kowalski
        |
konto zwykłe

jan.admin
        |
konto administracyjne Protected Users

Brak Kerberos w środowisku

Protected Users wymusza bardziej restrykcyjne uwierzytelnianie.

Najpierw trzeba naprawić:

• DNS,
• czas,
• SPN.

Podsumowanie

Protected Users Group jest jednym z najprostszych, ale jednocześnie bardzo skutecznych mechanizmów ochrony kont uprzywilejowanych w Active Directory.

Nie zwiększa uprawnień użytkownika.

Nie jest kolejną grupą administracyjną.

Jego zadaniem jest ograniczenie możliwości wykorzystania przejętego konta.

Najważniejsze efekty:

• ograniczenie NTLM,
• ochrona przed Pass-the-Hash,
• ograniczenie delegacji Kerberos,
• brak łatwego odzyskania poświadczeń,
• wymuszenie bezpieczniejszych metod uwierzytelniania.

W dobrze zabezpieczonym środowisku Windows Server konta administracyjne nie powinny działać wyłącznie dzięki silnym hasłom.

Powinny być dodatkowo chronione przez mechanizmy takie jak:

Protected Users, MFA, LAPS, tiering administracyjny oraz kontrola dostępu.

Polecane wpisy

Serwer certyfikatów (AD CS) w Windows Server: Wdrażanie infrastruktury klucza publicznego (PKI)

Serwer certyfikatów (AD CS) w Windows Server: Wdrażanie infrastruktury klucza publicznego (PKI) 🎯 Cel artykułu Celem tego przewodnika jest przedstawienie kompletnego Czytaj dalej

Jak konfigurować i zarządzać strefami DNS oraz zakresami DHCP w Active Directory

Jak konfigurować i zarządzać strefami DNS oraz zakresami DHCP w Active Directory Wstęp W każdej sieci komputerowej opartej na systemie Czytaj dalej