Active Directory zählt zu den kritischsten IT-Ressourcen und ist ein häufiges Ziel von Hackern. Daher hat seine Absicherung für IT- und Sicherheitsteams höchste Priorität. Dazu gehört auch die Überprüfung, ob Active Directory kompromittiert wurde oder nicht.
Mit Active Directory für Windows und Azure dominiert Microsoft den Markt für Tools für Identitäts- und Zugriffsmanagement (IAM) mit einem Marktanteil von mehr als 50 %, darunter rund 95 % der Fortune 1000. Damit gibt es nur wenige Ziele für Hacker, die noch lohnender wären.
In diesem Beitrag sehen wir uns an, wie sich mehrere kritische Active-Directory-Komponenten auf Anzeichen einer Kompromittierung überprüfen lassen – wichtige Schritte, die Sie in Ihre Best Practices für die Active-Directory-Sicherheit aufnehmen sollten.
Siehe die wichtigsten Sicherheitstools für Active Directory
Möchten Sie die Erkennung von Active-Directory-Kompromittierungen verbessern? Der Sponsor dieses Beitrags, Semperis, hat Purple Knight und Forest Druid entwickelt, um Indicators of Exposure und Indicators of Compromise in AD, Azure AD/Entra ID, Okta und der Tier-0-Peripherie zu erkennen. Erfahren Sie, wie diese kostenlosen Tools die gesamte Prüfung erleichtern!
Nach Anzeichen eines Angreifers suchen
Bedrohungsakteure, die über das nötige Geschick verfügen, um in Ihre Active-Directory-Umgebung vorzudringen, können möglicherweise auch so geschickt vorgehen, dass sie keine Spuren hinterlassen. Dadurch lässt sich unmöglich feststellen, ob Active Directory kompromittiert wurde.
Ein Angreifer könnte beispielsweise der Gruppe „Domänenadministratoren“ beitreten, Hacking-Aktivitäten durchführen und die Gruppe anschließend wieder verlassen. Wenn die Überwachung aktiviert ist, können Sie die Mitgliedschaft in privilegierten Gruppen durch Monitoring überprüfen. Wenn Sie ein Mitglied entdecken, das einer privilegierten Gruppe angehört, aber nicht auf der Liste der vorgesehenen Administratoren steht, können Sie den Administrator entfernen oder untersuchen, wie dieser Benutzer Mitglied der privilegierten Gruppe wurde.
Viel hängt von der Geschwindigkeit und den Fähigkeiten des Angreifers ab. Ein Angreifer kann Angriffsmethoden einsetzen, durch die verhindert wird, dass Ereignisse in den Ereignisprotokollen aufgezeichnet werden. Um nach Anzeichen eines Angriffs zu suchen, können Sie nicht auf jedem domänengebundenen Computer und jedem Domänencontroller ständig die Ereignisprotokolle prüfen. Die Überprüfung des Status wichtiger Active-Directory-Komponenten sollte der erste Schritt Ihrer Strategie sein, um festzustellen, ob Active Directory kompromittiert wurde.
Beachten Sie, dass Angreifer versuchen werden, Active-Directory-Komponenten anzugreifen, die Active-Directory-Administratoren nicht ohne Weiteres kennen oder berühren. Sie müssen überprüfen, ob sich jede dieser Komponenten im Standardzustand befindet, und feststellen, ob eine davon gegenüber diesem Zustand verändert wurde. Obwohl es zahlreiche Komponenten gibt, die Sie untersuchen sollten, konzentriert sich dieser Beitrag nur auf die „kritischen“. Wir betrachten AdminSDHolder, die Standardobjekte der Gruppenrichtlinie, PrimaryGroupIDs und Domänencontroller. Die Liste in diesem Beitrag reicht zwar nicht aus, um festzustellen, ob Ihr Active Directory kompromittiert wurde, doch bei den genannten Elementen handelt es sich um typische Ziele, die ein Angreifer manipulieren würde, um Zugriff auf Active Directory zu erlangen.
AdminSDHolder-Objekt und privilegierte Konten
Jede Active-Directory-Domäne enthält unterhalb des Systemcontainers einen eindeutigen Container namens AdminSDHolder. Bei der Bereitstellung des ersten Domänencontrollers einer Active-Directory-Domäne wird auch der AdminSDHolder-Container erstellt. Die Verwaltung der Berechtigungen, die von privilegierten Konten verwendet werden, obliegt dem AdminSDHolder-Container.
Der SDProp-Prozess kopiert die Berechtigungen des AdminSDHolder-Containers auf alle privilegierten Konten, nachdem er die auf den Container angewendeten Berechtigungen überprüft hat. Ein gewöhnlicher Benutzer interagiert nicht mit dem AdminSDHolder-Objekt. Ein Angreifer mit ausreichenden Berechtigungen kann jedoch die für AdminSDHolder festgelegten Berechtigungen ändern und sich Zugriff auf Active Directory verschaffen.
Um zu überprüfen, ob jemand den AdminSDHolder-Container verändert hat, können Sie im Attribut-Editor das Attribut „WhenChanged“ aufrufen, wie im folgenden Screenshot dargestellt:
Der AdminSDHolder-Container wurde am 23.03.2023 erstellt, als der Domänencontroller bereitgestellt wurde, und am 28.05.2023 geändert, wie im obigen Screenshot zu sehen ist. Bei einer Änderung wurden höchstwahrscheinlich Berechtigungen auf der Registerkarte „Sicherheit“ hinzugefügt. Sie können diese überprüfen und entfernen, wenn sie nicht mehr benötigt werden. Nach der Bereitstellung der Active-Directory-Domäne müssen Administratoren das AdminSDHolder-Objekt nicht mehr bearbeiten.
Gruppenrichtlinienobjekte: Ein wichtiges Ziel für Hacker
Sie sollten wissen, dass Angreifer inzwischen hauptsächlich GPOs (Gruppenrichtlinienobjekte) ins Visier nehmen. Ein GPO ist ein leistungsfähiges Active-Directory-Objekt. Da GPOs über so viele Einstellungen verfügen, kann ein Hacker, sobald er Zugriff darauf hat, diese ändern und auf dem Zielcomputer anwenden oder über eine geplante Aufgabe auf den Zielcomputern bösartigen Code ausführen. Bei den Zielcomputern kann es sich um Benutzerkonten, Domänencontroller oder Computerkonten handeln.
Beachten Sie, dass Active Directory zwei standardmäßige Gruppenrichtlinienobjekte implementiert: „Default Domain Policy“ und „Default Domain Controllers Policy“. Diese beiden GPOs bleiben nach der Bereitstellung unverändert, mit Ausnahme der „Default Domain Policy“. Die Kennwortrichtlinien Ihres Unternehmens erfordern möglicherweise, dass Sie die Kontorichtlinien in der „Default Domain Policy“ ändern. Diese Änderung wird dann jedoch dauerhaft vorgenommen.
Normalerweise erstellen Sie ein neues GPO, wenn Sie organisationsspezifische oder sicherheitsrelevante Einstellungen auf Benutzer- und Computerkonten in Ihrer Umgebung anwenden möchten. Im Attribut-Editor oder mithilfe des folgenden PowerShell-Befehls können Sie jederzeit den Änderungszeitpunkt sowohl der Standarddomänenrichtlinie als auch der Standarddomänencontroller-Richtlinie überprüfen. Dieser PowerShell-Befehl listet alle GPOs in der Domäne und ihren Änderungszeitpunkt auf:
$AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime$AllGPOsWenn sich das Datum der Active-Directory-Bereitstellung und der Änderungszeitpunkt der Standarddomänenrichtlinie sowie der Standarddomänencontroller-Richtlinie unterscheiden, hat möglicherweise jemand diese GPOs geändert, um Zugriff auf Active Directory zu erlangen.
PrimaryGroupID: Ein leichteres Ziel
Derzeit kommt es immer häufiger zu Angriffen über die PrimaryGroupID, da ein Angreifer dafür weniger Aufwand betreiben muss, bevor er die Kontrolle über Active Directory übernehmen kann.
Alle Active-Directory-Benutzerkonten werden zunächst der standardmäßigen Sicherheitsgruppe „Domain Users“ zugewiesen, die zur PrimaryGroupID des Benutzers wird. Die PrimaryGroupIDs der Benutzerkonten lauten 513, die PrimaryGroupIDs der Computerkonten 515 und die PrimaryGroupID des Domänencontrollers 516.
Ein Angreifer kann die PrimaryGroupID eines Benutzers oder Computers ändern und dadurch das Standardverhalten von Active Directory verändern. Wird beispielsweise die PrimaryGroupID eines Benutzers so geändert, dass er der Gruppe „Domain Admins“ angehört, erhält der Angreifer privilegierten Zugriff auf Active Directory.
Sie müssen ein PowerShell-Skript verwenden, um alle Benutzer-, Computer- und Domänencontrollerkonten zu überprüfen und sicherzustellen, dass ihre PrimaryGroupIDs nicht geändert wurden. Wenn Sie Änderungen feststellen, bedeutet dies, dass jemand versucht hat, die standardmäßige Mitgliedschaft der Objekte zu ändern, um Zugriff auf Active Directory zu erlangen.
Domänencontroller und ihr Standardspeicherort
Nach ihrer Implementierung befinden sich Domänencontroller weiterhin an ihrem Standardspeicherort „OU=Domain Controllers, DC=Domain>, DC=local>“.
Aufgrund seines Standardspeicherorts in Active Directory erhält der Domänencontroller garantiert die Gruppenrichtlinieneinstellungen aus der Gruppenrichtlinie „Default Domain Controllers“. Diese Einstellungen dienen speziell dem Schutz von Domänencontrollern.
Domänencontroller erhalten diese Einstellungen nicht, wenn sie aus ihrem Standardspeicherort verschoben werden. Stattdessen erhalten sie möglicherweise Einstellungen aus einem anderen Gruppenrichtlinienobjekt. Wenn ein Angreifer über die entsprechenden Berechtigungen verfügt, könnte er beispielsweise einen oder mehrere Domänencontroller in eine andere Organisationseinheit mit einem anderen darauf angewendeten GPO verschieben. Dieses GPO könnte eine geplante Aufgabe enthalten, die bösartigen Code ausführt. Sie sollten stets ein kurzes PowerShell-Skript ausführen oder Sicherheitstools zur Bewertung einsetzen, um zu überprüfen, ob sich jeder Domänencontroller in seiner standardmäßigen Organisationseinheit befindet.
Hier ist ein kurzes PowerShell-Skript, mit dem Sie den Speicherort aller Domänencontroller in einer Active-Directory-Gesamtstruktur überprüfen können. Das Skript ruft alle Domänencontroller aus der Active-Directory-Gesamtstruktur ab und überprüft anschließend nacheinander den Speicherort ihrer Computerkonten in Active Directory. Wenn sich einer der Domänencontroller nicht in seiner standardmäßigen Organisationseinheit befindet, wird das Ergebnis auf dem Bildschirm angezeigt.
$ComputersList = "C:\Temp\DCList.TXT"
Remove-Item $ComputersList -ErrorAction SilentlyContinue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName
foreach ($Item in $R)
{
$ThisDC = $Item.HostName
Add-Content $ComputersList $ThisDC
}
Foreach ($ComputerItem in Get-Content "$ComputersList")
{
$NameOne, $NameTwo = $ComputerItem.Split(".")
$Error.Clear()
$RNow = Get-ADComputer $NameOne -Server $ComputerItem
$DCName = $RNow.DistinguishedName
$CurLocName = $DCName
$RemovedComma = $CurLocName.replace(",", " ")
$DCT1, $DCT2, $DCT3 = $DCName.split(",")
IF ($DCT2 -eq "OU=Domain Controllers")
{
}
else
{
Write-Host "WARNING: Domain Controller is not located in its default OU"
}
}Fazit: Active Directory vor Hackern schützen
Die Überprüfung des Status kritischer Active-Directory-Komponenten auf Anzeichen einer Kompromittierung sollte für Administratoren zu den regelmäßigen Best Practices gehören. Wir haben den Standardspeicherort des Computerkontos für den Domänencontroller, den AdminSDHolder-Container, die Standardgruppenrichtlinienobjekte und die PrimaryGroupID sowie Techniken zur Erkennung einer Kompromittierung behandelt. Es gibt jedoch weitere Komponenten und Best Practices für Active Directory, die wir in künftigen Beiträgen behandeln werden.
Lesen Sie auch: