Shadow Credentials und msDS-KeyCredentialLink-Missbrauch

Was sind Shadow Credentials?

Shadow Credentials ist die in der Active-Directory-Community gebräuchliche Bezeichnung für einen Angriffspfad, der schlüsselbasiertes Authentifizierungsmaterial auf einem Konto missbraucht, meist über das Attribut msDS-KeyCredentialLink. Entscheidend ist nicht der Name. Entscheidend ist, dass ein Principal einen zusätzlichen Public-Key-Authentifizierungspfad erhalten kann, der vom Kennwort getrennt ist.

In einer legitimen Bereitstellung wird msDS-KeyCredentialLink von Windows Hello for Business und verwandten Key-Trust-Szenarien verwendet. Microsoft dokumentiert, dass in bestimmten hybriden Windows-Hello-for-Business-Bereitstellungen der öffentliche Schlüssel des Benutzers aus Microsoft Entra ID nach Active Directory synchronisiert und in das Attribut msDS-KeyCredentialLink des Benutzerobjekts geschrieben werden kann. Microsoft dokumentiert außerdem das Key-Trust-Verhalten für Kerberos PKINIT: Ein KDC, das Active Directory als Kontodatenbank verwendet, muss bestätigen, dass das Konto denselben öffentlichen Schlüssel in msDS-KeyCredentialLink besitzt.

Ein Shadow-Credentials-Missbrauch liegt vor, wenn ein Angreifer oder ein nicht autorisierter Administrator eine unerwartete Key Credential auf einem Benutzer- oder Computerobjekt hinzufügen oder beibehalten kann und anschließend den passenden privaten Schlüssel verwendet, um sich über einen schlüsselbasierten Ablauf als dieses Konto zu authentifizieren. Das ist kein Password Spraying, kein Kerberoasting, kein DCSync und kein Golden Ticket. Es ist eher ein ACL-gestützter Persistenz- und Impersonation-Pfad: Das Directory-Objekt des Kontos wurde so verändert, dass ein anderer Schlüssel die Authentifizierungsprüfungen erfüllen kann.

Dieser Artikel verwendet den Begriff Shadow Credentials, weil er bei Active-Directory-Verteidigern und Prüfern breit verstanden wird. Microsoft-Dokumentation beschreibt die zugrunde liegenden Mechanismen meist als Windows Hello for Business, Key Trust, PKINIT und msDS-KeyCredentialLink. Diese Unterscheidung ist wichtig: Das Attribut selbst ist nicht bösartig. Ein nicht leerer msDS-KeyCredentialLink-Wert kann in Umgebungen normal sein, die Windows Hello for Business, FIDO-nahe Abläufe oder Key-Trust-Funktionen nutzen. Das defensive Ziel ist, nicht autorisierte, verwaiste, unerwartete oder auf privilegierten Konten vorhandene Key Credentials zu identifizieren, nicht jeden Wert pauschal zu löschen.

Für den größeren Kontext von Identitäts-Angriffspfaden siehe AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen und ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen. Shadow Credentials gehören in dieselbe Risikofamilie, weil die Ursache häufig eine übermäßige Schreibfähigkeit auf einem Identitätsobjekt ist.

Wie msDS-KeyCredentialLink funktioniert

Legitimer Speicher für Key Credentials

msDS-KeyCredentialLink speichert Key-Credential-Daten auf einem Active-Directory-Objekt. Die Microsoft Open Specifications beschreiben KEYCREDENTIALLINK_BLOB als die Struktur, die im binären Teil des DN-Binary-Attributs msDS-KeyCredentialLink gespeichert wird. Microsoft dokumentiert außerdem Einschränkungen für das Hinzufügen von Werten auf Computerobjekten, unter anderem dass der binäre Teil ein gültig formatiertes KEYCREDENTIALLINK_BLOB sein muss, dass die Verwendung KEY_USAGE_NGC ist und dass die Quelle für diese dokumentierte Computer-Konto-Operation KEY_SOURCE_AD ist.

Diese Spezifikation für Computerobjekte darf nicht pauschal auf jedes Benutzerobjekt-Szenario übertragen werden. Für Benutzerobjekte ist die klarste operative Quelle die Windows-Hello-for-Business-Dokumentation: Nachdem ein Benutzer in bestimmten hybriden Umgebungen eine Windows-Hello-for-Business-Anmeldeinformation bereitgestellt hat, kann der öffentliche Schlüssel des Benutzers nach AD synchronisiert und in msDS-KeyCredentialLink geschrieben werden. Microsoft-Supportdokumentation stellt außerdem ein Skript bereit, mit dem Benutzerobjekte mit nicht leeren msDS-KeyCredentialLink-Werten aufgelistet und Felder wie Source, Usage, DeviceID und KeyID extrahiert werden können.

Key-Trust-Authentifizierungspfad

Die Authentifizierungsseite basiert auf Public-Key-Kryptografie. RFC 4556 definiert PKINIT als Public-Key-Kryptografie für den initialen Kerberos-Authentifizierungsaustausch. Microsofts PKCA-Dokumentation beschreibt, wie Windows PKINIT und Key Trust implementiert. In einem Key-Trust-Fall kann der KDC ein Konto anhand des öffentlichen Schlüssels nachschlagen, und Implementierungen mit Active Directory müssen bestätigen, dass derselbe öffentliche Schlüssel in msDS-KeyCredentialLink vorhanden ist.

Praktisch defensiv formuliert gibt das Attribut AD eine Möglichkeit, ein Konto mit Schlüsselmaterial zu verknüpfen, das für Authentifizierung genutzt werden kann. Der private Schlüssel sollte auf dem legitimen Gerät oder im Credential-Container geschützt bleiben. Der öffentliche Schlüssel ist das, womit AD prüfen kann, ob der Authentifizierungsversuch zu einem erwarteten Schlüssel passt. Wird einem hochwertigen Konto ein nicht autorisierter Schlüssel hinzugefügt, erhält dieses Konto einen zusätzlichen Authentifizierungspfad, den Verteidiger bei normalen Kennwortprüfungen leicht übersehen können.

Kennwort-Resets reichen nicht aus

Deshalb unterscheiden sich Shadow Credentials von einer kennwortbasierten Kompromittierung. Ein Kennwort-Reset adressiert ein gestohlenes Kennwort. Er entfernt nicht zwangsläufig einen nicht autorisierten Key-Credential-Wert vom Konto. Microsoft dokumentiert, dass Anmeldung und Entsperrung mit Windows Hello for Business einen Schlüssel oder ein Zertifikat verwenden und dass eine Änderung des Benutzerkennworts dieses Anmelde- oder Entsperrverhalten nicht beeinflusst. Für Incident Response bedeutet das: Kennwortrotation kann notwendig sein, reicht aber nicht aus, wenn das Kontoobjekt weiterhin nicht autorisiertes Schlüsselmaterial enthält.

Warum Key Trust das Angriffsmodell verändert

Klassische Active-Directory-Härtung konzentriert sich häufig auf Kennwörter, NTLM-Exposition, Kerberos-Service-Tickets und Mitgliedschaften in privilegierten Gruppen. Diese Themen bleiben wichtig, aber Key Trust stellt eine andere Frage: Wer kann das Kontoobjekt oder das mit dem Konto verknüpfte Schlüsselmaterial verändern?

Wenn ein Benutzer oder Dienst effektive Rechte zum Schreiben von msDS-KeyCredentialLink hat oder die DACL beziehungsweise den Besitzer des Objekts ändern kann, um diese Schreibfähigkeit zu erhalten, geht das Risiko über eine normale Kontoanmeldung hinaus. Es wird zur Kontrolle über das Identitätsobjekt. Windows Event 4662 hebt Write Property, WRITE_DAC und WRITE_OWNER als Zugriffstypen hervor, die auf AD-Objekten wichtig zu überwachen sind. Diese Rechte sind nicht automatisch bösartig, verdienen aber auf privilegierten Benutzern, Dienstkonten, Domänencontrollern oder Administrations-OUs deutlich mehr Aufmerksamkeit.

