Assinatura LDAP desativada: como binds sem assinatura expõem o Active Directory

What Is assinatura LDAP desativada?

Assinatura LDAP desativada significa que um controlador de domínio Active Directory ainda aceita tráfego LDAP sem proteção de integridade no caminho de bind usado pelo cliente. A orientação da Microsoft é direta: binds LDAP SASL sem assinatura e binds simples LDAP em uma conexão sem SSL/TLS devem ser rejeitados porque expõem o serviço de diretório a replay e a manipulação man-in-the-middle. No caso de um bind simples em texto claro, eles também podem expor credenciais diretamente na rede.

Na prática, a fraqueza aparece quando a equipe mantém a política do controlador de domínio em modo permissivo porque uma aplicação antiga, um script, um appliance ou uma integração de diretório ainda depende de comportamento LDAP fraco. O diretório continua disponível, mas a confiança que o controlador de domínio deposita nesse tráfego é excessiva. LDAP não é um canal secundário em Active Directory. Ele é um dos principais planos de controle para consultar usuários, grupos, computadores e objetos privilegiados.

Assinatura LDAP desativada costuma aparecer durante uma revisão mais ampla, como Como auditar a segurança do Active Directory: checklist prática para equipes internas, mas merece uma trilha própria de remediação porque a correção geralmente depende tanto de donos de aplicações quanto da equipe de diretório.

How assinatura LDAP desativada Works

A Microsoft documenta dois padrões arriscados que a assinatura LDAP deve impedir em controladores de domínio:

1. binds LDAP SASL que não solicitam assinatura
2. binds simples LDAP executados em texto claro em vez de SSL/TLS

Quando a assinatura é exigida, cliente e servidor assinam criptograficamente a sessão LDAP para impedir que um intermediário altere o fluxo sem ser percebido. Quando o bind simples ainda é necessário, a recomendação da Microsoft é protegê-lo com SSL/TLS em vez de permiti-lo em texto claro.

Também é importante não confundir assinatura LDAP com LDAP channel binding. A assinatura protege a integridade da sessão LDAP. Channel binding é uma medida separada para sessões LDAP protegidas por TLS e segue outra família de eventos e políticas. Em ambientes reais, os dois assuntos costumam ser remediados juntos, mas não são o mesmo controle.

A Microsoft também destaca uma mudança relevante: Windows Server 2025 e versões posteriores habilitam assinatura LDAP por padrão em novas implantações Active Directory. Isso mostra que o controle deixou de ser uma preferência opcional de hardening para se tornar expectativa básica.

The Attack Chain

Etapa 1 - Encontrar o caminho legado que ainda usa LDAP fraco

Os atacantes não precisam começar com uma conta Domain Admin. Eles procuram primeiro o sistema, script, jump box ou aplicação que ainda faz binds LDAP fracos contra um controlador de domínio. Em auditorias internas, esse caminho costuma aparecer com o mesmo trabalho usado em Monitoramento de segurança do Active Directory: eventos que realmente importam: identificar quais clientes ainda fazem binds SASL sem assinatura ou binds simples em texto claro e quem é o dono operacional desse fluxo.

# Exemplo de bind simples LDAP em texto claro
ldapsearch -x -H ldap://dc01.corp.local -D 'CORP\svc_legacyapp' -W -b 'DC=corp,DC=local' '(objectClass=user)'

Se uma aplicação ainda depende de bind simples em texto claro, o problema real não é apenas o comando. É o fato de o controlador de domínio continuar permissivo o bastante para aceitá-lo.

Etapa 2 - Interceptar ou adulterar tráfego LDAP fraco

A documentação da Microsoft sobre assinatura LDAP cita explicitamente risco de replay e man-in-the-middle sobre tráfego não assinado. Se o caminho de bind não tem proteção de integridade, um atacante bem posicionado na rede pode alterar requisições LDAP ou reutilizar material de autenticação de formas que o ambiente não deveria mais permitir.

Por isso, assinatura LDAP desativada costuma se sobrepor, do ponto de vista operacional, a Ataques NTLM Relay: sequestrando autenticação no AD. Os problemas não são idênticos, mas ambos reduzem a confiança no tráfego de autenticação e diretório que cruza a rede.

Etapa 3 - Transformar acesso ao diretório em mais privilégio

Quando o atacante consegue confiar nesse caminho LDAP fraco, o próximo passo nem sempre é comprometer o domínio imediatamente. Com mais frequência, ele usa esse acesso para reconhecimento de diretório e mapeamento de privilégios:

• enumerar grupos privilegiados e delegações
• localizar contas de serviço sensíveis e objetos de aplicação importantes
• identificar caminhos que mais tarde facilitam abuso de ACL, GPO ou contas excessivamente expostas

Essa é a mesma lógica descrita em Caminhos de ataque no Active Directory até Domain Admin: uma fraqueza no plano de controle do diretório fica mais perigosa quando ajuda o atacante a encontrar o caminho mais curto até objetos privilegiados.

