Udostępnij za pośrednictwem

Jak odzyskać po ataku Golden gMSA

  • Artykuł

W tym artykule opisano podejście do naprawiania poświadczeń konta usługi zarządzanego przez grupę (gMSA), które mają wpływ na zdarzenie ujawnienia bazy danych kontrolera domeny.

Symptomy

Aby uzyskać opis ataku Golden gMSA, zobacz następujący artykuł Semperis:

Wprowadzenie do ataku Golden GMSA

Opis w powyższym artykule jest dokładny. Podejściem do rozwiązania problemu jest zastąpienie obiektu klucza głównego usługi dystrybucji kluczy firmy Microsoft (kdssvc.dll, znanej również jako KDS) i wszystkich gMSA korzystających z naruszonego obiektu klucza głównego KDS.

Więcej informacji

W przypadku pomyślnego ataku na gMSA atakujący uzyskuje wszystkie ważne atrybuty obiektu klucza głównego KDS i Sid msds-ManagedPasswordID atrybuty obiektu gMSA.

Atrybut msds-ManagedPasswordID jest obecny tylko na zapisywalnej kopii domeny. W związku z tym, jeśli baza danych kontrolera domeny jest uwidoczniona, tylko domena, którą hostuje kontroler domeny, jest otwarta dla ataku Golden gMSA. Jeśli jednak osoba atakująca może uwierzytelnić się na kontrolerze domeny innej domeny w lesie, osoba atakująca może mieć wystarczające uprawnienia, aby uzyskać zawartość msds-ManagedPasswordID. Osoba atakująca może następnie użyć tych informacji do utworzenia ataku na konta gMSA w dodatkowych domenach.

Aby chronić dodatkowe domeny lasu po ujawnieniu jednej domeny, należy zastąpić wszystkie zarządzane konta w domenie uwidocznionej, zanim osoba atakująca będzie mogła użyć tych informacji. Zazwyczaj nie znasz szczegółów tego, co zostało ujawnione. W związku z tym zaleca się zastosowanie rozwiązania do wszystkich domen lasu.

Jako środek proaktywny inspekcja może służyć do śledzenia ujawnienia obiektu klucza głównego KDS. Listę kontroli dostępu systemu (SACL) z pomyślnymi odczytami można umieścić w kontenerze Główne klucze główne, co umożliwia inspekcję pomyślnych operacji odczytu atrybutu msKds-RootKeyData msKds-ProvRootKey klasy. Ta akcja określa poziom ekspozycji obiektu w odniesieniu do ataku Golden gMSA.

Uwaga 16.

Inspekcja pomaga wykrywać tylko atak online na dane klucza głównego KDS.

Możesz rozważyć ustawienie parametru ManagedPasswordIntervalInDays na 15 dni lub wybranie odpowiedniej wartości podczas tworzenia konta zarządzanego przez użytkownika, ponieważ ManagedPasswordIntervalInDays wartość staje się tylko do odczytu po utworzeniu konta zarządzanego przez grupy.

W przypadku naruszenia zabezpieczeń to ustawienie może skrócić czas następnego kroczenia.

Zmniejszy teoretyczną liczbę gMSA, która ma zostać ponownie utworzona między datą przywrócenia kopii zapasowej a końcem ekspozycji bazy danych, a przynajmniej okresem trwania okna ryzyka do czasu wprowadzania tych gMSAs, jeśli trzymasz się scenariusza 1.

Oto przykładowy scenariusz:

  1. Po ekspozycji bazy danych należy wykonać odzyskiwanie w ciągu "Dzień D".

  2. Przywrócona kopia zapasowa pochodzi z D-15.

    Uwaga 16.

    D-15 oznacza dzień, który jest 15 dni przed "Dzień D".

  3. Wartość gMSA ManagedPasswordIntervalInDays wynosi 15.

  4. GMSA istnieją i zostały zwinięte D-1.

  5. Nowsze konta zasad grupy zostały utworzone na podstawie D-10.

  6. Naruszenie zabezpieczeń odbywa się na D-5, a niektóre gMSA zostały utworzone w tej dacie.

Oto wyniki:

  1. GMSA utworzone między D i D-5 nie są zainteresowane*.

  2. Grupy gMSA utworzone między D-15 (przywrócona kopia zapasowa) i D-5 (naruszenie)* muszą zostać utworzone ponownie lub należy przyjąć, że okna ryzyka można oczekiwać z D+5 do D+10. Na przykład:

    • W systemie D+5 należy ponownie utworzyć konta zasad grupy utworzone na serwerze D-10.
    • W systemie D+10 należy ponownie utworzyć konta gMS utworzone na serwerze D-5.

    *Zależy od dokładnego czasu naruszenia lub utworzenia kopii zapasowej.

