Koniec czerwca 2017 r. Został zapamiętany przez społeczność IT za masową infekcję wielu największych firm i agencji rządowych w Rosji, na Ukrainie i innych krajach nowym wirusem ransomware Petya (NotPetya). W większości przypadków po penetracji sieci korporacyjnej Petya natychmiast rozprzestrzenia się na wszystkie komputery i serwery domen, paraliżując do 70-100% całej infrastruktury Windows. Chociaż jedną z metod dystrybucji Petyi między komputerami w sieci było wykorzystanie exploita EternalBlue (tak jak w przypadku WannaCry), nie był to główny kanał dystrybucji oprogramowania ransomware. W przeciwieństwie do WCry, który był dystrybuowany wyłącznie z powodu luk w SMBv1, NotPetya był pierwotnie więziony dla sieci korporacyjnych. Po zainfekowaniu systemu program szyfrujący wykorzystujący publiczne narzędzie Mimikatz otrzymał poświadczenia (hasła, skróty) użytkowników komputerów i wykorzystał je do dalszej dystrybucji w sieci za pomocą WMI i PsExec, aż do pełnej kontroli nad domeną. W związku z tym, aby chronić wszystkie systemy, nie wystarczyło zainstalować aktualizację MS17-010.
W tym artykule omówimy podstawowe metody ochrony systemów Windows w domenie Active Directory przed atakami przy użyciu narzędzi podobnych do Mimikatz..
Utility Mimikatz za pomocą modułu sekurlsa umożliwia wyodrębnianie haseł i skrótów autoryzowanych użytkowników przechowywanych w systemowej pamięci procesowej LSASS.EXE (Usługa lokalnego podsystemu bezpieczeństwa ) Mieliśmy już artykuł z przykładem użycia mimikatz do uzyskania haseł użytkowników w postaci zwykłego tekstu (od WDigest, LiveSSP i SSP).
Treść
- Zapobiegaj debugowaniu
- Wyłączanie WDigest
- Ochrona LSA przed modułami stron trzecich
- Wyłączanie LM i NTLM
- Zakaz stosowania szyfrowania odwracalnego
- Korzystanie z grupy chronionych użytkowników
- Nie używaj zapisanych haseł
- Odmów buforowania poświadczeń
- Strażnik poświadczeń
- Wnioski
Zapobiegaj debugowaniu
Artykuł z powyższego łącza pokazuje, w jaki sposób korzystanie z uprawnienia do debugowania pozwala Mimikatz uzyskać dostęp do procesu systemowego LSASS i wyodrębnić z niego hasła.
Domyślnie uprawnienia do trybu debugowania są przyznawane lokalnej grupie administratorów (BUILTIN \ Administrators). Chociaż w 99% przypadków to uprawnienie absolutnie nie jest używane przez administratorów (jest zwykle potrzebne programistom systemowym), w związku z tym, ze względów bezpieczeństwa, możliwość korzystania z uprawnień SeDebugPrivilege lepiej Odbywa się to poprzez zasady grupy (lokalne lub domeny). Przejdź do sekcji Konfiguracja komputera -> Ustawienia systemu Windows -> Ustawienia zabezpieczeń -> Zasady lokalne -> Przypisywanie praw użytkownika i włącz zasady Program debugowania. W nim musisz dodać grupę domen użytkowników, którzy mogą potrzebować praw do debugowania (zwykle programiści), lub pozostaw tę grupę pustą, aby nikt nie miał tego prawa.
Teraz, jeśli spróbujesz uruchomić debugowanie przez mimikatz, pojawi się błąd:
EROOR kuhl_m_privilege_simple; RtlAdjustPrivilege (20) c0000061
Wyłączanie WDigest
Protokół WDigest pojawił się w systemie Windows XP i był używany do przeprowadzania uwierzytelniania szyfrowanego HTTP (HTTP Digest Authentication), którego funkcją było używanie hasła użytkownika w przejrzystej formie. Windows 8.1 i Server 2012 R2 dodały możliwość całkowitego zakazania przechowywania haseł w postaci jawnego tekstu w LSASS. Aby zabronić przechowywania WDigest w pamięci, w tych systemach operacyjnych w gałęzi rejestru HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest istnieje już parametr DWORD32 o nazwie UseLogonCredential i wartość 0.
Jeśli chcesz całkowicie wyłączyć metodę uwierzytelniania WDigest, w tym samym oddziale (HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest) ustaw wartość klucza Negocjuj w 0.
Aby obsługiwać tę funkcję w systemach Windows 7, 8 i Windows Server 2008 R2 / 2012, musisz zainstalować specjalną aktualizację - KB2871997, a następnie ustawić te same klucze rejestru. W środowisku domeny ustawienia rejestru są najłatwiejsze do rozpowszechnienia przy użyciu zasad grupy.
Ochrona LSA przed modułami stron trzecich
Systemy Windows 8.1 i Windows Server 2012 R2 wprowadziły możliwość włączenia ochrony LSA, która chroni pamięć LSA i zapobiega możliwości łączenia się z nią przed niebezpiecznymi procesami. Aby włączyć tę ochronę, musisz w gałęzi rejestru HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA utwórz parametr RunAsPPL z wartością 1.
Po zastosowaniu tego parametru atakujący nie będzie mógł uzyskać dostępu do pamięci LSA, a mimikatz wyświetli błąd w poleceniu securlsa :: logonpassword
BŁĄD kuhl_m_securlsa_acquireLSA: Uchwyt pamięci (0x00000005).
Wyłączanie LM i NTLM
Nieaktualny protokół uwierzytelniania LM i odpowiednio przechowywanie skrótów LM należy wyłączyć za pomocą zasad grupy Network Security: Nie przechowuj wartości skrótu menedżera sieci LAN przy następnej zmianie hasła (na poziomie domyślnych zasad domeny).
Następnie musisz zrezygnować z użycia co najmniej protokołu NTLMv1 (zasada w obszarze Konfiguracja komputera -> Zasady -> Ustawienia systemu Windows -> Ustawienia zabezpieczeń -> Zasady lokalne -> Opcje zabezpieczeń - Zabezpieczenia sieci: Ogranicz NTLM: uwierzytelnianie NTLM w tej domenie), oraz jako maksimum i NTLMv2
A jeśli odrzucenie NTLMv1 jest zwykle bezbolesne, to odrzucenie NTLMv2 będzie musiało ciężko pracować. W dużych infrastrukturach z reguły dochodzi do scenariusza maksymalnego ograniczenia użycia NTLMv2. Tj. tam, gdzie to możliwe, należy stosować uwierzytelnianie Kerberos (z reguły wymagany będzie dodatkowy czas na skonfigurowanie uwierzytelniania Kerberos w IIS i SQL), a w pozostałych systemach - NTLMv2.
Zakaz stosowania szyfrowania odwracalnego
Należy wyraźnie zabronić przechowywania haseł użytkowników w AD w formie tekstowej. Aby to zrobić, włącz zasady domeny Przechowuj hasło przy użyciu odwracalnego szyfrowania dla wszystkich użytkowników w domenie w Konfiguracja komputera -> Ustawienia systemu Windows -> Ustawienia zabezpieczeń -> Zasady konta -> Zasady hasła, ustawiając jego wartość na Wyłączone.
Korzystanie z grupy chronionych użytkowników
Podczas korzystania z poziomu funkcjonalności domeny Windows Server 2012 R2 możliwe jest użycie specjalnej grupy chronionej Użytkownicy chronieni w celu ochrony użytkowników uprzywilejowanych. W szczególności konta te są chronione przed zagrożeniem ze względu na fakt, że członkowie tej grupy mogą logować się tylko za pośrednictwem Kerberos (bez NTLM, WDigest i CredSSP) itp. (szczegóły na powyższy link). Zaleca się dodanie do tej grupy kont administratorów domen, serwerów itp. Ta funkcja działa na serwerach i będzie działać w systemie Windows Server 2012 R2 (w przypadku systemu Windows Server 2008 R2 należy zainstalować dodatkową aktualizację wspomnianą powyżej KB2871997)
Nie używaj zapisanych haseł
Możesz uniemożliwić użytkownikom domeny zapisywanie ich haseł w celu uzyskania dostępu do zasobów sieciowych w Credential Manager.
Aby to zrobić, włącz zasadę Dostęp sieciowy: nie zezwalaj na przechowywanie haseł i poświadczeń do uwierzytelniania sieciowego w obszarze Konfiguracja komputera -> Ustawienia systemu Windows -> Ustawienia zabezpieczeń -> Zasady lokalne -> Opcje bezpieczeństwa.
Odmów buforowania poświadczeń
Jedną z funkcji mimikats jest uzyskanie skrótu haseł użytkowników z oddziału rejestru HKEY_LOCAL_MACHINE \ SECURITY \ Cache, w którym przechowywane są skróty haseł ostatnich 10 (domyślnie) zalogowanych użytkowników domeny. Tych skrótów można zwykle użyć do autoryzacji użytkowników w systemie, gdy kontroler domeny jest niedostępny.
Zaleca się zakazać przechowywania danych w pamięci podręcznej przez włączenie zasad Interactive Logowanie: Liczba z poprzedni loginy do pamięć podręczna (w skrzynka domena kontroler jest nie dostępne) w obszarze Konfiguracja komputera -> Ustawienia systemu Windows -> Zasady lokalne -> Opcje zabezpieczeń, zmieniając wartość jego parametru na 0.
Ponadto, aby przyspieszyć czyszczenie pamięci procesu lsass z kont użytkowników, którzy zakończyli sesję, musisz to zrobić w oddziale HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa musisz utworzyć klucz DWORD o nazwie TokenLeakDetectDelaySecs i wartość 30. Tj. pamięć zostanie wyczyszczona 30 sekund po logo użytkownika. W systemie Windows 7, 8 / Server 2008R2, 2012, aby ten klucz działał, należy zainstalować wspomnianą wcześniej aktualizację KB2871997.
Strażnik poświadczeń
W Windows 10 Enterprise, Windows Server 2016, dodano nowy składnik Credential Guard w celu odizolowania i ochrony procesu systemowego LSASS przed nieautoryzowanym dostępem. Szczegóły tutaj.
Wnioski
Omówione powyżej środki znacznie ograniczą możliwości mimikatz i podobnych narzędzi do uzyskiwania haseł i skrótów administratorów z procesu LSASS i rejestru. W każdym razie przy podejmowaniu decyzji o wdrożeniu tych zasad i metod należy je wprowadzać etapami z obowiązkowymi testami..
W następnym artykule omówimy najlepsze praktyki poprawy bezpieczeństwa sieci Windows poprzez ograniczenie korzystania z kont administratora, które na poziomie technicznym i organizacyjnym powinny poprawić ochronę domeny Windows przed takimi atakami. Bądź na bieżąco!
