Jorge de Almeida Pinto

Wichtigste Ergebnisse

  • BadSuccessor, eine Technik zur Ausweitung von Berechtigungen, die delegierte Managed Service Accounts (dMSAs) ausnutzt, stellt ein hohes Risiko für Unternehmen dar, die auch nur einen Windows Server 2025 Domain Controller (DC) verwenden. Die Technik kann verwendet werden, um sich als ein beliebiges Konto in Active Directory (AD) auszugeben - sogar als Domänenadministrator, das KRBTGT-Konto oder jedes andere aktivierte oder deaktivierte Konto mit hohen Privilegien.
  • Jorge de Almeida Pinto, Senior Incident Response Lead bei Semperis, entdeckte eine Möglichkeit, den Anwendungsfall der dMSA-Migration vollständig zu blockieren, wodurch Angreifer effektiv daran gehindert werden, eine dMSA zu missbrauchen, um möglicherweise eine AD-Domäne zu übernehmen.
  • Die Lösung wird im AD-Schema konfiguriert und sollte auf jeden AD Forest angewendet werden.
  • Diese Risikominderung kann implementiert werden, bis Microsoft einen Patch zur Behebung der Sicherheitslücke veröffentlicht hat.

Bis Windows Server 2025 unterstützten AD und Windows eigenständige Managed Service Accounts (sMSAs) und Group Managed Service Accounts (gMSAs). Mit Windows Server 2025 wird ein neuer Typ von verwalteten Dienstkonten eingeführt: delegierte verwaltete Dienstkonten.

Dieser neue Kontotyp wurde entwickelt, um die Verwaltung von Anmeldeinformationen für benutzerbasierte Servicekonten zu verbessern, indem er die Migration von einem alten Servicekonto zu einem dMSA unterstützt.

Forscher von Akamai1 entdeckten, dass Angreifer problemlos eine dMSA erstellen und konfigurieren und diese dann missbrauchen können, um sich als ein beliebiger authentifizierbarer Sicherheitsprinzipal im AD auszugeben. Sie nannten die Angriffstechnik BadSuccessor.

In diesem Blog-Beitrag finden Sie eine ausführliche Einführung und Informationen zur Abschwächung der Schwachstelle, einschließlich PowerShell-Code zur Implementierung der vorgeschlagenen Lösung, um den Anwendungsfall der Migration zu blockieren.

Warum müssen Sie BadSuccessor blockieren?

Bei bestimmungsgemäßer Verwendung unterstützt die dMSA-Migration offiziell nur Legacy-Dienstkonten als Quelle (Kontotyp user). Der BadSuccessor-Angriff funktioniert jedoch mit jedem authentifizierbaren Kontotyp als Quelle, einschließlich Computerkonten, sMSAs, gMSAs und sogar dMSAs. Darüber hinaus spielt es keine Rolle, ob das Quellkonto aktiviert oder deaktiviert ist.

Die einzigen Komponenten, die zur Ausführung dieses Angriffs benötigt werden, sind:

  • Mindestens ein beschreibbarer 2025 DC
  • Eine (gefährdete) dMSA und das richtige Werkzeug

Außerdem muss der Angriff nicht auf Windows Server 2025 stattfinden.

Der Kern des BadSuccessor-Angriffs beginnt mit der Fähigkeit, entweder eine neue dMSA zu erstellen oder eine bestehende dMSA zu kontrollieren. Die Delegation der Kontrolle über eine bestehende AD-Domäne erfordert daher eine sofortige Überprüfung und Aktion.2

Angesichts des Potenzials für eine vollständige Kompromittierung der AD-Domäne sollten Sie Maßnahmen ergreifen, um dieses Risiko zu mindern, sobald Sie Ihren ersten beschreibbaren Windows Server 2025 DC eingeführt haben - auch wenn Sie noch keine dMSAs verwenden.

Wie Sie BadSuccessor erkennen: Indikatoren für Gefährdung und Kompromittierung

