Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
DNS-Poisoning-Triage-Lab — Triagem forense de envenenamento de cache DNS em hardware legado. Inclui análise de PCAP de injeções de registros não solicitados de 839 bytes, mapeamento CVE-2025-40778 e remediação via Unbound (DoT) endurecido no Arch Linux. | Kitploit
Ferramentas/GitHubGitHub/nicholasc03/dns-poisoning-triage-lab
Sniffing e Análise de PacotesAnálise de VulnerabilidadesForensia de RedeAnálise ForenseInteligência de AmeaçasAprendizado e EducaçãoResposta a IncidentesAnálise de DNSLabs e Prática
GitHubnicholasc03/dns-poisoning-triage-lab

DNS-Poisoning-Triage-Lab

Triagem forense de envenenamento de cache DNS em hardware legado. Inclui análise de PCAP de injeções de registros não solicitados de 839 bytes, mapeamento CVE-2025-40778 e remediação via Unbound (DoT) endurecido no Arch Linux.

Ver RepositórioSite
16há 2 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Laboratório de Triagem de Tráfego DNS e ARP

Um exercício educacional de análise de pacotes e fortalecimento de resolvedor realizado em uma estação de trabalho Arch Linux.

Escopo: Este repositório é um projeto de aprendizado. A captura incluída é útil para praticar inspeção de DNS e ARP, mas não prova, por si só, um ataque de envenenamento de cache ativo, hardware malicioso, exploração de uma CVE específica ou uma conexão causal com uma métrica de roteamento do NetworkManager.

Por que revisei este projeto

Meu primeiro relatório tratou várias observações como causas confirmadas. Isso foi excessivo. Um quadro DNS de 839 bytes não é automaticamente malformado ou malicioso, e DNS-over-TLS protege o tráfego DNS para o resolvedor upstream configurado—ele não impede spoofing ARP ou todos os ataques de Camada 2/3.

A versão revisada mantém as partes úteis do laboratório enquanto separa:

  1. o que os dados fornecidos mostram;
  2. o que eu inicialmente suspeitei;
  3. o que exigiria mais evidências;
  4. o que a configuração do resolvedor realmente altera.

Essa distinção faz parte de um bom trabalho de incidente. É melhor restringir uma conclusão do que afirmar mais do que as evidências suportam.

