# T1596.004 - CDNs ## Descrição **CDNs** (Content Delivery Networks - Redes de Entrega de Conteúdo) é uma sub-técnica da tática de [[t1596-search-open-technical-databases|Busca em Bancos de Dados Técnicos Abertos]] (T1596) na qual adversários coletam e analisam dados de CDNs sobre infraestrutura de organizações alvo para uso em operações subsequentes. CDNs são serviços distribuídos globalmente - como Cloudflare, Akamai, Fastly, Amazon CloudFront e Azure CDN - que intermediam a entrega de conteúdo web entre servidores de origem e usuários finais, otimizando desempenho e disponibilidade. A coleta de informações sobre CDNs em uso por um alvo é particularmente valiosa para adversários porque: (1) CDNs frequentemente obscurecem os endereços IP reais dos servidores de origem - e contornar essa proteção revela infraestrutura crítica; (2) configurações incorretas de CDN podem expor conteúdo sensível não destinado a ser hospedado públicamente, como arquivos de staging, backups ou APIs internas; (3) CDNs que não implementam corretamente controles de acesso (como autenticação em nível de CDN) permitem acesso direto ao servidor de origem contornando proteções de WAF e limitação de taxa configuradas na camada CDN. Adversários utilizam ferramentas de lookup DNS, análise de histórico de DNS passivo (Passive DNS), consultas a plataformas de inteligência como Shodan, Censys e SecurityTrails, além de técnicas de descoberta de IP de origem como análise de registros MX, análise de cabeçalhos de e-mail, consultas a subdomínios não roteados via CDN e verificação de certificados TLS históricos. Misconfigurations como **CDN Origin Exposure** (acesso direto ao IP de origem via porta 80/443) e **CDN Subdomain Takeover** (subdomínios apontando para recursos CDN expirados) são vetores especialmente explorados. As informações obtidas habilitam outras formas de reconhecimento como [[t1595-active-scanning|Varredura Ativa]] (T1595) e [[Domínios Abertos]] (T1593), bem como o estabelecimento de recursos operacionais por meio de [[t1583-acquire-infrastructure|Aquisição de Infraestrutura]] (T1583) ou [[t1584-compromise-infrastructure|Comprometimento de Infraestrutura]] (T1584), e podem diretamente viabilizar acesso inicial via [[t1189-drive-by-compromise|Drive-by Compromise]] (T1189) ou exploração de aplicações. > **Técnica pai:** [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] > **Tática MITRE:** Reconnaissance > **Plataforma:** PRE (pré-comprometimento) --- ## Como Funciona ### Identificação do CDN em Uso O primeiro passo é determinar qual CDN protege o alvo. Isso é feito via análise de cabeçalhos HTTP e resolução DNS: ```bash # Análise de cabeçalhos HTTP - revela o CDN em uso curl -I https://www.empresa-alvo.com.br # Exemplos de cabeçalhos identificadores: # Cloudflare: "CF-RAY:", "cf-cache-status:", "Server: cloudflare" # Akamai: "X-Check-Cacheable:", "X-Akamai-Transformed:" # Amazon CloudFront: "X-Cache: Hit from cloudfront", "Via: 1.1 xxx.cloudfront.net" # Fastly: "X-Fastly-Request-ID:", "X-Served-By:" # Azure CDN: "X-Azure-Ref:", "X-Cache: TCP_HIT" ``` ### Descoberta do IP de Origem (Origin IP Bypass) O principal objetivo na análise de CDN é descobrir o endereço IP real do servidor de origem, contornando a proteção do CDN. Técnicas comuns incluem: **Análise de histórico DNS:** Antes de mover para um CDN, a organização apontava o domínio diretamente para o servidor de origem. Plataformas de Passive DNS registram esse histórico: ```bash # SecurityTrails - histórico DNS curl "https://api.securitytrails.com/v1/history/{dominio}/dns/a" \ -H "apikey: {API_KEY}" # VirusTotal - histórico de resoluções DNS https://www.virustotal.com/gui/domain/empresa-alvo.com.br/relations ``` **Análise de registros MX e SPF:** Servidores de e-mail frequentemente não são roteados via CDN e revelam faixas de IP reais da organização: ```bash # MX records - IP real do servidor de e-mail dig MX empresa-alvo.com.br +short # SPF TXT record - revela IPs autorizados a enviar e-mail dig TXT empresa-alvo.com.br +short | grep "v=spf1" ``` **Análise de cabeçalhos de e-mail:** E-mails enviados diretamente pelo servidor de origem (notificações, newsletters) contêm o IP real no cabeçalho `Received:`. **Subdomínios não protegidos por CDN:** Frequentemente, subdomínios como `mail.`, `ftp.`, `vpn.`, `admin.`, `dev.` ou `api.` são configurados sem a proteção do CDN e revelam o range de IP real: ```bash # Enumeração de subdomínios via amass amass enum -d empresa-alvo.com.br -o subdomains.txt # Resolução dos subdomínios encontrados cat subdomains.txt | xargs -I{} dig {} +short ``` ### Identificação de Misconfigurações de CDN **Subdomain Takeover via CDN:** Quando uma organização remove um recurso de CDN mas não remove o registro DNS CNAME apontando para ele, um atacante pode registrar esse recurso no CDN e assumir o subdomínio: ```bash # Verificar se CNAME aponta para recurso inexistente dig CNAME app.empresa-alvo.com.br +short # Resultado: empresa-alvo.azurewebsites.net # Verificar se o Azure Web App ainda existe curl -I https://empresa-alvo.azurewebsites.net # HTTP 404 Not Found - recurso removido, subdomínio takeover possível ``` **Conteúdo Sensível Exposto via CDN:** Buckets S3 ou Azure Blob Storage servidos por CloudFront ou Azure CDN sem autenticação adequada podem expor backups, dumps de banco de dados e arquivos de configuração indexados publicamente. --- ## Attack Flow ```mermaid graph TB A["Identificação do Alvo<br/>(domínio, organização)"] --> B["Detecção do CDN em Uso<br/>(cabeçalhos HTTP, DNS)"] B --> C["Mapeamento de Subdomínios<br/>(amass, subfinder, crt.sh)"] B --> D["Análise de Histórico DNS<br/>(SecurityTrails, PassiveDNS)"] C --> E["Subdomínios Fora do CDN<br/>(mail, vpn, dev, api)"] D --> F["IPs Históricos<br/>(antes da migração para CDN)"] E --> G["Resolução de IPs Reais<br/>(origem do servidor)"] F --> G G --> H{"Servidor de Origem<br/>Encontrado?"} H -->|Sim| I["Acesso Direto à Origem<br/>(bypass de WAF/CDN)"] H -->|Não| J["Análise de Misconfigurações<br/>(subdomain takeover, conteúdo exposto)"] I --> K["Varredura de Vulnerabilidades<br/>(T1595 contra IP real)"] J --> L["Subdomain Takeover<br/>ou Conteúdo Sensível"] K --> M["Exploração<br/>(T1190, T1189)"] L --> M M --> N["Acesso Inicial ou<br/>Intelligence para Próximas Fases"] ``` --- ## Exemplos de Uso ### Operações de Red Team - Bypass de Cloudflare Em engajamentos de red team documentados publicamente, a descoberta do IP de origem de servidores protegidos por Cloudflare é uma das primeiras atividades realizadas. A técnica mais eficaz é a consulta ao histórico DNS: organizações que migraram para o Cloudflare frequentemente tiveram o IP de origem exposto por meses ou anos antes da migração, e esse dado permanece disponível em bancos de dados de Passive DNS por tempo indefinido. A ferramenta **CloudFail** (descontinuada mas amplamente documentada) e seu sucessor **CloudUnflare** automatizavam a busca em múltiplas fontes (CrimeFlare, Shodan, histórico DNS, cabeçalhos de e-mail) para descobrir o IP real de servidores Cloudflare. Ferramentas modernas como **Censys** e **Shodan** permitem buscas por certificados TLS associados ao domínio alvo, frequentemente retornando o IP de origem quando o certificado foi emitido antes da migração para CDN. ### Subdomain Takeover - Casos Documentados O **Subdomain Takeover** via CDN é uma vulnerabilidade prevalente. Casos documentados incluem: - **Microsoft Azure CDN:** Organizações que removem Azure Web Apps ou Azure Static Websites mas mantêm CNAME `*.azurewebsites.net` ou `*.z13.web.core.windows.net` ficam vulneráveis. Um atacante pode registrar o recurso deletado e assumir o subdomínio para hospedar phishing com URL legítima da organização alvo. - **Amazon CloudFront/S3:** CNAMEs apontando para buckets S3 deletados ou distribuições CloudFront desativadas são alvos frequentes. O serviço **can-i-take-over-xyz** (GitHub) mantém lista atualizada de provedores vulneráveis a subdomain takeover. ### Cenários Específicos - Setor Financeiro Brasileiro Organizações financeiras brasileiras reguladas pelo Banco Central utilizam CDNs extensivamente para proteger portais de internet banking e APIs do Open Finance. No entanto, sistemas legados de backoffice, APIs de integração B2B e ambientes de homologação frequentemente não são roteados via CDN - expondo IPs de servidores que compartilham infraestrutura com sistemas críticos. Grupos de ameaça focados no Brasil, como os que operam o [[grandoreiro-banking-trojan|Grandoreiro]] e outros trojans bancários LATAM, utilizam informações de CDN para identificar provedores de hospedagem de portais de phishing convincentes - optando por CDNs que tornam rastreamento de origem mais difícil. ### Ferramentas Utilizadas para Coleta CDN | Ferramenta | Finalidade | Disponibilidade | |------------|------------|----------------| | Shodan | Busca por certificados e banners de serviço | Pública (plano gratuito limitado) | | Censys | Análise de certificados TLS e IPv4 scanning | Pública (plano gratuito) | | SecurityTrails | Histórico DNS e WHOIS | Pública (API key gratuita) | | crt.sh | Busca em Certificaté Transparency | Pública (gratuita) | | amass (OWASP) | Enumeração de subdomínios | Open source | | subfinder (ProjectDiscovery) | Descoberta passiva de subdomínios | Open source | --- ## Detecção A detecção de coleta CDN é complexa porque as atividades ocorrem majoritariamente em sistemas externos (Shodan, SecurityTrails, histórico DNS). A detecção viável foca em tentativas de acesso direto ao IP de origem identificado e em consultas anômalas ao próprio servidor. ### Regra Sigma - Acesso Direto ao IP de Origem (Bypass CDN) ```yaml title: "CDN Reconnaissance - Acesso Direto ao IP de Origem" status: experimental description: | Detecta tentativas de acesso HTTP/HTTPS direto ao IP do servidor de origem que deveriam chegar apenas via CDN. Requisições com cabeçalho Host correto mas originadas de IPs fora dos ranges do CDN indicam bypass intencional. logsource: category: webserver service: access_log detection: selection: request_headers_host: "empresa-alvo.com.br" filter_cdn_cloudflare: src_ip|cidr: - "173.245.48.0/20" - "103.21.244.0/22" - "103.22.200.0/22" - "103.31.4.0/22" - "141.101.64.0/18" condition: selection and not filter_cdn_cloudflare level: high tags: - attack.reconnaissance - attack.t1596.004 falsepositives: - Monitoramento interno de saúde do servidor - Ferramentas de observabilidade internas ``` ### Regra Sigma - Tentativas de Subdomain Takeover ```yaml title: "CDN Reconnaissance - Possível Subdomain Takeover" status: experimental description: | Detecta respostas de CDN indicando recurso não encontrado para subdomínios da organização, o que pode indicar candidatos a subdomain takeover. Monitorar periodicamente via DNS lookup externo. logsource: category: network service: dns detection: selection: query_name|endswith: - ".azurewebsites.net" - ".cloudfront.net" - ".fastly.net" - ".azureedge.net" response_code: "NXDOMAIN" condition: selection level: medium tags: - attack.reconnaissance - attack.t1596.004 - attack.t1584 falsepositives: - Recursos CDN removidos legitimamente sem remoção do CNAME ``` ### Indicadores de Comprometimento Comportamentais | Indicador | Descrição | Severidade | |-----------|-----------|-----------| | Acesso HTTP ao IP de origem com Host header correto | Bypass de CDN deliberado | Alta | | Requisições de ranges de IP Shodan/Censys | Scanning automatizado de infraestrutura | Média | | Múltiplos subdomínios testados em curto intervalo | Enumeração automatizada | Alta | | User-Agent de ferramenta de recon | `amass`, `subfinder`, `masscan` nos logs | Alta | | CNAME para recurso CDN deletado | Candidato a subdomain takeover | Crítica | --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1056-pre-compromise\|M1056]] | Pre-compromise | Implementar controles para reduzir a exposição de infraestrutura CDN. Configurar firewall de origem para aceitar tráfego exclusivamente dos IPs do CDN. Remover registros DNS CNAME obsoletos que apontam para recursos CDN desativados. Auditar periodicamente subdomínios para identificar candidatos a subdomain takeover. Usar IP allowlist no servidor de origem para bloquear acesso direto de qualquer IP fora dos ranges oficiais do CDN. | ### Controles Preventivos Adicionais 1. **Proteção de IP de Origem:** Configurar security groups (AWS), NSGs (Azure) ou firewall rules para aceitar tráfego nas portas 80/443 exclusivamente dos ranges IP publicados pelo provedor CDN. Provedores como Cloudflare publicam suas faixas IP em `https://www.cloudflare.com/ips/`. 2. **Autenticação de Origem:** Usar tokens de autenticação compartilhados (Cloudflare Authenticated Origin Pulls, Akamai SureRoute) que impedem que requisições não originadas do CDN sejam processadas pelo servidor de origem. 3. **Auditoria de DNS Periódica:** Implementar processo automatizado de auditoria quinzenal de todos os registros DNS para identificar CNAMEs apontando para recursos inexistentes. Ferramentas como **subjack** e **can-i-take-over-xyz** automatizam essa verificação. 4. **Certificaté Transparency Monitoring:** Assinar alertas no crt.sh e ferramentas similares para ser notificado quando novos certificados TLS são emitidos para subdomínios da organização - pode indicar subdomain takeover bem-sucedido. 5. **Segmentação de Ambiente:** Manter ambientes de desenvolvimento, homologação e produção em domínios completamente separados (não subdomínios), preferencialmente em provedores de nuvem distintos, para evitar que a descoberta de IPs de staging revele infraestrutura de produção. 6. **Política de Descomissionamento:** Criar procedimento formal que inclua remoção de registros DNS antes ou durante o descomissionamento de qualquer recurso CDN, prevenindo a jánela de vulnerabilidade de subdomain takeover. --- ## Contexto Brasil/LATAM O uso de CDNs no Brasil tem crescido exponencialmente com a expansão do e-commerce, fintechs e serviços digitais governamentais. A Cloudflare é o provedor dominante para organizações de médio porte; Akamai e AWS CloudFront são prevalentes em grandes corporações e no setor financeiro. ### Características do Ecossistema CDN Brasileiro **Regulação do Open Finance:** O Banco Central do Brasil exige que instituições participantes do Open Finance exponham APIs em domínios específicos (`openbanking.{banco}.com.br`). Essas APIs devem estar disponíveis públicamente, o que as torna alvos de enumeração e análise CDN para identificar a infraestrutura subjacente de APIs financeiras críticas. **Infraestrutura Governamental:** Portais governamentais brasileiros como gov.br, Receita Federal, INSS e sistemas de licitação pública utilizam CDNs com configurações variadas. Documentos governamentais sensíveis hospedados em buckets S3 ou Azure Blob servidos por CloudFront/Azure CDN sem autenticação adequada têm sido alvo de divulgação não intencional. **Setor de Telecomúnicações:** Operadoras como Claro, Vivo e TIM utilizam CDNs para portais de autoatendimento e APIs de integração. A descoberta de IPs de origem dessas APIs pode revelar infraestrutura de sistemas de billing e CRM críticos. ### Vetores de Ataque Relevantes para LATAM **Phishing com Subdomain Takeover:** A combinação de subdomain takeover em subdomínios de organizações confiáveis (bancos, governo) com campanhas de phishing regionalizadas é particularmente eficaz no Brasil, onde a familiaridade com domínios `.gov.br` e `.com.br` de instituições conhecidas gera alto nível de confiança nas vítimas. **Exposição de APIs Open Finance:** Misconfigurações em CDNs que servem APIs do Open Finance podem expor dados de clientes sem os controles de segurança esperados. A coleta de informações sobre CDNs em uso por participantes do Open Finance pode revelar onde aplicar [[t1595-active-scanning|varredura ativa]] (T1595) para identificar essas misconfigurações. **Ataques de Drive-by via CDN Comprometida:** Se uma organização usa um CDN compartilhado que é comprometido (supply chain do CDN), conteúdo malicioso pode ser injetado em todos os sites aténdidos por esse CDN - técnica relacionada a [[t1189-drive-by-compromise|Drive-by Compromise]] (T1189). A coleta prévia de informações sobre quais organizações usam qual CDN permite priorizar alvos caso o CDN sejá comprometido. ### Incidentes Notáveis Relacionados Múltiplos incidentes documentados no Brasil envolveram exposição inadvertida de dados via misconfigurações de CDN e armazenamento em nuvem: - Vazamentos de dados de saúde (LGPD) via buckets S3 sem autenticação servidos por CloudFront - Exposição de backups de sistemas de prefeituras via Azure Blob sem controle de acesso - Subdomínios de grandes varejistas disponíveis para takeover após migrações de plataforma Esses incidentes sublinham a importância de auditorias regulares de configuração CDN e monitoramento de Certificaté Transparency para detecção precoce. --- ## Referências - [MITRE ATT&CK - T1596.004](https://attack.mitre.org/techniques/T1596/004) - [Cloudflare - IP Ranges](https://www.cloudflare.com/ips/) - [crt.sh - Certificaté Transparency](https://crt.sh/) - [SecurityTrails - Passive DNS](https://securitytrails.com/) - [ProjectDiscovery - Subfinder](https://github.com/projectdiscovery/subfinder) - [can-i-take-over-xyz - Subdomain Takeover Reference](https://github.com/EdOverflow/can-i-take-over-xyz) - [Shodan](https://www.shodan.io/) - [Banco Central do Brasil - Open Finance](https://openfinancebrasil.org.br/) - [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] - [[t1595-active-scanning|T1595 - Active Scanning]] - [[t1583-001-domains|Domains]] - [[t1583-acquire-infrastructure|T1583 - Acquire Infrastructure]] - [[t1584-compromise-infrastructure|T1584 - Compromise Infrastructure]] - [[t1189-drive-by-compromise|T1189 - Drive-by Compromise]] - [[m1056-pre-compromise|M1056 - Pre-compromise]]