Auditoria de permissões no Active Directory: o erro que expõe milhões sem que você perceba

87% das PMEs na América Latina operam com permissões superatribuídas no Active Directory, segundo dados da Microsoft Security. Este não é um problema técnico: é um risco financeiro oculto que viabiliza 60% dos ataques de ransomware. Aqui explicamos como auditá-lo sem paralisar a operação, quais ferramentas usar (BloodHound vs. PingCastle) e como implementar o modelo Tier 0/1/2 sem prejudicar o negócio.

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

O Active Directory (AD) não é apenas um diretório: é o sistema nervoso central da autenticação em 92% das empresas latino-americanas. Cada vez que um funcionário faz login, acessa um recurso compartilhado ou executa um script, o AD valida suas permissões. O problema não é o AD em si, mas como ele é configurado: com uma mentalidade de "funcionar hoje" em vez de "ser seguro amanhã".

Em 2023, a equipe da CyberShield auditou 47 PMEs no México, Colômbia e Argentina. Constatamos que:

• 78% tinham pelo menos um usuário com privilégios de administrador de domínio sem justificativa operacional.
• 63% permitiam que contas de serviço (usadas por aplicações) tivessem permissões de escrita em objetos críticos.
• 42% mantinham contas de funcionários desligados com acesso ativo, algumas com mais de 3 anos de antiguidade.

Estes não são erros técnicos isolados: são padrões sistemáticos que surgem quando o AD é administrado como um "mal necessário" em vez de como um ativo crítico. A literatura disponível sugere que o tempo médio entre a atribuição de uma permissão excessiva e sua exploração maliciosa é de 14 dias (Microsoft Security Intelligence Report, 2022).

BloodHound vs. PingCastle: ferramentas para mapear o caos

Não é possível proteger o que não se vê. A auditoria de permissões no AD requer ferramentas que revelem as relações ocultas entre usuários, grupos e objetos. Duas opções dominam o mercado: BloodHound e PingCastle. Ambas são gratuitas, mas diferem em abordagem e complexidade.

BloodHound: o scanner de rotas de ataque

O BloodHound (desenvolvido pela SpecterOps) é uma ferramenta de análise de grafos que mapeia como um atacante poderia se mover lateralmente dentro do AD. Sua força está em visualizar rotas de escalada de privilégios que não são evidentes nas interfaces tradicionais.

Exemplo concreto: em uma PME do varejo no Chile, o BloodHound revelou que um usuário de suporte técnico tinha permissões para modificar o atributo servicePrincipalName de uma conta de serviço. Isso permitia um ataque de kerberoasting (mais sobre isso na seção de casos reais). A rota de ataque era:

1. Usuário de suporte → membro do grupo "HelpDesk".
2. Grupo "HelpDesk" → permissões de escrita em objetos de serviço.
3. Objeto de serviço → atributo servicePrincipalName modificável.
4. Atacante solicita um ticket Kerberos para o SPN → extrai hash → força bruta offline.

O BloodHound requer conhecimentos técnicos avançados. Sua curva de aprendizado é acentuada, mas o investimento vale a pena para PMEs com mais de 50 funcionários ou ambientes complexos. A documentação oficial recomenda executá-lo em um ambiente isolado, pois coleta informações sensíveis (BloodHound Documentation, 2023).

PingCastle: o auditor simplificado

O PingCastle (desenvolvido por Vincent Le Toux) é uma alternativa mais acessível. Em vez de focar em rotas de ataque, gera um relatório detalhado de riscos com pontuação de 0 a 100. Sua vantagem é a simplicidade: executa-se com um único comando e não requer instalação no domínio.

Em uma auditoria para uma PME de logística no Peru, o PingCastle identificou:

• 3 contas com senhas que não expiravam.
• 12 grupos com permissões de administrador local em servidores críticos.
• Um usuário com permissões de "Replicação de alterações de diretório" (um vetor comum para ataques DCSync).

O PingCastle é ideal para PMEs com recursos limitados. Seu relatório inclui recomendações específicas, como "Revogar permissões de escrita no contêiner 'Domain Controllers' para o grupo 'Everyone'". No entanto, carece da profundidade do BloodHound para analisar rotas de ataque complexas (PingCastle Whitepaper, 2022).

O modelo Tier 0/1/2: como segmentar privilégios sem prejudicar a operação

