Protegendo suas contas de serviço gerenciadas em 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.

As permissões de objeto de um gMSA decidem se essa automação permanece segura. Quando uma conta comum tem acesso de gravação ao atributo que controla a recuperação da senha, ela pode conceder a si mesma permissão para ler a credencial e então agir com os direitos existentes da identidade do serviço, incluindo qualquer associação a grupos privilegiados que a conta possua.

Essa única permissão é frequentemente a única coisa que separa uma implantação reforçada de uma violação em todo o domínio.

Contas de serviço são identidades não humanas, e 76% das organizações não as governam ou monitoram totalmente, de acordo com o Netwrix 2026 Data and Identity Security Report. Uma conta de serviço gerenciada por grupo remove a senha das mãos humanas, mas qualquer pessoa que possa reescrever quais principais podem recuperá-la ainda pode assumir a identidade.

O que é uma conta de serviço gerenciada por grupo (gMSA)?

Como funciona um gMSA

A senha de um gMSA passa pela mesma sequência em todos os hosts que a utilizam.

1. O Key Distribution Service (KDS) em cada controlador de domínio mantém o segredo usado para calcular as senhas de cada gMSA no domínio.

Uma conta de serviço gerenciada em grupo é uma conta gerenciada de Active Directory domain usada para executar serviços, aplicativos e tarefas agendadas. O Windows gera uma senha aleatória e a rotaciona automaticamente, e hosts autorizados recuperam a credencial do Active Directory em tempo de execução, para que os administradores nunca precisem saber a senha ou armazená-la em arquivos.

1. O host também recupera a senha anterior, mantendo a autenticação funcionando durante a breve janela enquanto a rotação se propaga.

gMSAs não se aplicam a sistemas operacionais Windows anteriores ao Windows Server 2012, portanto, todo host que os utiliza precisa do Windows Server 2012 ou superior. Um gMSA suporta uma identidade de serviço em vários computadores, enquanto uma conta de serviço gerenciada independente suporta um computador, e uma conta de usuário comum deixa o gerenciamento de senhas para os administradores.

1. Como cada host autorizado se autentica como o mesmo principal de domínio, um gMSA também simplifica o gerenciamento do Service Principal Name (SPN) para serviços que compartilham uma identidade entre hosts.
2. O Windows altera a senha automaticamente, a cada 30 dias por padrão, sem que nenhum host precise de aviso prévio ou intervenção manual.
3. Um host autorizado contata um controlador de domínio e recupera a senha atual em tempo de execução, calculada a partir desse segredo, em vez de armazená-la localmente.

gMSA vs outros tipos de contas de serviço

Juntos, esses atributos indicam a um host como recuperar a senha, e msDS-GroupMSAMembershipExpand é o que um atacante precisa reescrever, a má configuração que o tutorial mais abaixo explora.

Active Directory representa um gMSA com a classe de objeto msDS-GroupManagedServiceAccountExpand, e esses atributos do esquema armazenam a senha e os controles de recuperação.

Windows oferece vários principais para executar serviços, e cada um suporta serviços diferentes e gerencia sua senha de forma diferente. Escolha o tipo de conta de acordo com os requisitos de autenticação e o modelo de implantação do aplicativo.

Ao contrário de um sMSA, um gMSA pode ser compartilhado entre vários computadores, tornando-o adequado para fazendas de servidores e serviços balanceados. Ambos são contas de serviço gerenciadas que permitem que o Windows e o Active Directory gerenciem as senhas.

Por que as gMSAs são importantes

A Microsoft observa que as senhas gMSA são geradas pela máquina e rotacionadas automaticamente, mas não estão vinculadas à máquina, portanto ainda podem ser lidas a partir de um host comprometido, e uma gMSA não pode ser migrada diretamente para uma dMSA.

Windows Server 2025 adiciona a delegated managed service account (dMSA), que migra uma conta de serviço tradicional para uma conta de máquina com chaves gerenciadas e aleatórias, vinculando a autenticação à identidade do dispositivo.

Senhas fortes que ninguém precisa gerenciar

Usar uma conta de usuário comum como conta de serviço coloca a geração, distribuição e rotação de senhas nas mãos dos administradores, e a senha permanece inalterada até que alguém a altere. Um gMSA substitui esse ciclo manual por geração e recuperação gerenciadas pelo domínio.

