Veraltete und Überprivilegierte Konten in AD

Veraltete privilegierte Konten sind mehr als nur ein Ordnungsproblem im Verzeichnis. In Active Directory kann ein ruhendes Konto, das noch einer privilegierten Gruppe angehört, noch ein altes Passwort besitzt oder noch eine Dienstabhängigkeit besitzt, zu einem wenig sichtbaren Weg zurück in die Domäne werden.

Was sind veraltete und überprivilegierte Konten?

Veraltete privilegierte Konten sind alte oder wenig sichtbare Identitäten, die weiterhin relevanten administrativen Zugriff in Active Directory besitzen. Sie überschneiden sich häufig mit überprivilegierten Konten: Identitäten, die mehr Zugriff behalten haben, als ihre aktuelle Rolle erfordert.

Active-Directory-Umgebungen sammeln im Laufe der Zeit Konten an. Mitarbeitende verlassen das Unternehmen, Auftragnehmer beenden ihre Einsätze, Dienstkonten überleben Projekte, und Notfall-Admin-Identitäten bleiben aktiviert, lange nachdem der ursprüngliche Grund verschwunden ist.

Aus Angreiferperspektive verstärken sich diese beiden Bedingungen gegenseitig. Das beste Ziel ist nicht nur ein altes Konto. Es ist ein altes Konto, das noch in einem privilegierten Pfad sitzt, schwach überwacht wird und keinen klaren Owner hat, der ungewöhnliche Aktivität bemerken würde.

Funktionsweise

AD-Konten bleiben aktiv, bis jemand sie deaktiviert oder löscht. Wird Offboarding, Dienstkonto-Review oder Privilegien-Review übersprungen, füllt sich die Umgebung mit Konten, die:

• seit Monaten oder Jahren nicht mehr authentifiziert haben
• weiterhin privilegierten Gruppen angehören
• Passwörter besitzen, die vor langer Zeit gesetzt und nie überprüft wurden
• außerhalb jeder disziplinierten Lifecycle-Review liegen

Ein veraltetes privilegiertes Konto ist attraktiv, weil es hohen Wert mit geringer Kontrolle verbindet. Das Konto taucht im täglichen Admin-Alltag vielleicht nicht auf, löst aber weiterhin dieselben Berechtigungen aus, sobald das Passwort vorgelegt wird.

Microsofts Anleitung zur Bereinigung veralteter Konten weist inaktive Konten explizit als Sicherheitsrisiko aus und empfiehlt regelmäßige Kontrollen. Dieselbe Anleitung warnt zugleich, dass Dienstkonten über lange Zeiträume möglicherweise keine Anmeldung durchführen, sodass die Bereinigung Schutzmaßnahmen statt blinder Löschung braucht.

Veraltete privilegierte Konten: Grenzen des Suchbereichs

Eine Review veralteter Konten sollte präzise sein, was die Zeitstempel tatsächlich bedeuten.

LastLogonDate und die zugrunde liegenden replizierten Anmeldedaten sind nützlich, um Bereinigungskandidaten zu finden, aber sie sind nicht dasselbe wie eine exakte forensische letzte Nutzung auf jedem Domain Controller. Sie reichen aus, um Konten zu identifizieren, die eine menschliche Prüfung brauchen. Sie sind nicht das einzige Signal, auf das Sie sich vor dem Entfernen einer sensiblen Dienstidentität verlassen sollten.

Deshalb trennen ausgereifte Reviews mindestens drei Fälle:

• Benutzerkonten, die nach dem Offboarding eindeutig hätten deaktiviert werden müssen
• Dienst- oder Scheduled-Task-Identitäten, die möglicherweise weiterhin nicht-interaktiv genutzt werden
• privilegierte Notfall- oder Shared-Identitäten, die überlebt haben, weil niemand Abhängigkeiten testen wollte

Das Ziel ist nicht, jedes alte Konto zu behalten, weil eine Anwendung sonst ausfallen könnte. Das Ziel ist, unklare Ownership nicht länger als Grund zu akzeptieren, ruhende Privilegien für immer zu bewahren.

Eine nützliche operative Unterscheidung besteht zwischen Inaktivität und Irrelevanz. Ein Konto kann ruhig sein, weil es aufgegeben wurde, oder ruhig sein, weil es nur monatlich durch ein Backup, einen Scheduled Task oder einen selten genutzten Recovery-Prozess ausgelöst wird. Die Review muss diese Fälle explizit trennen.

Wichtige Einschränkungen bei Zeitstempeln

Für die Triage veralteter Konten sollten Sie mehrere Signale nutzen. Microsoft weist darauf hin, dass PasswordLastSet repliziert wird und dass lastLogonTimeStamp existiert, um potenziell veraltete Konten zu identifizieren. Das macht diese Attribute nützlich für eine domänenweite Bereinigung. Es bedeutet nicht, dass sie beweisen, dass ein Konto keine Abhängigkeit hat.

Eine sichere Review kombiniert:

• replizierte Inaktivitätsdaten wie Passwortalter oder lastLogonTimeStamp
• Domain-Controller-Ereignisdaten für aktuelle Authentifizierung
• Gruppenmitgliedschaft und Analyse delegierter Rechte
• Prüfungen von Dienst-, Scheduled-Task- und Anwendungsabhängigkeiten
• Owner-Bestätigung für Konten, die aktiviert bleiben müssen

Je höher das Privileg, desto weniger vertretbar ist es, sich auf einen einzelnen Zeitstempel zu verlassen. Ein ruhendes Domain-Admin-Mitglied und ein ruhender Benutzer mit geringen Rechten sind nicht dasselbe Risiko.

Die Angriffskette

Schritt 1 - Veraltete und hochwertige Konten identifizieren

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet |
  Sort-Object LastLogonDate

$groups = @('Domain Admins','Enterprise Admins','Schema Admins','Backup Operators','Account Operators')
foreach ($group in $groups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Get-ADUser -Properties LastLogonDate, PasswordLastSet |
    Select-Object @{N='Group';E={$group}}, SamAccountName, LastLogonDate, PasswordLastSet
}

Microsoft dokumentiert außerdem Search-ADAccount -AccountInactive -UsersOnly als praktischen Weg, um inaktive Benutzerkonten zu finden. Nutzen Sie es als Discovery-Tool und ergänzen Sie anschließend Privilegien- und Abhängigkeitskontext, bevor Sie handeln.

Schritt 2 - Konten mit alten Passwörtern und hohen Privilegien priorisieren

Konten mit sehr alten Passwörtern, dauerhafter Gruppenmitgliedschaft und ohne aktuellen Owner sind die ersten, die ein Angreifer zu validieren, zu spraysen oder wiederzuverwenden versucht.

Priorisieren Sie Konten, die mehr als eine Bedingung erfüllen:

• veraltete Anmeldedaten
• altes PasswordLastSet
• privilegierte Gruppenmitgliedschaft
• Mitgliedschaft über verschachtelte Gruppen
• Kontoflags wie "Passwort läuft nie ab"
• kein benannter fachlicher oder technischer Owner

Schritt 3 - Aus ruhendem Zugriff wird privilegierter Zugriff

Ein veraltetes Konto, das weiterhin in Domain Admins, delegierte Admin-Rechte, Backup-Privilegien oder breiten Serverzugriff auflöst, braucht keinen neuartigen Exploit. Das Privileg existiert bereits.

Schritt 4 - Persistenz über wenig sichtbare Identitäten

Ruhende Konten fehlen oft im täglichen Workflow, sodass ungewöhnliche Aktivität länger unauffällig bleiben kann, als sie sollte. Das gilt besonders für gemeinsam genutzte Admin-Konten und Dienstidentitäten, die niemand kürzlich überprüft hat.

Erkennung

Windows Event-IDs

Microsoft dokumentiert Audit Security Group Management als die Audit-Unterkategorie, die Ereignisse für Änderungen an Sicherheitsgruppenmitgliedschaften erzeugt, einschließlich globaler, lokaler und universeller Gruppenmitgliedschaftsereignisse. Diese Unterscheidung ist wichtig, wenn der privilegierte Pfad verschachtelte oder nicht-globale Gruppen nutzt.

Verhaltensauffälligkeiten

• erste erfolgreiche Nutzung eines Kontos nach langer Ruhephase
• privilegierte Gruppenmitgliedschaft kombiniert mit sehr hohem Passwortalter
• Dienstkonten, die sich interaktiv oder von unerwarteten Hosts aus anmelden
• gemeinsam genutzte Konten, die von mehreren Systemen ohne klaren betrieblichen Grund verwendet werden

SIEM-Erkennungsabfrage (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.TargetUserName: (* AND NOT '*$')

Diese Abfrage braucht Anreicherung mit Kontoalter, Privilegienkontext und erwarteter Ownership. Ruhephase ohne Kontext ist nur eine Liste. Ruhephase plus Privileg ist der eigentliche Befund.

Detection-Anreicherung, die den Alarm nützlich macht

Ein Alarm zu veralteten Konten sollte genug Kontext liefern, damit der Responder entscheiden kann, ob deaktiviert, untersucht oder eskaliert werden soll:

• aktueller Aktivierungsstatus
• Datum des letzten Passwort-Sets
• Kontext der letzten bekannten interaktiven und Netzwerk-Anmeldung
• direkte und verschachtelte privilegierte Gruppen
• ob das Konto als sensibel oder geschützt markiert ist
• ob das Konto Dienste, Scheduled Tasks oder Anwendungs-Credentials besitzt
• ob das Konto aktuelle Kerberos- oder NTLM-Aktivität aufweist

Ohne diese Anreicherung erstellen Teams meist eine Tabelle und verschieben die schwierigen Entscheidungen.

Behebung

Schneller Erfolg: Deaktivieren Sie zuerst offensichtlich veraltete Benutzerkonten und arbeiten Sie sich dann mit einer eigentümerbasierten Review durch Dienst- und Shared-Identitäten, statt sie unbegrenzt bestehen zu lassen.

1. Veraltete Konten deaktivieren

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -SearchBase 'OU=Users,DC=corp,DC=local' `
  -Properties LastLogonDate | ForEach-Object {
    Disable-ADAccount -Identity $_
    Write-Host "Disabled: $($_.SamAccountName) - Last login: $($_.LastLogonDate)"
  }

Für Benutzerkonten, die eindeutig nicht mehr existieren sollten: zuerst deaktivieren, Auswirkungen überwachen, dann nach der von Ihrem Betriebsteam akzeptierten Aufbewahrungsfrist löschen. Löschen Sie privilegierte oder dienstgebundene Objekte nicht als ersten Schritt, außer die Abhängigkeit ist bereits nachweislich nicht vorhanden.

2. Privilegierte Gruppenmitgliedschaft reduzieren

$groups = @('Domain Admins','Enterprise Admins','Schema Admins')
$groups | ForEach-Object {
  Get-ADGroupMember -Identity $_ -Recursive |
    Select-Object @{N='Group';E={$_}}, SamAccountName, distinguishedName
} | Export-Csv privileged_members.csv -NoTypeInformation

Entfernen Sie dauerhafte Privilegien, bevor Sie über die Löschung des Kontos diskutieren. Ein veraltetes Konto ohne Domain Admins oder gleichwertige delegierte Rechte ist weiterhin Bereinigungsarbeit, aber nicht mehr dieselbe unmittelbare Tier-0-Exposition.

3. Strengere Richtlinien für privilegierte Identitäten anwenden

New-ADFineGrainedPasswordPolicy -Name 'PrivilegedAccountsPSO' `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -ComplexityEnabled $true `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge (New-TimeSpan -Days 60) `
  -LockoutThreshold 3

Add-ADFineGrainedPasswordPolicySubject -Identity 'PrivilegedAccountsPSO' `
  -Subjects 'Domain Admins'

Microsoft dokumentiert Fine-Grained Password Policies als Möglichkeit, unterschiedliche Passwort- und Sperreinstellungen auf unterschiedliche Benutzergruppen anzuwenden, einschließlich strengerer Einstellungen für privilegierte Konten. Das ist nützlich, wenn privilegierte Konten weiterhin existieren, ersetzt aber nicht das Entfernen unnötiger Mitgliedschaft.

4. Den Lifecycle-Prozess reparieren, nicht nur die Konten

Die wiederkehrenden Ursachen sind meist operativ:

• Offboarding, das den E-Mail-Zugriff deaktiviert, aber AD-Gruppen vergisst
• Dienstkonten ohne Owner nach einem Teamwechsel
• Notfall-Admin-Konten, die nie wieder unter Review gestellt wurden
• gemeinsam genutzte Konten, die am Leben gehalten werden, weil niemand die Abhängigkeit testen will

Eine glaubwürdige Remediation schließt diese Prozesslücken, während die Kontobereinigung läuft.

5. Ausnahmen isolieren statt vergessen

Muss ein Konto mit geringer Aktivität aktiviert bleiben, dokumentieren Sie es als Ausnahme mit Review-Datum und benanntem Owner. Die Ausnahme sollte enthalten:

• warum das Konto aktiviert bleiben muss
• welche Systeme davon abhängen
• welche Gruppen oder delegierten Rechte es besitzt
• was ausfallen würde, wenn es deaktiviert würde
• welches Monitoring beweist, dass es nur wie vorgesehen genutzt wird

Ausnahmen ohne Ablaufdatum sind der Grund, warum veraltete privilegierte Konten zurückkehren.

Vor dem Abschluss des Befunds validieren

Eine Bereinigung veralteter Konten ist nicht abgeschlossen, wenn die Tabelle kürzer aussieht. Validieren Sie das tatsächliche Kontrollergebnis.

• den Export inaktiver Konten erneut ausführen und bestätigen, dass dieselben hochriskanten Identitäten nicht mehr aktiviert sind
• bestätigen, dass die privilegierte Gruppenmitgliedschaft entfernt wurde, statt nur auf einem deaktivierten Objekt zu verbleiben, das später unverändert reaktiviert werden könnte
• aktuelle 4624- und 4768-Aktivität prüfen, um Konten zu erkennen, die nach der Bereinigungsentscheidung erneut genutzt wurden
• Owner, Abhängigkeit und nächstes Review-Datum für jedes Konto dokumentieren, das trotz geringer Aktivität aktiviert bleiben muss
• den Geltungsbereich der Fine-Grained Password Policy für weiterhin aktivierte privilegierte Konten überprüfen
• verschachtelte Gruppenpfade prüfen, damit Privilegien nicht indirekt erhalten blieben

Bei Dienstkonten sollte die abschließende Prüfung auch bestätigen, dass die Abhängigkeit real und weiterhin aktuell ist. Kann niemand belegen, warum das Konto existiert, ist das ein Argument für die Stilllegung, nicht für eine weitere Ausnahme.

Wie EtcSec das erkennt

EtcSec macht diesen Befund nützlicher, indem es Inaktivität, Privilegienstufe, Passwortalter und fehlende Policy-Abdeckung korreliert. Das ist wichtig, weil ein ruhendes, wenig wertvolles Konto und ein ruhendes privilegiertes Konto nicht dasselbe operative Problem sind.

Weiterführende Links

• Active Directory-Passwortsicherheit: Fehlkonfigurationen, die zählen
• Kerberoasting: Wie Angreifer Dienstkonto-Passwörter knacken
• Active Directory Monitoring: Sicherheitsrelevante Event-IDs
• Gefährliche Gruppenverschachtelung: Versteckte Pfade zu Domain Admin
• Active-Directory-Angriffspfade zu Domain Admin

Primärquellen

• Regelmäßige Prüfung und Entfernung inaktiver Benutzerkonten in Active Directory
• Audit Security Group Management
• Fine-Grained Password Policies für AD DS konfigurieren
• Windows-Ereignisüberwachung konfigurieren (Microsoft Defender for Identity)