Microsoft hat noch keinen Patch zur Verfügung gestellt, um diese Schwachstelle zu entschärfen. Semperis hat zusätzliche Erkennungsfunktionen in Directory Services Protector DSP) zur Abwehr von BadSuccessor hinzugefügt. Die DSP wurde um einen neuen Indikator für die Gefährdung (Indicator of Exposure, IOE) und drei neue Indikatoren für die Gefährdung (Indicator of Compromise, IOC) erweitert, die die Erkennung und Eindämmung bösartiger Aktivitäten mit dMSAs ermöglichen.

Was sind dMSA-Anwendungsfälle?

Microsoft hat die dMSA für einen bestimmten, schwer zu lösenden Anwendungsfall entwickelt, den viele Unternehmen heute haben. In der Praxis unterstützt eine dMSA zwei Anwendungsfälle.

Aufgrund der vielen Anwendungsfälle hat jede dMSA einen Status, der bestimmt, wie die dMSA verwendet wird und der im Attribut msDS-DelegatedMSAState.

Die unterstützten Staaten sind:

  • 0: Unbenutzt (dieser Status ist der Standard, wenn er nicht definiert ist)
  • 1: Die Migration hat begonnen
  • 2: Migration Nutzung abgeschlossen
  • 3: Einheimische Verwendung

Eine dMSA kann wie eine gMSA verwendet werden. In diesem Fall ist der Status der dMSA 3, was bedeutet, dass sie nativ verwendet wird.

Die dMSA wurde entwickelt, um die Migration eines alten Dienstkontos zu einer dMSA zu unterstützen und so eine bessere und erweiterte Verwaltung der Anmeldeinformationen zu ermöglichen, ohne die Funktionalität eines Dienstes, einer Anwendung oder einer geplanten Aufgabe zu beeinträchtigen, die das alte Dienstkonto verwendet. Bessere und erweiterte Verwaltung der Anmeldeinformationen bedeutet technisch gesehen, dass das Kennwort häufiger und automatisch gewechselt wird und ein stärkeres und sehr komplexes Kennwort verwendet wird.

Die Migration vom Legacy-Dienstkonto zur dMSA wird von einem Administrator initiiert. Der Status sowohl des Legacy-Dienstkontos als auch der dMSA ändert sich zu 1-Migration gestartet. Sobald der Administrator die Migration abgeschlossen hat und der Status sowohl des Legacy-Dienstkontos als auch der dMSA sich zu 2Migration abgeschlossen - die spezifische Konfiguration des Legacy-Dienstkontos selbst wird auf die dMSA migriert. Die Gruppenmitgliedschaften des Legacy-Dienstkontos werden jedoch nicht auf die dMSA migriert und verbleiben beim Legacy-Dienstkonto.

Während des ersten Migrationsstatus erkennt das System automatisch, wo das alte Dienstkonto verwendet wird und konfiguriert die dMSA entsprechend. Wenn das System im zweiten Migrationsstatus versucht, sich mit dem (deaktivierten) alten Dienstkonto zu authentifizieren, übernimmt die dMSA die Authentifizierung.

Wenn die dMSA die Authentifizierung übernimmt, führt der Windows Server 2025-Domänencontroller das Privileged Attribute Certificate (PAC) des Legacy-Dienstkontos und das PAC der dMSA zu einem PAC zusammen, das alle kombinierten Gruppenmitgliedschaften und andere anwendbare objectSIDs enthält. Der dMSA erbt daher alle Benutzerrechte, Berechtigungen und Zugriffe, so dass er das alte Dienstkonto ohne Auswirkungen auf den Dienst, die Anwendung oder die geplante Aufgabe ersetzen kann.

Das Gute: dMSA-Nachfolge wie beabsichtigt

Die folgenden PowerShell-Cmdlets sind für die Migration eines Legacy-Dienstkontos zu einer dMSA verfügbar.

PowerShell CMDletAktion
Start-ADServiceAccountMigrationInitiieren Sie die Migration des Legacy-Dienstkontos zur dMSA. Dieser Status wechselt von initial zu gestartet. Kann nur ausgeführt werden, wenn der Status 0.
Complete-ADServiceAccountMigrationSchließen Sie die Migration des Legacy-Dienstkontos zur dMSA ab. Geht von gestartet zu abgeschlossen über. Kann nur ausgeführt werden, wenn der Status 1.
Undo-ADServiceAccountMigrationMachen Sie den letzten Migrationsschritt rückgängig und kehren Sie zum vorherigen Schritt zurück. Übergänge von abgeschlossen zu gestartet oder von gestartet zu initial. Kann nur ausgeführt werden, wenn der Status entweder 1 oder 2.
Reset-ADServiceAccountMigrationSetzt die Migration auf den Ausgangszustand zurück und macht alles rückgängig. Wechselt entweder von abgeschlossen oder gestartet zum Ausgangszustand. Kann nur ausgeführt werden, wenn der Status entweder 1 oder 2.

Je nach verwendetem PowerShell-Cmdlet wird ein operatives Attribut mit Eingabedaten gegen die RootDSE eines beschreibbaren DCs verwendet. In diesem Fall werden mehrere Aktionen gleichzeitig für das Legacy-Zieldienstkonto und die Ziel-DMSA ausgeführt. Die PowerShell-Cmdlets oder das operative Attribut können nur von Mitgliedern der Gruppe Domain Admins verwendet werden.

Damit Sie besser verstehen, was die einzelnen PowerShell-Cmdlets bewirken, finden Sie hier eine ausführlichere Beschreibung der Aktionen.

Bei der Verwendung von Start-ADServiceAccountMigrationwerden die folgenden Aktionen vom System ausgeführt:

  • Auf dem Legacy-Dienstkonto:
    • Setzen Sie msDS-SupersededServiceAccountState zu 1
    • Setzen Sie msDS-SupersededManagedAccountLink an den DN der anvisierten dMSA
  • Über die dMSA:
    • Setzen Sie msDS-DelegatedMSAState zu 1
    • Setzen Sie msDS-ManagedAccountPrecededByLink an die DN des angestrebten Legacy-Service-Kontos
    • Zuweisung von Leserechten an das Zielkonto des Legacy-Dienstes für alle Attribute der Ziel-DMSA
    • Weisen Sie dem Zielkonto des Legacy-Dienstes Schreibberechtigungen für das Attribut msDS-GroupMSAMembership der anvisierten dMSA

Bei der Verwendung von Complete-ADServiceAccountMigrationwerden die folgenden Aktionen vom System ausgeführt:

  • Auf dem Legacy-Dienstkonto:
    • Setzen Sie msDS-SupersededServiceAccountState zu 2
    • Deaktivieren Sie das Konto
  • Über die dMSA:
    • Setzen Sie msDS-DelegatedMSAState zu 2
    • Entfernen Sie die zuvor zugewiesenen Leseberechtigungen für das angestrebte Legacy-Dienstkonto aus allen Attributen der dMSA
    • Entfernen Sie die zuvor zugewiesenen Schreibrechte für das Zielkonto des Legacy-Dienstes aus dem Attribut msDS-GroupMSAMembership der dMSA
  • Verschieben Sie die folgenden Konfigurationen vom Legacy-Dienstkonto zur dMSA:
    • Dienstprinzipal-Namen (SPNs)
    • Erlaubt, an Liste zu delegieren
    • Ressourcenbasierte eingeschränkte Delegation
    • Zugewiesene Authentifizierungsrichtlinie
    • Zugewiesenes Authentifizierungssilo
    • Vertrauenswürdige Authentifizierung für Delegation UAC Bit

Bei der Verwendung von Reset-ADServiceAccountMigrationalle Aktionen, die entweder von Start-ADServiceAccountMigration oder Complete-ADServiceAccountMigration werden rückgängig gemacht und sowohl das Legacy-Dienstkonto als auch die dMSA kehren in ihren ursprünglichen Zustand zurück.

Bei der Verwendung von Undo-ADServiceAccountMigrationalle Aktionen, die entweder von Start-ADServiceAccountMigration oder Complete-ADServiceAccountMigration werden rückgängig gemacht und sowohl das Legacy-Dienstkonto als auch die dMSA kehren in den Zustand vor der Ausführung von zurück, Start-ADServiceAccountMigration oder Complete-ADServiceAccountMigration. Technisch gesehen bedeutet dies einen der folgenden Übergänge:

  • Von abgeschlossen bis begonnen
  • Vom Start bis zum Anfang