Deshalb sind Shadow Credentials auch ein Angriffspfadproblem. Der Einstiegspunkt kann eine delegierte Helpdesk-Gruppe, ein Dienstkonto mit breiten Objektrechten, eine geerbte Berechtigung auf einer OU oder eine veraltete administrative Delegation sein. Der Endzustand kann ein persistenter Authentifizierungspfad gegen ein privilegiertes Konto sein. Wenn Verteidiger nur Gruppenmitgliedschaften prüfen, übersehen sie möglicherweise die Objektberechtigung, die den Pfad ermöglicht hat. Gruppenverschachtelung kann zusätzlich verschleiern, wer effektiv delegierte Kontrolle erhält; prüfen Sie deshalb AD Gruppenverschachtelung: Versteckte DA-Pfade, wenn geerbte Rechte eine Rolle spielen.

Vergleichen Sie das mit Kerberos-Delegation: unkontrolliert bis RBCD. Delegationsmissbrauch hängt von Delegationseinstellungen und Dienstidentitätsbeziehungen ab. Shadow Credentials hängen von Schlüsselmaterial und Schreibkontrolle über das Objekt ab. Beide Themen liegen in der Nähe von Kerberos, aber sie sind nicht derselbe Fehlerzustand und sollten nicht in einem generischen Kerberos-Artikel vermischt werden.

Voraussetzungen für Missbrauch

Ein Shadow-Credentials-Szenario erfordert im Allgemeinen alle folgenden Bedingungen:

Bedingung	Defensive Bedeutung
Ein Zielkonto unterstützt einen relevanten schlüsselbasierten Authentifizierungspfad	Die Umgebung nutzt oder akzeptiert Key Trust, zertifikatgestützte Authentifizierung oder Windows-Hello-for-Business-Muster, die auf Public-Key-Validierung beruhen.
Ein nicht autorisierter Principal kann Key-Credential-Material hinzufügen oder erhalten	Die gefährliche Berechtigung kann direkter Schreibzugriff auf das Attribut oder breitere Objektkontrolle sein, die zu diesem Schreibzugriff führt.
Der Angreifer kontrolliert den passenden privaten Schlüssel	AD speichert die öffentliche Seite. Authentifizierung gelingt nur, wenn der Client den Besitz des passenden privaten Schlüssels beweisen kann.
Die Aktivität wird nicht erkannt oder bereinigt	Der Wert bleibt auf dem Objekt und kann eine rein kennwortbasierte Bereinigung überleben.

Was für sich allein keine Schwachstelle ist

Diese Voraussetzungen müssen sorgfältig gelesen werden. Die Präsenz von Windows Hello for Business bedeutet nicht automatisch, dass die Umgebung verwundbar ist. Die Präsenz von msDS-KeyCredentialLink bedeutet nicht automatisch Kompromittierung. Das Risiko entsteht, wenn Kontoobjektberechtigungen, Key-Credential-Inventar und Authentifizierungstelemetrie zeigen, dass eine unerwartete Key Credential hinzugefügt wurde oder verwendet wird.

Besonderheit bei Computerobjekten

Computerobjekte verdienen eine eigene Einschränkung. Microsoft dokumentiert Domain-Joined Device Public Key Authentication und erklärt, dass moderne Windows-Geräte einen gebundenen öffentlichen Schlüssel für ihr Computerkonto bereitstellen können, wenn ein Windows Server 2016 oder neuerer Domänencontroller unterstützt wird. Verteidiger sollten daher legitimes Schlüsselmaterial auf manchen Computerkonten erwarten. Die Kontrolle lautet nicht: keine Key Credentials irgendwo. Die Kontrolle lautet: korrekte Eigentümerschaft, erwartete Gerätezuordnung und eingeschränkte Schreibfähigkeit.

Besonderheit bei privilegierten Konten

Privilegierte Konten brauchen einen strengeren Maßstab. Microsofts Dokumentation zu Windows-Hello-for-Business-Dual-Enrollment beschreibt Key-Admins-Berechtigungen auf msDS-KeyCredentialLink und AdminSDHolder-Aspekte für geschützte privilegierte Benutzer und Gruppen. Das ist ein klares Signal für Verteidiger: Jeder Workflow, der absichtlich schlüsselbasierte Anmeldung für privilegierte Identitäten ermöglicht, muss dokumentiert, begrenzt und überwacht werden, weil er dieselbe Kontrollfläche berührt, die Angreifer missbrauchen würden.

