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

$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:

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):

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:

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

# 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:

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

$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:

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

$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

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.