Contas de serviço no Windows: riscos e uso de gMSA

Por que contas de serviço viraram alvo preferido de atacantes

Quase todo ambiente Windows tem contas que não pertencem a nenhuma pessoa: a conta que roda o SQL Server, a que executa o backup toda noite, a que autentica o ERP no banco de dados, a que dispara tarefas agendadas no servidor de arquivos. Essas são as contas de serviço. Elas existem para que aplicações funcionem sem depender do login de um colaborador, e por isso costumam ficar fora das rotinas normais de gestão de identidade.

O problema começa na criação. Para evitar que um serviço pare quando a senha vencer, muitas equipes marcam a opção "A senha nunca expira" e definem uma senha que, na prática, nunca mais é trocada. Com o passar dos anos, a mesma credencial acaba em scripts, planilhas, documentação de fornecedores e na memória de ex-funcionários. Muitas vezes ninguém sabe dizer quais sistemas usam aquela conta, e trocar a senha vira um risco operacional que ninguém quer correr.

Para quem ataca, esse cenário é ideal. Uma conta de serviço normalmente tem privilégios altos, nunca troca a senha, raramente é monitorada e não tem um dono humano que perceba um acesso estranho. Em boa parte dos incidentes de ransomware em ambientes Active Directory, a movimentação lateral passa por uma conta de serviço mal protegida.

Os riscos mais comuns de contas de serviço tradicionais

Antes de falar da solução, vale entender onde está a exposição. Em auditorias de Active Directory, os mesmos problemas aparecem com frequência, independentemente do porte da empresa:

• Senha que nunca expira: a credencial continua válida por anos, inclusive depois de vazar ou de alguém que a conhecia sair da empresa.
• Privilégio excessivo: contas de serviço colocadas em Domain Admins "porque a instalação pedia", quando bastava permissão local em um servidor ou em um banco específico.
• Senha fraca ou previsível: padrões como nome do sistema mais o ano ou a mesma senha repetida em várias contas de serviço.
• Logon interativo permitido: a conta pode ser usada para entrar via RDP ou no console, o que facilita o abuso por quem descobre a senha.
• Credencial armazenada no servidor: quando um serviço do Windows roda com uma conta de domínio, a senha fica guardada nos segredos LSA da máquina e pode ser extraída por quem obtiver acesso administrativo local.

Existe ainda um risco específico, bastante explorado: o Kerberoasting. Contas de usuário com um Service Principal Name (SPN) registrado podem ter tickets de serviço Kerberos solicitados por qualquer usuário autenticado do domínio. Parte desse ticket é cifrada com uma chave derivada da senha da conta de serviço. O atacante leva o ticket para fora do ambiente e tenta quebrar a senha offline, sem gerar bloqueio de conta nem alertas de tentativas de logon. Se a senha for curta ou humana, é questão de tempo.

Uma conta de serviço com SPN, senha antiga e privilégio de administrador de domínio é, na prática, uma chave mestra que qualquer usuário do domínio consegue tentar copiar sem ser notado.

O que é gMSA e como ela resolve o problema da senha

A Group Managed Service Account (gMSA) é um tipo de conta do Active Directory criado justamente para rodar serviços. Ela chegou com o Windows Server 2012 como evolução das Managed Service Accounts do Windows Server 2008 R2, que eram limitadas a um único computador. A gMSA pode ser usada por vários servidores ao mesmo tempo, o que a torna viável para farms de IIS, clusters e aplicações distribuídas.

A grande diferença é que nenhuma pessoa conhece a senha. Ela é gerada e mantida pelo próprio domínio, por meio do Key Distribution Service (KDS) nos controladores de domínio. A senha tem 240 bytes (equivalente a 120 caracteres) de conteúdo aleatório e é trocada automaticamente, por padrão a cada 30 dias. Os servidores autorizados buscam a senha atual diretamente no Active Directory sempre que precisam, e o serviço continua funcionando sem intervenção manual.

Na prática, isso elimina vários riscos de uma vez:

• Não existe senha para anotar em planilha, enviar por e-mail ou esquecer em script.
• A rotação acontece sozinha, sem janela de manutenção e sem risco de derrubar o sistema.
• O Kerberoasting perde o sentido: quebrar uma senha aleatória de 120 caracteres é inviável com o poder computacional atual.
• Por padrão, a conta não serve para logon interativo de um usuário comum, o que reduz o abuso manual.
• Só os computadores explicitamente autorizados conseguem recuperar a senha.

Como implantar gMSA no seu Active Directory

A implantação é relativamente simples, mas exige alguns pré-requisitos. É preciso ter o schema do Active Directory em nível Windows Server 2012 ou superior e pelo menos um controlador de domínio com Windows Server 2012 ou mais recente. Nos servidores que vão usar a conta, é necessário o módulo Active Directory do PowerShell (parte do RSAT). Com isso resolvido, o roteiro básico é este:

