Ataques de exploração gMSA e ataques Golden gMSA explicados

O que é um ataque gMSA?

Um ataque a uma conta de serviço gerenciada em grupo é uma intrusão onde os invasores comprometem ou calculam credenciais gMSA para obter acesso não autorizado a serviços e escalar privilégios em todo o ambiente do Active Directory.

gMSAs são usados para serviços do Windows, pools de aplicativos IIS, serviços do SQL Server, tarefas agendadas, serviços de backup e outras identidades de serviço automatizadas onde um serviço precisa de uma credencial de domínio gerenciada automaticamente. O abuso de gMSA oferece uma ampla superfície de ataque porque todo sistema ou serviço autorizado a recuperar ou executar com um gMSA se torna um ponto de entrada potencial para atacantes. Ao ler senhas gMSA e explorar essas contas, os atacantes podem se passar por identidades de serviço, mover-se lateralmente dentro do domínio e manter uma presença persistente que é difícil de detectar e remediar.

Os invasores geralmente usam os seguintes métodos para exploração de gMSA:

• Leia msDS-ManagedPassword: Invasores comprometem um host ou conta com acesso SYSTEM/autorizado e leem o atributo msDS-ManagedPassword para um gMSA do Active Directory. Este atributo contém as senhas atuais e anteriores do gMSA, então, ao ler os valores do atributo, os invasores realmente leem as senhas do gMSA.
• Golden gMSA (abuso da chave raiz KDS): Adversários obtêm os atributos da chave raiz do KDS (Key Distribution Service) (armazenados em CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=domain,DC=com) e os usam para calcular senhas gMSA offline, sem contatar um controlador de domínio. Forjando credenciais válidas, os atacantes podem autenticar-se como essas contas de serviço a qualquer momento.

Ataques Golden gMSA

Aqui estão as principais características de um ataque Golden gMSA:

• O comprometimento inicial requer direitos de alto nível (por exemplo, conta Domain Admin ou SYSTEM em um controlador de domínio) para ler ou exportar o material da chave raiz KDS.
• Uma vez obtidos os atributos da chave raiz KDS, os atacantes podem:
  • Calcule as senhas gMSA atuais e futuras sem contatar um controlador de domínio, para que não gere logs de autenticação nos DCs.
  • Criar credenciais para qualquer gMSA no domínio.
  • Mantenha o acesso persistente mesmo após a detecção da violação inicial (a chave raiz é válida por até 10 anos por padrão).
• Conceitualmente, um ataque Golden gMSA é análogo a um ataque Golden Ticket, pois ambos envolvem a criação de credenciais forjadas ou derivadas.

Usos da ferramenta

As seguintes ferramentas e scripts facilitam a exploração do Golden gMSA:

• Utilitários de despejo de credenciais são usados para extrair credenciais ou material de credenciais de um host para que um atacante possa escalar privilégios ou se mover lateralmente. Os alvos incluem a memória onde vivem tokens de autenticação/hashes NTLM, credenciais em cache e cópias de backup dos armazenamentos de credenciais.
• Utilitários de enumeração AD mapeiam objetos, permissões e relacionamentos do Active Directory para que um atacante possa encontrar onde chaves/objetos sensíveis estão localizados (para gMSA: chaves raiz KDS, objetos msDS-ManagedPassword e vínculos de serviço). Eles sondam a associação a grupos, ACLs e atributos.
• Utilitários de prova de conceito e scripts personalizados implementam lógica matemática/criptográfica que deriva senhas gMSA a partir da chave raiz KDS e dos metadados do objeto.

Como funciona um ataque gMSA?

Um ataque de exploração gMSA segue um caminho em etapas: o atacante começa descobrindo onde os gMSAs são usados e, finalmente, consegue se mover lateralmente e escalar privilégios de forma persistente e furtiva. Aqui estão as fases do ataque:

Descubra o uso do gMSA

