> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/cyber-best-practices/de/anleitungen-zur-behebung-von-schwachstellen/ad-scan-vulnerability-remediation-guide/privileged-accounts.md). # Privilegierte Konten ## P-Kerberoasting #### Was es bedeutet In Active Directory sind einige Konten registriert, um Dienste wie einen SQL Server oder eine Webanwendung auszuführen. Diese Konten haben ein **Service Principal Name (SPN)**, was im Wesentlichen ein Kennzeichen ist, das sagt: „Dieses Konto betreibt einen Netzwerkdienst.“ Das Sicherheitsrisiko ist: **jeder authentifizierte Benutzer** in der Domäne kann für jedes Konto mit einem SPN ein Kerberos-Ticket anfordern. Dieses Ticket ist mit dem Passwort des Kontos verschlüsselt, und der Angreifer kann dann versuchen, es offline zu knacken, ohne einen Alarm auszulösen. Das nennt man einen **Kerberoasting** Angriff. Besonders gefährlich ist es, wenn das Konto mit dem SPN auch ein **Domänenadministrator**, denn das Knacken dieses Passworts bedeutet die vollständige Kontrolle über die Domäne. #### Was der Scan prüft Der AD-Scan markiert Konten, die **alle drei** Bedingungen erfüllen: 1. Das Konto ist Mitglied einer **privilegierten Gruppe** (Domain Admins, Enterprise Admins usw.) 2. Das Konto hat ein **Service Principal Name (SPN)** 3. Das Passwort des Kontos **seit über 40 Tagen nicht geändert wurde** (dadurch haben Angreifer mehr Zeit, es zu knacken) #### Warum der Alarm bestehen bleiben kann Sie müssen **alle drei** Bedingungen beheben. Häufige unvollständige Lösungen: * **Das Passwort geändert, aber den SPN beibehalten:** Der Alarm verschwindet vorübergehend, kehrt aber nach 40 Tagen zurück. * **Den SPN entfernt, das Konto ist aber weiterhin in Domain Admins:** Der Alarm verschwindet, aber das zugrunde liegende Risiko bleibt bestehen. #### So diagnostizieren Sie ```powershell $privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators") $threshold = (Get-Date).AddDays(-40) foreach ($group in $privilegedGroups) { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { Get-ADUser $_ -Properties ServicePrincipalName, PasswordLastSet } | Where-Object { $_.ServicePrincipalName.Count -gt 0 -and $_.PasswordLastSet -lt $threshold } | Select-Object SamAccountName, @{N="Passwortalter (Tage)"; E={[math]::Round(((Get-Date) - $_.PasswordLastSet).TotalDays)}}, @{N="SPNs"; E={$_.ServicePrincipalName -join "; "}} } ``` #### So beheben Sie es **Beste Option: Das Konto aus den privilegierten Gruppen entfernen.** Dienstkonten müssen selten Domain Admins sein. Erstellen Sie ein dediziertes, nicht privilegiertes Konto mit nur den Berechtigungen, die der Dienst tatsächlich benötigt: ```powershell Remove-ADGroupMember -Identity "Domain Admins" -Members "svc_account" -Confirm:$false ``` **Wenn Sie es nicht aus der Administratorgruppe entfernen können:** Setzen Sie das Passwort mindestens regelmäßig zurück (alle 30 Tage oder häufiger): ```powershell Set-ADAccountPassword -Identity "svc_account" ` -NewPassword (ConvertTo-SecureString "YourNewStr0ngP@ssw0rd!" -AsPlainText -Force) -Reset ``` **Beste langfristige Lösung:** Umstellen auf ein **Group Managed Service Account (gMSA)**, das sein Passwort alle 30 Tage automatisch rotiert: ```powershell New-ADServiceAccount -Name "gMSA_SQLService" ` -DNSHostName "gmsa_sqlservice.yourdomain.com" ` -PrincipalsAllowedToRetrieveManagedPassword "SQLServersGroup" ``` ## P-AdminLogin #### Was es bedeutet Jede Active Directory-Domäne hat ein **integriertes Administratorkonto** das automatisch erstellt wird, wenn die Domäne eingerichtet wird. Dieses Konto hat die vollständige Kontrolle über die gesamte Domäne und kann nicht gesperrt werden. Aufgrund seiner Macht und Vorhersehbarkeit (Angreifer wissen, dass es immer existiert) sollte es reserviert sein für **nur Notfälle**, etwa zur Wiederherstellung nach einer Katastrophe. Die tägliche Verwaltung sollte persönliche Administratorkonten verwenden (z. B. `adm_john`), damit Aktionen einzelnen Personen zugeordnet werden können. #### Was der Scan prüft Der AD-Scan prüft, ob sich das integrierte Administratorkonto bei einem beliebigen Domänencontroller in den **letzten 35 Tagen**. Falls ja, wird der Alarm ausgelöst, was darauf hinweist, dass das Konto für Routineaufgaben verwendet wird, anstatt für Notfälle reserviert zu bleiben. #### Warum der Alarm bestehen bleiben kann * **Das Umbenennen des Kontos hilft nicht.** Der Scan identifiziert das integrierte Administratorkonto anhand seiner internen Kennung (RID-500), nicht anhand seines Namens. * **Das Ändern des Passworts hilft nicht.** Der Scan prüft Anmeldeaktivitäten, nicht das Passwortalter. * **Automatisierte Skripte oder geplante Aufgaben** die als integriertes Administratorkonto ausgeführt werden, lösen den Alarm weiterhin aus. * **Sie müssen nur warten.** Nachdem Sie das Konto nicht mehr verwenden, wird der Alarm nach 35 Tagen automatisch gelöscht. #### So diagnostizieren Sie ```powershell # Prüfen, wann sich das integrierte Administratorkonto zuletzt auf jedem DC angemeldet hat $domainSID = (Get-ADDomain).DomainSID $adminSID = "$domainSID-500" Get-ADDomainController -Filter * | ForEach-Object { $dc = $_ $admin = Get-ADUser -Identity $adminSID -Server $dc.HostName -Properties LastLogon $lastLogon = [DateTime]::FromFileTime($admin.LastLogon) $daysAgo = [math]::Round(((Get-Date) - $lastLogon).TotalDays, 1) [PSCustomObject]@{ DC = $dc.HostName LastLogon = $lastLogon DaysAgo = $daysAgo Status = if ($daysAgo -le 35) { "ALARM - Kürzlich verwendet" } else { "OK" } } } | Format-Table -AutoSize ``` Prüfen Sie auch geplante Aufgaben, die möglicherweise das integrierte Administratorkonto verwenden: ```powershell Get-ADDomainController -Filter * | ForEach-Object { Invoke-Command -ComputerName $_.HostName -ScriptBlock { Get-ScheduledTask | Where-Object { $_.Principal.UserId -match "Administrator" } | Select-Object TaskName, @{N="RunAs"; E={$_.Principal.UserId}} } } ``` #### So beheben Sie es 1. **Erstellen Sie persönliche Administratorkonten** für jeden Administrator (z. B. `adm_john`, `adm_jane`) 2. **Aktualisieren Sie alle geplanten Aufgaben** so, dass sie ein dediziertes Dienstkonto anstelle des integrierten Administratorkontos verwenden 3. **Hören Sie auf, sich anzumelden** mit dem integrierten Administratorkonto für Routineaufgaben 4. Der Alarm wird automatisch gelöscht **35 Tage** nach der letzten Anmeldung ## P-AdminNum #### Was es bedeutet Je mehr Konten mit Administratorrechten in Ihrer Domäne vorhanden sind, desto größer ist die Angriffsfläche. Jedes Administratorkonto ist ein potenzieller Einstiegspunkt für einen Angreifer. Viele Organisationen enden im Laufe der Zeit mit zu vielen Administratorkonten: temporärer Zugriff, der nie widerrufen wurde, Dienstkonten, die aus Bequemlichkeit zu Domain Admins hinzugefügt wurden usw. #### Was der Scan prüft Der AD-Scan zählt die Gesamtzahl der **eindeutigen Benutzer** über alle privilegierten Gruppen hinweg (Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators usw.). Wenn derselbe Benutzer in mehreren Gruppen ist, wird er nur einmal gezählt. Der Alarm wird ausgelöst, wenn: * Mehr als **10%** der aktiven Benutzer privilegiert sind, ODER * Mehr als **50** privilegierte Konten vorhanden sind > Diese Prüfung wird für kleine Organisationen mit weniger als 100 aktiven Benutzern übersprungen. #### So diagnostizieren Sie ```powershell $privilegedGroups = @( "Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators", "Account Operators", "Server Operators", "Backup Operators", "Print Operators" ) $uniqueMembers = @{} foreach ($group in $privilegedGroups) { try { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { $uniqueMembers[$_.DistinguishedName] = $_.SamAccountName } } catch {} } $activeUsers = (Get-ADUser -Filter "Enabled -eq `$true" | Measure-Object).Count $pct = [math]::Round(($uniqueMembers.Count / $activeUsers) * 100, 1) Write-Host "Privilegierte Konten: $($uniqueMembers.Count)" Write-Host "Aktive Benutzer: $activeUsers" Write-Host "Verhältnis: $pct% (Alarm, wenn >10 % oder >50 Konten)" Write-Host "" $uniqueMembers.Values | Sort-Object | ForEach-Object { Write-Host " - $_" } ``` #### So beheben Sie es Überprüfen Sie die Liste und entfernen Sie Konten, die keinen wirklichen Administratorzugriff benötigen: ```powershell Remove-ADGroupMember -Identity "Domain Admins" -Members "username" -Confirm:$false ``` Bewährte Vorgehensweisen: * Verwenden Sie **separate Administratorkonten** (`adm_john`), die sich von den Konten für die tägliche Nutzung unterscheiden * **Entfernen Sie Dienstkonten** aus Administratorgruppen und vergeben Sie nur die spezifischen Berechtigungen, die sie benötigen * **Überprüfen Sie die Mitgliedschaft in privilegierten Gruppen** regelmäßig ## P-ProtectedUsers #### Was es bedeutet Die **Protected Users** Gruppe ist eine spezielle Sicherheitsgruppe, die in Windows Server 2012 R2 eingeführt wurde. Mitglieder dieser Gruppe erhalten zusätzlichen Schutz: * Sie können **sich nur mit Kerberos authentifizieren** (dem sichereren Protokoll) und nicht mit dem älteren NTLM-Protokoll * Ihre **Anmeldeinformationen werden nicht zwischengespeichert** auf den Maschinen, auf denen sie sich anmelden: Ein Angreifer, der einen Arbeitsplatzrechner kompromittiert, kann ihre Anmeldeinformationen nicht aus dem Speicher stehlen * **Delegierung ist deaktiviert:** ihr Konto kann von Diensten nicht imitiert werden Diese Schutzmaßnahmen sind für Administratorkonten entscheidend, da diese in den meisten Angriffen die Hauptziele sind. #### Was der Scan prüft Der AD-Scan prüft, dass alle **aktivierten Administratorkonten** (Mitglieder von Domain Admins, Enterprise Admins usw.) auch Mitglieder der **Protected Users** Gruppe sind. #### Warum der Alarm bestehen bleiben kann * **Benutzer, die über verschachtelte Gruppen hinzugefügt wurden** werden möglicherweise nicht erkannt. Fügen Sie Benutzer **direkt** zur Gruppe Protected Users hinzu. * **Replikationsverzögerungen** zwischen Domänencontrollern können vorübergehende Inkonsistenzen verursachen. * **Managed Service Accounts (gMSA)** werden von dieser Prüfung ausgeschlossen: Sie müssen nicht in Protected Users sein. #### So diagnostizieren Sie ```powershell $protectedUsers = (Get-ADGroupMember -Identity "Protected Users").DistinguishedName $privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators") $notProtected = foreach ($group in $privilegedGroups) { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { Get-ADUser $_ -Properties Enabled } | Where-Object { $_.Enabled -and $_.DistinguishedName -notin $protectedUsers } } $notProtected | Select-Object -Unique SamAccountName, Name | Format-Table -AutoSize ``` #### So beheben Sie es ```powershell Add-ADGroupMember -Identity "Protected Users" -Members "adm_john", "adm_jane" ``` > **Wichtig:** Das Hinzufügen von Konten zu Protected Users erzwingt **Kerberos-only-Authentifizierung**. Einige Legacy-Anwendungen, die NTLM benötigen, funktionieren für diese Konten möglicherweise nicht mehr. **Testen Sie zuerst mit einem Konto** bevor Sie alle Administratoren hinzufügen. > > Bewährte Praxis: Administratorkonten sollten nur **für Verwaltungsaufgaben verwendet werden** (nicht für E-Mail, Web-Browsing oder das Ausführen von Geschäftsanwendungen), daher ist NTLM-Kompatibilität selten ein Problem. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/cyber-best-practices/de/anleitungen-zur-behebung-von-schwachstellen/ad-scan-vulnerability-remediation-guide/privileged-accounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.