Ma Configuracoes de GPO: Quando a Group Policy Se Torna um Vetor de Ataque

O Que São Configurações Incorretas de GPO?

Group Policy Objects (GPOs) são o principal mecanismo de gestão de configuração no Active Directory. Elas controlam definições de segurança, implantação de software, execução de scripts e ambientes de usuário em todas as máquinas do domínio. Quando as permissões de uma GPO estão mal configuradas, isso cria um dos vetores de ataque mais poderosos no Active Directory - uma única GPO mal configurada vinculada aos Domain Controllers pode comprometer todo o domínio.

As configurações incorretas de GPO são particularmente perigosas porque combinam duas ameaças: movimento lateral em larga escala (uma GPO comprometida pode enviar scripts maliciosos para centenas de máquinas simultaneamente) e escalonamento de privilégios (permissões fracas de GPO permitem que usuários com poucos privilégios modifiquem políticas aplicadas aos próprios Domain Controllers).

O outro problema crítico de GPO é a ausência do LAPS. Sem a Local Administrator Password Solution, todas as estações de trabalho do domínio compartilham a mesma senha de Administrator local. Descubra-a uma vez em qualquer máquina - por meio de um dump ou de um hash - e você terá acesso de administrador local em todas as estações de trabalho do domínio.

Como Funciona

As GPOs são armazenadas como objetos no Active Directory e como arquivos no compartilhamento SYSVOL dos Domain Controllers. Cada GPO tem dois componentes:

• GPC (Group Policy Container) - o objeto do AD, controlado por ACLs do AD
• GPT (Group Policy Template) - arquivos em \\domain\SYSVOL\, controlados por ACLs NTFS

Ambos precisam estar protegidos. Um atacante com acesso de escrita a qualquer um dos componentes pode injetar conteúdo malicioso que é executado em todas as máquinas às quais a GPO se aplica.

Ordem de Processamento das Group Policy

As GPOs são aplicadas nesta ordem (em caso de conflito, prevalece a última gravação):

1. Política local
2. GPOs de nível de site
3. GPOs de nível de domínio
4. GPOs de nível de OU (da unidade pai para a filha)

Isso significa que uma GPO vinculada no nível de uma OU que contém Domain Controllers é aplicada a todos os DCs dessa OU - tornando-a um alvo de valor excepcionalmente alto para atacantes.

A Cadeia de Ataque

Etapa 1 - Enumerar Permissões de GPO

# Encontra todas as GPOs em que contas não privilegiadas têm direitos de edição
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $acl = Get-GPPermission -Guid $gpo.Id -All
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo.SOMPath -join ", "
  $acl | Where-Object {
    $_.Permission -match "GpoEditDeleteModifySecurity|GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM|Creator Owner"
  } | Select-Object `
    @{N="GPO";E={$gpo.DisplayName}},
    @{N="Trustee";E={$_.Trustee.Name}},
    @{N="Permission";E={$_.Permission}},
    @{N="LinkedTo";E={$links}}
}

Etapa 2 - Identificar Vínculos Perigosos

# Encontra GPOs vinculadas a OUs de alto valor (Domain Controllers, Tier 0)
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo | Where-Object { 
    $_.SOMPath -match "Domain Controllers|Tier0|Admin" 
  }
  if ($links) {
    Write-Host "HIGH VALUE GPO: $($gpo.DisplayName) - Linked to: $($links.SOMPath -join ', ')"
    Get-GPPermission -Guid $gpo.Id -All | Where-Object {
      $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
    }
  }
}

Etapa 3 - Explorar Permissões Fracas (Se Encontradas)

Se uma conta com poucos privilégios tiver direitos GpoEdit em uma GPO vinculada aos Domain Controllers, o atacante pode adicionar um script de inicialização malicioso que é executado como SYSTEM em todos os DCs visados:

# O atacante modifica a GPO para adicionar uma tarefa agendada maliciosa
# Isso é executado como SYSTEM em todas as máquinas no escopo na próxima atualização de Group Policy
# Por padrão, os Domain Controllers atualizam a política a cada 5 minutos (não no intervalo
# de 90 minutos das estações de trabalho/servidores) - uma GPO maliciosa vinculada a uma OU de DC se propaga rapidamente
# Pode ser forçado imediatamente: gpupdate /force

Etapa 4 - Explorar a Ausência do LAPS para Movimento Lateral

Sem o LAPS, a conta de Administrator local em todas as estações de trabalho compartilha a mesma senha. Um único dump de hash leva a um movimento lateral em todo o domínio:

# Obtém o hash do administrador local a partir de qualquer máquina
# Usa pass-the-hash para se autenticar em todas as estações de trabalho (NetExec, o sucessor
# mantido do agora arquivado CrackMapExec)
netexec smb 10.10.0.0/24 -u Administrator -H "aabbccdd11223344:aabbccdd11223344"
# Todas as máquinas com a mesma senha de administrador local mostrarão [+]

Detecção

Event IDs do Windows

Consultas de Detecção para SIEM (Elastic KQL)

GPO modificada por conta não administrativa:

event.code: "5136" AND
winlog.event_data.ObjectClass: "groupPolicyContainer" AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM" OR "*$")

Modificação de arquivo no SYSVOL:

event.code: "4663" AND
file.path: (*\\SYSVOL\\*) AND
event.action: "File Write" AND
NOT winlog.event_data.SubjectUserName: ("SYSTEM" OR "*$")

Remediation

1. Corrigir Permissões Perigosas de GPO

# Remove permissões perigosas de uma GPO específica
Set-GPPermission -Name "Default Domain Controllers Policy" `
  -TargetName "Domain Users" -TargetType Group `
  -PermissionLevel None

# Audita e corrige todas as GPOs
Get-GPO -All | ForEach-Object {
  $gpo = $_
  Get-GPPermission -Guid $gpo.Id -All | Where-Object {
    $_.Permission -match "GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
  } | ForEach-Object {
    Set-GPPermission -Guid $gpo.Id -TargetName $_.Trustee.Name `
      -TargetType Group -PermissionLevel GpoRead
    Write-Host "Fixed: $($gpo.DisplayName) - Downgraded $($_.Trustee.Name) to Read"
  }
}

