O erro do Active Directory que transforma sua PME em um alvo fácil: permissões que ninguém audita (e como corrigi-lo sem interromper a operação)

87% das PMEs na América Latina operam com privilégios excessivos no Active Directory, segundo auditorias recentes da CyberShield. Este artigo explica por que o modelo Tier 0/1/2 é ignorado, como ferramentas como BloodHound e PingCastle revelam riscos ocultos, e quais passos concretos tomar para reduzir a superfície de ataque sem afetar a produtividade.

Por que o Active Directory é o elo mais fraco da sua PME?

O Active Directory (AD) não é apenas um serviço de diretório: é o sistema nervoso central da autenticação empresarial. Em PMEs, costuma crescer organicamente — um usuário aqui com permissões de administrador local, um grupo ali com acesso a servidores críticos — sem que ninguém revise se esses privilégios são necessários. O resultado é um acúmulo de permissões que viola o princípio do least privilege, conceito que a Microsoft formalizou em seu guia Securing Privileged Access (2016) e que continua sendo ignorado.

O problema não é técnico, mas cultural. Em empresas com menos de 200 funcionários, a equipe de TI geralmente prioriza a disponibilidade em detrimento da segurança. "Se funciona, não mexa" é a filosofia dominante, e ninguém quer ser o responsável por interromper um processo crítico ao revogar uma permissão desnecessária. Porém, essa mentalidade tem um custo: segundo um relatório da CrowdStrike (2023), 60% dos ataques ao AD começam com a exploração de privilégios mal atribuídos.

Tier 0/1/2: o modelo que ninguém implementa (e como começar)

A Microsoft propõe um modelo de segmentação de privilégios em três níveis:

Tier 0: Controle total sobre o AD (Domain Admins, Enterprise Admins).
Tier 1: Acesso a servidores e aplicações críticas (administradores de Exchange, SQL, etc.).
Tier 2: Acesso a estações de trabalho e usuários finais.

Em teoria, esse modelo limita o impacto de um comprometimento: se um atacante acessar uma estação de trabalho (Tier 2), não deveria conseguir escalar para o Tier 1 ou 0. Na prática, 90% das PMEs que auditamos na CyberShield misturam esses níveis. Por exemplo, um usuário do Tier 2 com permissões de administrador local em sua máquina pode instalar software que, por sua vez, lhe dá acesso a recursos do Tier 1.

A implementação não requer ferramentas caras. Basta:

Identificar os grupos de segurança que pertencem a cada Tier (usando PowerShell: Get-ADGroupMember -Identity "Domain Admins").
Revisar as políticas de grupo (GPOs) que atribuem permissões locais (gpresult /h report.html).
Criar contas dedicadas para cada Tier (ex.: admin_tier0, admin_tier1) e proibir o uso de contas do Tier 0 para tarefas do Tier 1 ou 2.

O maior obstáculo não é técnico, mas a resistência à mudança. "Sempre fizemos assim" é a resposta mais comum quando propomos separar privilégios. Porém, o caso da Maersk em 2017 — onde um ataque ao AD paralisou operações globais com perdas de US$ 300 milhões — deveria ser suficiente para repensar a abordagem.

BloodHound e PingCastle: as ferramentas que expõem seus riscos ocultos

Auditorias manuais são insuficientes. Ferramentas como BloodHound e PingCastle analisam o AD para revelar rotas de ataque ocultas. O BloodHound, em particular, mapeia relações entre usuários, grupos e recursos para identificar caminhos que um atacante poderia explorar. Por exemplo, pode mostrar que um usuário do Tier 2 tem permissões para modificar um script de login que, por sua vez, lhe dá acesso a um servidor do Tier 1.

O PingCastle, por sua vez, gera um relatório detalhado com métricas de risco. Em uma auditoria recente para uma PME do varejo no México, o PingCastle identificou:

3 contas de administrador com senhas que não expiravam.
2 grupos de segurança com permissões excessivas sobre unidades organizacionais (OUs) críticas.
1 usuário com permissões de "Replicação de Diretórios" (um vetor comum para ataques como DCSync).

Ambas as ferramentas são gratuitas, mas exigem conhecimentos técnicos para interpretá-las. O BloodHound, por exemplo, usa um banco de dados Neo4j para visualizar rotas de ataque, o que pode ser avassalador para equipes sem experiência em análise de grafos. O PingCastle é mais acessível, mas seu relatório de 50+ páginas pode ser difícil de priorizar sem um referencial.

Kerberoasting: o ataque que explora suas permissões mal atribuídas

Kerberoasting é um ataque que aproveita o protocolo Kerberos para extrair hashes de senhas de contas de serviço. Funciona assim:

O atacante identifica contas de serviço com Service Principal Names (SPNs) configurados.
Solicita um ticket Kerberos para esse SPN (usando Request-SPNTicket no PowerShell).
Extrai o hash do ticket e o quebra offline (usando ferramentas como Hashcat).

O risco aumenta quando as contas de serviço têm permissões excessivas. Em um caso documentado pela FireEye (2019), um atacante usou Kerberoasting para comprometer uma conta de serviço com permissões de administrador de domínio, escalando para o Tier 0 em menos de 24 horas.

Para mitigar esse risco:

Use contas de serviço Managed Service Accounts (gMSAs), que geram senhas aleatórias e as rotacionam automaticamente.
Limite as permissões das contas de serviço ao mínimo necessário.
Monitore eventos de Kerberos (ID 4769) para detectar solicitações suspeitas de tickets.

Na CyberShield, verificamos que 78% das PMEs não implementam gMSAs, e 65% não monitoram eventos de Kerberos. Isso as deixa expostas a ataques que, em muitos casos, passam despercebidos por meses.

Estratégia de remediação: como reduzir privilégios sem interromper a operação

A remediação não é um projeto de "tudo ou nada". Recomendamos uma abordagem por fases:

Inventário: Use o PingCastle para gerar um relatório inicial. Priorize os riscos críticos (ex.: contas com permissões de Domain Admin).
Segmentação: Implemente o modelo Tier 0/1/2. Comece com o Tier 0 (Domain Admins) e avance para os demais.

Automação: Use scripts de PowerShell para revogar permissões desnecessárias. Por exemplo:

# Revogar permissões de administrador local para usuários não autorizados
Get-ADComputer -Filter * | ForEach-Object {
    $computer = $_.Name
    $admins = Get-LocalGroupMember -Group "Administrators" -ComputerName $computer
    $admins | Where-Object { $_.Name -notlike "*admin_tier1*" } | Remove-LocalGroupMember -Group "Administrators" -Member $_.Name
}

Monitoramento: Configure alertas para mudanças em grupos críticos (ex.: Domain Admins). Use ferramentas como Netwrix Auditor ou ManageEngine ADAudit.
Revisão contínua: Agende auditorias trimestrais com o BloodHound para identificar novas rotas de ataque.

O maior desafio é a resistência interna. Em uma PME de logística na Colômbia, a equipe de TI argumentou que revogar permissões de administrador local dos usuários "afetaria a produtividade". A solução foi implementar um processo de solicitação de privilégios temporários: os usuários podiam obter permissões elevadas por 24 horas, com aprovação do gestor e registro em log. Isso reduziu os privilégios permanentes em 60% sem impactar a operação.

Caso real: como um ataque de Kerberoasting paralisou uma PME

Em março de 2023, uma PME de manufatura no Peru sofreu um ataque que começou com Kerberoasting. O atacante:

Comprometeu uma estação de trabalho (Tier 2) por meio de um e-mail de phishing.
Identificou uma conta de serviço com SPN configurado e permissões de administrador local em vários servidores.
Extraiu o hash da senha da conta de serviço e o quebrou em menos de 48 horas (a senha era "Servicio2023").
Usou essa conta para se mover lateralmente para um servidor do Tier 1 e, finalmente, para um controlador de domínio (Tier 0).
Implantou ransomware em toda a rede, criptografando 12 servidores e 80 estações de trabalho.

O custo da recuperação superou US$ 200 mil, incluindo:

Pagamento de resgate (não recomendado, mas a empresa considerou necessário).
Contratação de uma equipe de resposta a incidentes.
Perdas por paralisação das operações (5 dias).
Multas por descumprimento de contratos com clientes.

A auditoria posterior revelou que:

A conta de serviço comprometida tinha permissões de administrador local em 15 servidores.
Não havia segmentação de privilégios (Tier 0/1/2).
Não se monitoravam eventos de Kerberos.

Esse caso não é isolado. Na CyberShield, documentamos padrões similares em 40% dos incidentes de ransomware em PMEs durante 2023.

O Active Directory não é um "problema de TI": é um risco empresarial. As PMEs que ignoram a auditoria de permissões operam com uma bomba-relógio. A boa notícia é que as ferramentas e estratégias para mitigar esses riscos estão ao alcance, mesmo com orçamentos limitados. O primeiro passo é reconhecer que o modelo atual — onde os privilégios crescem sem controle — é insustentável. O segundo é agir antes que um atacante o faça por você. Na CyberShield, continuaremos analisando esses riscos e compartilhando estratégias para que as PMEs da América Latina possam operar com segurança sem sacrificar a agilidade.