Asegurando tus Group Managed Service Accounts

Visión general de Group Managed Service Accounts

La práctica tradicional de usar cuentas de usuario regulares como cuentas de servicio pone la carga de la gestión de contraseñas en los usuarios. Como resultado, las contraseñas de las cuentas a menudo permanecen iguales durante años, lo que las hace altamente susceptibles a ataques de fuerza bruta y mal uso. Las cuentas de servicio administradas por grupo (gMSAs) ofrecen una forma más segura de ejecutar tareas automatizadas, servicios y aplicaciones.

Las gMSA fueron introducidas en Windows Server 2016 y pueden ser utilizadas en Windows Server 2012 y superiores. Las contraseñas de gMSA son completamente manejadas por Windows: Se generan de manera aleatoria y se rotan automáticamente. Además, las contraseñas no tienen que ser conocidas por ningún usuario, ya que las cuentas de servicio se 'instalan' en el servidor que va a consultar la información de la contraseña de Active Directory en tiempo de ejecución. Como resultado, las gMSAs son mucho menos susceptibles a mal uso y compromiso que las cuentas de usuario que se utilizan como cuentas de servicio.

Seguridad de Group Managed Service Account

Las gMSAs son un tipo específico de objeto en Active Directory: msDS-GroupManagedServiceAccount. Estos objetos tienen atributos especiales asociados con ellos relacionados con su contraseña y su rotación. Similar a LAPS, querrás asegurarte de que los atributos de gMSA estén restringidos solo a los objetos de Active Directory que necesiten acceder a ellos.

Atributos y permisos de gMSA

Las gMSAs tienen los siguientes atributos:

• msDS-ManagedPassword— Un BLOB con la contraseña del gMSA
• msDS-ManagedPasswordID— El ID clave utilizado para generar la contraseña actual de gMSA
• msDS-ManagedPasswordPreviousID— El ID clave utilizado para generar la contraseña gMSA anterior
• msDS-GroupMSAMembership— Una lista de los objetos que tienen permiso para consultar la contraseña del gMSA
• msDS-ManagedPasswordInterval— El intervalo (días) en el que se rota la contraseña

Dado que la información de la contraseña se almacena en el atributo msDS-ManagedPassword, definitivamente querrás saber quién en tu entorno puede consultar la contraseña. Esa información se establece en el atributo msDS-GroupMSAMembership.

Sin embargo, es un poco más complicado que solo ese atributo, ya que los permisos de Active Directory entran en juego. Si por alguna razón un usuario u objeto está configurado para tener permisos para consultar la contraseña a través de la cuenta msDS-GroupMSAMembership, aún necesitan tener permisos de 'Lectura' para el atributo msDS-ManagedPassword del gMSA.

Esto significa que hay dos formas de asegurar las contraseñas gMSA:

• Asegúrese de que solo los objetos necesarios tengan el permiso para consultar la contraseña y que existan en el msDS-GroupMSAMembership
• Asegúrese de que solo los usuarios administrativos que necesiten acceso y las cuentas de computadora donde se instalan los gMSAs tengan permiso para leer el atributo. Además, asegúrese de que solo los administradores tengan la capacidad de modificar el gMSA y sus atributos, para que nadie pueda agregarse al atributo msDS-GroupMSAMembership.

Idealmente, deberías asegurar los gMSAs a través de ambos caminos para evitar que un atacante tenga la opción de explotar cualquiera de los escenarios mencionados anteriormente. A continuación, mostraremos cómo los permisos o configuraciones mal gestionados en un gMSA pueden llevar al compromiso de la cuenta y privilege escalation o movimiento lateral.

Abusando de la contraseña gMSA

Abusar de una gMSA es un concepto relativamente simple. Primero, obtén su contraseña utilizando una herramienta como Mimikatz o consultándola directamente debido a configuraciones inseguras en Active Directory. Dado que las gMSAs son cuentas de servicio, generalmente tienen privilegios relativamente altos, por lo que luego normalmente podrás moverte lateralmente o escalar.

Recorramos un escenario de ejemplo.

1. Primero comprometemos la cuenta de usuario ordinaria de Windows ‘notadmin’ a través de una técnica como el phishing. Esta cuenta tiene privilegios mínimos en Active Directory, pero es un administrador local en la máquina en la que hemos aterrizado.

2. A continuación, intentaremos averiguar si existen gMSA. Es muy sencillo de realizar si tienes acceso al cmdlet de Windows PowerShell. Ejecutando un script simple obtenemos todas las cuentas de servicio administradas en Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Con algunas modificaciones menores al script, podemos identificar quién tiene acceso para consultar las contraseñas gMSA:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Como podemos ver, solo la cuenta de Kevin Joyce puede consultar las contraseñas de estas cuentas de servicio:

4. Podemos reducir el alcance de los objetivos que queremos comprobando si estas cuentas de servicio son miembros de algún grupo privilegiado, y a partir de ahí podemos profundizar en los permisos establecidos en uno de los objetos:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Observando los resultados aquí, podemos ver que la cuenta de servicio gMSA es miembro de Domain Admins, así que esta será la que intentaremos explotar.

5. Al modificar un script proporcionado en una publicación sobre Microsoft LAPS, pudimos obtener un listado de todos los objetos que tienen permisos sobre una cuenta de servicios administrados que incluía Control total, Escribir todas las propiedades o Escribir propiedad para el atributo gMSA específico. A continuación, se muestra el resultado y el script está vinculado en la parte inferior.

6. Como puede ver, la cuenta notadmin tiene Control Total sobre la cuenta gMSA. Esto nos da la capacidad de modificar el atributo msDS-GroupMSAMembership, lo que nos permitirá recuperar la contraseña para la cuenta de servicio administrado:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Ahora que realmente podemos consultar la contraseña, veamos qué podemos hacer con ella:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. El valor almacenado en el atributo es un BLOB que contiene los datos de la contraseña, no la contraseña en sí, por lo que tendremos que decodificar la contraseña utilizando una herramienta como DSInternals:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Esto nos proporciona el SecureCurrentPassword y el CurrentPassword. El CurrentPassword parece no ser útil, pero eso es porque todos los caracteres están en UTF-16. El SecureCurrentPassword puede convertirse en un hash NTLM y utilizarse en un ataque de pass the hash con mimikatz para elevar nuestros privilegios.

9. Para pass the hash solo necesitamos ejecutar mimikatz y usar este comando:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Ahora que tenemos una shell que se ejecuta como la cuenta de servicio gMSA que era miembro de Domain Admins, podemos hacer lo que queramos para comprometer Active Directory. Una de las maneras más rápidas, pero probablemente la más ruidosa de hacerlo, es ejecutar un DCSync attack y robar el hash de la cuenta krbtgt:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

Protección y monitoreo de gMSA

Existen estrategias que puedes utilizar para prevenir y detectar el abuso de gMSA.

Permisos

La protección más obvia y posiblemente la más importante que puedes implementar es asegurarte de que se establezcan los permisos adecuados en tus cuentas de servicio administradas por grupo. Comprender quién tiene acceso de escritura a estos objetos es pertinente para protegerlos; alguien que pueda agregarse al atributo que controla quién puede consultar la contraseña en teoría ya tiene acceso para tomar control de esta cuenta y abusar de sus privilegios.

Lo siguiente sería entender quién tiene la capacidad de consultar las contraseñas de estas cuentas y quién necesita exactamente tal acceso. En realidad, la única cuenta que debería poder obtener la contraseña de una gMSA es la cuenta de computadora en la que está instalada la gMSA.

Registros de eventos

Existe un evento que puedes buscar en los registros de eventos nativos que te ayudará a identificar quién está consultando las contraseñas de las cuentas gMSA. Si habilitas la política ‘Audit directory service access’ para tu dominio y configuras una SACL en las gMSAs que deseas monitorear, puedes generar registros de eventos cuando las personas consulten el atributo msDS-ManagedPassword:

Activar esta configuración y crear un nuevo SACL generará un registro de eventos con el ID de evento 4662; se ve así:

Como puede ver, se ha registrado que la cuenta ‘notadmin’ leyó una propiedad en la cuenta gMSA. Las propiedades leídas son los GUID almacenados en el esquema para Active Directory, pero utilizando ADSI edit podemos ver que el GUID resaltado se resuelve en el atributo msDS-ManagedPassword.

Suponiendo que pueda tener algún tipo de reenvío de registros de eventos o una solución SIEM, estos registros serían invaluables para determinar quién está accediendo a estos atributos.

Netwrix StealthDEFEND

Otra opción es una herramienta como Netwrix StealthDEFEND. Netwrix StealthDEFEND no depende de los registros de eventos nativos y puede detectar el acceso a contraseñas gMSA y la asignación de permisos de alto riesgo directamente. Por ejemplo, el escenario mostrado arriba generaría la siguiente amenaza cuando la cuenta 'notadmin' consultara la contraseña:

Además, con Netwrix StealthDEFEND, puede construir fácilmente un playbook para ejecutar cuando se detecte abuso de gMSA. El playbook puede involucrar múltiples pasos, como requerir que la cuenta de usuario perpetrador responda a una solicitud de MFA, deshabilitar la cuenta o crear un incidente en ServiceNow.

Apéndice

Código de permisos gMSA:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

ver en brutogMSA_Permissions_Collection.ps1 alojado con por GitHub

FAQ

¿Qué es una gMSA?

Similar a las cuentas de servicio administradas (MSA), las cuentas de servicio administradas en grupo (gMSAs) son cuentas de dominio administradas que se utilizan para ayudar a asegurar los servicios y la gestión de acceso. La funcionalidad de gMSA proporciona una gestión automática de contraseñas por parte del controlador de dominio (DC), una gestión simplificada del nombre de entidad de servicio (SPN) y la capacidad de delegar la gestión a otros administradores, lo que mejora la seguridad de Active Directory y minimiza las cuentas con acceso privilegiado.

¿Cuál es la diferencia entre MSAs y gMSAs?

A diferencia de una MSA, una gMSA puede asociarse con varios ordenadores.

Cómo encontrar una cuenta de servicio administrada por grupo?

Para obtener una lista de gMSAs en su controlador de dominio, abra Administrador del Servidor > Herramientas > Active Directory Users and Computers > Cuentas de Servicio Administradas.

¿Puede una gMSA ser un Administrador de Dominio?

Sí, una cuenta gMSA puede ser miembro de Domain Admins, aunque esta práctica puede ser peligrosa para la seguridad de la información.

¿Cómo puedo crear una gMSA?

Las cuentas de servicio administradas por grupo se crean con el cmdlet New-ADServiceAccount.