2. Implantar o LAPS

# O Windows LAPS já vem integrado no Windows Server 2019/2022 (atualização de abril de 2023 ou posterior)
# e nativamente no Windows Server 2025 / Windows 11 22H2+ - não é necessária instalação
# via PowerShell Gallery. Confirme se o módulo está presente:
Get-Command -Module LAPS

# Estende o schema do AD para o LAPS (requer Schema Admin)
Update-LapsADSchema

# Concede permissões para que os DCs gravem os atributos do LAPS
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# Configure via GPO:
# Computer Configuration > Administrative Templates > LAPS
# - Enable local admin password management: Enabled
# - Password complexity: Large letters + small letters + numbers + special characters
# - Password length: 20 characters minimum
# - Password age: 30 days maximum

3. Aplicar Padrões de Política de Senha nas GPOs

# Audita todas as GPOs que implantam políticas de senha
Get-GPO -All | ForEach-Object {
  $report = Get-GPOReport -Guid $_.Id -ReportType XML
  if ($report -match "MinimumPasswordLength") {
    # Extrai e verifica o valor
    $minLen = [regex]::Match($report, 
      '<MinimumPasswordLength[^>]*>(\d+)<').Groups[1].Value
    if ([int]$minLen -lt 14) {
      Write-Warning "Weak password policy in GPO: $($_.DisplayName) - MinLength: $minLen"
    }
  }
}

4. Proteger o SYSVOL

# Verifica se as ACLs do SYSVOL estão corretas
# Apenas Domain Admins e SYSTEM devem ter acesso de escrita
icacls "\\corp.local\SYSVOL\corp.local\Policies" /verify

# Habilite a auditoria de alterações no SYSVOL via GPO:
# Computer Configuration > Windows Settings > Security Settings > 
#   Advanced Audit Policy > Object Access > Audit File System: Success, Failure

Como a EtcSec Detecta Isso

A EtcSec audita todas as GPOs do seu domínio em busca de permissões perigosas, políticas fracas e controles ausentes.

GPO_DANGEROUS_PERMISSIONS identifica GPOs em que contas não privilegiadas têm permissões de edição ou modificação - particularmente GPOs vinculadas a OUs de Domain Controllers, onde a exploração leva diretamente ao comprometimento total do domínio.

GPO_WEAK_PASSWORD_POLICY sinaliza qualquer GPO que implante uma política de senha abaixo dos padrões de segurança atuais - tamanho mínimo, requisitos de complexidade, idade máxima e histórico de senhas.

GPO_LAPS_NOT_DEPLOYED detecta ambientes em que o LAPS não está configurado via GPO, deixando as senhas de Administrator local sem gestão e idênticas em todas as estações de trabalho - permitindo movimento lateral em todo o domínio a partir do comprometimento de uma única máquina.

Perguntas Frequentes

Por que as configurações incorretas de GPO são tão perigosas? Uma GPO mal configurada é perigosa por causa da escala. Uma única GPO vinculada aos Domain Controllers pode executar código como SYSTEM em todos os DCs da organização simultaneamente. Ao contrário do comprometimento de contas individuais, uma GPO maliciosa afeta todas as máquinas no escopo no próximo ciclo de atualização de Group Policy - potencialmente centenas de máquinas em até 90 minutos.

