t1590-002-dns - RunkIntel

# T1590.002 - DNS ## Técnica Pai Esta é uma sub-técnica de [[t1590-gather-victim-network-information|T1590 - T1590 - Gather Victim Network Information]]. ## Descrição **T1590.002 - DNS** é uma sub-técnica de [[t1590-gather-victim-network-information|T1590 - Gather Victim Network Information]] na qual adversários coletam informações sobre a infraestrutura DNS da organização-alvo para subsidiar planejamento de ataques. Esta técnica opera na fase de **Reconhecimento** e é essencial para o mapeamento completo da superfície de ataque antes de qualquer operação ofensiva. O Sistema de Nomes de Domínio (DNS) é, por natureza, um banco de dados público e distribuído. Registros DNS revelam uma quantidade surpreendente de informações sobre a infraestrutura de uma organização: endereços IP de servidores web, servidores de e-mail, servidores de nomes autoritativos, certificados SSL, provedores de cloud, serviços SaaS utilizados e até configurações de segurança de e-mail (SPF, DKIM, DMARC). Para um adversário, essa é inteligência de altíssimo valor acessível sem interação direta com os sistemas do alvo. Registros DNS a serem coletados incluem: - **A / AAAA**: mapeiam hostnames para endereços IPv4/IPv6 - revelam o range de IPs da organização - **MX (Mail Exchanger)**: revelam o provedor de e-mail (Google Workspace, Microsoft 365, Proofpoint, Mimecast) - **NS (Name Server)**: identificam os servidores DNS autoritativos e o registrador de domínio - **TXT**: contêm registros SPF, DKIM, DMARC e verificações de propriedade de serviços (Google, Azure AD, Zendesk, Salesforce) - **CNAME**: revelam aliases e frequentemente expõem subdomínios de serviços cloud (ex: `app.empresa.com.br CNAME empresa.azurewebsites.net`) - **SRV**: revelam serviços específicos como SIP/VoIP, LDAP, Kerberos e serviços Microsoft internos - **SOA (Start of Authority)**: contém informações sobre o administrador DNS e configurações de zona - **PTR (Reverse DNS)**: permitem descoberta reversa de hostnames a partir de IPs Adversários também exploram **DNS Zone Transfers (AXFR)** - um mecanismo legítimo de replicação entre servidores DNS primário e secundário - quando mal configurado para permitir transferências de qualquer cliente, o que entrega a lista completa de registros da zona em uma única consulta. As informações coletadas permitem outros vetores de ataque: [[t1595-002-vulnerability-scanning|T1595.002 - Vulnerability Scanning]] direcionado aos IPs descobertos, [[t1583-acquire-infrastructure|T1583 - Acquire Infrastructure]] para typosquatting ou lookalike domains, [[t1566-phishing|T1566 - Phishing]] utilizando subdomínios descobertos como pretexto e [[t1133-external-remote-services|T1133 - External Remote Services]] para acesso via serviços remotos identificados. --- ## Como Funciona ### 1. Consultas DNS Públicas Diretas O primeiro método é simplesmente consultar os registros DNS públicos usando ferramentas como `dig`, `nslookup` ou `host`: ```bash # Registros básicos dig empresa.com.br ANY dig empresa.com.br MX dig empresa.com.br TXT dig empresa.com.br NS # Tentativa de zone transfer (AXFR) dig axfr empresa.com.br @ns1.empresa.com.br ``` Ferramentas especializadas como **DNSRecon**, **DNSEnum**, **Fierce** e **Amass** automatizam esse processo para enumerar subdomínios em escala. ### 2. Passive DNS e Bancos de Dados Históricos Serviços de **Passive DNS** armazenam histórico de resoluções DNS coletadas de sensores distribuídos ao redor do mundo. Isso permite que adversários: - Descubram subdomínios que não aparecem mais nos registros ativos mas que ainda podem estar ativos - Identifiquem infraestrutura histórica do alvo (IPs antigos, servidores descontinuados mas ainda acessíveis) - Correlacionem domínios diferentes que apontaram para o mesmo IP (identificando infraestrutura compartilhada) - Detectem mudanças de provedor de e-mail ou migração de cloud Plataformas como **RiskIQ PassiveTotal**, **Farsight DNSDB**, **SecurityTrails** e **VirusTotal** oferecem acesso a bases de Passive DNS. ### 3. Certificaté Transparency (CT Logs) Os logs de transparência de certificados SSL/TLS são uma fonte poderosa de subdomínios. Toda vez que um certificado é emitido para `*.empresa.com.br` ou subdomínios específicos, o registro fica público nos CT logs. Ferramentas como **crt.sh**, **Certspotter** e **Facebook CT Monitor** permitem consultar esses logs: ``` https://crt.sh/?q=%.empresa.com.br ``` ### 4. DNS Brute Force Além dos registros existentes, adversários realizam brute force de subdomínios usando wordlists: - Ferramentas: **Gobuster** (modo DNS), **Amass**, **Sublist3r**, **MassDNS** - Wordlists comuns: `mail`, `webmail`, `vpn`, `remote`, `dev`, `staging`, `api`, `admin`, `portal` - Identificação de **takeover de subdomínio**: subdomínios que apontam para serviços cloud descontinuados (S3, Azure, GitHub Pages, Heroku) que podem ser reclamados por atacantes ### 5. Análise de Registros TXT para Mapeamento de SaaS Registros TXT são particularmente informativos para adversários que planejam ataques de engenharia social ou phishing: - `v=spf1 include:salesforce.com include:mailchimp.com` revela uso de Salesforce CRM e Mailchimp - `MS=ms12345678` indica verificação de domínio com Microsoft/Azure AD - `google-site-verification=...` indica Google Workspace - `atlassian-domain-verification=...` indica Jira/Confluence - `_dmarc TXT v=DMARC1; p=none` indica política DMARC permissiva (e-mail spoofing possível) --- ## Attack Flow ```mermaid graph TB A["Identificação do Domínio Raiz da organização ex: empresa.com.br"] --> B["Consulta de Registros A, AAAA, MX, TXT, NS, SOA Banco de dados público DNS"] B --> C["Tentativa de Zone Transfer AXFR contra NS autoritativos Falha = servidor configurado Sucesso = dump completo da zona"] C --> D["Enumeração de Subdomínios Passive DNS + CT Logs crt.sh / SecurityTrails"] D --> E["Brute Force de Subdomínios Wordlists + MassDNS Amass / Gobuster DNS"] E --> F["Análise de Registros TXT SPF/DKIM/DMARC Mapeamento de SaaS"] F --> G["Correlação e Mapeamento IP ranges identificados Serviços e provedores mapeados"] G --> H["Varredura Direcionada T1595.002 - Vulnerability Scanning Contra IPs descobertos"] G --> I["Infraestrutura para Phishing T1583 - Acquire Infrastructure Lookalike domains / typosquatting"] G --> J["Acesso Remoto T1133 - External Remote Services VPN, RDP, portais web descobertos"] ``` --- ## Exemplos de Uso ### Reconhecimento Pré-Ataque em Organizações Financeiras Brasileiras Investigações de resposta a incidentes em bancos e fintechs brasileiras frequentemente revelam que atacantes realizaram mapeamento extensivo de DNS semanas antes do ataque. O mapeamento revela subdomínios de portais de funcionários, sistemas de home banking, APIs de integração com parceiros (Open Finance) e sistemas legados com baixo nível de segurança. No setor financeiro brasileiro, [[sector-financeiro|a exposição de subdomínios de sistemas legados]] é um vetor recorrente de comprometimento. ### Ataques de Subdomain Takeover O **subdomain takeover** ocorre quando um subdomínio (ex: `app.empresa.com.br`) aponta via CNAME para um serviço cloud (Heroku, Azure, GitHub Pages) que foi descontinuado mas o registro DNS não foi removido. Um atacante pode criar uma conta no serviço e "reclamar" o subdomínio. No Brasil, casos desse tipo foram documentados em empresas de e-commerce e governo, onde subdomain takeovers foram utilizados para hospedar páginas de phishing com URLs legítimas. ### Espionagem via Análise de Registros MX Ao identificar que uma organização usa Microsoft 365 (registro MX `company-br.mail.protection.outlook.com`) versus um serviço local, o adversário ajusta sua estratégia: contra Microsoft 365, pode tentar ataques de password spray, phishing com pretexto de MFA da Microsoft, ou explorar configurações incorretas de políticas Conditional Access. Grupos de espionagem como [[g0016-apt29|APT29]] são conhecidos por adaptar TTPs com base no mapeamento de infraestrutura de e-mail. ### Identificação de DMARC Inexistente ou Permissivo A ausência de registro DMARC ou uma política `p=none` permite que qualquer pessoa envie e-mails aparentando ser do domínio da organização sem rejeição automática. Adversários identificam isso via consulta TXT (`_dmarc.empresa.com.br`) e utilizam em campanhas de [[t1566-phishing|phishing]] e [[t1598-001-spearphishing-service|spearphishing]]. No Brasil, estudos mostram que a maioria das organizações de médio porte ainda não implementou DMARC com política `reject` ou `quarantine`. ### APT e Mapeamento de Infraestrutura Governamental Grupos de espionagem que operam contra governos sul-americanos realizam mapeamento DNS extensivo de domínios `.gov.br`, `.jus.br`, `.leg.br` para identificar portais de acesso remoto, sistemas de e-mail e serviços web vulneráveis. Esse mapeamento precede campanhas de [[t1566-002-spearphishing-link|spearphishing direcionado]] contra servidores públicos. --- ## Detecção A detecção de reconhecimento DNS é intrinsecamente difícil porque as consultas ocorrem contra servidores DNS públicos e não geram tráfego direto contra os sistemas da organização. Entretanto, alguns indicadores são detectáveis: ### Indicadores Detectáveis - **Tentativa de Zone Transfer (AXFR)**: requisições AXFR de IPs externos não autorizados devem gerar alertas imediatos. Todo servidor DNS autoritativo deve registrar e alertar sobre tentativas de AXFR - **Volume anômalo de consultas DNS**: ferramentas de enumeração geram alto volume de consultas (subdomain brute force) que podem ser detectadas em resolvers recursivos da organização - **Consultas a registros incomuns**: consultas AOL ANY ou SOA de IPs externos desconhecidos - **Certificaté Transparency monitoring**: organizações podem monitorar CT logs para detectar quando alguém consulta seus certificados (passivo, sem proteção, mas indica interesse) ### Regra Sigma - Tentativa de Zone Transfer DNS ```yaml title: DNS Zone Transfer Attempt (AXFR) status: experimental description: Detecta tentativas de transferência de zona DNS de fontes não autorizadas logsource: category: dns product: bind detection: selection: EventID: 1 query_type: AXFR filter_legitimate: src_ip|cidr: - '10.0.0.0/8' - '172.16.0.0/12' - '192.168.0.0/16' condition: selection and not filter_legitimate level: high tags: - attack.reconnaissance - attack.t1590.002 falsepositives: - Servidores DNS secundários legítimos que precisam de zone transfer - Ferramentas de monitoramento de DNS autorizadas ``` ### Monitoramento Proativo de CT Logs ```python # Monitorar crt.sh para novos certificados emitidos para o domínio import requests resp = requests.get(f"https://crt.sh/?q=%.empresa.com.br&output=json") # Alertar sobre subdomínios novos não reconhecidos ``` ### Fontes de Dados Recomendadas - **BIND/PowerDNS query logs**: registro de todas as consultas recebidas pelo servidor autoritativo - **Firewall DNS inspection**: análise de tráfego DNS saindo da rede corporativa - **DNS RPZ (Response Policy Zones)**: bloqueio e log de consultas a domínios maliciosos conhecidos - **SIEM com enriquecimento de Passive DNS**: correlação de IPs com histórico de resolução DNS --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1054 | [[m1054-software-configuration\|M1054 - Software Configuration]] | Configurar servidores DNS para restringir Zone Transfers (AXFR) apenas a servidores secundários autorizados via ACL; desabilitar recursão em servidores autoritativos públicos | | - | DMARC, DKIM, SPF | Implementar os três registros de autenticação de e-mail com política DMARC `reject` para prevenir spoofing do domínio; reduz o valor do mapeamento de infraestrutura de e-mail para adversários | | - | Minimização de Registros Públicos | Remover registros DNS de serviços internos que não precisam ser acessados externamente; não expor IPs de sistemas internos via DNS público | | - | Monitoramento de CT Logs | Subscrever alertas de Certificaté Transparency para detectar emissão não autorizada de certificados para subdomínios da organização | | - | Gestão de Subdomínios | Auditar periodicamente registros DNS para identificar e remover CNAMEs apontando para serviços cloud descontinuados (prevenção de subdomain takeover) | | - | Split-Horizon DNS | Implementar DNS split-horizon: servidor DNS interno resolve nomes internos; servidor DNS externo expõe apenas os registros necessários publicamente | --- ## Contexto Brasil/LATAM O Brasil apresenta características específicas que tornam o reconhecimento DNS particularmente relevante para o contexto de ameaças regional: ### Domínios .gov.br e Infraestrutura Pública O registro.br, operado pelo NIC.br, mantém o registro de todos os domínios `.br`. A estrutura de subdomínios governamentais brasileiros - `.gov.br`, `.jus.br`, `.leg.br`, `.mil.br` - é altamente padronizada, o que facilita a enumeração automatizada. Estudos do **CERT.br** revelaram que muitas prefeituras e órgãos municipais possuem configurações DNS inadequadas, incluindo Zone Transfers abertos e subdomínios abandonados. ### DMARC no Brasil Uma análise do ecossistema de e-mail corporativo brasileiro mostra que uma parcela significativa de organizações de médio porte ainda opera sem DMARC ou com política `p=none`, facilitando ataques de spoofing de domínio. O [[sector-financeiro|setor financeiro]] é o mais avançado na adoção, impulsionado por regulações do Banco Central (BACEN) e requisitos de segurança da FEBRABAN. ### Open Finance e APIs DNS Com a implementação do Open Finance no Brasil, as instituições financeiras participantes expõem APIs padronizadas em subdomínios conhecidos (ex: `openfinance.banco.com.br/open-banking/`). Isso cria uma superfície de ataque previsível e mapeável, tornando o reconhecimento DNS especialmente valioso para adversários que miram o setor financeiro brasileiro. ### Recomendações para Organizações Brasileiras - Utilizar o **RDAP do registro.br** para monitorar seu próprio domínio e detectar alterações não autorizadas - Subscrever ao serviço **Alerta.br** do NIC.br para notificações de segurança - Realizar auditorias periódicas de DNS usando ferramentas como **DNSdumpster** e **SecurityTrails** para ver o que adversários podem descobrir sobre sua própria organização - Garantir que todos os domínios `.com.br` da organização possuam registros DMARC com pelo menos `p=quarantine` --- ## Referências - [MITRE ATT&CK - T1590.002](https://attack.mitre.org/techniques/T1590/002/) - [NIC.br - Segurança DNS](https://www.nic.br/segurança/) - [CERT.br - Boas Práticas DNS](https://www.cert.br/docs/whitepapers/dns-security/) - [RFC 5936 - DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936) - [crt.sh - Certificaté Transparency Search](https://crt.sh/) - [SecurityTrails - DNS Intelligence](https://securitytrails.com/) - [OWASP - DNS Subdomain Takeover](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover) - [RFC 7489 - DMARC](https://www.rfc-editor.org/rfc/rfc7489) - [[m1054-software-configuration|M1054 - Software Configuration]] - [[t1595-002-vulnerability-scanning|T1595.002 - Vulnerability Scanning]] - [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] - [[t1583-acquire-infrastructure|T1583 - Acquire Infrastructure]]