Os atacantes começam mapeando onde os gMSAs estão implantados no ambiente. Eles escaneiam o Active Directory e os endpoints para identificar serviços, pools de aplicativos, tarefas agendadas e processos de banco de dados ou backup que são executados sob identidades gMSA. Com esse mapeamento, eles sondam esses hosts em busca de vulnerabilidades exploráveis (como RCE em servidores web, falhas de serviço não corrigidas e configurações de serviço fracas) que podem ser abusadas para obter execução de código ou escalar para NT AUTHORITY\SYSTEM.

Acessar senhas gMSA

Em um host comprometido com privilégios SYSTEM ou por meio de uma conta com permissões suficientes no Active Directory, o invasor usa ferramentas ou APIs (por exemplo, PowerShell com DSInternals ou leituras de diretório) para recuperar o atributo msDS-ManagedPassword. O invasor então decodifica o blob de credenciais em texto simples (ou um hash NTLM), frequentemente usando a função PowerShell ConvertFrom-ADManagedPasswordBlob. Com essas credenciais em texto simples ou derivadas, o invasor pode fazer login como a conta de serviço, executar o serviço, acessar quaisquer recursos que ela possa alcançar e se mover para outros sistemas com pouco esforço.

Ataque Golden gMSA

Em um cenário Golden gMSA, um adversário extrai os atributos da chave raiz KDS (como msKds-RootKeyData, msKds-KDFParam e parâmetros KDF relacionados) que o Active Directory usa para derivar senhas gMSA. Usando ferramentas como GoldenGMSA ou scripts personalizados, eles podem calcular senhas gMSA atuais e futuras offline. Dessa forma, podem autenticar-se em qualquer serviço que dependa dessas gMSAs.

Movimentação lateral ou escalonamento de privilégios

Uma vez que as credenciais gMSA (seja lidas diretamente ou calculadas a partir da chave KDS) estejam sob o controle do invasor, ele pode usá-las para:

• Autentique-se em bancos de dados, interfaces de gerenciamento, compartilhamentos de arquivos ou outros serviços que aceitam o gMSA.
• Mude para outros hosts que confiam na identidade do serviço.
• Combine com técnicas Silver Ticket ou Golden Ticket, ou abuso de token para escalar privilégios.
• Exfiltrar dados sensíveis.
• Implante persistência ou crie novas contas de serviço privilegiadas.

Serviços executados sob gMSAs geralmente operam com privilégios elevados e conectividade extensa, oferecendo aos atacantes uma ampla superfície de ataque para explorar.

Diagrama do fluxo de ataque

Aqui está um diagrama de fluxo explicando a cadeia de eventos em um ataque gMSA e um exemplo de história do ponto de vista de uma organização para ajudá-lo a entender o ataque.

Um invasor compromete o servidor web voltado para o cliente de uma organização por meio de um plugin vulnerável, instala um web shell, escala para SYSTEM nesse host e extrai credenciais de serviço. Usando a chave raiz KDS despejada e os parâmetros KDF, ele calcula senhas gMSA offline e autentica-se nos serviços de backend (banco de dados e compartilhamentos de arquivos) sem se conectar ao controlador de domínio. Em 48 horas, exfiltram registros sensíveis de clientes.

Exemplos de ataques gMSA

Não existem relatórios públicos ou divulgações de violação que indiquem que um atacante usou um ataque gMSA ou Golden gMSA na prática. Mas há pesquisas extensas, PoCs, ferramentas e orientações de fornecedores que provam que a técnica é real e prática. A seguir está um resumo das evidências do mundo real.

Consequências dos ataques gMSA

As equipes de TI usam gMSAs para acesso automatizado e com privilégios elevados. O roubo delas pode amplificar um incidente, permitindo movimentação lateral furtiva, acesso prolongado e ampla exposição de dados. Isso pode significar consequências financeiras, operacionais, reputacionais e legais graves.

Alvos comuns de ataques gMSA: Quem está em risco?

De modo geral, grandes empresas, agências governamentais e instituições financeiras que operam ambientes complexos de Active Directory com muitos gMSAs para serviços (SQL, IIS, Exchange, backups) estão entre os alvos mais comuns de ataques a gMSA. Do ponto de vista técnico, os seguintes componentes em uma infraestrutura de TI estão mais em risco:

Avaliação de risco

Para avaliar o risco de ataques gMSA, você deve considerar três fatores principais: o dano potencial de um ataque, a dificuldade de executar o ataque e a probabilidade de sua ocorrência. Juntos, eles destacam por que os gMSAs exigem proteção e monitoramento fortes.

Como prevenir ataques gMSA

Ao implementar controles técnicos rigorosos e práticas administrativas sólidas, as organizações podem reduzir o risco de um ataque de exploração de gMSA.

Medidas técnicas

As seguintes medidas técnicas podem ajudar a prevenir ataques gMSA e Golden gMSA:

• Configure listas de controle de acesso do sistema (SACLs) nas chaves raiz KDS para registrar quaisquer tentativas de leitura do atributo msKds-RootKeyData. Dessa forma, as equipes de segurança são alertadas se os invasores tentarem acessar os segredos usados para derivar senhas gMSA.
• Imponha o princípio do menor privilégio nas associações gMSA. Para isso, limite quais contas e grupos são listados no atributo msDS-GroupMSAMembership de um gMSA. Apenas os serviços que realmente precisam do gMSA devem ter acesso. Remover associações desnecessárias ajuda a fechar possíveis caminhos de abuso.
• Revise regularmente quem tem permissão para gerenciar e usar gMSAs. As equipes de segurança devem auditar as alterações nas permissões e nos padrões de uso para identificar atividades suspeitas que possam indicar acesso não autorizado e tentativas de escalonamento de privilégios.
• Reduza o valor da configuração ManagedPasswordIntervalInDays para que as senhas gMSA sejam atualizadas com mais frequência. Isso limita a janela de oportunidade para que invasores reutilizem credenciais comprometidas.

Melhores práticas administrativas

Como parte das melhores práticas administrativas, as organizações devem manter um controle rigoroso sobre o ciclo de vida do gMSA e a gestão de chaves.

• Periodicamente crie novas chaves raiz KDS e as reatribua às suas gMSAs ativas. Isso evita que chaves antigas ou potencialmente comprometidas sejam usadas para derivar senhas gMSA válidas.
• Monitore o Evento ID 4662, que registra tentativas de acesso a objetos de diretório. Monitorar este evento especificamente para atributos gMSA pode ajudar a detectar acessos não autorizados ou consultas suspeitas.
• Desative proativamente os gMSAs que não estão mais em uso e remova permissões órfãs de serviços antigos. Isso reduz o número de contas disponíveis para os atacantes explorarem, minimizando sua superfície de ataque geral.

Como a Netwrix pode ajudar

Netwrix’s Identity Threat Detection & Response (ITDR) suite ajuda as organizações a identificar atividades suspeitas e proteger sua infraestrutura de identidade em ambientes locais e híbridos. Oferece capacidades de visibilidade, alerta, resposta e recuperação relevantes para a defesa de gMSAs.

Aqui estão algumas de suas capacidades principais e como elas se relacionam com a prevenção ou mitigação de riscos relacionados a gMSA:

Detecção de ameaças

Produtos Netwrix ITDR, como Threat Manager e Threat Prevention, podem detectar atividades suspeitas relacionadas à infraestrutura de identidade, como alterações incomuns ou não autorizadas no Active Directory. Eles podem monitorar alterações e acessos em nível de objeto e atributo no AD (como leituras não autorizadas dos atributos msDS-ManagedPassword e msKds-RootKeyData) e podem alertar sobre alterações de configuração arriscadas ou mudanças na associação de grupos privilegiados.

Real-time monitoring and alerting

Netwrix ITDR fornece alertas em tempo real sobre eventos críticos do Active Directory e padrões anômalos de acesso. Isso inclui o monitoramento de contas que não são controladores de domínio tentando acessar atributos sensíveis do KDS, a associação a grupos sensíveis e modificações em atributos privilegiados. Esses recursos de monitoramento ajudam a detectar o uso indevido de gMSA.

