Magic Quadrant™ für Privileged Access Management 2025: Netwrix zum vierten Jahr in Folge anerkannt. Laden Sie den Bericht herunter.

Plattform
Ressourcen­zentrumBlog
Grundlagen der LDAP-Reconnaissance mit PowerShell

Grundlagen der LDAP-Reconnaissance mit PowerShell

Aug 31, 2022

In dem Einführungsbeitrag dieser Serie haben wir erörtert, was ein Active Directory (AD) Dienstkonto ist, erklärt, warum diese privilegierten Konten ein ernsthaftes Sicherheitsrisiko darstellen, und versprochen, in zukünftigen Beiträgen 4 Arten von Angriffen auf Dienstkonten im Detail zu beschreiben. Dieser Beitrag untersucht den ersten dieser Angriffe: LDAP-Reconnaissance, die Angreifer nutzen können, um Dienstkonten in einer IT-Umgebung zu entdecken, während sie eine Entdeckung vermeiden.

Insbesondere werden wir in diesem Beitrag untersuchen, wie Angreifer ohne spezielle Berechtigungen, wie Domain Admin oder sogar lokale Administratorrechte, einfache PowerShell-Abfragen verwenden können, um Dienstkonten zu finden, ohne spezialisierte Tools wie Bloodhound installieren oder erlernen zu müssen.

Auffinden von Privileged Accounts

Active Directory bietet viele Sicherheits- und Verwaltungsvorteile, kann es aber einem neugierigen Angreifer auch ein wenig zu leicht machen. Aufgrund der Architektur von AD kann ein Angreifer, sobald er einen mit dem Domain verbundenen Computer infiltriert hat, das Verzeichnis und seine Objekte abfragen. Und weil Active Directory standardmäßig keinen Mechanismus zur Überwachung und Alarmierung bei verdächtigen Aktivitäten bietet, können sie oft unentdeckt bleiben.

Hier sind einige der Methoden, wie ein Angreifer Servicekonten durch Abfragen von LDAP entdecken kann.

Entdeckung des Service Principal Name (SPN)

Dienstkonten nutzen SPNs, um die Kerberos-Authentifizierung zu unterstützen. Obwohl dies die Sicherheit verbessert, hinterlässt es auch genau eine Spur, wo diese Konten verwendet werden und wofür sie eingesetzt werden. Diese Informationen können von einem Angreifer leicht ausgenutzt werden. SPNs werden häufig verwendet, um Dienste für Anwendungen wie Microsoft SQL Server und SharePoint zu betreiben.

In einem anderen blog post, demonstrieren wir, wie man fortgeschrittene AD-Aufklärung durchführt; es gibt jedoch einfachere Methoden, um die Informationen zu erhalten, die wir hier benötigen. Mit der folgenden einfachen LDAP-Abfrage kann ein Angreifer eine Liste von AD-Konten erhalten, die registrierte SPNs haben, sowie die Computer, Anwendungen und Daten, zu denen sie Zugang bieten:

      #Build LDAP filters to look for users with SPN values registered for current domain
$ldapFilter = "(&(objectclass=user)(objectcategory=user)(servicePrincipalName=*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
#Execute Search
$results = $search.FindAll()
#Display SPN values from the returned objects
foreach ($result in $results)
{
    $userEntry = $result.GetDirectoryEntry()
    Write-Host "User Name = " $userEntry.name
    foreach ($SPN in $userEntry.servicePrincipalName)
    {
        Write-Host "SPN = " $SPN      
    }
    Write-Host ""   
}
      

Die SPN-Werte in den Ergebnissen zeigen, wo jedes Konto registriert ist und für welchen Dienst es auf diesem System registriert ist. Zum Beispiel, hier ist der SPN-Wert für ein SQL-Dienstkonto:

Image

Entdeckung von Dienstkonten unter Verwendung generischer Objektattribute

Während SPNs sehr zuverlässig und informativ sind, werden sie keine umfassende Liste von Dienstkonten erstellen, da viele Konten nicht über SPNs mit Kerberos integrieren und keine SPN-Werte festgelegt haben. Angreifer ohne Domänenrechte können jedoch oft Dienstkonten auf anderen Wegen entdecken. Insbesondere verwenden die meisten Organisationen Namenskonventionen, wie zum Beispiel, dass alle Namen von Dienstkonten mit „SVC“ oder etwas Ähnlichem beginnen, und Dienstkonten werden typischerweise in ihre eigenen organisatorischen Einheiten (OUs) oder Gruppen platziert.