Oto przykładowa oś czasu:

Diagram przedstawiający przykładową oś czasu gMSAs.

W celu debugowania można przejrzeć identyfikatory zdarzeń systemu, zabezpieczeń, usług katalogowych i dziennika zdarzeń Security-Netlogon.

Aby uzyskać więcej informacji na temat naruszenia zabezpieczeń, zobacz Używanie zasobów zabezpieczeń firmy Microsoft i platformy Azure w celu ułatwienia odzyskiwania po naruszeniu bezpieczeństwa tożsamości systemowej.

Rozwiązanie

Aby rozwiązać ten problem, użyj jednej z następujących metod, w zależności od sytuacji. Metody obejmują utworzenie nowego obiektu klucza głównego KDS i ponowne uruchomienie usługi dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny domeny.

Scenariusz 1: Masz wiarygodne informacje o tym, jakie informacje zostały ujawnione i kiedy

Jeśli wiesz, że ekspozycja miała miejsce przed określoną datą, a ta data jest wcześniejsza niż najstarsze hasło zarządzanego konta zarządzanego przez Ciebie, możesz rozwiązać problem bez ponownego tworzenia zasad grupy, jak pokazano w poniższej procedurze.

Metoda polega na utworzeniu nowego obiektu klucza głównego KDS nieznanego osobie atakującej. Gdy konta zasad grupy przerzucą swoje hasło, zostaną przeniesione do nowego obiektu klucza głównego KDS. Aby rozwiązać problemy z zasadami grupy, które niedawno wprowadziły swoje hasło przy użyciu starego klucza głównego KDS, konieczne jest przywrócenie autorytatywne w celu wymuszenia aktualizacji hasła natychmiast po przywróceniu.

Uwaga 16.

  • Nie trzeba ręcznie naprawiać zasad grupy, które zostały utworzone po zakończeniu ekspozycji bazy danych usług domena usługi Active Directory (AD DS). Osoba atakująca nie zna szczegółów tych kont, a hasła dla tych kont zostaną wygenerowane ponownie na podstawie nowego obiektu klucza głównego KDS.
  • Należy rozważyć obiekt gMSA w trybie konserwacji do momentu ukończenia procedury i zignorować możliwe błędy zgłaszane z kontami w dzienniku zdarzeń System, Security, Directory Services i Security-Netlogon.
  • W przewodniku założono, że konta zarządzane przez administratora są obiektami podrzędnymi kontenera Zarządzanych kont usług. Jeśli konta zostały przeniesione do niestandardowych kontenerów nadrzędnych, należy uruchomić kroki związane z kontenerem Zarządzanych kont usług w gMSA w tych kontenerach.
  • Przywracanie autorytatywne przywraca wszystkie atrybuty do stanu, w których znajdowały się w czasie tworzenia kopii zapasowej, w tym kont, które mogą pobierać poświadczenia gMSA (PrincipalsAllowedToRetrieveManagedPassword).

W domenie, w której znajdują się konta zarządzane przez grupy, które chcesz naprawić, wykonaj następujące kroki:

  1. Przełącz kontroler domeny w tryb offline i odizoluj go od sieci.

  2. Przywróć kontroler domeny z kopii zapasowej utworzonej przed ujawnieniem bazy danych usług AD DS.

    Jeśli interwał haseł dla konta zarządzanego przez grupy jest dłuższy niż wiek kopii zapasowej, możesz zdecydować się na tolerowanie okna, w którym nadal działa poprzedni materiał klucza. Jeśli nie możesz czekać tak długo, a pasująca starsza kopia zapasowa nie ma zbyt wielu gMSA, musisz przełączyć plan na scenariusz 2.

  3. Uruchom operację autorytatywnego przywracania w kontenerze zarządzanych kont usług domeny. Upewnij się, że operacja przywracania zawiera wszystkie obiekty podrzędne kontenerów, które mogą być skojarzone z tym kontrolerem domeny. Ten krok powoduje wycofanie stanu ostatniej aktualizacji hasła. Następnym razem, gdy usługa pobierze hasło, hasło zostanie zaktualizowane do nowego na podstawie nowego obiektu klucza głównego KDS.

  4. Zatrzymaj i wyłącz usługę dystrybucji kluczy firmy Microsoft na przywróconym kontrolerze domeny.

  5. Na innym kontrolerze domeny wykonaj kroki opisane w temacie Create the Key Distribution Services KDS Root Key (Tworzenie klucza głównego usług dystrybucji kluczy), aby utworzyć nowy obiekt klucza głównego KDS.

    Uwaga 16.

    W środowisku produkcyjnym należy poczekać 10 godzin, aby upewnić się, że nowy klucz główny KDS jest dostępny. Sprawdź atrybut, EffectiveTime aby dowiedzieć się, kiedy będzie można używać nowego klucza głównego KDS.

  6. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

  7. Utwórz nowy gMSA. Upewnij się, że nowy gMSA używa nowego obiektu klucza głównego KDS do utworzenia wartości atrybutu msds-ManagedPasswordID .

    Uwaga 16.

    Ten krok jest opcjonalny, ale umożliwia sprawdzenie, czy nowy klucz główny KDS jest obecnie używany i używany w usłudze dystrybucji kluczy firmy Microsoft.

  8. msds-ManagedPasswordID Sprawdź wartość pierwszego utworzonego konta zarządzanego przez użytkownika. Wartość tego atrybutu to dane binarne zawierające identyfikator GUID pasującego obiektu klucza głównego KDS.

    Załóżmy na przykład, że obiekt klucz główny KDS ma następujące CNpolecenie .

    Zrzut ekranu przedstawiający wartość atrybutu CN obiektu klucza głównego KDS.

    GMSA utworzona przy użyciu tego obiektu ma wartość podobną msds-ManagedPasswordID do poniższej.

    Zrzut ekranu przedstawiający wartość atrybutu msDS-ManagedPasswordId obiektu gMSA, pokazujący, jak zawiera on elementy atrybutu CN klucza głównego KDS.

    W tej wartości dane identyfikatora GUID zaczynają się od przesunięcia 24. Części identyfikatora GUID znajdują się w innej sekwencji. Na tej ilustracji czerwone, zielone i niebieskie sekcje identyfikują ponownie uporządkowane części. Pomarańczowa sekcja identyfikuje część sekwencji, która jest taka sama jak oryginalny identyfikator GUID.

    Jeśli pierwsza utworzona usługa gMSA używa nowego klucza głównego KDS, wszystkie kolejne konta zasad grupy również używają nowego klucza.

  9. Wyłącz i zatrzymaj usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

  10. Ponownie połącz się i przełącz przywrócony kontroler domeny z powrotem do trybu online. Upewnij się, że replikacja działa.

    Teraz przywracanie autorytatywne i wszystkie pozostałe zmiany (w tym przywrócone konta gMSA) są replikowane.

  11. Ponownie włącz i uruchom usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny. Wpisy tajne przywróconych gMSA zostaną wycofane, a nowe hasła zostaną utworzone na podstawie nowego obiektu klucza głównego KDS po żądaniu.

    Uwaga 16.

    Jeśli konta zasad grupy są przywracane, ale nie są używane i mają PrincipalsAllowedToRetrieveManagedPassword wypełniony parametr, możesz uruchomić Test-ADServiceAccount polecenie cmdlet na przywróconej gMSA przy użyciu podmiotu zabezpieczeń, który może pobrać hasło. Jeśli wymagana jest zmiana hasła, to polecenie cmdlet będzie następnie rzutować konta zasad grupy na nowy klucz główny KDS.

  12. Sprawdź, czy wszystkie konta zarządzane przez grupy zostały wycofane.

    Uwaga 16.

    GMSA bez wypełnionego parametru PrincipalsAllowedToRetrieveManagedPassword nigdy nie będzie rzutowany.

  13. Usuń stary obiekt klucza głównego KDS i zweryfikuj replikacje.

  14. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

Scenariusz 2: Nie znasz szczegółów ujawnienia obiektu klucza głównego KDS i nie możesz czekać na wprowadzenie haseł

Jeśli nie wiesz, jakie informacje zostały ujawnione lub kiedy zostały ujawnione, takie narażenie może być częścią całkowitej ekspozycji lasu usługi Active Directory. Może to spowodować sytuację, w której osoba atakująca może uruchomić ataki w trybie offline na wszystkie hasła. W takim przypadku rozważ uruchomienie odzyskiwania lasu lub zresetowanie wszystkich haseł konta. Odzyskiwanie kont zasad grupy do czystego stanu jest częścią tego działania.

Podczas poniższego procesu należy utworzyć nowy obiekt klucza głównego KDS. Następnie użyjesz tego obiektu, aby zastąpić wszystkie konta gMSA w domenach lasu, które używają uwidocznionego obiektu klucza głównego KDS.