A senha ainda precisa alcançar cada host, portanto, a autorização e a segurança do host fazem parte da proteção das credenciais.

Uma identidade em toda uma fazenda de servidores

Protocolos de autenticação que suportam autenticação mútua, como Kerberos, exigem que cada instância de um serviço hospedado em farm use o mesmo principal. Um gMSA fornece a todos os hosts membros um principal de domínio único, e os administradores gerenciam suas permissões centralmente sem sincronizar uma senha entre os hosts.

Menor exposição a ataques de força bruta e uso indevido

Um gMSA usa uma senha de 240 bytes gerada aleatoriamente que o Windows altera a cada 30 dias, minimizando o risco de comprometimento por meio de ataques de força bruta ou dicionário. Os administradores configuram a conta e seus hosts autorizados e nunca manipulam a senha, para que os serviços obtenham credenciais fortes sem que ninguém as copie em scripts, notas de implantação ou arquivos de configuração.

Serviços do Windows, pools de aplicativos IIS e tarefas agendadas podem ser executados como gMSA, e a orientação Kerberoasting da Microsoft também cita o SQL Server. O suporte ao aplicativo continua sendo um requisito de implantação, portanto, teste cada serviço sob o gMSA antes de ir para produção.

Uma configuração padrão mais segura contra Kerberoasting

A geração automática elimina a seleção de senhas pelas pessoas, e a rotação automática elimina a tarefa recorrente de atualizar uma credencial estática em cada host de serviço. A Microsoft recomenda gMSAs para serviços locais, a menos que um serviço não possa usá-los.

A responsabilidade restante é a governança de acesso, porque alguém que pode alterar a autorização de recuperação de senha pode obter a credencial sem nunca participar da geração da senha.

Kerberoasting permite que um invasor com qualquer conta de domínio solicite tickets de serviço e quebre a senha de uma conta de serviço offline, portanto, a força da senha determina se o ataque funciona.

As orientações de Kerberoasting da Microsoft indicam contas com senhas fracas como as mais vulneráveis e recomendam gMSAs ou dMSAs sempre que possível, pois uma senha gerada elimina a fraqueza escolhida pelo humano da qual a técnica depende.

Como configurar um gMSA com segurança

Netwrix Threat Manager detecta roubo de credenciais, movimentação lateral e escalonamento de privilégios em ambientes híbridos. Solicite uma demonstração.

1. Verifique os requisitos

Confirme os requisitos de domínio, host, administração e aplicação antes de implantar o gMSA.

Crie a conta com uma lista explícita de hosts autorizados, depois instale e valide em cada host.

• Níveis funcionais de domínio e floresta definidos para Windows Server 2012 ou posterior, que a Microsoft diz suportar recursos gMSA para todos os dispositivos.
• Hosts que executam Windows Server 2012 ou posterior.
• O módulo PowerShell do Active Directory no sistema de administração, que precisa de uma arquitetura de 64 bits para executar os cmdlets gMSA.
• Uma chave raiz KDS disponível para os controladores de domínio.
• Membro de Domain Admins ou Enterprise Admins, ou permissão delegada para criar msDS-GroupManagedServiceAccountExpand objetos.
• Um serviço que suporta gMSAs, como um serviço do Windows, um pool de aplicativos IIS ou uma tarefa agendada.

Delegue a criação de gMSA para um grupo administrativo dedicado e mantenha a identidade do serviço fora dos grupos administrativos.

2. Crie a chave raiz KDS

3. Crie o gMSA com New-ADServiceAccount

Clusters de failover não suportam gMSAs, mas serviços que rodam no serviço Cluster podem usar um se forem um serviço Windows, um pool de aplicativos ou uma tarefa agendada, ou se suportarem gMSAs nativamente. Kerberos também deve funcionar de ponta a ponta, então registre os SPNs para cada serviço, mantenha os registros DNS e os relógios precisos, e permita o tráfego Kerberos entre os sistemas envolvidos.

Apesar do nome do parâmetro, -EffectiveImmediatelyExpand não ignora a replicação. Outros controladores de domínio não podem usar a chave até que ela seja replicada, e o procedimento de criação de chaves da Microsoft faz com que os controladores de domínio esperem até 10 horas antes de permitir a criação de um gMSA, então permita essa janela em produção.

4. Instale e teste o gMSA em cada host

Crie um grupo de segurança dedicado para as contas dos computadores host do serviço, depois crie o gMSA com New-ADServiceAccountExpand, nomeando seu nome DNS e o grupo de segurança em PrincipalsAllowedToRetrieveManagedPasswordExpand. A Microsoft exige que os nomes gMSA sejam únicos em toda a floresta, não apenas no domínio.

Verifique se a floresta já possui uma chave raiz KDS antes de criar uma, pois a chave é um pré-requisito único a nível de floresta. Crie-a em um controlador de domínio Windows Server 2012 ou posterior com Add-KdsRootKey -EffectiveImmediatelyExpand, depois confirme o ID do Evento 4004Expand no log de eventos KDS.

5. Configure o serviço para ser executado como o gMSA

Defina um intervalo de senha personalizado com -ManagedPasswordIntervalInDaysExpand durante a criação, se o deployment precisar, pois o intervalo só pode ser definido na criação. Registre o proprietário do aplicativo da conta e os hosts pretendidos junto com a configuração do deployment, e exclua grupos gerais de administração de servidores e grupos que contenham usuários comuns do parâmetro de recuperação, conforme explicado em "Limit who can retrieve the password".

Teste cada servidor membro individualmente, pois um resultado bem-sucedido em um servidor não garante a associação a grupos ou conectividade em outro servidor. Resolva a validação falhada antes de alterar a identidade de logon de um serviço em produção.

Defina a identidade de logon do serviço por meio do Service Control Manager, das configurações de identidade do pool de aplicativos IIS ou da configuração da tarefa agendada, e deixe a senha em branco. O Windows recupera a credencial gerenciada.

Como os atacantes abusam de uma senha gMSA

Conceda à conta as permissões de aplicativo necessárias e, em seguida, confirme tanto a inicialização do serviço quanto o acesso aos recursos dependentes. Um teste de conta aprovado comprova apenas a prontidão das credenciais, portanto, a carga de trabalho ainda precisa de suas próprias permissões para arquivos, banco de dados e outros recursos.

Adicione a conta de computador de cada host ao grupo de segurança, depois execute Install-ADServiceAccountExpand seguido por Test-ADServiceAccountExpand em cada host autorizado. Test-ADServiceAccountExpand verifica se o host pode recuperar a senha.

O laboratório abaixo usa uma conta comum chamada notadminExpand e um gMSA privilegiado que está mal configurado. Os nomes de domínio e conta pertencem a esse ambiente de exemplo.

Encontre os gMSAs e quem pode lê-los

Um invasor pode recuperar uma senha gMSA por meio de um caminho autorizado ou permissões inseguras do Active Directory, e então autenticar-se como a conta com seus direitos existentes.Exploração de gMSA cobre a classe de ataque mais ampla, incluindo ataques Golden gMSA, que seguem uma rota diferente para credenciais gerenciadas.

1. Com o módulo PowerShell do Active Directory disponível, o invasor enumera as contas de serviço gerenciadas com Get-ADServiceAccount -Filter *Expand.

Encontre um gMSA privilegiado e uma forma de entrar

1. Solicitar a propriedade PrincipalsAllowedToRetrieveManagedPasswordExpand mostra quais principais podem ler a senha de cada conta.

Nos resultados do laboratório, apenas uma conta administrativa pode consultar as senhas, então notadminExpand ainda não pode lê-las. Essa configuração é importante quando o atacante examina quem pode alterar o objeto gMSA.

1. O invasor verifica se alguma conta de serviço pertence a grupos privilegiados consultando a propriedade memberOfExpand.

O gMSA do laboratório pertence a Domain Admins, então o atacante o seleciona. Sua associação existente fornece os privilégios necessários para as etapas posteriores.

Recuperar e decodificar a senha

1. Revisar permissões de objetos identifica principais com Controle total, Gravar todas as propriedades ou Gravar propriedade no atributo de autorização de recuperação de senha, usando um script adaptado de uma abordagem descrita em um post sobre Microsoft LAPS. O script de permissões em "Find and audit every gMSA" abaixo executa a mesma verificação.
2. No laboratório, notadminExpand tem Controle Total sobre o objeto gMSA, o que lhe permite usar Set-ADServiceAccountExpand para se adicionar a PrincipalsAllowedToRetrieveManagedPasswordExpand.

Use a senha para escalar

1. O atributo contém um BLOB com os dados da senha em vez da senha em si, então o invasor o decodifica com DSInternals, que expõe os valores da senha atual e anteriores e pode converter a senha atual em um hash NT.
2. O atacante compromete notadminExpand por meio de uma técnica como phishing. A conta tem privilégios mínimos do Active Directory, mas possui local administrator rights na máquina comprometida.
3. Após a alteração, notadminExpand pode consultar o atributo msDS-ManagedPasswordExpand e armazenar o objeto retornado.

Como proteger seus gMSAs

Uma única permissão excessivamente ampla, Full Control em um objeto gMSA, foi o que permitiu que o ataque passasse de uma conta comprometida comum para a falsificação de credenciais em todo o domínio.

Os ataques Golden gMSA alcançam a senha de um gMSA por uma rota diferente e são abordados na página de exploração de gMSA.

Proteja em conjunto a autorização de recuperação de um gMSA, permissões de objetos e privilégios de serviço.

1. Com a credencial recuperada, o atacante autentica-se como gMSA via pass-the-hash e inicia um processo sob a identidade do serviço, herdando todos os direitos que essa identidade possui.

Limitar quem pode recuperar a senha

Restringir quem pode alterar o gMSA

1. Como o gMSA do laboratório pertence a Domain Admins, o invasor pode usar seus direitos de replicação para executar um ataque DCSync contra a conta krbtgtExpand. O material de credenciais dessa conta assina todos os tickets Kerberos no domínio, então recuperá-lo permite que o invasor falsifique tickets para qualquer usuário posteriormente.

Mantenha os gMSAs fora dos grupos privilegiados

Apenas as contas de computador que executam o serviço devem normalmente recuperar sua senha gMSA. Para uma implantação multi-servidor, use um grupo de segurança dedicado contendo essas contas de computador, configure-o através de PrincipalsAllowedToRetrieveManagedPasswordExpand, e revise sua associação sempre que a lista de hosts do serviço mudar.

Conceda acesso de gravação apenas aos administradores que precisam gerenciar a conta e revise as permissões Controle Total, Gravar Todas as Propriedades e Gravar Propriedade específica em cada gMSA. Um principal com permissão para alterar msDS-GroupMSAMembershipExpand pode autorizar a recuperação da própria senha, que é exatamente a má configuração que o tutorial acima explora.

Conceda a cada gMSA apenas os direitos que seu serviço requer. Um gMSA pode pertencer a Domain Admins, mas essa associação concede a qualquer pessoa que obtenha suas credenciais privilégios administrativos em todo o domínio, e a orientação de mitigação da Microsoft recomenda revisar as permissões da conta de serviço e remover acessos excessivos.

Aplicar criptografia AES

Proteja a conta por meio de ambos os caminhos de permissão. Restrinja quais principais o atributo msDS-GroupMSAMembershipExpand representa e restrinja o acesso ao diretório ao próprio objeto gMSA, especialmente a permissão para modificar a conta ou sua autorização de recuperação.

Verifique a associação direta ao grupo e as permissões efetivas que os grupos aninhados conferem, e documente o acesso necessário do aplicativo antes de remover permissões para que o proprietário do serviço possa validar a configuração revisada.

Controladores de domínio com Windows Server 2025 não emitem mais tickets de concessão RC4, portanto, um dispositivo legado que depende de RC4 não pode se autenticar neles.

Encontre e audite cada gMSA

A Microsoft está eliminando a criptografia RC4 Kerberos por padrão, não apenas recomendando contra ela. Uma atualização de 2022 já mudou o tipo de criptografia padrão para Advanced Encryption Standard (AES)-SHA1 para qualquer conta sem tipo de criptografia explícito configurado.

Verifique o atributo msDS-SupportedEncryptionTypesExpand de cada gMSA e confirme que inclua AES em vez de depender do padrão de fallback do domínio, pois é exatamente esse fallback que a Microsoft está removendo.

Redefina a senha da conta após ativar o suporte AES para gerar novas chaves e depois teste a autenticação, pois um gMSA deixado apenas no RC4 pode perder completamente a autenticação Kerberos em vez de funcionar com um cifrador mais fraco.

Monitorar leituras de senha

Script original: gMSA_Permissions_Collection.ps1.

O evento resultante identifica a conta do sujeito, o objeto do diretório alvo e as propriedades acessadas.

O script de permissões abaixo informa quais contas possuem Controle Total ou acesso de Gravar Propriedade ao atributo msDS-GroupMSAMembershipExpand de um gMSA, a verificação que a etapa 5 do tutorial acima executa do lado do atacante. Os administradores ainda precisam revisar herança, associação a grupos e acesso efetivo ao decidir quem deve manter esses direitos.

Enumere as contas de serviço gerenciadas com Get-ADServiceAccount -Filter *Expand, depois filtre os objetos cujo ObjectClassExpand é msDS-GroupManagedServiceAccountExpand para distinguir gMSAs de contas de serviço gerenciadas independentes.

Remova gMSAs que você não usa mais

Ative a política de acesso ao serviço de diretório de auditoria e configure uma lista de controle de acesso do sistema (SACL) nos gMSAs para monitorar, o que gera o ID de evento 4662Expand sempre que um principal lê msDS-ManagedPasswordExpand.

Os identificadores de propriedade aparecem como GUIDs de esquema no evento, e o ADSI Edit pode resolver o GUID relevante para confirmar que corresponde a msDS-ManagedPasswordExpand.

Encaminhe os logs do controlador de domínio para um sistema de gerenciamento de informações e eventos de segurança (SIEM), compare as leituras de senha com os hosts de serviço aprovados da conta e investigue recuperações por usuários ou computadores inesperados.

Como a Netwrix ajuda a proteger os gMSA

Proteger a administração de gMSA

A revisão manual das permissões de recuperação e dos logs de auditoria não é escalável quando um ambiente possui mais do que alguns gMSAs. Estes três produtos Netwrix cobrem o acesso administrativo à conta, detectam o uso indevido de credenciais e fornecem visibilidade contínua sobre quais contas ainda possuem permissões excessivas.

Remova um gMSA não utilizado de seus hosts anteriores com Uninstall-ADServiceAccountExpand. A desinstalação do host e a remoção da conta do diretório são ações de ciclo de vida separadas. Confirme que todas as cargas de trabalho dependentes foram migradas ou aposentadas antes de excluir o objeto AD e remova autorizações de host obsoletas e permissões de recursos associadas como parte da mesma alteração.

Detectar comportamento anômalo de contas de serviço

Com Netwrix Privilege Secure, o distrito concede acesso imediato por meio de contas temporárias que são removidas assim que a tarefa é concluída, e implementou Privileged Access Management para seus sistemas críticos em dias, não meses.

Netwrix Privilege Secure substitui o acesso permanente a objetos privilegiados como gMSAs por contas temporárias limitadas à tarefa. Eastern Carver County Schools viu equipes Red Teams obterem repetidamente acesso a sistemas críticos por meio de acesso privilegiado excessivo e desnecessário.

Encontre contas de serviço com permissões excessivas e obsoletas

Netwrix Threat Manager detecta roubo de credenciais, movimento lateral e escalonamento de privilégios em ambientes híbridos. Investigue essas detecções para abuso de identidades de serviço como gMSAs, onde um invasor que se autentica com uma senha gerenciada roubada exerce os direitos existentes da identidade.

Combine a rotação automática com permissões rigorosas de recuperação

Netwrix Access Analyzer resolve a associação a grupos aninhados e analisa as permissões efetivas em objetos do Active Directory, e seus relatórios também sinalizam contas de fiduciários obsoletas. Use essas descobertas para revisar a recuperação de gMSA e as permissões de objetos e identificar candidatos para limpeza.

A rotação automática de senhas e as permissões rigorosas de recuperação são dois controles separados, e um gMSA permanece seguro apenas quando ambos são mantidos. O exemplo acima mostra o que acontece quando apenas uma permissão falha: uma conta comprometida comum herda uma credencial de Domain Admin e falsifica tickets para todo o domínio, sem que nenhuma senha seja quebrada ou adivinhada.

Trate as revisões de permissões como trabalho recorrente, não como uma etapa de configuração única, pois cada novo host, cada alteração na associação de grupo e cada migração de serviço podem reabrir o mesmo caminho.

Solicite uma demonstração para ver como Netwrix Privilege Secure remove o acesso permanente a contas privilegiadas, Netwrix Threat Manager detecta abuso de contas de serviço e Netwrix Access Analyzer identifica contas com permissões excessivas.