Segredos cPassword do GPO SYSVOL no Active Directory: Por Que um Patch de 2014 Não Resolveu o Problema

Segredos cPassword do GPO SYSVOL no Active Directory: O Que São

Falhas de configuração envolvendo segredos cPassword do GPO SYSVOL no Active Directory estão entre as mais antigas que se recusam a desaparecer — e são uma das configurações incorretas de segurança do Active Directory mais comuns ainda encontradas em auditorias de produção hoje. Elas vêm das Group Policy Preferences (GPP), um recurso que a Microsoft adicionou no Windows Server 2008 e que permitia aos administradores distribuir contas de usuário local, unidades mapeadas, tarefas agendadas, serviços e fontes de dados via Group Policy — incluindo, para vários desses tipos de preferência, um nome de usuário e senha a aplicar nas máquinas de destino.

Essas credenciais eram armazenadas no atributo cpassword do arquivo XML da preferência (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), criptografadas em AES-256, e gravadas no compartilhamento SYSVOL do domínio — o mesmo compartilhamento que todo controlador de domínio replica e que qualquer usuário autenticado (e, por padrão, usuários de qualquer domínio confiável) pode ler para que as máquinas cliente obtenham seus Group Policy Objects (GPOs).

O problema: a Microsoft publicou a chave AES privada usada para criptografar cada valor cpassword em sua própria documentação de protocolo, porque a GPP precisava de uma forma de descriptografar o valor no lado do cliente durante o processamento da política. Qualquer usuário de domínio autenticado que consiga ler o SYSVOL — ou seja, todos eles, por design — pode encontrar a string criptografada e descriptografá-la em segundos com ferramentas disponíveis publicamente. A exposição foi documentada publicamente pela primeira vez em 2012 pelo pesquisador de segurança Chris Campbell (obscuresec), que lançou uma prova de conceito em PowerShell para localizar e descriptografar esses valores bem antes de a Microsoft lançar uma correção.

Por Que Isso Continua Reaparecendo Uma Década Depois

Se a MS14-025 foi lançada em 2014, por que as auditorias ainda encontram entradas cpassword ativas hoje? Alguns padrões recorrentes explicam isso:

• Migrações e aquisições de domínio. GPOs são frequentemente migradas por completo de um domínio legado, incluindo quaisquer preferências configuradas antes de o ambiente adquirido ter sido corrigido ou revisado.
• Backups de GPO restaurados. Backups de GPO feitos antes de 2014 e restaurados anos depois reintroduzem exatamente o XML que o patch pretendia evitar dali em diante — o patch protege o editor, não uma operação de restauração.
• Ambientes gerenciados por MSPs e fornecedores. Provedores de serviços gerenciados que reutilizam um modelo padrão de GPO em vários clientes podem propagar a mesma credencial de administrador local exposta para todo ambiente que esse modelo atinge.
• Ausência de revisão periódica do SYSVOL. Ao contrário de um serviço ativo, o conteúdo do SYSVOL não expira nem é sinalizado por patches de rotina — nada força uma nova varredura a menos que alguém a execute deliberadamente.

Nenhum desses caminhos exige que um sistema mal configurado tenha deixado de aplicar o patch de 2014. Eles só exigem que um valor cpassword tenha existido no SYSVOL em algum ponto da história do domínio e nunca tenha sido ativamente procurado e removido — e é exatamente por isso que a varredura proativa, não a conformidade com patches, é o controle que realmente fecha essa lacuna.

Como Funciona

A Microsoft resolveu parte disso com a MS14-025 (CVE-2014-1812), publicada em 13 de maio de 2014 e distribuída como a atualização KB2962486. O patch removeu os campos "Password" do editor de Group Policy Preferences no Group Policy Management Console (GPMC) e nas Remote Server Administration Tools (RSAT), de modo que os administradores não podem mais criar novas entradas de GPP contendo uma senha (Microsoft Support: MS14-025).

O que a KB2962486 não faz é remover retroativamente valores cpassword que já haviam sido gravados no SYSVOL antes da instalação do patch, e ela não impede um atacante de descriptografar o que ainda está lá. O guia da ANSSI sobre administração segura de AD aponta exatamente essa lacuna: o patch muda o que o editor permite que um administrador digite dali em diante, mas objetos GPP históricos criados antes da instalação do patch precisam ser localizados e limpos manualmente (ANSSI-PA-099).