Objetivos do laboratório

  • Inspecionar tráfego DNS e ARP com Wireshark e tshark.
  • Comparar resultados do resolvedor local com um resolvedor público conhecido sem rotular erroneamente DNS em texto simples como criptografado.
  • Configurar o Unbound para encaminhar consultas DNS upstream sobre TLS autenticado.
  • Documentar limitações e explicações alternativas.
  • Produzir etapas que outra pessoa possa repetir.
  • Ambiente

    • Estação de trabalho Arch Linux
    • Wireshark / tshark
    • BIND dig
    • Resolvedor local Unbound
    • Resolvedores upstream Cloudflare e Quad9 via TCP/853

    Versões exatas dos pacotes devem ser registradas quando o laboratório for reexecutado. O repositório atual não contém metadados de versão suficientes para atribuir o tráfego a uma vulnerabilidade de produto.

    Evidências fornecidas

    CaminhoPropósito
    evidence/incident_triage_snippet.pcapAmostra pequena de captura de pacotes usada para inspeção DNS/ARP
    evidence/wireshark_anomoly.pngNome de arquivo de captura de tela legado mantido para histórico do repositório; anomaly é a grafia correta
    reports/ANALYSIS.mdRevisão baseada em evidências e limitações
    scripts/checkdns.shCompara a saída do resolvedor e rotula claramente o transporte
    configs/unbound.confExemplo de configuração de encaminhamento do Unbound usando DNS-over-TLS
    logs/remediation_validation.txtExemplo de saída de validação com conclusões corrigidas
    CVE_RESEARCH.mdExplica por que as evidências disponíveis não suportam uma atribuição de CVE

    Reproduzir a revisão

    1. Registre a integridade do arquivo

    root@kitploit:~
    sha256sum evidence/incident_triage_snippet.pcap
    capinfos evidence/incident_triage_snippet.pcap
    

    Salve o hash e os metadados da captura com suas anotações. Não chame a captura de “evidência completa de incidente”; é um trecho.

    2. Revise o tráfego ARP

    root@kitploit:~
    tshark -r evidence/incident_triage_snippet.pcap -Y arp \
      -T fields -e frame.number -e frame.time_relative \
      -e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
      -e arp.dst.proto_ipv4 -e arp.dst.hw_mac
    

    Procure por alegações repetidas ou conflitantes de IP para MAC. Um conflito é uma pista para investigar, não prova automática de um atacante. Verifique se os endereços são valores sintéticos de laboratório, se um dispositivo mudou legitimamente e se o tempo suporta a hipótese.

    3. Revise o tráfego DNS

    root@kitploit:~
    tshark -r evidence/incident_triage_snippet.pcap -Y dns \
      -T fields -e frame.number -e frame.time_relative \
      -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
      -e dns.id -e dns.flags.response -e dns.qry.name \
      -e dns.count.answers -e frame.len
    

    Filtros úteis de acompanhamento:

    root@kitploit:~
    dns && frame.len == 839
    dns.flags.response == 1
    dns.qry.name == "."
    arp.duplicate-address-detected || arp.duplicate-address-frame
    

    O tamanho do pacote por si só não é um veredito. Os tamanhos das respostas DNS podem variar devido à contagem de registros, EDNS, DNSSEC e comportamento de transporte. Inspecione os registros decodificados e compare-os com uma linha de base conhecida como boa.

    4. Compare resolvedores

    root@kitploit:~
    chmod +x scripts/checkdns.sh
    ./scripts/checkdns.sh example.com
    

    O script rotula corretamente uma consulta direta dig @1.1.1.1 como DNS em texto simples na porta 53. Quando kdig está disponível, ele também realiza um teste TLS separado.

    5. Valide o encaminhamento do Unbound

    Revise configs/unbound.conf, adapte os caminhos dos certificados para o sistema local e valide antes do uso:

    root@kitploit:~
    sudo unbound-checkconf configs/unbound.conf
    sudo ss -tnp | grep ':853'
    dig @127.0.0.1 example.com
    

    Uma consulta bem-sucedida mais uma conexão estabelecida com TCP/853 suporta a conclusão mais restrita de que o Unbound está encaminhando para o upstream configurado via TLS. Isso não prova que um problema não relacionado de ARP ou roteamento foi eliminado.

    Descobertas e limitações

    • A captura pode ser usada para identificar quadros DNS e ARP e praticar uma revisão estruturada.
    • Um quadro DNS de 839 bytes é uma observação, não um indicador de comprometimento por si só.
    • As evidências atuais não identificam um resolvedor BIND 9 vulnerável ou versão afetada, então CVE-2025-40778 é pesquisa de contexto em vez de uma atribuição de incidente.
    • DNS-over-TLS autenticado melhora a confidencialidade e integridade entre este resolvedor e seu upstream. Ele não protege toda a rede local.
    • Uma atribuição forte exigiria proveniência completa da captura, inventários de dispositivos, evidências de resolvedor/versão, referências de número de pacote, carimbos de data/hora e testes repetíveis de antes/depois.

    Referências

    • RFC 7858 — DNS sobre TLS
    • RFC 8310 — Perfis de Uso de Privacidade DNS
    • Aviso ISC para CVE-2025-40778
    • Referência de filtro de exibição do Wireshark

    Aviso legal e de privacidade

    Use ferramentas de captura de pacotes e teste de rede apenas em sistemas e redes que você possui ou está autorizado a testar. Revise capturas em busca de endereços privados, nomes de host, tokens, credenciais e informações pessoais antes de publicá-las.

    Baixar ferramenta