Das Schlechte und das Hässliche: dMSA-Missbrauch

Wie die Akamai-Forscher herausfanden, sind die Attribute des Legacy-Service-Kontos und der dMSA, die an der Migration beteiligt sind, nicht vor regulären LDAP-Schreibzugriffen geschützt. Jeder, der mindestens die Berechtigung Write Property für die Attribute der dMSA hat - oder eine andere Berechtigung, die zu dieser Berechtigung führen kann - kann Daten schreiben. Leider hebt dieses Schlupfloch die durch das PowerShell-Cmdlet und das operative Attribut unter der Haube implementierten Schutzmaßnahmen auf.

Darüber hinaus scheint der authentifizierende Windows Server 2025 writable DC bei der Validierung nur zwei Attribute der dMSA zu berücksichtigen und nichts vom Legacy-Dienstkonto. Wenn die msDS-DelegatedMSAState der dMSA ist eingestellt auf 2 (und es spielt keine Rolle, wie es zu diesem Zustand gekommen ist), prüft der DC, welches Konto in der Datei msDS-ManagedAccountPrecededByLink Attribut.

Mit diesen Informationen und unter der Annahme, dass das anfragende Konto (normalerweise ein Computerkonto, aber es kann alles sein) die Berechtigung hat, das Kennwort oder die Schlüssel von der dMSA anzufordern, führt der authentifizierende Windows Server 2025 beschreibbare DC das Privileged Attribute Certificate (PAC) des Legacy-Dienstkontos und der dMSA zu einem PAC zusammen. Der DC stellt dann dieses zusammengefasste PAC in einer TGS-REP an das anfordernde Konto aus.

Der Distinguished Name (DN) des Kontos in der msDS-ManagedAccountPrecededByLink Attribut kann alles sein - und BadSuccessor nutzt diese Schwachstelle voll aus.

Mit Hilfe der administrativen Ebenen können Sie Ihre hochprivilegierten Konten (Benutzer, Dienste, Computer, sMSAs, gMSAs, dMSAs) verbergen und schützen. Der Schwerpunkt liegt hier auf dem "Verstecken" der hochprivilegierten Konten, so dass ihr DN für niedrigprivilegierte Konten nicht sichtbar ist. Wichtig ist auch, dass der DN von hochprivilegierten Konten nicht leicht zu erraten sein sollte.

Dieser Angriff kann schnell zu einem sehr hässlichen Nachfolger werden.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

HINWEIS: Das KRBTGT-Konto kann in ein geschütztes und verborgenes Tiering-Modell verschoben werden - Microsoft empfiehlt jedoch nicht, es zu verschieben.3

HINWEIS: Das Administratorkonto kann in ein geschütztes und verstecktes Tiering-Modell verschoben werden. Es ist auch in Ordnung, es umzubenennen.4

Wenn Sie sich dafür entscheiden, das Standard-Domänenadministratorkonto oder das KRBTGT-Konto in die administrative Tiering-Struktur zu verschieben, stellen Sie sicher, dass beide in einer separaten OU untergebracht sind (d.h. nicht mit anderen Konten kombiniert) und nur Tier-0-Administratorkonten Zugriff auf diese OU erhalten.

Wie man Nachfolger blockiert

Ich habe das aktuelle Innenleben einer dMSA aus der Sicht eines "guten Nachfolgers" und eines "schlechten und hässlichen Nachfolgers" untersucht:

  • A: Unterstützung aller beschriebenen Anwendungsfälle
  • B: Erlauben und unterstützen Sie den guten Nachfolger
  • C: Blockieren Sie den schlechten und hässlichen Nachfolger

Die regulären LDAP-Schreibvorgänge, wie sie für den schlechten und hässlichen Nachfolger beschrieben wurden, erfordern, dass der Akteur über bestimmte Berechtigungen für eine dMSA verfügt. Die Verwendung der PowerShell-Cmdlets erfordert, dass der Akteur Mitglied bei Domain Admins ist.

