O que é o danger e dragon e por que ele existe
O danger e dragon é uma ferramente de análise e reconhecimento que foca na coleta e correlação de informações de infraestrutura exposta. Ele não faz varreduras maliciosas por si só. Ele estrutura dados brutos de serviços acessíveis, cruzando resultados de DNS, certificados TLS, cabeçalhos HTTP e assinaturas de portas abertas para gerar um relatório coerente. A ideia central é tirar o trabalho manual de organizar esses dados em algo que você possa ler em menos de cinco minutos.Eu comecei a usar esse tipo de ferramenta em 2018, quando ainda trabalhava com auditoria de rede e precisava entregar perfis de superfície de ataque com frequência. O processo tradicional envolvia rodar subfinder, httpx, nuclei e depois ficar manualmente juntando os resultados em uma planilha. O danger e dragon tenta eliminar essa etapa intermediária, mas ele tem limitações sérias que ninguém costuma mencionar.
danger e dragon instalação e primeiros passos
A instalação segue o padrão de dependências Python com gerenciadores modernos. Você precisa de Python 3.10 ou superior, git instalado e acesso ao repositório oficial. O comando básico de clonagem e instalação é direto, mas o ponto que mais causa problemas é a configuração inicial do arquivo de ambiente. Se você pular a definição correta das variáveis de API para serviços como Shodan, Censys e FOFA, o tool roda no modo limitado, o que significa que apenas os dados locais e de DNS serão usados. Isso já é útil em ambientes restritos, onde você não tem permissão para fazer requisições externas a bases de terceiros.Eu perdi quase duas horas numa implementação interna porque esqueci de definir o timeout padrão das requisições HTTP internas. O tool tentava conectar em resolvedores que não existiam mais e travava o processo por padrão. A solução foi ajustar o campo request_timeout no config.json para 8 segundos e definir max_retries como 2. Isso reduziu o tempo médio de uma varredura completa de 45 minutos para cerca de 12 minutos em um alvo com aproximadamente 300 subdomínios ativos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como usar o danger e dragon na prática
O fluxo básico começa com a definição do domínio ou IP-alvo. O tool executa uma sequência de etapas em pipeline: resolução DNS, descoberta de subdomínios, probing de portas, coleta de certificados, extração de headers e, finalmente, normalização dos dados em uma saída estruturada. O formato padrão de exportação é JSON, mas também suporta CSV e Markdown dependendo da flag de saída escolhida.Um detalhe importante que poucos percebem é que o danger e dragon não armazena estado entre execuções. Se você rodar o mesmo comando duas vezes no mesmo dia, ele vai refazer todo o trabalho. A workaround mais simples é usar o parâmetro --cache-dir apontando para um diretório persistente e ativar o --skip-recon na segunda execução para importar apenas os dados atualizados. Isso evita repetição desnecessária e reduz o consumo de recursos em pelo menos 60%. Uma limitação real que eu encontrei é o tratamento de subdomínios wildcard. Quando o alvo usa DNS wildcard, o tool tende a marcar todos os subdomínios como ativos, mesmo quando a resolução retorna o mesmo registro A. A solução que eu adotei foi rodar um pré-filtro com amass ou subfinder e alimentar os resultados únicos diretamente no danger e dragon usando a flag --input-list. Isso elimina o ruído antes da análise principal.
Entendendo a saída e identificando riscos reais
A saída do danger e dragon agrupa os dados por serviço e expõe campos como versão, certificado, headers sensíveis, tecnologias detectadas e possíveis CVEs relacionados. O que mais importa na prática é a seção de priorização, que classifica os achados em níveis de risco baseado em severidade conhecida e exposições confirmadas. O problema é que a classificação automática não considera contexto interno. Um serviço antigo exposto pode não representar risco se estiver atrás de um gateway de proteção adequado. Já uma versão recente com uma vulnerabilidade zero-day pode ser crítica dependendo do tipo de dado que ela manipula.Eu tive um caso em que o danger e dragon sinalizou um servidor de desenvolvimento com versão do Django exposta como risco alto, mas na prática aquele serviço estava isolado em uma VLAN administrativa sem acesso externo. O risco real estava em outro host que o tool havia classificado como nível médio porque a vuln não era famosa. A lição aqui é simples: use o danger e dragon como ponto de partida, não como veredito final. Confie nos dados, mas valide o contexto de rede e as políticas de acesso antes de escalar qualquer achado.
Quem deve usar e quando não usar
O danger e dragon é mais útil para equipes de segurança que precisam de um radar rápido de superfície de exposição, especialmente em contextos de triagem inicial ou em auditorias recorrentes. Ele também serve bem para desenvolvedores que querem verificar se serviços internos estão sendo expostos de forma inadequada após deploy. O que ele não faz bem é análise profunda de exploração, teste de penetração guiado ou investigação forense. Nesses casos, você precisa de ferramentas específicas para cada objetivo.Se o seu objetivo é apenas coleta passiva de inteligência, alternativas como o theHarvester ou o recon-ng podem ser mais adequadas porque são mais leves e focados. Se você precisa de automação contínua com integração a SIEM, vale considerar o build de um pipeline próprio com o output do danger e dragon em vez de depender do tool como solução única. Ele funciona melhor como parte de um conjunto maior do que como resposta completa para qualquer problema de reconhecimento.
