# 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*