Resposta rápida

Netwrix ITDR suporta ações automatizadas ou semi-automatizadas de resposta a incidentes caso uma violação seja detectada, como desativar contas, gerar alertas, reverter alterações indesejadas e iniciar investigações forenses. Em um cenário de ataque gMSA, isso significa que você pode responder rapidamente quando uma atividade suspeita for detectada, como desativar o gMSA ou revogar permissões.

Auditoria e relatórios de segurança

Netwrix Auditor fornece trilhas de auditoria detalhadas, valores “antes e depois” para alterações no AD, relatórios de avaliação de risco, painéis e relatórios de conformidade. Estes são úteis para rastrear alterações de permissão gMSA, uso ao longo do tempo e identificação de configurações incorretas.

Estratégias de detecção, mitigação e resposta

Para se defender contra ataques relacionados ao gMSA, as organizações devem adotar uma abordagem proativa que abranja detecção precoce, mitigação preventiva e resposta eficaz. Aqui estão algumas etapas práticas para fortalecer suas defesas contra comprometimentos da chave raiz KDS e do gMSA.

Detecção

Para detectar um ataque gMSA precocemente, as equipes devem seguir estas práticas:

Monitore leituras não autorizadas de atributos críticos, como msDS-ManagedPassword e msKds-RootKeyData

Esses atributos estão diretamente ligados à recuperação de senha gMSA e à geração offline de senhas, e raramente são acessados fora das operações normais do controlador de domínio. Consultas incomuns contra eles podem indicar tentativas de coleta de credenciais. Para detectar isso, os administradores podem ativar a auditoria do serviço de diretório no Active Directory e configurar a Auditoria Avançada de Segurança para registrar o Acesso ao Serviço de Diretório (ID do Evento 4662).

Verifique contas não-DC acessando atributos sensíveis do KDS

Apenas controladores de domínio devem interagir com os dados da chave raiz KDS. Monitorar o acesso por contas inesperadas pode revelar uso indevido de privilégios ou tentativas de movimentação lateral.

Combine monitoramento com análises

Ao filtrar leituras em atributos sensíveis e correlacioná-las com o tipo de conta (como contas não-DC), as equipes de segurança podem detectar consultas suspeitas. Melhor ainda, integre esses logs em uma plataforma SIEM para correlação entre eventos, detecção de anomalias e alertas em tempo real.

Uso normal básico de gMSA em serviços e servidores

Isso permite a detecção de anomalias quando gMSAs são acessados fora do seu escopo esperado (por exemplo, um gMSA SQL sendo usado em um servidor web).

Mitigação

As equipes de TI devem abordar a mitigação como um esforço coordenado e em camadas que não apenas corta o acesso atual do invasor, mas também fortalece as defesas para minimizar as chances de comprometimento futuro. Alguns passos importantes de mitigação são discutidos abaixo.

Recriar gMSAs contra uma nova chave raiz KDS quando houver suspeita de comprometimento

Gerar uma nova chave raiz corta a capacidade de um invasor de derivar senhas a partir de artefatos previamente expostos, restaurando a confiança nas contas gerenciadas.

Renove as senhas gMSA executando Test-ADServiceAccount

Forçar a atualização da senha garante que, mesmo que as credenciais sejam comprometidas, os invasores percam o acesso a segredos válidos.

Aplicar segmentação e impor escopo

Implemente segmentação de rede e serviço para limitar onde gMSAs podem ser usados. Dessa forma, se um nível for comprometido, os atacantes não poderão se mover facilmente para outras áreas sensíveis.

Teste regularmente seus playbooks de remediação

Realize exercícios práticos e técnicos que simulem a rotação da chave KDS e a recuperação do gMSA para garantir que seus procedimentos sejam eficazes e funcionem sob pressão.

Resposta