Detection

O caminho de detecção mais limpo usa os eventos Directory Service documentados pela Microsoft para assinatura LDAP.

Para priorizar, comece pelo Event 2887 para saber se o problema ainda está ativo. Se estiver, aumente a verbosidade de LDAP Interface Events para que o Event 2889 forneça IP e identidade. Isso ajuda a atribuir a correção ao dono correto da aplicação em vez de deixar o tema como um problema AD genérico.

# Ler os principais eventos ligados à assinatura LDAP em um DC
Get-WinEvent -LogName 'Directory Service' |
  Where-Object { $_.Id -in 2886,2887,2888,2889,3039,3040,3041,3074,3075 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Durante a remediação, vale correlacionar esses eventos com uma revisão mais ampla como Conformidade AD e Azure: NIS2, ISO 27001 e CIS Controls. Assinatura LDAP é um daqueles controles que costumam aparecer em política escrita muito antes de serem realmente aplicados na produção.

Remediation

💡 Quick Win: use primeiro os eventos 2887 e 2889. Identifique todos os clientes que ainda dependem de binds SASL sem assinatura ou binds simples LDAP em texto claro antes de obrigar os DCs a rejeitá-los.

Uma sequência de remediação durável costuma seguir esta ordem:

1. Inventariar clientes fracos. Revise os dados de 2887 e habilite eventos detalhados para que 2889 identifique exatamente os sistemas de origem.
2. Corrigir o comportamento do cliente. Atualize a aplicação, o driver, o appliance ou o script para que solicite assinatura em SASL ou use SSL/TLS para binds simples.
3. Exigir assinatura nos controladores de domínio. Na política, configure Domain controller: LDAP server signing requirements como Require signing.
4. Revisar a política do cliente. Use Network security: LDAP client signing requirements para impedir que clientes Windows gerenciados iniciem sessões LDAP fracas.
5. Retestar aplicações dependentes. Valide o comportamento do bind em fluxos realmente usados em produção.
6. Monitorar tentativas residuais. Depois da aplicação, acompanhe 2888 e 2889 para encontrar sistemas que ainda precisam de ação.

# Exemplo de validação de política em um host Windows
secedit /export /cfg C:\Temp\secpol.cfg
Select-String -Path C:\Temp\secpol.cfg -Pattern 'LDAP'

A armadilha operacional mais comum é forçar a configuração sem coordenar com os donos das aplicações. Assinatura LDAP deve ser exigida, mas o caminho mais seguro passa por inventário, migração e novos testes. Isso é ainda mais importante quando o ambiente também apresenta GPO mal configurado como vetor de ataque ou outras falhas de higiene que dificultam a mudança.

Validate Before You Close the Finding

A validação final deve provar mais do que uma política alterada. Execute novamente o mesmo teste que identificou o cliente fraco, confirme que agora ele usa assinatura ou LDAPS conforme o caso e peça validação do fluxo real ao dono da aplicação. Problemas de assinatura LDAP costumam sobreviver como exceções esquecidas, contas de serviço não revisadas ou appliances que nunca foram retestados após a mudança de GPO.

Se o ambiente também mostrar exposição a relay em serviços próximos, documente isso explicitamente. Em muitos ambientes, o mesmo sistema que ainda fala LDAP fraco também apresenta condições associadas a NTLM_RELAY_OPPORTUNITY. Registrar essa relação ajuda a remover a dependência de forma definitiva.

How EtcSec Detects This

EtcSec relaciona esse tema diretamente a LDAP_SIGNING_DISABLED, e geralmente faz sentido analisá-lo ao lado de NTLM_RELAY_OPPORTUNITY quando tráfego de diretório fraco e caminhos de rede suscetíveis a relay aparecem juntos. O ponto importante não é apenas saber que a configuração está fraca, mas verificar se a política do DC ainda é permissiva, se clientes fracos continuam ativos e se a correção pertence à equipe de AD ou ao time de aplicação.

ℹ️ Note: EtcSec verifica automaticamente fraquezas de assinatura LDAP em cada auditoria Active Directory para separar uma política escrita de um controle realmente aplicado em controladores de domínio ativos.

Official References

• Microsoft Learn: LDAP signing for Active Directory Domain Services on Windows Server
• Microsoft Learn: Manage LDAP signing using Group Policy for Active Directory Domain Service
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Support KB4520412: LDAP channel binding and LDAP signing requirements for Windows

Related Reading

Ao tratar assinatura LDAP, revise também Ataques NTLM Relay: sequestrando autenticação no AD, Monitoramento de segurança do Active Directory: eventos que realmente importam, Caminhos de ataque no Active Directory até Domain Admin, GPO mal configurado como vetor de ataque e Segurança de senhas no Active Directory: erros de configuração que importam. O hardening de LDAP é mais forte quando confiança de rede, confiança no diretório e caminhos de privilégio são revistos juntos.