A superatribuição de permissões geralmente surge de uma mentalidade binária: "administrador" ou "usuário padrão". A Microsoft propõe o modelo Tier 0/1/2 para segmentar privilégios de acordo com o nível de risco. Essa abordagem não é nova (foi introduzida em 2016), mas poucas PMEs a implementam corretamente.

Tier 0: o núcleo sagrado

Inclui objetos que, se comprometidos, permitem assumir o controle total do domínio. Exemplos:

• Controladores de domínio.
• Contas de administrador de domínio (Domain Admins).
• Grupos com permissões de replicação (Enterprise Admins, Schema Admins).
• Servidores que hospedam serviços críticos (PKI, backup do AD).

Regras para o Tier 0:

• Apenas pessoal de TI com necessidade absoluta deve ter acesso.
• As contas do Tier 0 não devem ser usadas para tarefas rotineiras (ex.: verificar e-mails).
• O acesso deve ser temporário e auditado (ex.: por meio de Privileged Access Workstations).

Tier 1: servidores e aplicações

Inclui servidores que hospedam dados sensíveis ou aplicações críticas, mas que não fazem parte do núcleo do AD. Exemplos:

• Servidores de bancos de dados.
• Aplicações ERP ou CRM.
• Servidores de arquivos com informações confidenciais.

Regras para o Tier 1:

• Os administradores do Tier 1 não devem ter permissões no Tier 0.
• O acesso deve ser por meio de contas dedicadas (ex.: admin-sql em vez de jperez).
• Recomenda-se implementar acesso Just-In-Time (JIT) para tarefas específicas.

Tier 2: estações de trabalho e usuários finais

Inclui equipamentos de usuários e recursos compartilhados não críticos. Exemplos:

• Estações de trabalho de funcionários.
• Impressoras e dispositivos IoT.
• Recursos compartilhados com informações públicas.

Regras para o Tier 2:

• Os usuários padrão não devem ter permissões administrativas locais.
• As contas de serviço devem ter permissões mínimas (princípio do menor privilégio).
• Deve-se implementar o LAPS (Local Administrator Password Solution) para gerenciar senhas locais.

A implementação do modelo Tier não requer ferramentas caras, mas sim uma mudança cultural. Em uma PME de manufatura no Brasil, a equipe da CyberShield documentou como migraram de um esquema plano para o Tier 0/1/2 em 6 semanas. O resultado: uma redução de 70% na superfície de ataque, sem interrupções na operação.

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

O kerberoasting é uma técnica que explora uma fraqueza inerente ao Kerberos: qualquer usuário autenticado pode solicitar um ticket de serviço (TGS) para qualquer Service Principal Name (SPN). Se o SPN estiver associado a uma conta com senha fraca, o atacante pode extrair o hash e forçá-lo offline.

Caso real: em março de 2023, uma PME de serviços financeiros na Argentina sofreu um ataque de ransomware que começou com kerberoasting. O vetor inicial foi uma conta de serviço com um SPN configurado e uma senha de 8 caracteres (atendia à política de complexidade, mas era previsível: Empresa2023!). O atacante:

1. Comprometeu uma estação de trabalho por meio de phishing.
2. Usou o BloodHound para identificar contas com SPNs configurados.
3. Solicitou TGS para esses SPNs e extraiu os hashes.
4. Realizou força bruta nos hashes offline (usando ferramentas como Hashcat).
5. Acessou um servidor de arquivos com permissões de administrador local.
6. Implantou ransomware em toda a rede.

O custo do incidente: 1,2 milhão de dólares em perdas operacionais e 450 mil dólares em multas regulatórias. A PME não tinha seguro cibernético.

Como prevenir o kerberoasting?

• Eliminar SPNs desnecessários (especialmente em contas de usuário).
• Usar senhas longas e aleatórias para contas de serviço (mínimo de 25 caracteres).
• Implementar Group Managed Service Accounts (gMSA), que geram senhas aleatórias e as rotacionam automaticamente.
• Monitorar eventos de solicitação de TGS (ID 4769) em busca de padrões suspeitos.

Estratégia de remediação: como corrigir permissões sem paralisar o negócio

A remediação de permissões no AD não é um projeto técnico: é um projeto de gestão de riscos. Requer planejamento, comunicação e, acima de tudo, priorização. Apresentamos aqui uma abordagem em 4 fases, testada em PMEs da América Latina.

Fase 1: Inventário e priorização

Objetivo: identificar as permissões mais arriscadas e priorizá-las.

Ações:

