Data/Locales/checks/de/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Audit des Azure-AD-Connect-Synchronisierungskontos (MSOL_)", "status": "machine-draft" }, "description": { "value": "Wenn Azure AD Connect im Expressmodus installiert wird, erstellt es ein Domänenkonto mit dem Namen MSOL_<zufälliger-Hex> und gewährt ihm Replicating Directory Changes + Replicating Directory Changes All im Domänennamenskontext – also DCSync-Rechte. Das Konto ist faktisch Tier Zero, liegt aber standardmäßig im Standardcontainer Users, hat eine Kennwortablauffrist von 10 Jahren und taucht in Werkzeugen zur Aufzählung privilegierter Gruppen selten auf, da es seine Macht über direkte ACL statt über Gruppenmitgliedschaft erhält. Die Kompromittierung dieses Kontos entspricht funktional einer Domänenübernahme.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle MSOL_-Konten sind inventarisiert, das Kennwort innerhalb der letzten 180 Tage gewechselt, in eine Tier-Zero-OU mit eingeschränkten Anmelderechten verschoben, und der AAD-Connect-Server selbst ist als Tier-Zero-System gehärtet.", "status": "machine-draft" }, "remediationSteps": { "value": "Suchen Sie das MSOL_-Konto: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Bestätigen Sie, dass es DCSync-Rechte besitzt: dsacls 'DC=domain,DC=com' | findstr MSOL_. Verschieben Sie es in eine Tier-Zero-Admin-OU. Wechseln Sie das Kennwort mit dem AAD-Connect-Werkzeug (setzen Sie es NICHT über Standardwerkzeuge zurück – verwenden Sie Add-ADSyncADDSConnectorAccount im PowerShell-Modul ADSync auf dem AAD-Connect-Server). Wenden Sie eine GPO zur Anmeldebeschränkung an, sodass sich das Konto nur lokal beim AAD-Connect-Server selbst anmelden kann. Behandeln Sie den AAD-Connect-Host als Tier Zero – beschränken Sie, wer ihn per RDP/Admin verwalten darf.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Dienstkonten von Sicherungssoftware in privilegierten Gruppen", "status": "machine-draft" }, "description": { "value": "Sicherungssoftware (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) verlangt typischerweise ein Dienstkonto mit sehr hohen Berechtigungen. Die Dokumentation schlägt zur einfachen Einrichtung oft Domain Admin vor, und viele Administratoren folgen dem. Sobald ein Angreifer den Sicherungsserver kompromittiert (ein häufiger initialer Zugriffsvektor bei Ransomware), erbt er über das Dienstkonto Domain Admin. Dies ist in den Incident-Response-Daten von 2023 bis 2025 der Eskalationspfad Nummer 1 bei Ransomware.", "status": "machine-draft" }, "recommendedValue": { "value": "Keine Dienstkonten von Sicherungssoftware sind Mitglieder von Domain Admins, Enterprise Admins, Schema Admins oder Backup Operators. Verwenden Sie vom Hersteller dokumentierte Konten mit geringsten Rechten und isolierte Sicherungsanmeldeinformationen.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifizieren Sie das eingesetzte Sicherungsprodukt und befolgen Sie dessen Leitfaden für geringste Rechte (Veeam: nur lokaler Administrator des Sicherungsservers + AD-Konto mit Objektlesezugriff; Rubrik: dediziertes Dienstprinzipal in einer reinen Cloud-Rolle usw.). Entfernen Sie das Sicherungskonto aus Domain Admins. Migrieren Sie zu einem gMSA, wo unterstützt. Platzieren Sie den Sicherungsserver in einer Tier-1-OU mit eingeschränkten Anmelderechten. Falls für eine bestimmte Arbeitslast tatsächlich vollständiger DA erforderlich ist, dokumentieren Sie dies und isolieren Sie diesen Teil der Sicherung auf ein eigenes Konto, getrennt vom Hauptkonto.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Dienstkonten von Hypervisoren / Virtualisierung in privilegierten Gruppen", "status": "machine-draft" }, "description": { "value": "Integrationen von vCenter / Hyper-V / SCVMM / Citrix / Nutanix mit AD verwenden häufig ein während der Einrichtung konfiguriertes Dienstkonto. Ist dieses Konto ein Domain Admin, kaskadiert die Kompromittierung der Verwaltungsebene des Hypervisors (oder der SSO-Datenbank des Hosts) zu AD. Der Hypervisor ist konzeptionell bereits Tier Zero; seine AD-Identität sollte dem entsprechen.", "status": "machine-draft" }, "recommendedValue": { "value": "Hypervisor-Dienstkonten haben nur die vom Hersteller dokumentierten Rechte (typischerweise Lesezugriff für das Inventar + bestimmte OU-Schreibrechte, falls die VM-AD-Integration verwendet wird). Nicht in Domain Admins.", "status": "machine-draft" }, "remediationSteps": { "value": "Überprüfen Sie das AD-Dienstkonto für jedes Hypervisor-Produkt. Wenden Sie die Herstellerrichtlinien für geringste Rechte an. Für vCenter: Verwenden Sie das dokumentierte SSO-Identitätsquellenmuster, statt einen Domain Admin zuzuordnen. Für Hyper-V/SCVMM: Beschränken Sie die Rechte des Dienstkontos auf die OUs, die die VM-Computerkonten hosten. Behandeln Sie den Hypervisor-Verwaltungshost in Ihrem Administrationsmodell als Tier Zero.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Dienstkonten des Konfigurationsmanagements in privilegierten Gruppen", "status": "machine-draft" }, "description": { "value": "Konfigurationsmanagementplattformen (SCCM/MECM, Intune-Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) verteilen per Definition Software an jeden Endpunkt – sie sind bereits eine privilegierte Plattform für Lateralbewegung. Insbesondere SCCM verfügt über bekannte Missbrauchsprimitiven (Offenlegung des Netzwerkzugriffskontos, NTLM-Coercion zum Standortserver, Client-Push). Ein Konfigurationsmanagement-Dienstkonto in Domain Admins verschafft einem Angreifer, der auf einem beliebigen verwalteten Endpunkt landet, die Schlüssel zur Domäne.", "status": "machine-draft" }, "recommendedValue": { "value": "Konfigurationsmanagement-Dienstkonten sind auf ihre dokumentierten Mindestrechte beschränkt und niemals in Domain Admins / Enterprise Admins. Das SCCM-Netzwerkzugriffskonto ist eine nicht privilegierte dedizierte Identität.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifizieren Sie das Konfigurationsmanagementprodukt und überprüfen Sie die Rechte des Dienstkontos. Für SCCM: Stellen Sie sicher, dass das Netzwerkzugriffskonto nicht privilegiert ist (KEIN Domain Admin); stellen Sie sicher, dass das Maschinenkonto des Standortservers kein Domain Admin ist; überprüfen Sie die Hierarchie-Dienstkonten auf geringste Rechte. Verschieben Sie Standortserver und Verwaltungspunkte in eine Tier-Zero-OU mit eingeschränkten Anmeldungen.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "SQL-/Datenbankdienstkonten in privilegierten Gruppen", "status": "machine-draft" }, "description": { "value": "Dienstkonten von SQL Server / MySQL / PostgreSQL in Domain Admins sind in Umgebungen verbreitet, in denen das DBA-Team SQL mit der Standardempfehlung „Vorhandenes AD-Konto verwenden“ installiert und aus Bequemlichkeit ein Administratorkonto gewählt hat. Sobald der Datenbankserver im Netzwerk erreichbar ist, verschafft die Kompromittierung einer SQL-Anmeldeinformation oder eine SQL-Server-Schwachstelle dem Angreifer direkt Domain Admin.", "status": "machine-draft" }, "recommendedValue": { "value": "Datenbankdienstkonten laufen als gMSAs oder dedizierte Dienstidentitäten ohne Mitgliedschaft in privilegierten Gruppen.", "status": "machine-draft" }, "remediationSteps": { "value": "Migrieren Sie SQL-Dienstkonten zu gMSA, wo unterstützt. Entfernen Sie bei Konten, die benutzerbasiert bleiben müssen, die Mitgliedschaft in privilegierten Gruppen und gewähren Sie nur die lokalen Rechte, die die Datenbank-Engine benötigt (Anmelden als Dienst, Überprüfen durchsuchen umgehen, Speicherkontingente für einen Prozess anpassen – siehe Microsoft-Dokumentation für die konkreten Rechte).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Tier-Zero-Administratorkonten außerhalb einer dedizierten Tier-Zero-OU", "status": "machine-draft" }, "description": { "value": "Wenn Ihre Domain Admins in derselben OU wie reguläre Benutzer liegen, gilt jede GPO, die auf Benutzer abzielt (Anmeldeskripte, Browserrichtlinie, zugeordnete Laufwerke usw.), auch für Ihre Domain Admins – das bedeutet, jeder, der diese GPOs bearbeiten kann, kann bei der nächsten Anmeldung Code als Domain Admin ausführen. Das gestufte Microsoft-Modell empfiehlt eine dedizierte Tier-Zero-Administrator-OU mit eingeschränkter GPO-Autorenschaft und eingeschränkten Anmelderechten.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle Mitglieder von Domain Admins, Enterprise Admins und Schema Admins befinden sich in einer dedizierten Tier-Zero-OU (typischerweise OU=Tier-0,OU=Admin) mit eingeschränkter GPO-Autorenschaft.", "status": "machine-draft" }, "remediationSteps": { "value": "Erstellen Sie OU=Tier-0,OU=Admin, falls sie nicht existiert. Verschieben Sie alle Mitglieder von Domain/Enterprise/Schema Admins dorthin. Beschränken Sie die GPO-Autorenschaft dieser OU (nur die Tier-Zero-Administratoren selbst). Wenden Sie eine dedizierte GPO zur Anmeldebeschränkung an, sodass sich Tier-Zero-Konten nur bei Tier-Zero-Hosts anmelden können. Blockieren Sie die Vererbung an der OU.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Dienstkonten mit interaktiven Anmelderechten über privilegierte Gruppe", "status": "machine-draft" }, "description": { "value": "Dienstkonten, die Mitglieder von Domain Admins sind (oder einer beliebigen Gruppe, der über die standardmäßige Mitgliedschaft in privilegierten Gruppen „Lokal anmelden zulassen“ gewährt wird), können interaktiv verwendet werden. Angreifer lieben das – sie erbeuten ein Dienstkontokennwort (Kerberoasting, Registrierung, Skripte in SYSVOL), verwenden es interaktiv auf einer Arbeitsstation, dumpen LSASS und bewegen sich weiter. Dienstkonten sollten sich außer beim Host, den sie bedienen, bei nichts interaktiv anmelden können.", "status": "machine-draft" }, "recommendedValue": { "value": "Dienstkonten (Heuristik: sAMAccountName beginnt mit svc/sa/service oder hat einen SPN + keine jüngste interaktive Anmeldung) wird über die Default Domain Controllers Policy und eine dedizierte GPO zur Tier-1-/Tier-2-Anmeldebeschränkung ausdrücklich „Lokal anmelden zulassen“ und „Anmelden über Remotedesktopdienste zulassen“ verweigert.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifizieren Sie Dienstkonten (SPN-tragend, Namenskonvention oder Geschäftsinventar). Wenden Sie eine Default-Domain-Policy-GPO an: Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > „Lokal anmelden verweigern“ = <Dienstkontengruppe>. Fügen Sie dieselben Konten zu „Anmelden über Remotedesktopdienste verweigern“ hinzu. Fügen Sie sie, wo unterstützt (Server 2012 R2+), der Gruppe Protected Users hinzu.", "status": "machine-draft" } } } |