Wie bereits erwähnt, führen die PowerShell-Cmdlets unterschiedliche Aktionen für das Legacy-Dienstkonto und die dMSA durch, indem sie ein operatives Attribut mit Eingabedaten nutzen.

Mit diesen Gedanken überprüfte ich das AD-Schema, insbesondere die Schemadefinition des msDS-ManagedAccountPrecededByLink Attribut, da es steuert, welches Konto (offiziell) migriert oder angegriffen wird (Abbildung 1).

Obwohl das Attribut msDS-DelegatedMSAState eine wichtige Rolle spielt, muss sie dennoch verwaltet werden, indem ein regulärer LDAP-Schreibvorgang ausgeführt wird, um den Status der dMSA auf 3 wenn Sie es nativ und nicht zu Migrationszwecken verwenden.

Abbildung 1: Die ursprüngliche AD-Schema-Definition des Attributs msDS-ManagedAccountPrecededByLink mit systemOnly auf FALSE gesetzt

Wenn ich mir die Definition des angezeigten Attributs ansehe, hatte ich die Absicht, reguläre LDAP-Schreibvorgänge zu blockieren und operative Attribut-Schreibvorgänge zu unterstützen. Vor diesem Hintergrund stach die Eigenschaft systemOnly hervor, von der ich hoffte, dass sie das Ziel der Untersuchung erreichen würde. Dieses Attribut kann nicht wie jedes andere reguläre Attribut geändert werden. Eine Funktion auf dem DC muss zunächst aktiviert werden, um eine spezielle Schreibaktion zu unterstützen, und dann wieder deaktiviert werden. Die Absicht der Sperre ist es, reguläres WRITE zu verhindern, während READ weiterhin möglich ist.

Gehen wir dies Schritt für Schritt durch.

Abbildung 2 zeigt die Überprüfung der Konfiguration der dMSA dMSA.weak.5 Diese dMSA befindet sich im Anfangszustand und es ist kein Konto mit ihr verknüpft (d.h. es wird kein Konto angezeigt).

Abbildung 2: Anzeigen der Konfiguration der dMSA: dMSA.weak

Der Angreifer setzt den Status von dMSA.weak zu 2konfiguriert ein verknüpftes Konto (den Standard-Domänenadministrator, der in diesem AD in ADM.TEC umbenannt wurde) und fügt sich selbst als das Konto hinzu, das das Passwort/die Schlüssel der dMSA abrufen darf6 (Abbildung 3). In diesem Fall ist die Aktion möglich, weil der Angreifer über ein Konto verfügt, das Mitglied der Gruppe Legacy Account Operators ist.

Abbildung 3: Rekonfigurieren dMSA.weak bei missbräuchlicher Verwendung

Als nächstes überprüfen wir die Konfiguration von dMSA.weak5 (Abbildung 4).

Abbildung 4: Anzeigen der Konfiguration von dMSA.weak

Die dMSA hat jetzt den Status "Migration abgeschlossen". 2hat ein damit verknüpftes Konto, und der Angreifer kann das Passwort/die Schlüssel der dMSA abrufen. Mit RUBEUS beispielsweise kann der Angriff auf die dMSA und insbesondere auf das damit verknüpfte Konto gestartet werden.

Als nächstes entfernen wir die vorherige Konfiguration6 und überprüfen, ob sie tatsächlich entfernt wurde5(Abbildung 5 und Abbildung 6).

Abbildung 5: Entfernen der zuvor eingestellten Konfiguration aus dMSA.weak
Abbildung 6: Anzeigen der Konfiguration von dMSA.weak

Jetzt können wir den Status des Blocks7 anzeigen(Abbildung 7).

Abbildung 7: Überprüfen des Status des Blocks auf dem Attribut (False bedeutet nicht gesperrt)

Als nächstes aktivieren wir den Block für das Migrationsszenario8(Abbildung 8).

Abbildung 8: Aktivieren des Blocks für das Attribut (True kennzeichnet gesperrt)

Auch dies können wir bestätigen, indem wir uns den Status des Blocks ansehen7(Abbildung 9).