1. Criar a KDS root key (uma única vez por floresta) com Add-KdsRootKey -EffectiveImmediately. Apesar do nome, o domínio aguarda cerca de 10 horas para a replicação entre controladores antes de liberar o uso da chave.
2. Criar um grupo de segurança com os servidores que poderão usar a conta, por exemplo GRP-gMSA-ERP, e adicionar as contas de computador. Os servidores precisam ser reiniciados (ou ter o ticket Kerberos renovado) para que a nova associação ao grupo passe a valer.
3. Criar a gMSA com New-ADServiceAccount -Name svc-erp -DNSHostName svc-erp.empresa.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-gMSA-ERP".
4. Instalar e testar no servidor com Install-ADServiceAccount svc-erp e depois Test-ADServiceAccount svc-erp, que deve retornar True.
5. Configurar o serviço para rodar como EMPRESA\svc-erp$ (o cifrão no final é obrigatório) e deixar o campo de senha em branco.
6. Conceder apenas as permissões necessárias: direitos no banco de dados, na pasta compartilhada ou no servidor específico, nunca em grupos administrativos amplos.

A gMSA funciona com serviços do Windows, pools de aplicativos do IIS, SQL Server e tarefas agendadas. Neste último caso, a configuração costuma ser feita via PowerShell, já que a interface gráfica do Agendador de Tarefas não oferece a opção de forma direta. Antes de migrar um sistema de terceiros, vale confirmar com o fornecedor se a aplicação aceita gMSA: alguns softwares legados exigem digitar a senha em uma tela própria e não conseguem trabalhar com uma credencial gerenciada.

Uma boa prática é migrar por etapas: comece por um serviço interno de baixo impacto, valide o comportamento por algumas semanas e só então avance para sistemas críticos como ERP e banco de dados.

Limitações da gMSA e boas práticas complementares

A gMSA reduz muito o risco, mas não é uma solução mágica. O ponto mais sensível é o grupo autorizado a ler a senha. Se um servidor desse grupo for comprometido, o atacante com privilégio administrativo local consegue recuperar a credencial da gMSA e usá-la em outros lugares. Por isso o atributo PrincipalsAllowedToRetrieveManagedPassword deve conter só os computadores que realmente precisam da conta, nunca grupos amplos como "Domain Computers". Também é essencial proteger os controladores de domínio e a KDS root key: quem controla o domínio controla todas as gMSAs.

Para as contas de serviço que ainda não podem ser migradas, algumas medidas diminuem bastante a exposição:

• Inventariar as contas com SPN usando Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet para saber quais estão expostas ao Kerberoasting e há quanto tempo não trocam a senha.
• Usar senhas longas e aleatórias, com 25 caracteres ou mais, guardadas em um cofre de senhas corporativo, nunca em arquivos de texto.
• Bloquear logon interativo e via RDP por GPO, com as diretivas "Negar logon local" e "Negar logon através dos Serviços de Área de Trabalho Remota".
• Exigir criptografia AES no Kerberos e desativar o RC4 sempre que possível, o que torna a quebra offline dos tickets bem mais difícil.
• Remover privilégios desnecessários, principalmente participação em Domain Admins, Enterprise Admins e Administrators.
• Monitorar eventos de autenticação, como o evento 4769 com volume anormal de pedidos de ticket de serviço, que pode indicar Kerberoasting em andamento.

Vale acompanhar também as novidades da Microsoft. O Windows Server 2025 trouxe as Delegated Managed Service Accounts (dMSA), pensadas para facilitar a migração de contas de serviço tradicionais para contas gerenciadas, vinculando a autenticação à identidade da máquina. Como todo recurso novo de identidade, a adoção deve vir acompanhada de revisão das permissões delegadas nas unidades organizacionais do AD e da aplicação das atualizações de segurança mais recentes.

Como a Duk ajuda a proteger as contas de serviço da sua empresa

Revisar contas de serviço é um daqueles trabalhos que todo mundo sabe que precisa fazer, mas que ficam para depois porque mexem em sistemas críticos. O receio de derrubar o ERP ou o backup acaba mantendo senhas de dez anos em produção. Fazer essa migração com método, inventário e plano de retorno é o que separa um projeto tranquilo de uma madrugada de incidente.

A Duk Informática & Cloud atua há mais de 18 anos com infraestrutura Microsoft e atende mais de 550 empresas. Como Microsoft Gold Partner, nossa equipe faz o levantamento completo das contas de serviço do seu Active Directory, identifica as que estão expostas a Kerberoasting ou com privilégio excessivo, planeja a migração para gMSA em etapas e aplica as políticas complementares de proteção, sem interromper a operação.

Se a sua empresa tem contas com senha que nunca expira, aplicações rodando como administrador de domínio ou simplesmente não sabe quais contas de serviço existem no ambiente, esse é um bom momento para conversar. Fale com a Duk e agende uma avaliação de segurança do seu Active Directory com quem cuida de ambientes Windows todos os dias.