A própria chave AES não é um segredo que um atacante precise roubar — é a mesma chave estática de 32 bytes para todo domínio Active Directory do planeta, documentada pela Microsoft e replicada em pesquisas de segurança desde a divulgação original de 2012, posteriormente incorporada diretamente em ferramentas ofensivas como PowerSploit e CrackMapExec (adsecurity.org: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

A Cadeia de Ataque

Explorar um cpassword remanescente não requer acesso elevado nem exploit — é uma técnica pós-autenticação disponível para qualquer usuário de domínio, e frequentemente também para qualquer usuário em uma floresta confiável.

Passo 1 — Enumerar o SYSVOL em busca de cpassword

Um atacante com qualquer credencial de domínio válida (ou um ponto de apoio de baixo privilégio) busca no compartilhamento SYSVOL arquivos XML contendo o atributo cpassword:

# Linux, com credenciais de domínio válidas
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Passo 2 — Descriptografar com a chave AES publicada

Get-GPPPassword e ferramentas equivalentes (Get-DecryptedCpassword, gpp-decrypt) aplicam a chave AES publicamente conhecida ao valor cpassword decodificado em Base64 e retornam o texto claro instantaneamente — não há força bruta nem etapa de cracking, apenas uma rotina fixa de descriptografia.

Passo 3 — Reutilizar a credencial

Como a GPP era frequentemente usada para padronizar uma conta de administrador local em muitas máquinas, ou para executar uma tarefa agendada ou serviço sob uma conta de serviço de domínio, a senha recuperada costuma ser diretamente reutilizável para movimento lateral ou escalada de privilégios, sem exigir nenhuma técnica adicional. Uma única entrada em Groups.xml que definiu uma senha de administrador local comum em todo o domínio já é suficiente para comprometer cada estação de trabalho atingida por essa GPO.

Detecção

Para confirmar a exposição diretamente, em vez de esperar por sinais de log, o guia da ANSSI sobre administração segura de AD (ANSSI-PA-099) fornece uma verificação proativa de uma linha que os auditores podem executar a partir de um sistema associado ao domínio:

:: Substitua <FQDN> pelo nome de domínio totalmente qualificado (FQDN) do AD.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Qualquer ocorrência significa que um valor cpassword — com ferramentas corrigidas ou não — ainda está presente no SYSVOL hoje (ANSSI-PA-099, Recomendação R31, Listagem 3). Como essa verificação lê conteúdo estático de arquivo em vez de telemetria ao vivo, é a forma mais rápida de um auditor obter uma resposta definitiva sem depender da retenção de logs. O mesmo princípio se aplica a outros vazamentos de credenciais obsoletas que vale a pena verificar na mesma passagem, como senhas deixadas em campos de descrição do AD. Para um panorama mais amplo sobre o que priorizar em uma revisão completa, veja nosso guia sobre como auditar a segurança do Active Directory.

Remediação

1. Confirme que a KB2962486 está implantada em todo sistema ainda usado para editar Group Policy pelo console nativo GPMC/MMC (anterior ao Windows Server 2016) ou por ferramentas RSAT mais antigas (anteriores ao Windows 10). Isso impede que novas senhas sejam inseridas em GPP a partir de agora.
2. Execute a varredura do SYSVOL (comando findstr acima, ou uma busca recursiva equivalente) e enumere todo arquivo Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml e DataSources.xml em cada GPO em busca do atributo cpassword — incluindo GPOs desabilitadas e não vinculadas, que revisões manuais frequentemente ignoram.
3. Rotacione toda credencial encontrada, imediatamente. Excluir a entrada XML não invalida uma senha que já era descriptografável; presuma que ela foi lida e aja de acordo.
4. Remova a configuração GPP em vez de deixar um campo de senha vazio — conforme a recomendação R32 da ANSSI, nenhuma senha deve voltar a ser registrada em uma Group Policy Preference (ANSSI-PA-099, Recomendação R32, p.49). Nosso guia prático sobre as recomendações de AD da ANSSI mostra como transformar recomendações como essa em um plano de implantação.
5. Substitua as contas de administrador local geridas por GPP pelo Windows LAPS, que rotaciona uma senha única e aleatória por máquina e a armazena como um atributo protegido do AD em vez de um arquivo XML estático.
6. Estenda o mesmo escrutínio aos scripts de logon/logoff armazenados no SYSVOL ou NETLOGON — a recomendação R31 da ANSSI aplica o mesmo princípio de segredo reutilizável a qualquer script legível por contas de privilégio mais baixo, não apenas ao XML de GPP. Um script que mapeia uma unidade com uma senha de conta de serviço embutida está tão exposto quanto um campo cpassword.
7. Reforce o acesso de leitura onde for viável. SYSVOL e NETLOGON precisam permanecer legíveis para o processamento de políticas, mas revise possíveis desvios de permissão em SYSVOL/NETLOGON além do padrão, e habilite o UNC hardening para esses compartilhamentos, para que os clientes validem integridade e autenticação mútua ao lê-los.
8. Repita a varredura após cada restauração de backup de GPO ou migração de domínio, não apenas uma vez. Como essas são as duas formas mais comuns de entradas antigas de cpassword ressurgirem, trate a nova varredura do SYSVOL como uma etapa permanente em qualquer runbook de migração, e não como uma limpeza pontual, atribuindo um responsável para que isso não dependa de alguém se lembrar.

Como a EtcSec Detecta Isso

O audit de Active Directory da EtcSec sinaliza essa exposição como GPO_PASSWORD_IN_SYSVOL, uma verificação de severidade crítica que varre o XML de preferências de cada GPO em busca de um atributo cpassword preenchido — incluindo GPOs desabilitadas ou não vinculadas, que revisões manuais frequentemente deixam passar. Ela é combinada com SYSVOL_NETLOGON_PERMISSIONS, que revisa o acesso de leitura/escrita nos compartilhamentos SYSVOL e NETLOGON em busca de desvios além da baseline esperada. Juntas, as duas verificações cobrem tanto a exposição histórica de GPP quanto a higiene contínua de permissões necessária para impedir que o SYSVOL volte a se tornar um depósito de segredos reutilizáveis.