# T1595.001 - Scanning IP Blocks > [!danger] Técnica Ativa de Reconhecimento > **ID MITRE:** T1595.001 | **Tática:** Reconnaissance | **Plataforma:** PRE > Diferente da maioria das técnicas de reconhecimento passivo, o scanning de blocos IP **gera tráfego ativo** que pode ser detectado por firewalls, IDS/IPS e honeypots. ## Técnica Pai Esta é uma sub-técnica de [[t1595-active-scanning|T1595 - T1595 - Active Scanning]]. ## Descrição O **Scanning de Blocos IP** é uma subtécnica do [[t1595-active-scanning|T1595 - Active Scanning]] onde adversários varrem faixas de endereços IP alocadas a uma organização para mapear a superfície de ataque exposta na internet. Diferentemente do reconhecimento passivo (OSINT), essa técnica envolve o envio ativo de pacotes de rede para sistemas da vítima, o que a torna detectável - mas ainda assim amplamente utilizada por sua eficácia. Blocos de endereços IP são alocados por RIRs (Registros Regionais de Internet) como o **LACNIC** (responsável pela América Latina e Caribe) e podem ser obtidos públicamente via consultas WHOIS, bases de dados BGP, e serviços como Shodan, Censys, e ARIN. A partir de um bloco conhecido, o adversário realiza uma varredura sistemática para identificar quais endereços estão ativos, quais portas estão abertas, quais serviços estão rodando, e qual a versão dos softwares expostos. Esta técnica é especialmente relevante no contexto brasileiro e latino-americano, pois muitas organizações da região ainda operam com serviços legados expostos diretamente na internet, configurações permissivas de firewall, e falta de monitoramento adequado de tráfego de entrada. Grupos como [[g1003-ember-bear|Ember Bear]] (UAC-0056, vinculado à Rússia) utilizaram scanning massivo de blocos IP antes de campanhas destrutivas contra infraestrutura crítica ucraniana - tática aplicável a qualquer contexto geopolítico de alta tensão. Já o [[g0139-teamtnt|TeamTNT]], grupo focado em criptomoeda e cloud, realiza scanning contínuo de blocos IP em busca de credenciais expostas (Docker APIs, Kubernetes, etc.). ## Como Funciona O processo de scanning de blocos IP segue etapas bem definidas, frequentemente automatizadas: **1. Obtenção do bloco IP alvo:** O adversário usa consultas WHOIS (via `whois`, `bgp.he.net`, ou a base do LACNIC para LATAM) para identificar todos os blocos ASN alocados à organização. Uma empresa de médio porte brasileira pode ter 1-5 blocos /24 distintos; um banco de grande porte pode ter dezenas de blocos em múltiplos ASNs. **2. Varredura ICMP (ping sweep):** O primeiro passo é identificar quais IPs estão ativos usando ICMP Echo Requests (ping). Ferramentas como `nmap -sn`, `fping`, ou `masscan` realizam isso em segundos para blocos /24 inteiros. Muitas organizações bloqueiam ICMP, mas isso em si é uma informação útil para o adversário. **3. Port scanning:** Para IPs ativos, o adversário realiza varredura de portas - desde SYN scans furtivos (`nmap -sS`) até varreduras agressivas com detecção de versão (`nmap -sV`). Portas comuns priorizadas: 22 (SSH), 80/443 (HTTP/HTTPS), 3389 (RDP), 445 (SMB), 1433/3306/5432 (bancos de dados), 8080/8443 (aplicações web), 27017 (MongoDB), 6379 (Redis). **4. Banner grabbing e fingerprinting:** A partir das portas abertas, ferramentas como `nmap --script`, `nuclei`, ou `whatweb` identificam versões de software, sistemas operacionais, e tecnologias em uso. Servidores que retornam banners detalhados (Apache 2.4.x, OpenSSH 7.x, etc.) permitem ao adversário cruzar com bancos de CVEs para identificar vulnerabilidades exploráveis. **5. Coleta via ferramentas especializadas:** Serviços como Shodan, Censys, e BinaryEdge mantêm índices permanentemente atualizados de toda a internet. Um adversário pode simplesmente consultar `org:"Empresa Alvo" country:"BR"` no Shodan para obter um mapa completo sem enviar um único pacote para a rede da vítima. Isso representa um scanning de blocos IP **totalmente passivo do ponto de vista da vítima**. **6. Priorização e enriquecimento:** Os resultados são correlacionados com dados de [[t1590-005-ip-addresses|T1590.005 - IP Addresses]] para criar um mapa priorizado de alvos: serviços desatualizados, portas não esperadas abertas, e serviços administrativos expostos (painéis de gestão, interfaces de administração). ## Attack Flow ```mermaid graph TB A["🎯 Definição do Alvo<br/>Organização identificada<br/>para reconhecimento"] --> B["📡 Coleta de ASN/Blocos IP<br/>WHOIS, LACNIC, BGP<br/>bgp.he.net, ARIN"] B --> C["🏓 ICMP Sweep<br/>Ping scan para mapear<br/>IPs ativos no bloco"] B --> D["🔍 Shodan / Censys<br/>Consulta passiva de<br/>bancos de dados OSINT"] C --> E["🔓 Port Scanning<br/>nmap SYN scan<br/>masscan varredura rápida"] D --> E E --> F["🏷️ Banner Grabbing<br/>Identificação de versões<br/>de software e OS"] E --> G["🌐 Web Tech Fingerprint<br/>whatweb, wappalyzer<br/>HTTP headers analysis"] F --> H["📊 Mapa de Superfície<br/>Serviços expostos<br/>versões vulneráveis"] G --> H H --> I["⚠️ CVE Correlation<br/>Cruzamento com NVD<br/>CISA KEV, Exploit-DB"] I --> J["🎯 Alvos Priorizados<br/>Serviços sem patch<br/>configs permissivas"] J --> K["💥 Exploração Inicial<br/>T1190 Exploit Public-Facing<br/>ou T1133 Remote Services"] J --> L["🏗️ Infraestrutura<br/>T1583 Acquire Infrastructure<br/>na mesma região geográfica"] ``` ## Exemplos de Uso ### Ember Bear - Operações contra Infraestrutura Crítica O [[g1003-ember-bear|Ember Bear]] (também conhecido como UAC-0056 ou Lorec53) é um grupo APT atribuído à Rússia, documentado pelo CERT-UA por ataques a organizações governamentais e de infraestrutura crítica. Antes de campanhas de wiper malware (HermeticWiper, WhisperGaté), o grupo realizou scanning extensivo de blocos IP para mapear serviços expostos, identificar VPNs sem patch, e descobrir superfícies de ataque. Esta abordagem de "preparar o terreno" via scanning massivo antes de ataques destrutivos é uma assinatura operacional do grupo. ### TeamTNT - Cryptojacking via Cloud Scanning O [[g0139-teamtnt|TeamTNT]] é especializado em comprometer ambientes cloud e containers para mineração de criptomoedas. O grupo realiza scanning contínuo de blocos IP em busca de: - Docker APIs expostas sem autenticação (porta 2375/2376) - Kubernetes API servers sem RBAC adequado (porta 6443/8443) - Redis sem senha (porta 6379) - Jenkins expostos (porta 8080) - MongoDB sem autenticação (porta 27017) No Brasil, o TeamTNT comprometeu diversas instâncias de cloud de empresas de médio porte, aproveitando a ausência de monitoramento de scanning em Security Groups permissivos de AWS e Azure. ### Caso Prático: Banco Brasileiro Exposto ``` ASN: AS28573 (Claro Brasil) - sub-alocação corporativa Bloco: 200.X.X.0/24 (fictício para exemplo) nmap -sV -p 22,80,443,3389,8080,1433 200.X.X.0/24 Resultado típico encontrado: 200.X.X.45:3389 (RDP aberto - Windows Server 2012 R2) 200.X.X.67:8080 (Apache Tomcat 7.0.68 - CVE-2017-12616) 200.X.X.89:1433 (MSSQL 2014 - sem patch de Agosto/2019) ``` > [!warning] Exposição LATAM > Dados do Shodan mostram que o Brasil tem consistentemente entre os 10 países com maior número de RDPs expostos na internet, com concentração em empresas de médio porte e órgãos públicos municipais/estaduais. ## Detecção O scanning de blocos IP **gera tráfego detectável** nos logs de firewall, IDS/IPS, e sistemas de monitoramento de rede. É uma das técnicas de reconhecimento com **maior superfície de detecção**. ### Sigma Rule - Detecção de Port Scanning ```yaml title: Port Scanning Detected from External Source status: experimental description: > Detecta padrões de port scanning a partir de endereços IP externos, caracterizados por múltiplas conexões recusadas/expiradas em sequência para diferentes portas de um mesmo host de origem. logsource: category: firewall product: paloalto detection: selection_denied: action: deny direction: inbound timeframe: 60s condition: selection_denied | count(dst_port) by src_ip > 20 level: medium tags: - attack.reconnaissance - attack.t1595.001 falsepositives: - Scanners de segurança autorizados (Nessus, Qualys, Rapid7) - Ferramentas de monitoramento de disponibilidade - Testes de penetração internos agendados ``` ### Sigma Rule - Acesso a Serviço Exposto Identificado via Scanning ```yaml title: Access to Previously Scanned Service Port status: experimental description: > Correlaciona scanning prévio com acesso subsequente ao mesmo IP de origem, indicando progressão de reconhecimento para exploração. logsource: category: network_connection product: zeek detection: selection_scan_followed_by_access: community_id|exists: true timeframe: 3600s condition: > (count(dst_port) by src_ip > 10 within 60s) and (new_connection by same src_ip within 3600s) level: high tags: - attack.reconnaissance - attack.t1595.001 - attack.initial_access ``` ### Indicadores de Scanning no Brasil | Fonte de Scanning Comum | Ferramenta | Característica | |------------------------|-----------|----------------| | Masscan | Varredura ultrarrápida de portas | Alta taxa de SYN packets, timing linear | | Shodan crawler | Indexação passiva | User-agent: "Mozilla/5.0 (compatible; Shodan)" | | ZGrab/ZMap | Internet-wide scanning | IPs conhecidos: 216.128.63.0/24 (DigitalOcean) | | Nmap default | Scanning direcionado | Fingerprinting via timing e payloads específicos | | Nuclei | Vulnerability scanning | Payloads HTTP com templates identificáveis | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1056 | [[m1056-pre-compromise\|M1056 - Pre-compromise]] | Redução da superfície de ataque antes do comprometimento: fechar portas desnecessárias, implementar firewall de aplicação, e monitorar exposição via serviços como Shodan/Censys. | ### Controles Técnicos Recomendados > [!tip] Defesa em Profundidade contra IP Scanning > **Redução de superfície:** > - Auditar regularmente portas expostas via Shodan/Censys com a perspectiva do atacante > - Implementar Security Groups/ACLs restritivos em cloud (AWS, Azure, GCP) > - Usar VPN/zero-trust para serviços administrativos (RDP, SSH, painéis de gestão) > - Desabilitar banners de versão em serviços expostos (Apache, Nginx, SSH) > > **Detecção:** > - Configurar alertas em firewall para padrões de scanning (>N conexões recusadas por IP/minuto) > - Implementar honeypots em IPs não utilizados do bloco alocado > - Integrar feeds de IPs de scanners conhecidos (Shodan, Censys, ZMap) para filtragem/alerta > > **Resposta:** > - Política de bloqueio automático de IPs com comportamento de scanning via fail2ban ou NGFW > - Registro de todos os IPs que realizam scanning para correlação futura com tentativas de exploração ## Contexto Brasil/LATAM O Brasil é um dos alvos mais frequentes de scanning massivo de IPs na América Latina, por múltiplos fatores: **LACNIC e exposição regional:** O LACNIC administra os blocos IP da América Latina e Caribe. Dados históricos do LACNIC mostram crescimento consistente de incidentes de scanning na região, com o Brasil representando aproximadamente 40% dos alvos. **Infraestrutura de cloud mal configurada:** Com a aceleração digital pós-2020, muitas empresas brasileiras migraram para cloud sem implementar controles adequados. Relatórios da Tempest e da Apura Cyber Intelligence documentam casos recorrentes de Docker APIs, Redis e MongoDB sem autenticação encontrados em IPs brasileiros por pesquisadores de segurança. **Setor financeiro como alvo prioritário:** O setor financeiro brasileiro (maior mercado bancário da LATAM) é alvo constante de scanning direcionado. O [[_sectors|setor financeiro]] opera com infraestrutura de alto valor e é prioritário para grupos financeiramente motivados. **Grupos ativos na região:** Além do [[g1003-ember-bear|Ember Bear]] e [[g0139-teamtnt|TeamTNT]], grupos como Lapsus$, Prilex (especializado em ATMs brasileiros), e grupos de ransomware como LockBit e ALPHV realizam scanning de blocos IP brasileiros antes de campanhas. **CERT.br e dados de incidentes:** O CERT.br registra anualmente milhões de tentativas de scanning contra redes brasileiras, com scanning de porta 445 (SMB) e 3389 (RDP) sendo os mais frequentes. Em 2024, o CERT.br reportou aumento de 23% em scanning direcionado a infraestrutura crítica. > [!example] Caso Real LATAM - TeamTNT no Brasil > Em 2021-2022, o TeamTNT foi identificado realizando scanning massivo de blocos IP de provedores de cloud brasileiros (AWS São Paulo, Azure Brasil Sul) em busca de Docker APIs expostas. O grupo comprometeu dezenas de instâncias de empresas brasileiras para mineração de Monero, utilizando scanning automatizado de blocos /16 inteiros em menos de 30 minutos com masscan. ## Referências - [MITRE ATT&CK - T1595.001 Scanning IP Blocks](https://attack.mitre.org/techniques/T1595/001/) - [MITRE ATT&CK - T1595 Active Scanning](https://attack.mitre.org/techniques/T1595/) - [[g1003-ember-bear|Ember Bear]] - Grupo documentado usando esta técnica - [[g0139-teamtnt|TeamTNT]] - Grupo especializado em cloud scanning - [[m1056-pre-compromise|M1056 - Pre-compromise]] - Mitigação primária - [[t1590-005-ip-addresses|T1590.005 - IP Addresses]] - Coleta passiva de IPs (técnica complementar) - [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] - Shodan/Censys como alternativa passiva - [[t1190-exploit-public-facing-application|T1190 - Exploit Public-Facing Application]] - Exploração downstream típica - [[t1133-external-remote-services|T1133 - External Remote Services]] - Acesso inicial via serviços identificados - [LACNIC - Estatísticas de Incidentes LATAM](https://www.lacnic.net/cgi-bin/lacnic/Flack) - [CERT.br - Estatísticas de Incidentes 2024](https://www.cert.br/stats/) - [Shodan - Pesquisa de Exposição Brasil](https://www.shodan.io/search?query=country%3ABR) --- *Fonte: [MITRE ATT&CK - T1595.001](https://attack.mitre.org/techniques/T1595/001) | Versão MITRE: 16.2*