O que é o LAPS e por que devo implantá-lo? A Local Administrator Password Solution (LAPS) gerencia automaticamente a senha da conta Administrator local em cada computador ingressado no domínio, definindo uma senha aleatória exclusiva que é rotacionada periodicamente. Sem o LAPS, todas as estações de trabalho normalmente compartilham a mesma senha de Administrator local, permitindo que um atacante que descubra o hash de uma máquina se autentique em todas as outras estações de trabalho - uma técnica chamada pass-the-hash.

Qual é a configuração mínima de GPO que preciso revisar? Priorize primeiro as GPOs vinculadas aos Domain Controllers e às OUs Tier 0 - esses são os alvos de maior impacto. Em seguida, audite a Default Domain Policy e a Default Domain Controllers Policy em busca de alterações não autorizadas de permissão. Somente essas duas GPOs já cobrem a superfície de risco mais crítica.

Prioridades de Revisão

O tópico Configurações Incorretas de GPO: Como a Group Policy se Torna um Vetor de Ataque deve ser tratado como uma exposição real dentro do seu ambiente de Active Directory, e não como uma configuração isolada única. Comece definindo o perímetro da revisão: quais grupos privilegiados, contas de serviço, ACLs, vínculos de GPO, trusts, configurações de delegação, modelos de certificado e estações de trabalho administrativas são afetados, quais fluxos de trabalho de negócio dependem deles, quais privilégios eles expõem e quais exceções de emergência foram adicionadas ao longo do tempo. Essa etapa de delimitação evita uma remediação superficial, porque o sintoma técnico costuma ser menor do que o raio de impacto operacional. Ao documentar todo o caminho da configuração até o privilégio, a equipe pode priorizar as mudanças que reduzem o risco rapidamente sem quebrar o acesso em produção. Isso também cria uma linha de base defensável para validações posteriores e oferece à liderança uma explicação clara do motivo pelo qual o problema importa agora.

Controles Adjacentes a Revisar

Quando atacantes alcançam o seu ambiente de Active Directory, raramente param no primeiro ponto fraco. Em torno do tópico Configurações Incorretas de GPO: Como a Group Policy se Torna um Vetor de Ataque, eles normalmente testam se o caminho exposto pode ser encadeado com contas privilegiadas obsoletas, aninhamento inseguro de grupos, delegação excessiva, configurações fracas de senha, caminhos de GPO graváveis e abuso de ACLs herdadas. Isso significa que os defensores devem revisar não apenas a fraqueza principal, mas também toda dependência próxima que transforma acesso em persistência ou escalonamento de privilégios. Confirme quais identidades, funções, permissões e pressupostos de confiança podem ser reaproveitados por um operador motivado. Se uma correção fecha apenas um objeto e deixa intactos os caminhos de privilégio adjacentes, o risco efetivo praticamente não muda. Uma revisão disciplinada das oportunidades de encadeamento é o que transforma este tópico em um exercício prático de hardening, em vez de uma verificação pontual.

Configurações Incorretas de GPO: Validação Antes da Aprovação Final

Uma revisão sólida de Configurações Incorretas de GPO deve terminar com evidência de produção, não com a suposição de que o caminho de risco desapareceu. Antes de encerrar o achado, reverifique as identidades privilegiadas, os direitos delegados e o acesso herdado, a política, a ACL, o grupo ou o escopo de GPO que realmente mudou, e a evidência de logging ou de coleta associada ao achado. Confirme que o estado mais seguro se aplica ao escopo que realmente importa: a OU de produção, a atribuição de função efetiva, o caminho da aplicação, ou o caminho de trust e delegação que um atacante realmente exploraria. Registre o responsável técnico, a dependência de negócio e a condição de rollback para que a próxima revisão possa verificar se o estado mais seguro foi mantido.

Use uma checklist curta de aprovação final:

• verifique se o estado de risco desapareceu do ponto de vista do atacante, não apenas em uma captura de tela do administrador
• mantenha uma exportação ou amostra de log de antes/depois que comprove que o escopo afetado mudou
• documente o responsável e a decisão de exceção caso o controle não pudesse ser totalmente aplicado

Para exposições adjacentes, faça uma verificação cruzada do resultado com Aninhamento Perigoso de Grupos: Caminhos Ocultos para Domain Admin, Caminhos de Ataque do Active Directory para Domain Admin, Monitoramento do Active Directory: Event IDs de Segurança que Importam, e Conformidade AD e Azure: NIS2, ISO 27001, CIS Controls. A mesma lacuna de controle costuma reaparecer em caminhos de identidade próximos, lacunas de logging ou permissões delegadas, motivo pelo qual a etapa final de validação é tão importante quanto o achado inicial.

Configurações Incorretas de GPO: Evidências a Manter para o Próximo Ciclo de Revisão

O próximo revisor não deveria precisar reconstruir o caso de memória. Mantenha a evidência que originalmente justificou o achado, a prova de que a mudança foi aplicada e a nota que explica por que o estado final é aceitável. Para este tópico, a evidência mais útil geralmente combina a exportação atual das identidades, grupos ou caminhos delegados afetados, a prova de configuração de antes e depois do controle que você alterou, e o ticket, o responsável e a nota de exceção que explicam o estado final. Esse pacote compacto torna as revisões trimestrais ou pós-mudança muito mais rápidas e ajuda a explicar se o problema foi removido, reduzido ou formalmente aceito.

Se uma mudança posterior de administração, política ou aplicação reabrir o caminho, essa evidência histórica também facilita provar o que sofreu desvio. É isso que transforma Configurações Incorretas de GPO de uma verificação pontual em um processo repetível de garantia.

Leitura Relacionada

Revise este tópico junto com Monitoramento do Active Directory: Event IDs de Segurança que Importam, Segurança de Senhas no Active Directory: Configurações Incorretas que os Atacantes Adoram, Aninhamento Perigoso de Grupos: Caminhos Ocultos para Domain Admin, Ataques NTLM Relay: Sequestrando a Autenticação no AD, e Caminhos de Ataque do Active Directory para Domain Admin. Esses artigos adjacentes mostram como as mesmas fraquezas de identidade costumam se encadear em uma avaliação real, em vez de aparecerem como achados isolados.

• Monitoramento do Active Directory: Event IDs de Segurança que Importam
• Segurança de Senhas no Active Directory: Configurações Incorretas que os Atacantes Adoram
• Aninhamento Perigoso de Grupos: Caminhos Ocultos para Domain Admin
• Ataques NTLM Relay: Sequestrando a Autenticação no AD
• Caminhos de Ataque do Active Directory para Domain Admin

Usar essas referências mantém a discussão de remediação focada em todo o caminho de ataque, em vez de em uma única lacuna de controle.

Validar Escopo, Herança e Exceções

A limpeza de GPOs deve ser testada em relação à estrutura real de OUs e aos fluxos de trabalho administrativos existentes em produção. As equipes devem confirmar quais políticas vinculadas ainda se aplicam a sistemas de alto valor, se bloqueios de herança ou direitos de edição delegados introduzem novas oportunidades de bypass, e se políticas de emergência ou legadas continuam justificadas. Essa revisão mantém o hardening da Group Policy ancorado em como o controle de privilégio e de estações de trabalho realmente funciona no ambiente.

Revisar a Responsabilidade Administrativa das GPOs

A pergunta final é quem ainda pode alterar a política depois da limpeza. Se muitos administradores, equipes delegadas ou scripts legados podem editar GPOs de alto impacto, o mesmo risco rapidamente retorna por meio da administração de rotina. Revisar a responsabilidade, os caminhos de aprovação e o monitoramento de mudanças sensíveis em GPOs mantém o esforço de hardening duradouro, em vez de temporário.

O Que Observar Depois da Limpeza

Depois de um projeto de remediação de GPO, preste muita atenção a novos editores delegados, mudanças de política de emergência e vínculos aplicados a OUs de alto valor. Esses são os pontos em que as fraquezas antigas tendem a reaparecer. Uma revisão leve das edições recentes de GPO, das mudanças de responsabilidade e das políticas recém-vinculadas ajuda a confirmar que o ambiente permanece protegido depois que o esforço inicial de limpeza termina.

Sustentando a Governança de GPO ao Longo do Tempo

O controle de longo prazo é a consistência. Se as equipes continuarem acompanhando quem pode editar políticas críticas, quais mudanças de emergência ignoram a revisão padrão e com que rapidez os vínculos de alto risco são investigados, a Group Policy permanece um controle defensivo em vez de se tornar uma superfície de ataque recorrente. Esse ritmo operacional costuma ser o que diferencia uma limpeza pontual de um hardening duradouro.

O hardening de GPO também depende da rapidez com que mudanças incomuns de política são revisadas após manutenções em horário comercial, patches de emergência e implantações de novas estações de trabalho. Manter esse ciclo de revisão ativo ajuda as equipes a detectar quando edições de conveniência reintroduzem configurações perigosas muito depois de o projeto original de remediação ter sido encerrado. Na prática, a segurança duradoura de GPO depende menos de uma linha de base perfeita única e mais de manter visibilidade sobre toda mudança futura que possa afetar sistemas privilegiados.