⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar a URL exata do alvo, IP, conta ou recurso.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

HUNT-LDAP — Injeção LDAP e Injeção XPath

Nota de base: A injeção LDAP raramente é divulgada com payloads literais em plataformas públicas (a maioria está em relatórios de pentest internos). Esta habilidade é baseada no Guia de Prevenção/Teste de Injeção LDAP da OWASP (WSTG-INPV-06), na Academia de Segurança Web da PortSwigger (injeção LDAP) e na gramática de filtro RFC 4515 — todas referências publicamente verificáveis em vez de IDs inventados do HackerOne. Não cite um relatório que você não possa vincular.

Alvos de Joias da Coroa

Injeção LDAP que contorna a autenticação = Crítico. Exfiltração cega de atributos de credenciais/segredos = Alto. Apenas enumeração de AD = Médio-Alto.

Cadeias de maior valor:

• Contorno de autenticação LDAP — feche o filtro uid e anexe um OR sempre verdadeiro para que o bind/search retorne a entrada do administrador sem uma senha válida.
• Exfiltração cega de atributos — extração caractere por caractere de um valor de atributo via um oráculo booleano (sucesso/falha de login, contagem de resultados ou comprimento da resposta).
• Exfiltração de hash userPassword (apenas não-AD) — em OpenLDAP/389-DS, o atributo userPassword pode conter hashes {SSHA}/{CRYPT} que SÃO legíveis por consulta. Veja o aviso AD vs genérico abaixo.
• Contorno de autenticação por injeção XPath — ' or '1'='1 contra autenticação baseada em XML.

CRÍTICO — Active Directory vs LDAP genérico

Não confunda os dois. Eles se comportam de maneira muito diferente:

Não diga a um leitor que a injeção LDAP cega produz hashes de senha do AD — ela não produz. unicodePwd é somente gravação. Contra o AD, a vitória é a enumeração (campos sAMAccountName, memberOf, description/info que os administradores usam indevidamente para armazenar senhas) e o contorno de autenticação — não o despejo de hashes. A técnica de exfiltração de hash se aplica apenas a diretórios não-AD que expõem userPassword.

Sinais de Superfície de Ataque

Corporate SSO / intranet login pages (often legacy Java/Spring/PHP)
Windows + IIS + "integrated" directory auth
/api/ldap/*  /api/directory/*  /people  /address-book  /search?dir=
"Find a colleague" / org-chart / employee-search features
XML-backed config or auth → XPath injection candidate
Error strings that confirm an LDAP backend:
  javax.naming.NameNotFoundException
  javax.naming.directory.InvalidSearchFilterException
  LDAP: error code 49 - 80090308  (AD invalid creds / bind failure)
  com.sun.jndi.ldap.*  /  System.DirectoryServices  /  ldap_search():
  "Bad search filter"  /  net.ldap (Go)  /  python-ldap SERVER_DOWN

Gramática de filtro LDAP (RFC 4515) — por que a injeção funciona

Um filtro de login é tipicamente construído por concatenação de strings:

(&(uid=<USERNAME>)(userPassword=<PASSWORD>))

& = AND, | = OR, ! = NOT. Filtros são notação prefixa/polonesa — o operador vem primeiro e cada sub-filtro é entre parênteses. Para injetar, você deve (a) escapar o grupo (uid=...) atual, (b) injetar sua própria lógica e (c) deixar a contagem geral de parênteses equilibrada ou o servidor lançará um erro de sintaxe de filtro em vez de executar.

O conjunto de caracteres especiais — TESTE CADA UM

…