Die Angriffskette

Ein sicheres defensives Modell der Angriffskette sieht so aus:

Phase	Was passiert	Was Verteidiger prüfen sollten
1. Berechtigungsermittlung	Der Angreifer identifiziert ein Konto oder eine OU, wo er Attribute oder den Sicherheitsdeskriptor des Zielobjekts beeinflussen kann.	Effektive Rechte auf hochwertigen Benutzern, Computerkonten, Dienstkonten und Administrations-OUs prüfen.
2. Hinzufügen einer Key Credential	Ein unerwarteter Key-Credential-Wert wird zu `msDS-KeyCredentialLink` hinzugefügt.	Event 5136 für den LDAP-Anzeigenamen `msDS-KeyCredentialLink` überwachen, besonders `Value Added`-Operationen.
3. Schlüsselbasierte Authentifizierung	Der Angreifer versucht Authentifizierung mit dem privaten Schlüssel, der zum hinzugefügten öffentlichen Schlüssel passt.	4768-Events, PKINIT- oder Smartcard-ähnliche Pre-Authentication-Muster, Quellhosts und Kontosensitivität korrelieren.
4. Laterale Bewegung oder Persistenz	Das Konto wird für Zugriff, Rechteausweitung oder Persistenz genutzt, während Kennwortrotation allein den Schlüsselpfad möglicherweise nicht entfernt.	Nicht autorisierte Key Credentials entfernen, Objektberechtigungen korrigieren und validieren, dass keine unerwartete schlüsselbasierte Authentifizierung weiterläuft.

Der Artikel liefert bewusst keine tool-spezifischen Exploit-Befehle. Verteidiger benötigen keinen kopierbaren Ausnutzungspfad, um den Kontrollfehler zu verstehen. Der Kernpunkt ist, dass eine Directory-Objektänderung einen Authentifizierungspfad schaffen kann, den normale Kennworthygiene nicht entfernt.

Diese Angriffskette erklärt auch, warum Shadow Credentials häufig neben anderen AD-Risiken stehen. Ein veraltetes privilegiertes Konto, eine gefährliche geerbte ACL oder ein schwaches Delegationsmodell kann die Bedingungen für den Key-Credential-Schreibzugriff schaffen. Zur Kontenexposition siehe Veraltete und Überprivilegierte Konten in AD. Für Kerberos-Persistenzkontext vergleichen Sie die andere Mechanik von Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain.

Erkennung

Shadow-Credentials-Erkennung sollte korrelationsbasiert sein. Kein einzelnes Windows-Ereignis beweist die vollständige Technik. Eine brauchbare Erkennung kombiniert Directory-Änderungsbeweise, Objektberechtigungskontext, Authentifizierungsverhalten und legitimes Windows-Hello-for-Business-Inventar.

Signal	Quelle	Was es beweisen kann	Einschränkung
`msDS-KeyCredentialLink`-Wert hinzugefügt oder geändert	Event 5136, Directory Service Changes	Das Objektattribut wurde geändert; das Ereignis kann LDAP-Anzeigename, Operationstyp, Objekt-DN und Korrelations-ID zeigen.	Es beweist nicht, dass die Änderung bösartig ist. WHfB-Enrollment oder Geräteabläufe können legitim sein.
Schreibzugriff auf sensible Objekte	Event 4662, SACL auf AD-Objekten	Ein Principal hat Operationen wie `Write Property`, `WRITE_DAC` oder `WRITE_OWNER` auf überwachten Objekten oder Eigenschaften ausgeführt oder versucht.	Erfordert korrektes Auditing und SACL-Abdeckung. Ohne SACLs kann Beweismaterial fehlen.
TGT-Anforderung mit Public-Key-artiger Pre-Authentication	Event 4768 auf Domänencontrollern	Ein TGT wurde angefordert; das Ereignis enthält den Pre-Authentication-Typ und in relevanten Szenarien zertifikatsbezogene Felder.	Es ist Authentifizierungstelemetrie, kein Beweis, dass ein bösartiger Schlüssel hinzugefügt wurde. Mit 5136/4662 und Kontokontext korrelieren.
Inventar nicht leerer Key Credentials	AD-Abfrage oder Microsoft-Support-artiges Parsing	Welche Benutzer `msDS-KeyCredentialLink`-Werte haben und was Felder wie Source, Usage, DeviceID und KeyID zeigen.	Das Inventar muss mit bekannten WHfB-, FIDO- oder Geräte-Enrollment-Datensätzen verglichen werden.
Unerwartete effektive Berechtigungen	AD-ACL-Prüfung	Welche Benutzer, Gruppen oder Dienste das Attribut schreiben oder die Objektsicherheit ändern können.	Berechtigungsbefunde sind Exposition, kein Beweis für Ausnutzung.

Directory-Änderungstelemetrie

Für 5136 empfiehlt Microsoft, das Feld LDAP Display Name zu überwachen, wenn Änderungen an einem bestimmten AD-Attribut verfolgt werden. Für dieses Thema ist der relevante Anzeigename msDS-KeyCredentialLink. Priorisieren Sie Value Added-Events und korrelieren Sie anschließend nach Objekt-DN, Konto, das die Änderung ausgeführt hat, Quellworkstation soweit verfügbar und nahen Directory-Operationen mit derselben Korrelations-ID.

Für 4662 priorisieren Sie hochwertige Benutzer, privilegierte Gruppen, Administrations-OUs, Dienstkonten und Computerobjekte, die sensible Infrastruktur darstellen. Microsoft hebt Zugriffstypen wie Write Property, WRITE_DAC und WRITE_OWNER als wichtig zu überwachen hervor. Für eine Shadow-Credentials-Suche sind sie besonders relevant, wenn sie ein privilegiertes Identitätsobjekt oder eine Property-GUID betreffen, die msDS-KeyCredentialLink zugeordnet ist.

Authentifizierungskorrelation

Für 4768 behandeln Sie das Ereignis als Authentifizierungskontext. Microsoft dokumentiert, dass 4768 erzeugt wird, wenn der KDC ein TGT ausstellt, und dass das Ereignis ein Feld Pre-Authentication Type enthält. Typen, die mit Smartcard- oder Public-Key-Authentifizierung verbunden sind, können helfen, schlüsselbasierte Authentifizierungsmuster zu erkennen, müssen aber mit Directory-Änderungen und erwartetem Anmeldeverhalten korreliert werden. Wenn ein privilegiertes Konto plötzlich schlüsselbasierte Authentifizierung nach einer unerwarteten Attributänderung zeigt, ist die kombinierte Geschichte deutlich stärker als eines der Ereignisse allein.

Inventarfragen

Eine praktische Suche sollte diese Fragen beantworten:

Welche privilegierten Benutzer, Dienstkonten und Computerkonten haben nicht leere msDS-KeyCredentialLink-Werte?
Sind diese Werte für eine dokumentierte Windows-Hello-for-Business-, FIDO- oder Geräteauthentifizierungsbereitstellung erwartet?
Ordnet sich jeder Eintrag einem bekannten Gerät, erwarteten Benutzer, erwarteten KeyID und erwarteter Quelle zu?
Wer kann das Attribut schreiben oder DACL beziehungsweise Besitzer des Objekts ändern?
Wurden Key-Credential-Werte kurz vor ungewöhnlicher Kerberos-Authentifizierung oder administrativer Aktivität hinzugefügt?

Für eine breitere Ereignisabdeckung verwenden Sie AD Sicherheitsüberwachung: Event IDs und SIEM als ergänzende Checkliste, aber halten Sie die Shadow-Credentials-Korrelation spezifisch. Generisches Kerberos-Monitoring reicht nicht aus.

Remediation

Remediation muss gezielt erfolgen. Ein pauschales Leeren von msDS-KeyCredentialLink in der gesamten Domäne kann legitime Windows-Hello-for-Business- oder Geräteauthentifizierungsszenarien brechen. Der sicherere Ansatz ist, Eigentümerschaft zu validieren, nicht autorisierte Werte zu entfernen und die Berechtigungen zu korrigieren, die den Wert ermöglicht haben.

Inventar und Triage

Beginnen Sie mit Inventar. Listen Sie Benutzer und Computer mit nicht leeren msDS-KeyCredentialLink-Werten auf und parsen Sie die Werte, soweit möglich, in Felder wie Source, Usage, DeviceID und KeyID. Microsoft-Supportdokumentation zeigt diese Analyse für Benutzerobjekte und erklärt, dass das passende Zertifikat im persönlichen Zertifikatspeicher des Benutzers auf dem Computer mit der passenden Gerätekennung zu finden sein sollte. In einer verwalteten Umgebung sollte dieses Inventar außerdem mit Microsoft-Entra-Gerätedatensätzen, Windows-Hello-for-Business-Enrollment-Datensätzen und dem Privileged-Access-Prozess verglichen werden.

Trennen Sie anschließend erwartete von unerwarteten Werten. Erwartete Werte sollten bekannten Benutzern, Geräten und Authentifizierungsdesigns zugeordnet sein. Unerwartete Werte sind Einträge auf Konten, die keine schlüsselbasierte Authentifizierung nutzen sollten, Einträge ohne Zuordnung zu einem genehmigten Gerät, Einträge, die von einem nicht genehmigten Principal hinzugefügt wurden, Einträge nach verdächtiger administrativer Aktivität oder Werte auf privilegierten Konten ohne dokumentierten Dual-Enrollment- oder Privileged-Workstation-Prozess.

Nur nicht autorisierte Werte entfernen

Bei bestätigten nicht autorisierten Einträgen entfernen Sie den konkreten nicht autorisierten Wert vom Objekt. Verlassen Sie sich nicht allein auf Kennwort-Reset. Ein Kennwort-Reset kann weiterhin erforderlich sein, wenn das Konto anderweitig kompromittiert wurde, beweist aber nicht allein, dass schlüsselbasiertes Authentifizierungsmaterial aus AD entfernt wurde.

Den Berechtigungspfad korrigieren

Nach der Wertebereinigung korrigieren Sie Berechtigungen. Prüfen Sie direkte und geerbte Rechte, die das Schreiben von msDS-KeyCredentialLink, das breite Schreiben von Objekteigenschaften, das Ändern der DACL oder das Ändern des Objektbesitzers ermöglichen. Entfernen Sie breite Delegationen von privilegierten Konten, Administrations-OUs, Dienstkonto-OUs und Computerkonten, wenn sie nicht erforderlich sind. Wenn ein Helpdesk- oder Automatisierungsworkflow Windows-Hello-for-Business-Enrollment legitim verwalten muss, grenzen Sie ihn eng ein und überwachen ihn explizit.

Für privilegierte Konten prüfen Sie Key Admins und verwandte Gruppen. Microsofts Dual-Enrollment-Dokumentation beschreibt Key-Admins-Berechtigungen auf msDS-KeyCredentialLink und AdminSDHolder-Aspekte für geschützte Konten. Wenn Windows-Hello-for-Business-Enrollment für privilegierte Konten erlaubt ist, dokumentieren Sie, welche Geräte genehmigt sind, welche Konten erlaubt sind und wie neue Key-Credential-Werte autorisiert werden. Wenn es nicht erlaubt ist, sollten privilegierte Konten nicht stillschweigend Key Credentials ansammeln.

Härten Sie schließlich das Betriebsmodell. Verwenden Sie Tiered Administration oder eine gleichwertige Admin-Isolation, damit weniger vertrauenswürdige Workstations und breite delegierte Gruppen keine hochwertigen Identitätsobjekte verändern können. Trennen Sie privilegierte Identitätsadministration von täglichen Produktivitätskonten. Prüfen Sie Angriffspfade regelmäßig, weil dieses Problem meist durch eine Rechtekette und nicht durch eine einzelne offensichtliche Gruppenmitgliedschaft entsteht.

Validierung nach der Bereinigung

Validierung sollte sowohl die Bereinigung als auch die Wiederherstellung der Kontrolle belegen.

Validierungsschritt	Erfolgskriterium
Key-Credential-Inventar erneut ausführen	Nur erwartete `msDS-KeyCredentialLink`-Werte bleiben, und jeder ist einem dokumentierten Benutzer, Gerät, Source, Usage und KeyID zugeordnet.
Objektberechtigungen erneut prüfen	Kein nicht autorisierter Principal kann das Attribut schreiben, breite Objekteigenschaften schreiben, DACL ändern oder Besitzer auf hochwertigen Konten ändern.
5136 nach Bereinigung prüfen	Keine unerwarteten `Value Added`-Operationen für `msDS-KeyCredentialLink` auf privilegierten Konten oder sensiblen Computern.
4662 nach Bereinigung prüfen	Write-Property- und Security-Descriptor-Aktivität auf überwachten Objekten entspricht genehmigten Admin-Workflows.
4768 nach Bereinigung prüfen	Schlüsselbasierte Authentifizierung für sensible Konten erfolgt nur von erwarteten Benutzern, Geräten und Szenarien.
Legitime WHfB/FIDO-Flows testen	Genehmigte Benutzer können sich weiterhin anmelden, wenn das Unternehmen bewusst auf Key Trust setzt.

Wenn ein Vorfall ein privilegiertes Konto betraf, sollte die Validierung auch nachgelagerte Aktivität prüfen. Prüfen Sie administrative Anmeldungen, Gruppenmitgliedschaftsänderungen, Dienstkonfigurationsänderungen, GPO-Änderungen, neue Zertifikate und jede spätere Bewegung, die die wiedergewonnene Identität genutzt haben könnte. Shadow Credentials können die Zugriffsmethode sein, aber nicht zwingend das Endziel.

Wie EtcSec verwandte Exposition erkennt

EtcSec sollte diesen Artikel nicht mit einem ungenauen Schwachstellentyp versehen, wenn der Katalog keinen direkten Shadow-Credentials- oder msDS-KeyCredentialLink-Eintrag enthält. Die verwandte Exposition passt trotzdem zum Active-Directory-Auditmodell von EtcSec: gefährliche Objektberechtigungen, Exposition privilegierter Konten, geerbte ACL-Pfade und Monitoring-Lücken rund um AD-Objektänderungen.

Praktisch kann eine EtcSec-Prüfung helfen, die Bedingungen zu identifizieren, die diesen Angriffspfad ermöglichen: Principals mit übermäßiger Schreibkontrolle über Benutzer- oder Computerobjekte, nicht isolierte privilegierte Konten, gefährliche ACL-Pfade zu administrativen Identitäten und Monitoring-Lücken bei Directory-Objektänderungen. Das ist der richtige Rahmen. Shadow Credentials sind keine generische Kerberos-Schwäche; sie sind ein Key-Trust-Missbrauchspfad, der durch Objektkontrolle entsteht.

Kontrolle	Warum sie wichtig ist
`msDS-KeyCredentialLink` auf Benutzern und Computern inventarisieren	Legt fest, welche schlüsselbasierten Authentifizierungspfade vor einem Vorfall existieren.
Schreibzugriff auf Key-Credential-Attribute einschränken	Verhindert, dass nicht autorisierte Principals neues Authentifizierungsmaterial hinzufügen.
5136 auf `msDS-KeyCredentialLink` überwachen	Erfasst attributbezogene Änderungen, wenn Directory Service Changes Auditing und SACLs konfiguriert sind.
4662 auf sensiblen Identitätsobjekten überwachen	Zeigt Write-Property-, DACL- und Ownership-Operationen, wenn SACLs vorhanden sind.
4768 mit Directory-Änderungen korrelieren	Hilft, schlüsselbasiertes Authentifizierungsverhalten mit jüngsten Objektänderungen zu verbinden.
Privilegierte Konten durch Admin-Isolation schützen	Reduziert die Chance, dass eine Kompromittierung niedrigerer Ebenen hochwertige Identitätsobjekte verändern kann.
Key Admins und AdminSDHolder-Verhalten prüfen	Verhindert, dass legitime WHfB-Administrationspfade zu unkontrollierten privilegierten Key-Write-Pfaden werden.

Shadow Credentials: Missbrauch von msDS-KeyCredentialLink in Active Directory