Quando um ataque gMSA é suspeito ou confirmado, as organizações devem agir de forma decisiva para conter a ameaça, limitar os danos e prevenir recorrências.

Colocar em quarentena os sistemas afetados

Isole hosts comprometidos para evitar que atacantes realizem movimentos laterais adicionais ou continuem a usar indevidamente credenciais gMSA comprometidas. Você também deve isolar controladores de domínio se for detectado acesso suspeito a msKds-RootKeyData ou outros atributos críticos, garantindo que os atacantes não possam persistir nos serviços de diretório.

Desativar gMSAs comprometidos

Desative imediatamente as gMSAs comprometidas para impedir que adversários as utilizem para autenticação e atividades maliciosas.

Roteie todas as credenciais relevantes e atualize os serviços afetados

Roteie todas as credenciais relevantes, incluindo gMSAs, contas de serviço e contas administrativas. Em seguida, atualize os serviços afetados para garantir uma reautenticação suave com os gMSAs recém-rotacionados.

Preserve artefatos forenses e inicie a investigação forense

Uma investigação forense ajuda a determinar o escopo e a causa raiz do incidente. Certifique-se de capturar dados do domain controller e do Configuration NC, como logs e snapshots do NTDS, antes de fazer alterações irreversíveis de remediação. É importante equilibrar a urgência de parar o ataque com a necessidade de reter evidências para análise. Próximo:

• Revise os logs de eventos, alertas SACL e anomalias relacionadas à identidade.
• Capture dados voláteis (como dumps de memória e logs de autenticação) dos sistemas afetados para análise pós-incidente.
• Fique atento a mecanismos de persistência, como tarefas agendadas, ACLs modificadas ou contas de administrador sombra que possam ter sido introduzidas durante o comprometimento.

Estas etapas podem ajudar a identificar mecanismos de ataque e fechar lacunas de segurança.

Impacto específico do setor

O impacto dos ataques gMSA não é o mesmo para todas as indústrias. Ao entender as consequências específicas de cada setor, as organizações podem priorizar as defesas com base em seus ativos mais valiosos.

Evolução dos ataques e tendências futuras

À medida que as organizações adotam gMSAs para aumentar a segurança e simplificar o gerenciamento de senhas, os atacantes estão aprimorando suas técnicas para explorar essas contas. As seguintes tendências destacam como os adversários estão explorando as vulnerabilidades do gMSA e para onde o cenário de ameaças está se direcionando.

Estatísticas principais e infográficos

gMSAs são projetados com recursos de segurança robustos, mas atacantes que miram a chave raiz KDS podem contornar essas proteções. Vamos dar uma olhada em alguns fatos e estatísticas que apoiam isso:

• gMSAs alteram suas senhas a cada 30 dias para limitar a exposição das credenciais. Mas se os invasores roubarem a chave raiz KDS, eles podem calcular as senhas gMSA offline a qualquer momento, anulando efetivamente a proteção da rotação.
• Como cada gMSA em um domínio depende da mesma chave raiz KDS para a geração de senhas, comprometer essa única chave raiz pode afetar todos os gMSAs no domínio. Isso cria um risco em todo o domínio a partir de um único ponto de falha.

O gráfico de barras a seguir compara a janela de segurança prevista (rotação de 30 dias) com a janela real de acesso do invasor (indefinida se o KDS for comprometido).

Considerações finais

No final, os gMSAs são uma espada de dois gumes, eles simplificam a autenticação de serviços e fortalecem a segurança quando gerenciados corretamente, mas nas mãos erradas, podem se tornar as chaves do reino. Quando invasores forjam um Golden gMSA, eles não apenas roubam uma senha; eles herdam a chave mestra da sua infraestrutura, com o poder de se mover silenciosamente entre sistemas e serviços. O perigo está na invisibilidade deles: permanecendo despercebidos até que toda a empresa esteja em risco. Proteger suas chaves raiz KDS, monitorar atividades suspeitas de gMSA e implementar uma forte segurança no controlador de domínio são salvaguardas essenciais para o seu ambiente Active Directory.