Data/Locales/checks/de/ADTradecraftChecks.json
|
{ "_family": "ADTradecraftChecks.json", "ADTRADE-001": { "name": { "value": "cpassword-Rückstände aus Gruppenrichtlinieneinstellungen in SYSVOL", "status": "machine-draft" }, "description": { "value": "Von 2008 bis Mai 2014 erlaubten Gruppenrichtlinieneinstellungen (Group Policy Preferences) Administratoren, geplante Aufgaben, lokale Benutzerkennwörter, zugeordnete Laufwerke und Dienste über ein Feld „cpassword“ zu verteilen – verschlüsselt mit einem AES-256-Schlüssel, den Microsoft öffentlich dokumentiert hat. Die Korrektur in MS14-025 deaktivierte das cpassword-Feld in NEUEN Einstellungen, ließ bestehende in SYSVOL jedoch unangetastet. Jedes Red-Team-Engagement findet diese immer noch. Jeder authentifizierte Domänenbenutzer kann SYSVOL lesen, das cpassword abgreifen und es offline entschlüsseln. Wenn Sie hier etwas finden, behandeln Sie jede offengelegte Anmeldeinformation als kompromittiert und wechseln Sie sie.", "status": "machine-draft" }, "recommendedValue": { "value": "Null cpassword-Attribute irgendwo unter \\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml.", "status": "machine-draft" }, "remediationSteps": { "value": "Durchsuchen Sie SYSVOL: Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'. Für jede Übereinstimmung: (1) Wechseln Sie das Kennwort des Kontos, dessen Anmeldeinformation offengelegt ist (der Benutzername steht in derselben XML), (2) prüfen Sie die Protokolle auf Verwendung dieser Anmeldeinformation seit Erstellung der Einstellung, (3) löschen Sie die GPP-Einstellung, sobald die neue Anmeldeinformation vorhanden ist. Microsofts KB2962486 enthält die Anleitung zur Bereinigung.", "status": "machine-draft" } }, "ADTRADE-002": { "name": { "value": "DCShadow-Indikator (unautorisierte Server der Konfigurationspartition)", "status": "machine-draft" }, "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) registriert einen vom Angreifer kontrollierten Host als Domänencontroller, indem nTDSDSA- + Server-Objekte unter CN=Sites,CN=Configuration geschrieben werden. Der gefälschte DC wird dann verwendet, um schädliche Replikationsdaten (SID-History, Kennwort-Hashes) einzuschleusen, ohne jemals ein echter DC zu sein. HINWEIS: In langlebigen Domänen ist ein nicht zuordenbares Server-Objekt weit häufiger ZURÜCKGEBLIEBENE DC-METADATEN (ein DC, der ohne „ntdsutil metadata cleanup“ entfernt wurde) als ein tatsächlicher DCShadow-Angriff, daher wird dies als Hoch statt als Kritisch eingestuft – untersuchen Sie den whenCreated-Zeitstempel, um ein kürzlich erstelltes (verdächtiges) Objekt von alten veralteten Metadaten zu unterscheiden.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle Server-Objekte unter CN=Sites,CN=Configuration entsprechen echten, inventarisierten Domänencontrollern. Keine kürzlich erstellten Server-Objekte, die keinem bekannten DC entsprechen.", "status": "machine-draft" }, "remediationSteps": { "value": "Aufzählen: Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated. Gleichen Sie mit Ihrem DC-Inventar ab (Get-ADDomainController -Filter *). Jedes Server-Objekt, das keinem echten DC entspricht, insbesondere kürzlich erstellte, erfordert eine sofortige Incident Response – DCShadow ist ein Primitiv auf Domänenübernahmeniveau. Überwachen Sie 5137-/5141-Ereignisse am Schema-Container als Signal zur Erkennungszeit.", "status": "machine-draft" } }, "ADTRADE-003": { "name": { "value": "Veraltete BitLocker-Wiederherstellungsschlüssel", "status": "machine-draft" }, "description": { "value": "BitLocker-Wiederherstellungsschlüssel werden in AD als msFVE-RecoveryInformation-Unterobjekte des Computers gespeichert, der sie gesichert hat. Wird ein Computer außer Betrieb genommen, das AD-Objekt aber zurückgelassen, bleiben die Wiederherstellungsschlüssel für jeden mit BitLocker-Wiederherstellungsrechten abfragbar – typischerweise eine breitere Gruppe als „Tier Zero“. Veraltete Schlüssel bedeuten, dass entsorgte Datenträger entschlüsselbar sind, wenn sie von einem Refurbisher oder aus dem Müll geborgen werden.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle msFVE-RecoveryInformation-Objekte gehören zu Computern, die in den letzten 90 Tagen aktiv waren. Keine Schlüssel, die deaktivierten oder kürzlich geänderten und dann veralteten Computerkonten zugeordnet und verwaist sind.", "status": "machine-draft" }, "remediationSteps": { "value": "Zählen Sie die Wiederherstellungsinformationen auf: Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated. Gehen Sie für jedes zum übergeordneten Computerobjekt hinauf und prüfen Sie dessen lastLogonTimestamp / Enabled. Für Computer, die >90 Tage inaktiv sind: Bestätigen Sie, dass der Datenträger gelöscht oder zerstört wurde, und löschen Sie dann das AD-Computerobjekt (was die Wiederherstellungsinformationen kaskadiert). Für aktiv genutzte Computer mit sehr alten Wiederherstellungsschlüsseln: Wechseln Sie über Backup-BitLockerKeyProtector. Stellen Sie sicher, dass die BitLocker-Wiederherstellungsgruppe eine enge Mitgliedschaft hat.", "status": "machine-draft" } }, "ADTRADE-004": { "name": { "value": "Hygiene der RODC-Kennwortreplikationsrichtlinie", "status": "machine-draft" }, "description": { "value": "Schreibgeschützte Domänencontroller (RODCs) speichern Kennwörter für die in ihrer Kennwortreplikationsrichtlinie (PRP) aufgeführten Prinzipale zwischen. Ist ein Tier-Zero-Konto (Domain Admin, Enterprise Admin, krbtgt) über die PRP eines RODC erreichbar – direkt oder über Gruppenverschachtelung –, kompromittiert die Kompromittierung des RODC diese Konten. Die standardmäßige Gruppe „Denied RODC Password Replication Group“ sollte DA / EA / SA / Schema Admins / krbtgt ausdrücklich enthalten; einige Umgebungen passen die Richtlinie an und entfernen diese Verweigerungen versehentlich.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle RODCs in der Domäne haben eine Kennwortreplikationsrichtlinie, in der Domain Admins, Enterprise Admins, Schema Admins, krbtgt und Account Operators Mitglieder der Verweigerungsseite sind. Keine hochprivilegierten Konten sind Mitglieder der Zulassungsseite.", "status": "machine-draft" }, "remediationSteps": { "value": "Für jeden RODC: Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }. Überprüfen Sie, dass die Verweigerungsliste die integrierte „Denied RODC Password Replication Group“ enthält. Falls Ihre Umgebung keine RODCs hat, ist diese Prüfung nicht zutreffend – BESTANDEN. Microsofts RODC-Planungsleitfaden enthält die kanonische PRP-Vorlage.", "status": "machine-draft" } }, "ADTRADE-005": { "name": { "value": "Schlüsselrotation des Entra-Seamless-SSO-Computerkontos (AZUREADSSOACC$)", "status": "machine-draft" }, "description": { "value": "Wenn Entra (Azure AD) Seamless Single Sign-On für hybride Identität aktiviert ist, erstellt AD ein Computerkonto namens AZUREADSSOACC$. Sein Kennwort ist der gemeinsame Kerberos-Schlüssel, den Entra zur Validierung von SSO-Tickets verwendet. Microsoft dokumentiert, dass dieser Schlüssel NICHT automatisch gewechselt wird – Administratoren müssen ihn rollieren. Extrahiert ein Angreifer den AZUREADSSOACC$-Schlüssel (es ist ein normaler NT-Hash, über DCSync oder von einem DC lesbar), kann er Kerberos-Silver-Tickets für den Azure-AD-Dienst fälschen und sich ohne weitere Interaktion als JEDER synchronisierte hybride Benutzer authentifizieren, solange der Schlüssel gültig bleibt. Ein seit über 90 Tagen nicht gewechselter Schlüssel vergrößert dieses Zeitfenster dramatisch.", "status": "machine-draft" }, "recommendedValue": { "value": "AZUREADSSOACC$-Kerberos-Schlüssel mindestens alle 90 Tage gewechselt (pro Rotation zweimal rollieren, um den vorherigen Schlüssel ungültig zu machen).", "status": "machine-draft" }, "remediationSteps": { "value": "Wechseln Sie den Seamless-SSO-Schlüssel auf einer Maschine mit dem Entra-Connect- / Azure-AD-Modul: Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest. Führen Sie die Rotation zweimal durch (das Konto speichert aktuellen + vorherigen Schlüssel) und planen Sie sie wiederkehrend ein. Falls Seamless SSO nicht mehr verwendet wird, deaktivieren Sie es und löschen Sie das AZUREADSSOACC$-Objekt.", "status": "machine-draft" } }, "ADTRADE-006": { "name": { "value": "Shadow Credentials (msDS-KeyCredentialLink) auf privilegierten Prinzipalen", "status": "machine-draft" }, "description": { "value": "Das Attribut msDS-KeyCredentialLink enthält öffentliche Schlüssel, die für die Anmeldung per Windows Hello for Business / kennwortloses PKINIT verwendet werden. Ein Angreifer mit Schreibzugriff auf dieses Attribut an einem Ziel kann sein EIGENES Schlüsselpaar hinzufügen (Whisker / pyWhisker) und anschließend mit dem passenden privaten Schlüssel ein Kerberos-TGT als dieses Konto anfordern – eine unauffällige Technik zur Persistenz und Identitätsübernahme, bekannt als „Shadow Credentials“. Jede unerwartete Schlüssel-Anmeldeinformation an einem Tier-Zero-Objekt (einem Domain Admin, einem Domänencontroller oder einem beliebigen adminCount=1-Konto) sollte als potenzielle Hintertür behandelt werden, bis nachgewiesen ist, dass es sich um eine legitime WHfB-Registrierung handelt.", "status": "machine-draft" }, "recommendedValue": { "value": "Keine unbekannten msDS-KeyCredentialLink-Werte auf privilegierten/Tier-Zero-Prinzipalen; jeder Schlüssel entspricht einer bekannten WHfB-/kennwortlosen Registrierung.", "status": "machine-draft" }, "remediationSteps": { "value": "Prüfen Sie für jeden gekennzeichneten Prinzipal die Schlüssel-Anmeldeinformationen (Get-ADObject -Properties msDS-KeyCredentialLink oder das DSInternals-Cmdlet Get-ADKeyCredential) und ordnen Sie jeden Geräteschlüssel einer legitimen Windows-Hello-for-Business-Registrierung zu. Entfernen Sie jeden Eintrag, den Sie keiner genehmigten Registrierung zuordnen können. Beschränken Sie, wer msDS-KeyCredentialLink schreiben darf (prüfen Sie Key Admins / Enterprise Key Admins sowie OU-/Objekt-DACLs, die diesen Schreibzugriff gewähren). Setzen Sie die betroffenen Konten zurück, falls eine Kompromittierung vermutet wird.", "status": "machine-draft" } }, "ADTRADE-007": { "name": { "value": "BadSuccessor-dMSA-Migrations-Eskalationsfläche", "status": "machine-draft" }, "description": { "value": "Windows Server 2025 führte delegierte verwaltete Dienstkonten (dMSA, Objektklasse msDS-DelegatedManagedServiceAccount) mit einer Migrationsfunktion ein: Ein dMSA kann als Ablösung eines bestehenden Kontos markiert werden, woraufhin es dessen Berechtigungen und Kerberos-Schlüssel erbt. Die 2024 offengelegte Technik „BadSuccessor“ missbraucht dies: Ein Prinzipal, der lediglich ein dMSA in einer OU ERSTELLEN kann (CreateChild für die dMSA-Klasse oder breite Schreib-/GenericAll-Rechte über die OU), kann eines erstellen, es auf ein privilegiertes Konto verweisen und dessen Schlüssel erben – und so zu diesem Konto eskalieren, ohne jemals direkt Rechte darüber zu besitzen. Diese Prüfung inventarisiert OUs, in denen ein Nicht-Tier-Zero-Prinzipal diese Fähigkeit besitzt.", "status": "machine-draft" }, "recommendedValue": { "value": "Kein Nicht-Tier-Zero-Prinzipal kann ein delegiertes MSA (msDS-DelegatedManagedServiceAccount) in irgendeiner OU erstellen oder schreiben.", "status": "machine-draft" }, "remediationSteps": { "value": "Entfernen Sie in jeder gekennzeichneten OU CreateChild (für die Klasse msDS-DelegatedManagedServiceAccount), GenericAll, WriteDacl und WriteOwner von nicht administrativen Prinzipalen. Prüfen Sie delegierte OU-Berechtigungen umfassend – dieselben ACEs, die BadSuccessor ermöglichen, ermöglichen auch andere Missbräuche bei der Objekterstellung. Überwachen Sie bis zur Behebung/Minderung die Erstellung von msDS-DelegatedManagedServiceAccount-Objekten (4662-/5137-Ereignisse). Diese Prüfung wird in Gesamtstrukturen ÜBERSPRUNGEN, deren Schema älter als Server 2025 ist.", "status": "machine-draft" } }, "ADTRADE-008": { "name": { "value": "Mitgliedschaft in Key Admins / Enterprise Key Admins", "status": "machine-draft" }, "description": { "value": "Den Gruppen Key Admins (Domänen-RID 526) und Enterprise Key Admins (RID 527) wird das Recht gewährt, das Attribut msDS-KeyCredentialLink domänen-/gesamtstrukturweit zu schreiben. Das macht jedes Mitglied zu einem domänenweiten Shadow-Credential-Primitiv: Ein Mitglied kann an jedem Konto Schlüssel-Anmeldeinformationen platzieren und sich per PKINIT als dieses Konto authentifizieren. Diese Gruppen werden LEER ausgeliefert und sollten leer bleiben, sofern nicht ein bestimmter Windows-Hello-for-Business-Workflow zur Schlüsselbereitstellung sie nachweislich erfordert. Jedes Mitglied ist ein Eskalationspfad, der begründet werden muss.", "status": "machine-draft" }, "recommendedValue": { "value": "Die Gruppen Key Admins und Enterprise Key Admins sind leer (keine ständigen Mitglieder).", "status": "machine-draft" }, "remediationSteps": { "value": "Überprüfen Sie jedes Mitglied von Key Admins und Enterprise Key Admins. Entfernen Sie jedes Konto, das keinen dokumentierten, fortlaufenden Bedarf zur Bereitstellung von Windows-Hello-for-Business-Schlüsseln hat. Falls die WHfB-Schlüsselbereitstellung delegierte Rechte erfordert, beschränken Sie diese auf ein dediziertes Dienstkonto mit den engstmöglichen Berechtigungen, statt auf eine Mitgliedschaft in diesen domänenweiten Gruppen. Behandeln Sie unerwartete Mitglieder als potenziellen Persistenzmechanismus.", "status": "machine-draft" } }, "ADTRADE-009": { "name": { "value": "Mitgliedschaft in der Gruppe Cert Publishers", "status": "machine-draft" }, "description": { "value": "Mitglieder der Gruppe Cert Publishers (Domänen-RID 517) dürfen Zertifikate im NTAuth-Speicher sowie an Benutzer-/Computerobjekten veröffentlichen. Standardmäßig enthält die Gruppe nur das/die Computerkonto/-konten der Enterprise-CA. Ein in diese Gruppe aufgenommenes Benutzer- oder Dienstkonto erlangt die Fähigkeit, zu beeinflussen, welche Zertifikate für die Authentifizierung als vertrauenswürdig gelten, was ein Sprungbrett in mehreren AD-CS-Eskalationspfaden (Angriffe der ESC-Klasse) ist und zertifikatbasierte Identitätsübernahme ermöglichen kann. Die Mitgliedschaft von Computerkonten (der CA-Hosts selbst) ist zu erwarten; jedes Nicht-Computer-Mitglied ist ein Befund.", "status": "machine-draft" }, "recommendedValue": { "value": "Cert Publishers enthält nur das/die Computerkonto/-konten der Enterprise-CA – keine Benutzer- oder Dienstkonten.", "status": "machine-draft" }, "remediationSteps": { "value": "Entfernen Sie jedes Benutzer- oder Dienstkonto aus der Gruppe Cert Publishers; dort gehören nur Computerkonten der Enterprise-CA hinein. Überprüfen Sie den Inhalt des NTAuth-Speichers (certutil -viewstore -enterprise NTAuth) auf unerwartete CA-Zertifikate. Härten Sie AD CS umfassend: Prüfen Sie die Registrierungsberechtigungen der Zertifikatvorlagen und die Fehlkonfigurationsfläche ESC1–ESC8.", "status": "machine-draft" } }, "ADTRADE-010": { "name": { "value": "Sicherheitslage und Kennwortoffenlegung gruppenverwalteter Dienstkonten (gMSA)", "status": "machine-draft" }, "description": { "value": "Gruppenverwaltete Dienstkonten (gMSA) besitzen 240-Bit-Kennwörter, die AD automatisch generiert und wechselt, wodurch Kerberoasting schwacher Dienstkontokennwörter und der manuelle Rotationsaufwand entfallen. Zwei Aspekte der Sicherheitslage: (1) ob gMSAs überhaupt für Dienstidentitäten verwendet werden und (2) wer berechtigt ist, das verwaltete Kennwort abzurufen, gesteuert durch die Sicherheitsbeschreibung msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). Gewährt diese Beschreibung einem breiten Prinzipal (Jeder, Authentifizierte Benutzer, Domänen-Benutzer) oder einem nicht privilegierten Prinzipal Zugriff, kann dieser Prinzipal das gMSA-Klartextkennwort wiederherstellen (z. B. GMSAPasswordReader) und den Dienst vollständig übernehmen.", "status": "machine-draft" }, "recommendedValue": { "value": "Dienstidentitäten laufen als gMSAs; msDS-GroupMSAMembership ist auf ausschließlich die konkreten Hosts beschränkt, die den Dienst ausführen müssen (keine breiten oder nicht privilegierten Prinzipale).", "status": "machine-draft" }, "remediationSteps": { "value": "Setzen Sie für jedes gMSA PrincipalsAllowedToRetrieveManagedPassword auf die genauen Computerkonten (oder eine eng gefasste Gruppe), die den Dienst ausführen: Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>. Entfernen Sie Jeder / Authentifizierte Benutzer / Domänen-Benutzer aus dieser Liste. Wo Dienstkonten noch statische Benutzerkontokennwörter verwenden, migrieren Sie sie zu gMSAs, um automatische Rotation und Kerberoasting-Resistenz zu erlangen.", "status": "machine-draft" } } } |