Uwaga 16.

Poniższe kroki przypominają procedurę opisaną w temacie Wprowadzenie do kont usług zarządzanych przez grupę. Istnieje jednak kilka ważnych zmian.

Wykonaj te kroki:

  1. Wyłącz wszystkie istniejące konta zarządzane przez grupę i oznacz je jako konta do usunięcia. W tym celu dla każdego konta ustaw userAccountControl atrybut na 4098 (ta wartość łączy flagi WORKSTATION_TRUST_ACCOUNT i ACCOUNTDISABLE (wyłączone).

    Możesz użyć skryptu programu PowerShell w następujący sposób, aby ustawić konta:

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. Użyj jednego kontrolera domeny i wykonaj następujące kroki:

    1. Wykonaj kroki opisane w artykule Create the Key Distribution Services KDS Root Key (Tworzenie klucza głównego usług dystrybucji kluczy ), aby utworzyć nowy obiekt klucza głównego KDS.

    2. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft. Po ponownym uruchomieniu usługa pobiera nowy obiekt.

    3. Tworzenie kopii zapasowych nazw hostów DNS i nazw głównych usług (SPN) skojarzonych z każdym gMSA oznaczonym do usunięcia.

    4. Edytuj istniejące konta zasad grupy, aby usunąć nazwy SPN i nazwy hostów DNS.

    5. Utwórz nowe konta gMSA, aby zastąpić istniejące konta zasad grupy. Należy je również skonfigurować przy użyciu nazw hostów DNS i nazw SPN, które zostały właśnie usunięte.

      Uwaga 16.

      Należy również przejrzeć wszystkie wpisy uprawnień przy użyciu bezpośrednio usuniętych identyfikatorów SID usługi gMSA, ponieważ nie są już możliwe do rozwiązania. Podczas zastępowania wpisu kontroli dostępu (ACE) rozważ użycie grup do zarządzania wpisami uprawnień gMSA.

  3. Sprawdź nowe konta zasad grupy, aby upewnić się, że używają nowego obiektu klucza głównego KDS. W tym celu wykonaj następujące kroki:

    1. Zanotuj CN wartość (GUID) obiektu klucza głównego KDS.

    2. msds-ManagedPasswordID Sprawdź wartość pierwszego utworzonego konta zarządzanego przez użytkownika. Wartość tego atrybutu to dane binarne zawierające identyfikator GUID pasującego obiektu klucza głównego KDS.

      Załóżmy na przykład, że obiekt klucz główny KDS ma następujące CNpolecenie .

      Zrzut ekranu przedstawiający wartość atrybutu CN obiektu klucza głównego KDS.

      GMSA utworzona przy użyciu tego obiektu ma wartość podobną msds-ManagedPasswordID do obrazu.

      Zrzut ekranu przedstawiający wartość atrybutu msDS-ManagedPasswordId obiektu gMSA, pokazujący, jak zawiera on elementy atrybutu CN klucza głównego KDS.

      W tej wartości dane identyfikatora GUID zaczynają się od przesunięcia 24. Części identyfikatora GUID znajdują się w innej sekwencji. Na tej ilustracji czerwone, zielone i niebieskie sekcje identyfikują ponownie uporządkowane części. Pomarańczowa sekcja identyfikuje część sekwencji, która jest taka sama jak oryginalny identyfikator GUID.

      Jeśli pierwsza utworzona usługa gMSA używa nowego klucza głównego KDS, wszystkie kolejne konta zasad grupy również używają nowego klucza.

  4. Zaktualizuj odpowiednie usługi, aby używać nowych zasad grupy.

  5. Usuń stare konta zasad grupy, które używały starego obiektu klucza głównego KDS, używając następującego polecenia cmdlet:

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. Usuń stary obiekt klucza głównego KDS i zweryfikuj replikacje.

  7. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

Scenariusz 3. Rezygnacja administratora domeny, w tym czasie nie zostały skradzione żadne informacje i możesz poczekać na wycofanie haseł

Jeśli członek o wysokim poziomie uprawnień z administratorami domeny lub równoważnymi uprawnieniami rezygnuje, nie ma dowodu ujawnienia klucza głównego KDS w tym czasie i możesz sobie pozwolić na przedział czasu wprowadzania haseł. Nie musisz ponownie utworzyć kont gMSA.

W ramach środków zapobiegawczych klucz główny KDS musi zostać przerzucony, aby zapobiec wszelkim atakom po wykorzystaniu. Na przykład były administrator domeny okazał się nieuczciwy i przechowywał pewne kopie zapasowe.

Zostanie utworzony nowy obiekt klucza głównego KDS, a konta gMSA będą w naturalny sposób rzutowane.

Uwaga 16.

W przypadku naruszenia zabezpieczeń związanego z administratorem domeny zapoznaj się ze scenariuszem 1 lub scenariuszem 2, zgodnie z tym, co zostało ujawnione, i postępuj zgodnie z działaniami korygowania lokalnego w temacie "Korzystanie z zasobów zabezpieczeń firmy Microsoft i platformy Azure w celu ułatwienia odzyskiwania po naruszeniu tożsamości systemowej".

W domenie zawierającej zarządzane konta zarządzane przez użytkownika, które chcesz wdrożyć, wykonaj następujące kroki:

  1. Na kontrolerze domeny wykonaj kroki opisane w temacie Tworzenie klucza głównego KDS usług dystrybucji kluczy, aby utworzyć nowy obiekt klucza głównego KDS.

    Uwaga 16.

    W środowisku produkcyjnym należy poczekać 10 godzin, aby upewnić się, że nowy klucz główny KDS jest dostępny. Sprawdź atrybut, EffectiveTime aby dowiedzieć się, kiedy będzie można używać nowego klucza głównego KDS.

  2. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

  3. Utwórz nowy gMSA. Upewnij się, że nowy gMSA używa nowego obiektu klucza głównego KDS do utworzenia wartości atrybutu msds-ManagedPasswordID .

    Uwaga 16.

    Ten krok jest opcjonalny, ale umożliwia sprawdzenie, czy nowy klucz główny KDS jest obecnie używany i używany w usłudze dystrybucji kluczy firmy Microsoft.

  4. msds-ManagedPasswordID Sprawdź wartość pierwszego utworzonego konta zarządzanego przez użytkownika. Wartość tego atrybutu to dane binarne zawierające identyfikator GUID pasującego obiektu klucza głównego KDS.

    Załóżmy na przykład, że obiekt klucz główny KDS ma następujące CNpolecenie .

    Zrzut ekranu przedstawiający wartość atrybutu CN obiektu klucza głównego KDS.

    GMSA utworzona przy użyciu tego obiektu ma wartość podobną msds-ManagedPasswordID do poniższej ilustracji.

    Zrzut ekranu przedstawiający wartość atrybutu msDS-ManagedPasswordId obiektu gMSA, pokazujący, jak zawiera on elementy atrybutu CN klucza głównego KDS.

    W tej wartości dane identyfikatora GUID zaczynają się od przesunięcia 24. Części identyfikatora GUID znajdują się w innej sekwencji. Na tej ilustracji czerwone, zielone i niebieskie sekcje identyfikują ponownie uporządkowane części. Pomarańczowa sekcja identyfikuje część sekwencji, która jest taka sama jak oryginalny identyfikator GUID.

    Jeśli pierwsza utworzona usługa gMSA używa nowego klucza głównego KDS, wszystkie kolejne konta zasad grupy również używają nowego klucza.

  5. W zależności od następnego rzutu hasła wpisy tajne gMSA będą naturalnie rzutowane, a nowe hasła zostaną utworzone na podstawie nowego obiektu klucza głównego KDS po żądaniu.

    Uwaga 16.

    Jeśli używane konta zasad grupy zostały wycofane, ale nieużywane konta zasad grupy z tym samym interwałem rzutowania nie zostały wypełnione i mają PrincipalsAllowedToRetrieveManagedPassword wypełniony parametr, możesz uruchomić Test-ADServiceAccount polecenie cmdlet. Używa podmiotu zabezpieczeń, który może pobrać hasło gMSA, a następnie przenosi grupę zarządzanego konta do nowego klucza głównego usługi KDS.

  6. Sprawdź, czy wszystkie konta zarządzane przez grupy zostały wycofane.

    Uwaga 16.

    GMSA bez parametru nigdy nie będzie rzutowy PrincipalsAllowedToRetrieveManagedPassword .

  7. Po wprowadzeniu wszystkich gMSA do nowego obiektu klucza głównego KDS usuń stary obiekt klucza głównego KDS i zweryfikuj replikacje.

  8. Uruchom ponownie usługę dystrybucji kluczy firmy Microsoft na wszystkich kontrolerach domeny.

Informacje

Omówienie kont usług zarządzanych przez grupę

Wyłączenie odpowiedzialności za kontakty z osobami trzecimi

Firma Microsoft udostępnia informacje kontaktowe innych firm, aby uzyskać dodatkowe informacje na temat tego tematu. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.