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

O que é a 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 Auditar a segurança do Active Directory: o que revisar primeiro e como comprovar a remediação, 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.

Como funciona

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. A ressalva é que esse novo padrão vale apenas para implantações novas: a Microsoft afirma que, ao atualizar um Windows Server anterior para o Windows Server 2025, as políticas de assinatura LDAP existentes são preservadas para evitar interrupções, portanto um controlador de domínio atualizado mantém qualquer configuração permissiva que já tinha.

A cadeia de ataque

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.

Detecção

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

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. No Windows Server 2025 e versões posteriores, configure também Domain controller: LDAP server signing requirements enforcement: a Microsoft documenta que essa política mais recente tem precedência sobre a mais antiga e a substitui, portanto a configuração antiga sozinha não decide mais o resultado.
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.

Valide antes de encerrar o achado

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.

Como a EtcSec detecta isso

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.

Referências oficiais

• 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 - Windows Server
• Microsoft Support: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412)

Leituras relacionadas

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.