Servicekonten anhand von Benennungskonventionen für Konten finden

Hier ist ein PowerShell-Skript, das alle Konten findet, die „svc“ im Namen enthalten:

      #Build LDAP filter to find service accounts based on naming conventions
$ldapFilter = "(&(objectclass=Person)(cn=*svc*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"

#Add list of properties to search for
$objProperties = "name"
Foreach ($i in $objProperties){$search.PropertiesToLoad.Add($i)}

#Execute Search
$results = $search.FindAll()
#Display values from the returned objects
foreach ($result in $results)
{
    $userEntry = $result.GetDirectoryEntry()
    Write-Host "User Name = " $userEntry.name
    Write-Host ""   
}
      

Servicekonten basierend auf OU finden

Und hier ist ein LDAP-Filter, der in das vorherige Skript eingefügt werden kann, um alle OUs zu finden, die „Service“ oder „svc“ im Namen enthalten:

      $ldapFilter = "(&(objectClass=organizationalUnit)(|name=*Service*)(name=*svc*)))"

The attacker can then search those OUs for all user objects to find your service accounts. This script focuses on one OU with “Service” in its name:

$search = New-Object System,DirecoryServices.DirectorySearcher
$search.SearchRoot = "LDAP://OU=Service Accounts,OU=JEFFLAB,DC=local"
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
      

Servicekonto-Entdeckung über Benutzerkontensteuerung

Eine weitere hinterhältige Methode, um im Active Directory nach Dienstkonten zu suchen, ist die Untersuchung der Kontensteuerungseinstellungen, da Dienstkonten oft andere Einstellungen als reguläre Benutzerkonten haben. Das beste Beispiel dafür ist die Einstellung „password never expires“ — Dienstkonten haben möglicherweise Passwörter, die niemals ablaufen, weil das Zurücksetzen mühsam sein kann und zu Ausfällen von Anwendungen oder Diensten führen könnte.

Image

Mit PowerShell ist es möglich, alle Konten mit diesem aktivierten Wert zu finden, indem man einen etwas komplizierteren LDAP-Filter verwendet:

      $ldapFilter = "(&(objectclass=user)(objectcategory=user)(useraccountcontrol:1.2.840.113556.1.4.803:=65536))"
      

Privileged Discovery

Obwohl sich dieser Beitrag ausschließlich auf Methoden konzentrierte, um Dienstkonten zu finden, ohne irgendwelche Privilegien zu nutzen, gibt es viele andere effektive Wege, um Dienstkonten zu entdecken, falls ein Angreifer ein Konto findet, das auf einem oder mehreren Systemen innerhalb des Netzwerks Privilegien hat. Dazu gehören:

  • Auflisten von Diensten auf Endpunkten und Extrahieren des Startname-Kontos
  • Suche nach Verbindungszeichenfolgen in web.config, Skripten und anderen Orten, an denen Dienstkonten möglicherweise hartkodiert sind
  • Untersuchung der lokalen Richtlinie für Benutzer, denen das Recht „Als Dienst anmelden“ gewährt wurde
  • Extrahieren von Ereignisprotokollen für nicht-interaktive Anmeldetypen
  • Suche nach Anwendungspool- und anderen Webanwendungsdienstkonten

Ausnutzung der entdeckten Konten

Sobald ein Angreifer eine Liste von Dienstkonten hat, ist der nächste Schritt, diese auszunutzen. Entdecken Sie einige ihrer Optionen in den folgenden Beiträgen:

Erfahren Sie mehr über LDAP-Reconnaissance und andere Angriffstechniken im Netwrix attack catalog.

Teilen auf

Erfahren Sie mehr

Über den Autor

Ein mann in einer blauen jacke und einem karierten hemd lchelt fr die kamera

Jeff Warren

Chief Product Officer

Jeff Warren überwacht das Netwrix Produktportfolio und bringt über ein Jahrzehnt Erfahrung im sicherheitsorientierten Produktmanagement und der Entwicklung mit. Bevor er zu Netwrix kam, leitete Jeff die Produktorganisation bei Stealthbits Technologies, wo er seine Erfahrung als Software-Ingenieur nutzte, um innovative, unternehmensweite Sicherheitslösungen zu entwickeln. Mit einem praktischen Ansatz und einem Talent für die Lösung schwieriger Sicherheitsherausforderungen konzentriert sich Jeff darauf, praktikable Lösungen zu schaffen, die funktionieren. Er hat einen BS in Informationssystemen von der University of Delaware.