Responder e Validação de Defesa contra NTLM Relay
Responder e Validação de Defesa contra NTLM Relay
Atualizado em: 2026-09
O que você vai aprender:
- Como funciona um ataque NTLM relay usando ferramentas como Responder e ntlmrelayx
- Métodos práticos para validar defesas contra NTLM relay em ambientes Windows on-premise, Cloud híbrida e OT/ICS
- Como montar detecções, testes e playbooks operacionais para Blue Team e Red Team
Pré-requisitos: conhecimento intermediário-avançado em administração Windows, redes TCP/IP, PowerShell, Kali Linux, e acesso autorizado ao ambiente para testes.
Nível: intermediário | avançado
Sumário:
- Contexto Atual e Relevância Estratégica
- Fundamentos Técnicos do Tema
- Arquitetura, Fluxos e Superfície de Ataque
- Cenários Reais e Estudos de Caso
- Implementação Prática Step-by-Step
- Hardening, Controles e Melhores Práticas
- Playbooks Operacionais para Blue Team e Red Team
- Métricas, KPIs e Auditoria Técnica
- Erros Comuns, Armadilhas e Correções
- FAQ Técnico para Busca Orgânica
- Considerações Finais
- Referências
Em 2025 e 2026 vimos um aumento de incidentes onde adversários exploraram protocolos legados e relaying de autenticação para escalar privilégios em ambientes corporativos e em infraestruturas críticas. Ataques de NTLM relay continuam sendo uma via prática porque dependem mais de falhas de configuração e permissões do que de vulnerabilidades zero-day. Este artigo entrega um cookbook técnico: do entendimento do protocolo NTLM e suas fragilidades, passando por laboratórios reproduzíveis com Responder e ntlmrelayx, até validações de defesa, detecções no SIEM, e playbooks prontos para resposta. Cada seção contém comandos, trade-offs e métricas acionáveis – não é leitura passiva.
Contexto Atual e Relevância Estratégica
1 2 | Fluxo de impacto - visão simplificada Atacante -> Captura de name service (LLMNR/NBNS/MDNS) -> Responder responde -> Cliente envia NTLM auth -> ntlmrelayx relays -> Serviço alvo aceita NTLM -> Execução/credenciais |
NTLM relay não é nova vulnerabilidade de software; é classe de ataque que explora fraquezas no design do protocolo de autenticação NTLM e em configurações permissivas. A relevância estratégica aumentou porque muitas organizações migraram workloads para modelos híbridos e mantiveram serviços legados sem SMB signing, Extended Protection ou políticas restritivas de NTLM. Em 2026, incidentes conduzidos por grupos com acesso limitado demonstraram que simples configurações e permissões mal gerenciadas continuam a permitir movimento lateral e elevação de privilégios.
NTLM relay explora confiança implícita entre cliente e serviço; mitigar exige mudanças em políticas, autenticação e arquitetura – não apenas deploys de agentes.
Panorama de risco e impacto
Os impactos variam: de acesso a shares sensíveis até comprometimento total de domínios. Em avaliações de risco, quantifique:
- Percentual de servidores com SMB signing desabilitado
- Número de endpoints que respondem a LLMNR/NBNS
- Contas com privilégios locais amplos que permitem elevação via relay
| Métrica | Por quê importa | Meta |
|---|---|---|
| Servidores sem SMB signing (%) | Maior superfície de relay SMB | <5% |
| Endpoints respondendo LLMNR/NBNS | Facilita poisoning local | 0 em rede corporativa |
| Autenticações NTLM no domínio (%) | Menos NTLM reduz vetor | <2% |
Validações sem autorização formal podem violar normas internas, leis e contratos. Sempre tenha escopo e autorização (POA) assinados antes de executar Red Team ou testes de Responder/ntlmrelayx.
Por que o tema é urgente em 2026
Movimentos recentes de atacantes mostram preferência por técnicas que minimizam ruído e reintegram credenciais para autenticar contra serviços internos. Ao mesmo tempo, políticas de segurança atrasaram remoção de NTLM em sistemas legados. Ferramentas de red team foram otimizadas para operações rápidas, e frameworks de detecção (ex.: Microsoft DETECT) cresceram – mas lacunas de instrumentação persistem. Conclusão: defender e validar contra NTLM relay é prioridade de curto prazo em programas de hardening e resposta.
Fundamentos Técnicos do Tema
NTLM – o básico e por que é frágil
NTLM (NT LAN Manager) é um conjunto de protocolos de autenticação usados historicamente no Windows. NTLM autentica via desafio-resposta (challenge-response), sem proteção nativa contra reuso de credenciais entre conexões (relay), e é vulnerável quando o endpoint confia cegamente no interlocutor.
1 2 3 4 5 6 7 8 9 10 11 | +---------------------------+ | Camada de decisão (policy)| +---------------------------+ | +---------------------------+ | Controles e lógica | +---------------------------+ | +---------------------------+ | Telemetria e evidência | +---------------------------+ |
Vulnerabilidades fundamentais:
- Falta de binding de serviço – ausência de garantia de destino verdadeiro
- Autenticações passadas como NTLM hashes que podem ser reutilizadas
- Protocolos de name resolution inseguros (LLMNR, NBNS) facilitam envenenamento
Componentes relevantes no Windows
Componentes que precisam ser conhecidos para defesa e validação:
- SMB (portas 445/139) e SMB signing
- NTLM authentication provider (LSA/SSPI)
- Group Policy settings: Network security: Restrict NTLM, Audit NTLM
- Extended Protection for Authentication (EPA)
- Protected Users, Authentication Policies, Kerberos enforcement
Como um NTLM relay funciona, tecnicamente
Resumo técnico do mecanismo:
- Cliente resolve nome (ex.: share.internal.local) via DNS, LLMNR, NBNS.
- Atacante responde com sua resolução (poisoning) e captura o tráfego de autenticação.
- Cliente inicia NTLM challenge-response com o “serviço” atacado (o cervegado).
- Atacante retransmite (relays) os dados de autenticação para serviço real, mantendo binding do protocolo.
- Se o alvo aceita NTLM sem validação adicional, o atacante obtém sessão autenticada.
- Com sessão autenticada, atacante pode abrir SMB, RPC, HTTP com privilégios do cliente.
SMB signing bloqueia muitos relays porque garante integridade da sessão; porém depende de suporte no cliente e servidor e pode ter impacto de performance se for forçado indiscriminadamente.
Ferramentas principais e intenções
| Ferramenta | Uso | Limitação |
|---|---|---|
| Responder | Poisoning LLMNR/NBNS/MDNS e captura de autenticações | Requer vítima na mesma broadcast domain |
| ntlmrelayx (Impacket) | Relay de NTLM para diversos serviços (SMB, HTTP, LDAP, MSSQL) | Alguns serviços protegem contra relay via SMB signing ou EPA |
| Inveigh | PowerShell LLMNR/NBNS responder para ambientes Windows | Depende de permissões locais para execução |
| Mimikatz | Extração de credenciais e pós-exploitation | Antivírus e proteção LSA mitigam execução direta |
Arquitetura, Fluxos e Superfície de Ataque
Onde o relay é viável – mapa de superfície
Superfície de ataque típica inclui:
- Segmentos de rede com hosts desprotegidos e sem monitoramento
- Serviços legados sem SMB signing/Extended Protection
- Contas com privilégios desnecessários em serviços que aceitam NTLM
- Ambientes OT/ICS com equipamentos Windows antigos
1 2 3 4 | Arquitetura simplificada [Estação Vítima] --(LLMNR/NBNS)--> [Atacante com Responder] [Atacante] --(NTLM Relay)--> [Servidor alvo SMB/RPC/LDAPS] [Servidor alvo] --> Acesso/execução dependendo dos privilégios |
Mapeamento de serviços que comumente aceitam NTLM relay
| Serviço/Protocolo | Porta/Contexto | Mitigação mais efetiva |
|---|---|---|
| SMB/CIFS | 445/139 | SMB signing forçado, restrict NTLM |
| HTTP/REST/IIS | 80/443 | Extended Protection for Authentication, TLS client auth |
| LDAP/LDAPS | 389/636 | LDAPS + require signing and sealing |
| MS-RPC / RPC over HTTP | 135, dinamicas | SMB signing / Endpoint hardening |
| MSSQL | 1433 | Kerberos constrained delegation, TLS |
Fluxos defensivos recomendados
1 2 3 4 5 6 | Fluxo de defesa - alto nível 1. Inventory de serviços que aceitam NTLM 2. Aplicar SMB signing + EPA onde possível 3. Reduzir NTLM via GPO e monitorar eventos de fallback 4. Instrumentar SIEM para autenticações NTLM e padrões de relay 5. Testar com red team autorizado e ajustar controles |
Mitigação completa demanda inventário e priorização por risco. Forçar SMB signing sem planejamento pode quebrar aplicações legadas; teste em pilot antes de deploy em massa.
Cenários Reais e Estudos de Caso
Estudo de caso 1 – Movimento lateral em corporação financeira
Resumo do incidente: invasor aproveitou workstation de helpdesk com software legado. LLMNR estava habilitado na rede; Responder capturou autenticações NTLM e ntlmrelayx foi usado para obter sessão em servidor de arquivos com privilégios de domínio. Persistência foi instalada via scheduled task. O ponto de falha: servidor aceitava NTLM sem signing e contas com permissão de escrita em SYSVOL.
Decisão tática adotada pelo time de resposta:
- Imediato: isolar a workstation e revogar sessões Kerberos/NTLM do usuário
- Curto prazo: desabilitar LLMNR/NBNS via GPO e ativar Audit NTLM
- Médio prazo: implementar SMB signing e revisar permissões em shares críticos
Estudo de caso 2 – Falha em ambiente OT com equipamentos antigos
Resumo: dispositivo HMI rodando Windows Embedded respondia a requests SMB. Equipe de manutenção exigiu NTLM por compatibilidade. Atacante local conseguiu relay para servidor SCADA usando credenciais de operador, resultando em interrupção de processo. Solução envolveu segmentação de rede física e uso de jump hosts controlados para manutenção.
Em OT/ICS, mitigações que interrompem protocolos podem causar falhas físicas. Ações devem ser coordenadas com engenharia de processo e testes de segurança funcional.
Comparativo de impacto – Red Team x incidente real
| Aspecto | Red Team (teste controlado) | Incidente real |
|---|---|---|
| Visibilidade | Controlada, logs preservados | Logs podem estar corrompidos; auditoria incompleta |
| Tempo de detecção | Minutos a horas | Horas a dias |
| Impacto operacional | Baixo (escopo autorizado) | Alto (parada de serviço possível) |
Implementação Prática Step-by-Step
Kit de lab
Título descritivo: Ambiente de laboratório mínimo
1 2 3 4 5 6 7 | [ Inventário ] -> [ Baseline ] -> [ Mudança em Dev/Test ] | v [ FAT / SAT ] | v [ Produção + monitoramento ] |
- Máquina atacante: Kali Linux atualizada com Impacket, Responder, Bettercap
- Máquinas alvo: Windows Server 2019/2022 com shares e serviços IIS, endpoints Windows 10/11
- Controlador de domínio: AD para testes de confiança e políticas
- Rede: VLAN separada para testes; privilégios de administração do lab
Instalação de ferramentas no Kali
1 2 3 4 5 | sudo apt update && sudo apt install -y git python3-pip pip3 install impacket git clone https://github.com/SpiderLabs/Responder.git /opt/responder git clone https://github.com/SecureAuthCorp/impacket.git /opt/impacket cd /opt/impacket && pip3 install . |
Valide instalação:
1 2 | ntlmrelayx.py -h Responder.py -h |
Passo a passo: reproduzir NTLM relay controlado (8+ passos)
- Confirmar escopo e autorização formal para teste no ambiente lab.
- Identificar segmento de rede de teste e configurar IPs estáticos.
- Ligar Responder para envenenamento LLMNR/NBNS: 1sudo python3 /opt/responder/Responder.py -I eth0 -rdw
- Do atacante, preparar ntlmrelayx para relay para SMB e obter shell via impacket smbexec: 1sudo ntlmrelayx.py -tf targets.txt -smb2support -c "whoami" --no-dc-ntlm
- Gerar tráfego cliente simulando acesso a share para ter victims na mesma VLAN.
- Observar logs do Responder: NTLM hashes e contextos de serviço autenticante.
- Quando o relay for bem-sucedido, confirmar comandos executados no alvo (ou sessão SMB aberta).
- Capturar logs de segurança no Windows: 4624, 4648, 4776, e salvar evidências com timestamps.
- Reverter alterações, limpar payloads e documentar em relatório técnico com evidência de consentimento.
Use targets.txt com urls baseados no protocolo: smb://10.0.0.5 e http://10.0.0.6 caso queira observar relay para múltiplos serviços; ntlmrelayx suporta diversos backends.
Comandos práticos e validação da saída
Exemplo de execução controlada do ntlmrelayx para relayer NTLM para SMB e executar mimikatz:
1 | sudo ntlmrelayx.py -t smb://10.0.0.5 -c 'whoami /all' --smb2support |
Validação esperada:
- Output do ntlmrelayx indicando NTLM auth relay recebido
- Conexão SMB estabelecida no alvo
- Comando remoto executado com privilégios do usuário autenticado
Responder output típico:
1 2 | [SMB] NTLMv2-SSP Client WORKSTATION$ -> 10.0.0.5:445 - user:DOMAIN\user [SMB] NTLMv2-SSP Hash : <hash> |
Limitações e trade-offs do lab
Ambiente isolado não reproduz dificuldades de produção como proxies, WAFs, split-horizon DNS e load balancers. Além disso, serviços em cloud podem interromper relay por políticas de autenticação que usam tokens OAuth/Kerberos. Considere variações: testar com Azure AD Application Proxy, AWS Managed AD, e serviços SaaS que não aceitam NTLM.
Hardening, Controles e Melhores Práticas
Matriz de controles – por fase (inventário, impedir, detectar, responder)
| Fase | Controle | Descrição | Prioridade |
|---|---|---|---|
| Inventário | Inventory de serviços que aceitam NTLM | Scan de portas 445/139 e análise de respostas de SMB/HTTP | Alta |
| Impedir | SMB signing forçado | Enable RequireSecuritySignature via GPO em servidores e clientes | Alta |
| Impedir | Restrict NTLM via GPO | Configurar ‘Network security: Restrict NTLM’ para negar autenticações não autorizadas | Alta |
| Impedir | Extended Protection for Authentication (EPA) | Configurar em IIS e serviços que suportam | Média |
| Detectar | Audit NTLM e logs centralizados | Ativar ‘Audit NTLM authentication’ e encaminhar para SIEM | Alta |
| Responder | Playbook de isolamento e rotação de credenciais | Procedimento com steps validados de isolamento e rotação | Alta |
Passos práticos de GPO e registry
Enable SMB signing nos servidores via GPO:
1 2 3 4 | Computer Configuration > Policies > Administrative Templates > Network > Lanman Workstation > Enable 'Require Security Signatures' = Enabled Computer Configuration > Policies > Administrative Templates > Network > Lanman Server > Enable 'Require Security Signatures' = Enabled |
Nota: Em ambientes com aplicações legadas, implemente primeiro em ‘audit only’ ou pilot em grupos de servidores. A mudança pode quebrar aplicações que não suportam signing.
Configurar ‘Network security: Restrict NTLM’ passo a passo
GPO path:
1 2 3 | Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all > Network security: Restrict NTLM: Incoming NTLM traffic = Deny all |
Trade-off: negar NTLM por completo pode quebrar aplicações internas e integração com sistemas legados. Recomendação: aplicar bloqueio por exceção (allow list) e priorizar migração para Kerberos/TLS.
Hardening de serviços específicos
- IIS – habilite Extended Protection for Authentication e configure channel binding tokens quando suportado
- LDAP – habilite LDAPS, disable LDAP simple bind over plain text
- MSSQL – exigir Kerberos ou TLS para autenticação integrada
1 2 3 4 5 6 | Fluxo de hardening por serviço 1. Identificar serviço que aceita NTLM 2. Verificar suporte para Kerberos/TLS/EPA 3. Habilitar mecanismo seguro em staging 4. Testar compatibilidade com aplicações 5. Forçar política em produção após validação |
Use ‘Authentication Policies and Silos’ para limitar conta privilegiadas que podem autenticar interativamente, reduzindo impacto de relays com contas de alto privilégio.
Playbooks Operacionais para Blue Team e Red Team
Playbook Blue Team – Detecção e Resposta
- Ativar ‘Audit NTLM authentication’ no domínio e encaminhar logs para SIEM
- Implementar alertas para padrões: múltiplos 4624 com Authentication Package: NTLM seguidos de acessos a serviços sensíveis
- Monitorar conexões SMB inusitadas vindas de hosts de usuário
- Investigação imediata: identificar origem do LLMNR/NBNS poisoning via captura de tráfego
- Isolar host comprometido e revogar sessões e chaves Kerberos relevantes
Playbook Red Team – Execução controlada
- Obter autorização e definir escopo de testes
- Catalogar alvos e segmentar attacks para áreas autorizadas
- Deploy Responder/Inveigh com logging e timestamps
- Usar ntlmrelayx com payloads inofensivos primeiro (ex.: whoami) para validar possibilidades
- Entregar relatório técnico com evidência e recomendações priorizadas
Playbook detalhado Blue Team – resposta a detecção de relay
- Alerta acionado no SIEM: múltiplas autenticações NTLM de um host de usuário para serviços críticos.
- Triagem: coletar eventos 4624, 4648, 4776 do host e do servidor alvo; correlacionar via IP/username/timestamp.
- Captura de rede: se disponível, coletar PCAP de switch ou endpoint para comprovar NTLMSSP negotiation.
- Isolamento: retirar host da VLAN ou firewall para bloquear tráfego SMB/445 por host.
- Rotação de credenciais afetadas e revogação de tokens Kerberos.
- Scan forensico: checar process list, scheduled tasks, serviços persistentes, DLLs carregadas.
- Remediação: aplicar políticas de assinatura e bloco de NTLM ao servidor alvo se seguro.
- Relatório pós-morte: timeline, evidências, lições aprendidas e plano de mitigação permanente.
Rotação de credenciais deve ser coordenada com aplicativos que usam service accounts; rotação abrupta pode causar downtime.
1 2 3 4 | [ Detectar ] --> [ Contornar / Contenção ] ^ | | v [ Lições ] <------- [ Recuperar + validar ] |
Playbook resumido
| Comando | Quando usar | Resultado esperado |
|---|---|---|
| Responder.py -I eth0 -rdw | Testes de captura em VLAN controlada | Receber hashes NTLM de vítimas |
| ntlmrelayx.py -t smb://10.0.0.5 -c ‘whoami’ | Validar relay para SMB | Output ‘whoami’ com contexto do usuário |
| GPO: RequireSecuritySignatures | Mitigação preventiva | Clients/Servers exigem SMB signing |
Métricas, KPIs e Auditoria Técnica
Métricas recomendadas para medir risco e progresso
| KPI | Descrição | Objetivo |
|---|---|---|
| % de autenticações NTLM | Proporção de logons via NTLM vs Kerberos | <2% em 12 meses |
| Time to Detect (TTD) | Tempo médio entre ataque e alerta | <30 minutos para atividades críticas |
| Time to Remediate (TTR) | Tempo para isolar e rotacionar credenciais | <4 horas |
| Hosts com SMB signing desabilitado | Número absoluto e percentual | <5% com plano de remoção |
Métodos de auditoria técnica
Auditar ambientes envolve: (1) varreduras de portas e banners SMB, (2) análise de políticas Group Policy e registry keys, (3) captura de tráfego para identificar NTLMSSP flags, e (4) testes de relay controlados com ntlmrelayx. Documente evidências: outputs de nmap/smbclient, logs Windows Security, e PCAPs.
1 2 3 4 | [ Coleta ] -> [ Indicador ] -> [ Limiar/alerta ] ^ | | v [ Melhoria ] <-------------- [ Ação / ticket ] |
1 2 | Exemplo de nmap para identificar SMB sudo nmap -sS -p 445 --script smb-protocols <target> |
Erros Comuns, Armadilhas e Correções
Erro: Forçar mitigação sem inventário
Alinhe inventário antes de forçar SMB signing ou negar NTLM. Sem isso, aplicações antigas podem quebrar e causar interrupções operacionais. Correção: pilotar GPO em OU reduzido, trabalhar com donos de aplicação.
1 2 3 4 | [ Anti-padrão ] --> [ Sintoma ] --> [ Correção ] | v [ Evidência / regressão ] |
Erro: confiar só em bloqueio de portas
Bloquear porta 445 na borda não impede relay interno. Relay é ataque lateral que acontece dentro da rede; controles de microsegmentação e egress filtering complementam, mas não substituem políticas de autenticação.
Erro: não auditar NTLM especificamente
Algumas equipes assumem que proxies ou EDR cobrem tudo. É necessário ativar audit NTLM e regras específicas no SIEM. Correção: implementar GPO de audit e criar parsers para eventos 4624/4648/4776.
Mitigação técnica sem telemetria é investimento sem retorno mensurável. Sempre valide com métricas antes e depois.
FAQ Técnico para Busca Orgânica
O que é NTLM relay?
NTLM relay é técnica onde um atacante intercepta credenciais NTLM de um cliente e as retransmite a um serviço alvo, autenticando-se como o cliente. O sucesso depende de o serviço aceitar NTLM sem validação adicional.
Responder e ntlmrelayx são usados apenas por atacantes?
Não. São ferramentas de pesquisa usadas por Red Teams e defensores para validar exposições. Seu uso em produção sem autorização é ilegal.
Como detectar um NTLM relay no SIEM?
Crie correlações entre eventos: autenticações NTLM (4624 / Authentication Package: NTLM), 4648 (logon usando credenciais explícitas), 4776 (validação de credenciais), e conexões SMB inesperadas do usuário. PCAPs mostrando NTLMSSP flags sem uso de Kerberos também são indicativos.
SMB signing resolve tudo?
É uma mitigação crítica porque protege integridade da sessão SMB, dificultando relay. Porém, não resolve relays via HTTP ou outros protocolos que não suportam signing; portanto é parte de uma estratégia, não a solução completa.
Quais políticas de GPO devo priorizar?
‘Network security: Restrict NTLM’ e ‘RequireSecuritySignatures’ são as prioridades. Ative ‘Audit NTLM authentication’ para medir impacto antes de negar tráfego.
Como testar sem quebrar sistemas?
Pilotos em OUs, testes em lab isolado e uso de contas de teste com privilégios mínimos. Documente rollback procedures e mantenha backups de configurações de GPO.
Como mitigar em ambientes OT com equipamentos legados?
Segmentação de rede física, jump hosts gerenciados para manutenção, e compensating controls como IDS passivo e sensores de tráfego. Coordene com engenharia de processo e teste em plantas de simulação.
Quais logs coletar para investigação pós-ataque?
Windows Security logs (4624, 4648, 4625, 4776), Sysmon logs para processos e rede, capturas de tráfego (PCAP), e logs de network devices. Correlacione com timestamps de autenticação.
Existe CVE específico para NTLM relay?
NTLM relay é design flaw/exploitability de protocolo; não há um único CVE que o descreva. No entanto, CVEs em implementações (por exemplo, servidores SMB vulneráveis) podem permitir vetores adicionais.
Posso eliminar NTLM completamente?
Em muitos ambientes modernos o objetivo é eliminar NTLM, mas migração completa exige análise de compatibilidade. Planeje por fases e use bloqueio com lista de exceções enquanto migra aplicativos para Kerberos/TLS.
Quais ferramentas de detecção automatizada existem?
Ferramentas como Microsoft Defender for Identity, Azure ATP, e soluções EDR com regras de comportamento podem detectar padrões de relay; mas a configuração e tuning são essenciais para reduzir falsos positivos.
Como validar que SMB signing está funcionando?
Testes podem ser feitos via PowerShell e ferramentas smbclient; procure no wireshark por presença do header de signing e verifique GPO aplicada nos hosts com gpresult /r.
Considerações Finais
NTLM relay é problema de configuração, visibilidade e arquitetura, não apenas de software. Defesas eficazes exigem inventário, políticas bem planejadas, testes controlados e instrumentação robusta. Organizações que tratam este tema como item de higiene – inventário, pilot, rollout e monitoramento – reduzirão rapidamente sua exposição. Em ambientes críticos como OT e setores regulados, mitigação sem coordenação operacional pode ser perigosa; trabalhe com engenheiros e aplique compensating controls.
Próximo passo: execute este checklist básico em 7 dias para validar exposição (mensurável): 1) rodar varredura SMB em rede controlada; 2) ativar Audit NTLM em uma OU pilot; 3) executar Responder em lab isolado e documentar resultados; 4) identificar top 10 servidores com NTLM alto e priorizar para SMB signing. Registre antes/depois e envie para o CISO.
Recursos Visuais Sugeridos
Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.
- MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
- CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
- NIST Cybersecurity Framework – figuras oficiais e referências de controles.
- ENISA – relatórios anuais com gráficos e mapas de ameaça.
- Kali Linux – documentação oficial com fluxos práticos.
- Parrot Security – documentação oficial com arquitetura modular.
Referências
- NTLM Authentication and Relay Attacks, Microsoft Docs, 2023, https://learn.microsoft.com/en-us/windows-server/security/
- Responder – LLMNR, NBT-NS and MDNS Poisoning Tool, SpiderLabs (GitHub), 2022, https://github.com/SpiderLabs/Responder
- Impacket – A collection of Python classes for working with network protocols, SecureAuthCorp (GitHub), 2022, https://github.com/SecureAuthCorp/impacket
- ntlmrelayx Usage and Documentation, SecureAuthCorp/Impacket, 2022, https://github.com/SecureAuthCorp/impacket/tree/master/examples/ntlmrelayx
- Microsoft Security Guidance: Configure SMB signing, Microsoft Docs, 2024, https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing
- Mimikatz – Credentials extraction, Benjamin Delpy, 2021, https://github.com/gentilkiwi/mimikatz
- Hardening Windows Authentication for NTLM and Kerberos, Microsoft Security, 2024, https://learn.microsoft.com/en-us/security/
- Detecting NTLM Relay Attacks, SANS Whitepaper, 2023, https://www.sans.org/white-papers/
- Threat Group Reports and NTLM usage patterns, Mandiant, 2024, https://www.mandiant.com/resources
- Network protocol sniffing and analysis (Wireshark), Wireshark Foundation, 2023, https://www.wireshark.org/
- Best practices – Authentication policies and silos, Microsoft Docs, 2024, https://learn.microsoft.com/en-us/windows/security/identity-protection/
- NTLM auditing and logging guide, Microsoft Learn, 2023, https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/
- SMB Security Enhancements and Kerberos usage in enterprise, RFCs and Microsoft literature, 2022, https://datatracker.ietf.org/
- Practical Red Teaming – Relaying attacks and mitigations, Offensive Security blog, 2023, https://www.offensive-security.com/blog/