Abbildung 9: Überprüfen des Status des Blocks auf dem Attribut (True kennzeichnet gesperrt)

Der Angreifer versucht es nun erneut6:

  • Setzen Sie den Status von dMSA.weak zu 2
  • Konfigurieren Sie ein verknüpftes Konto (wieder der umbenannte Standard-Domänenadministrator)
  • Fügen Sie sich selbst als das Konto hinzu, das das Passwort/die Schlüssel der dMSA abrufen darf(Abbildung 10).

Jetzt kann die Transaktion nicht abgeschlossen werden, da der Angreifer nicht berechtigt ist, die DN des verknüpften Kontos zu schreiben.
Ziel C erreicht!

Abbildung 10: Versuch einer Neukonfiguration dMSA.weak bei missbräuchlicher Verwendung

Lassen Sie uns nun noch einmal die Konfiguration von dMSA.weak5 (Abbildung11).

Abbildung 11: Anzeigen der Konfiguration von dMSA.weak

Da die gesamte Transaktion fehlgeschlagen ist, wurde nichts geändert. Wenn die Attribute einzeln geschrieben worden wären, wären alle erfolgreich gewesen, mit Ausnahme des Schreibens in die msDS-ManagedAccountPrecededByLink Attribut. Es wird nichts angezeigt, da es keinen Wert hat.

Wenn die Sperre aktiviert ist, schlägt auch der offizielle Weg zur Migration eines Legacy-Dienstkontos zu einer dMSA fehl(Abbildung 12). Das ist sehr bedauerlich. Aber es gibt Licht am Ende des Tunnels!

Bei der Sperre geht es darum, Schreibvorgänge gegen die msDS-ManagedAccountPrecededByLink Attribut. Wenn Sie sich die offiziellen PowerShell-Cmdlets für die Migration ansehen, finden Sie nur die Cmdlets Start-ADServiceAccountMigration und Reset-ADServiceAccountMigration in dieses Attribut schreiben. Das Cmdlet Undo-ADServiceAccountMigration schreibt auch in dieses Attribut, wenn Sie den Schritt von gestartet zu initial rückgängig machen. Bei anderen Übergängen wird dieses Attribut nicht geschrieben oder ausgeführt.

Ziele A und B: teilweise erreicht.

Abbildung 12: Initiieren der offiziellen Migration eines Legacy-Dienstkontos sVC.SQL zu einer dMSA namens dMSA.SQL$

Als nächstes deaktivieren wir den Block für das Migrationsszenario9(Abbildung 13).

Abbildung 13: Deaktivieren des Blocks für das Attribut (False bedeutet nicht gesperrt)

Nun sehen wir uns erneut den Zustand des Blocks7 an(Abbildung 14).

Abbildung 14: Überprüfen des Status des Blocks auf dem Attribut (False bedeutet nicht gesperrt)

Wenn der Angreifer nun versucht6,:

  • Setzen Sie den Status von dMSA.weak zu 2
  • Konfigurieren Sie ein verknüpftes Konto (wieder der umbenannte Standard-Domänenadministrator)
  • Sich selbst als das Konto hinzufügen, das das Passwort/die Schlüssel der dMSA abrufen darf

-sie haben Erfolg, denn der Block ist wieder weg(Abbildung 15).

Abbildung 15: Rekonfigurieren dMSA.weak bei missbräuchlicher Verwendung

Wenn wir nun die Konfiguration von dMSA.weak5 (Abbildung 16), sehen wir, dass der Angreifer den Zustand der abgeschlossenen Migration hat 2über ein mit der dMSA verknüpftes Konto verfügt und berechtigt ist, das Passwort/die Schlüssel der dMSA abzurufen.

Abbildung 16: Anzeigen der Konfiguration von dMSA.weak

Wenn die Sperre deaktiviert ist, können wir auch die offizielle Methode verwenden, um die Migration eines Legacy-Dienstkontos zu einer dMSA erfolgreich einzuleiten, abzuschließen und zurückzusetzen(Abbildung 17). Für dieses Beispiel wurde ein anderes Legacy-Dienstkonto und eine dMSA verwendet und die Migration wurde von einem Domain Admin-Konto ausgeführt.

Abbildung 17: Initiieren, Abschließen und Zurücksetzen der Migration des Legacy-Dienstkontos sVC.SQL zu einer dMSA namens dMSA.SQL$

Das Blockieren von BadSuccessor erfordert eine aktive Verwaltung

Mit dieser Lösung ist es möglich, das dMSA-Migrationsszenario und damit jeglichen Missbrauch zu verhindern.

Wir empfehlen Unternehmen dennoch, ihr Delegationsmodell2 proaktiv zu überprüfen und entsprechend zu handeln, um Risiken zu minimieren. In diesem Zusammenhang liegt der Schwerpunkt der Überprüfung auf der Erstellung und Verwaltung von dMSAs in jeder AD-Domäne.

Unternehmen, die entweder ein Upgrade auf Windows Server 2025 AD durchführen oder ein neues Windows Server 2025 AD installieren möchten, können diese Lösung implementieren, um die Risiken eines Angriffs zu mindern, bis Microsoft einen Patch veröffentlicht hat.

Die Implementierung der Sperre für das Migrationsszenario erfolgt im AD-Schema, und die Änderung ist reversibel: Sie können sie auf block8 setzen und zu einem späteren Zeitpunkt auf unblock7 setzen. Das bedeutet, dass mehrere Verwaltungsansätze möglich sind.

Ihr Unternehmen kann diesen Block implementieren, weil es keine dMSAs für das Migrationsszenario verwenden möchte.

Wenn Ihr Unternehmen dMSAs für das Migrationsszenario verwenden möchte, können Sie die Sperre zum Schutz von AD dennoch implementieren. Jedes Mal, wenn Sie die Migration eines Kontos einleiten möchten, können Sie die Sperre im Voraus entfernen und sie anschließend erneut implementieren. Sie können die Migration eines Kontos mit oder ohne die Sperre abschließen.

Mit diesem Ansatz ist es möglich, die Ziele A, B und C zu erreichen.

Selbst wenn Sie einen Block implementieren, ermöglichen die IOEs und IOCs von Semperis DSP eine genaue Überwachung von dMSA-Erstellungs-, Verwaltungs- und Authentifizierungsereignissen sowie von Attributänderungen.

Erfahren Sie mehr über die Gefahren von übermäßigen Privilegien in AD

Endnoten

  1. BadSuccessor: Missbrauch von dMSA zur Eskalation von Privilegien in Active Directory
  2. (2025-05-25) Überprüfen Ihres Delegationsmodells vor der Einführung von W2K25 DCs und Verbesserung der Sicherheit (wegen "BadSuccessor")
  3. Microsoft Lernen: KRBTGT Konto-Attribute
  4. Microsoft Lernen: Administrator-Konto
  5. Bad Successor - VIEW DATA IN ATTRIBUTES "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  6. Schlechter Nachfolger - WRITE DATA INTO ATTRIBUTES "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  7. Schlechter Nachfolger - VIEW STATE OF BLOCK
  8. Schlechter Nachfolger - ADDING/ENABLING BLOCK
  9. Schlechter Nachfolger - BLOCK ENTFERNEN/DISABLIEREN

HAFTUNGSAUSSCHLUSS

Dieser Inhalt wird ausschließlich zu Bildungs- und Informationszwecken bereitgestellt. Er soll das Bewusstsein und die verantwortungsvolle Behebung von Sicherheitslücken fördern, die auf Systemen bestehen können, die Sie besitzen oder zu deren Prüfung Sie berechtigt sind. Die unbefugte Nutzung dieser Informationen zu böswilligen Zwecken, zur Ausbeutung oder zum unrechtmäßigen Zugriff ist strengstens untersagt. Semperis befürwortet oder duldet keine illegalen Aktivitäten und lehnt jede Haftung ab, die aus dem Missbrauch des Materials entsteht. Darüber hinaus übernimmt Semperis keine Garantie für die Richtigkeit oder Vollständigkeit der Inhalte und haftet nicht für Schäden, die sich aus der Verwendung der Inhalte ergeben.