Magic Quadrant™ per la gestione degli accessi privilegiati 2025: Netwrix riconosciuta per il quarto anno consecutivo. Scarica il report.

Piattaforma
Centro risorseBlog
Nozioni di base del riconoscimento LDAP con PowerShell

Nozioni di base del riconoscimento LDAP con PowerShell

Aug 31, 2022

Nel post introduttivo di questa serie, abbiamo esaminato cosa sia un account di servizio Active Directory (AD), spiegato perché questi account privilegiati rappresentano un serio rischio per la sicurezza e promesso di dettagliare 4 tipi di attacchi agli account di servizio nei post futuri. Questo post esplora il primo di questi attacchi: il ricognizione LDAP, che gli aggressori possono utilizzare per scoprire account di servizio in un ambiente IT evitando di essere rilevati.

In particolare, in questo post, esploreremo come un attaccante senza permessi speciali, come i diritti di Domain Admin o anche di amministratore locale, possa utilizzare semplici query PowerShell per trovare account di servizio, senza dover installare o imparare strumenti specializzati come Bloodhound.

Ricerca di account Privileged Access Management

Active Directory offre molti vantaggi in termini di sicurezza e gestione, ma può anche rendere le cose un po' troppo facili per un attaccante curioso. A causa dell'architettura di AD, una volta che un attaccante ha infiltrato un computer associato a un dominio, può interrogare la directory e i suoi oggetti. E poiché per impostazione predefinita Active Directory non fornisce un meccanismo per audire e allertare su attività sospette, spesso possono evitare di essere rilevati.

Ecco alcuni dei modi in cui un attaccante può scoprire account di servizio interrogando LDAP.

Scoperta del Service Principal Name (SPN)

Gli account di servizio sfruttano gli SPN per supportare l'autenticazione Kerberos. Sebbene ciò garantisca una sicurezza migliorata, lascia anche una traccia precisa di dove questi account vengono utilizzati e per cosa. Queste informazioni possono essere facilmente sfruttate da un attaccante. Gli SPN sono comunemente utilizzati per eseguire servizi a supporto di applicazioni come Microsoft SQL Server e SharePoint.

In un altro blog post, dimostriamo come eseguire un'analisi avanzata di AD; tuttavia, esistono metodi più semplici per ottenere le informazioni di cui abbiamo bisogno per i nostri scopi qui. Utilizzando la seguente semplice query LDAP, un attaccante può ottenere un elenco degli account AD che hanno registrato SPN, così come i computer, le applicazioni e i dati a cui forniscono accesso:

      #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 ""   
}
      

I valori SPN nei risultati riveleranno dove ogni account è registrato e per quale servizio è registrato su quel sistema. Ad esempio, ecco il valore SPN per un account di servizio SQL:

Image

Scoperta degli account di servizio utilizzando attributi generici degli oggetti

Sebbene gli SPN siano molto affidabili e informativi, non produrranno un elenco completo degli account di servizio perché molti account non si integrano con Kerberos tramite SPN e non avranno valori SPN impostati. Tuttavia, gli aggressori senza diritti di dominio possono spesso scoprire comunque gli account di servizio attraverso altri mezzi. In particolare, la maggior parte delle organizzazioni utilizza convenzioni di denominazione, come l'inizio di tutti i nomi degli account di servizio con “SVC” o qualcosa di simile, e gli account di servizio sono tipicamente collocati nelle proprie unità organizzative (OU) o gruppi.

Trovare account di servizio basati su convenzioni di denominazione degli account

Ecco uno script PowerShell che troverà tutti gli account che contengono “svc” nel nome:

      #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 ""   
}
      

Ricerca di account di servizio basata su OU

E qui c'è un filtro LDAP che può essere sostituito nello script precedente per trovare qualsiasi OU che contenga “Service” o “svc” nel nome:

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

Scoperta degli account di servizio tramite il controllo degli account utente

Un altro modo subdolo per cercare account di servizio in Active Directory è investigare le impostazioni di controllo degli account, poiché gli account di servizio spesso hanno impostazioni diverse rispetto agli account utente regolari. Il miglior esempio di ciò è l'impostazione “password never expires” — gli account di servizio possono avere password impostate per non scadere mai perché l'atto di reimpostarle può essere noioso e risultare in interruzioni di applicazioni o servizi.

Image

Con PowerShell, è possibile trovare tutti gli account con questo valore abilitato, utilizzando un filtro LDAP leggermente più complesso:

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

Scoperta dei privilegi

Mentre questo post si è concentrato esclusivamente su metodi per trovare account di servizio senza sfruttare alcun privilegio, se un attaccante trova un account che ha privilegi su uno o più sistemi all'interno della rete, ci sono molti altri modi efficaci per scoprire account di servizio. Essi includono:

  • Enumerazione dei servizi sugli endpoint e estrazione dell'account startname
  • Ricerca di stringhe di connessione in web.config, script e altri luoghi dove gli account di servizio possono essere codificati in modo fisso
  • Esplorando la policy locale per gli utenti ai quali è stato concesso il diritto di “Log on as a Service”
  • Estrazione dei log degli eventi per tipi di accesso non interattivi
  • Ricerca di account di servizio di application pool e altre applicazioni web

Sfruttando gli account scoperti

Una volta che un avversario ha ottenuto un elenco di account di servizio, il passo successivo è sfruttarli. Scopri alcune delle loro opzioni nei post seguenti:

Scopri di più sul ricognizione LDAP e altre tecniche di attacco nel Netwrix attack catalog.

Condividi su

Scopri di più

Informazioni sull'autore

Un uomo con una giacca blu e una camicia a quadri sorride alla macchina fotografica

Jeff Warren

Chief Product Officer

Jeff Warren supervisiona il portfolio di prodotti Netwrix, portando oltre un decennio di esperienza nella gestione e sviluppo di prodotti focalizzati sulla sicurezza. Prima di entrare in Netwrix, Jeff ha guidato l'organizzazione dei prodotti presso Stealthbits Technologies, dove ha utilizzato la sua esperienza come ingegnere del software per sviluppare soluzioni di sicurezza innovative su scala aziendale. Con un approccio pratico e un talento nel risolvere sfide di sicurezza complesse, Jeff è concentrato sulla costruzione di soluzioni pratiche che funzionano. È laureato in Information Systems presso l'Università del Delaware.