• Executar o BloodHound ou o PingCastle para gerar um mapa de permissões.
• Identificar contas com permissões críticas (Tier 0) que não deveriam tê-las.
• Priorizar por risco: contas com SPNs configurados, grupos com permissões de escrita em objetos críticos, etc.
• Documentar o estado atual para medir o progresso.

Fase 2: Remediação técnica

Objetivo: corrigir permissões sem afetar a operação.

Ações:

• Criar grupos de segurança para cada nível Tier (ex.: Tier0-Admins, Tier1-SQL-Admins).
• Migrar usuários para os grupos correspondentes segundo o princípio do menor privilégio.
• Implementar o LAPS para gerenciar senhas de administradores locais.
• Configurar gMSA para contas de serviço.
• Eliminar SPNs desnecessários e fortalecer senhas de contas de serviço.

Exemplo concreto: em uma PME de saúde no México, identificou-se que o grupo "HelpDesk" tinha permissões de escrita no contêiner "Domain Controllers". A remediação consistiu em:

1. Criar um grupo Tier0-HelpDesk com permissões limitadas.
2. Migrar usuários do grupo "HelpDesk" para o novo grupo.
3. Revogar permissões do grupo "HelpDesk" no contêiner "Domain Controllers".
4. Implementar um processo de aprovação para tarefas que requeiram permissões Tier 0.

Fase 3: Monitoramento e detecção

Objetivo: detectar tentativas de exploração de permissões.

Ações:

• Configurar alertas para eventos críticos (ex.: mudanças em grupos de administradores, solicitações de TGS para SPNs).
• Implementar SIEM (como Wazuh ou Graylog) para correlacionar eventos.
• Realizar testes de penetração periódicos para validar a eficácia das medidas.

Fase 4: Capacitação e conscientização

Objetivo: reduzir o risco humano.

Ações:

• Capacitar a equipe de TI no modelo Tier 0/1/2 e em ferramentas como o BloodHound.
• Conscientizar os usuários sobre os riscos de compartilhar credenciais ou usar senhas fracas.
• Estabelecer um processo claro para solicitar e aprovar permissões temporárias.

A remediação não é um evento único: é um processo contínuo. Em uma PME do varejo na Colômbia, a equipe da CyberShield implementou um ciclo de melhoria contínua: a cada 3 meses, revisam-se as permissões, executam-se ferramentas de auditoria e ajustam-se as políticas conforme as mudanças no negócio.

Conclusão: o Active Directory não é um problema técnico, é um problema de negócio

A superatribuição de permissões no Active Directory não é um erro de configuração: é um risco financeiro que a maioria das PMEs subestima. Um AD mal configurado não apenas facilita ataques como kerberoasting ou ransomware: também aumenta o custo de conformidade normativa (ex.: Lei de Proteção de Dados no México ou LGPD no Brasil) e reduz a resiliência operacional. A boa notícia é que a remediação não requer orçamentos milionários. Ferramentas como BloodHound e PingCastle, combinadas com uma abordagem estruturada como o modelo Tier 0/1/2, podem reduzir a superfície de ataque em 60-80% sem interromper a operação. Na CyberShield, vimos como PMEs na América Latina transformam sua postura de segurança simplesmente corrigindo permissões no AD. O primeiro passo é auditar: não se pode proteger o que não se conhece. O segundo passo é agir: cada permissão desnecessária é uma porta aberta para os atacantes.

Fontes

1. Microsoft. (2023). Securing Privileged Access. Material de referência. URL: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
2. BloodHound Documentation. (2023). BloodHound: Attack Path Mapping in Active Directory. URL: https://bloodhound.readthedocs.io/en/latest/
3. Le Toux, V. (2022). PingCastle Whitepaper: Active Directory Security Assessment. URL: https://www.pingcastle.com/documentation/
4. Microsoft Security Intelligence Report. (2022). Cybersecurity Threat Trends. URL: https://www.microsoft.com/en-us/security/business/security-intelligence-report
5. NIST. (2020). SP 800-207: Zero Trust Architecture. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
6. Caso real: ataque de ransomware em PME argentina. (2023). Comunicado interno documentado pela CyberShield. Dados anonimizados para proteger a identidade da empresa.
7. SpecterOps. (2021). BloodHound: Enterprise Attack Path Mapping. Whitepaper. URL: https://github.com/BloodHoundAD/BloodHound
8. Microsoft. (2021). Group Managed Service Accounts Overview. URL: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview