A FortiGuard Labs contabilizou 249,3 bilhões de tentativas de ataque e atividade cibernética maliciosa contra alvos no Brasil no primeiro semestre de 2026. O número que realmente muda decisão de segurança, porém, está dentro desse total: 9 bilhões de varreduras ativas em seis meses, volume 44% maior que o registrado em todo o ano de 2025. O que mais cresceu não foi a fase de ataque. Foi a fase que vem antes dela.
A fase mais barata da cadeia é a que mais cresce
Varredura ativa é a técnica T1595 do MITRE ATT&CK, dentro da tática Reconnaissance (TA0043). É o momento em que o atacante ainda não tem alvo, só tem método: varrer faixas de IP (T1595.001), procurar versões vulneráveis (T1595.002) e testar caminhos conhecidos por wordlist (T1595.003). O resto do relatório da Fortinet acompanha a mesma curva. Malware saltou de 187,5 milhões de ocorrências em todo o ano de 2025 para 406,8 milhões só no primeiro semestre de 2026, trojans triplicaram de 32 milhões para 100 milhões, cryptominer chegou a 69 mil ocorrências superando o ano anterior inteiro, e foram 6.932 incidentes de ransomware. Mas o crescimento do reconhecimento é o indicador que aparece primeiro, porque ele acontece semanas ou meses antes do resto.
A consequência prática é uma inversão de lógica que ainda não chegou à maioria das conversas sobre risco. Em campanha de reconhecimento em massa, o alvo não é escolhido, ele é encontrado. Ninguém decidiu atacar a sua empresa: alguém varreu a internet procurando uma versão específica de um produto, e a sua instância respondeu. Porte, setor e relevância de marca não entram nessa conta em nenhum momento.
O reconhecimento que não gera um único pacote no seu servidor
Boa parte do mapeamento moderno é passiva, e por isso invisível para quem só olha o próprio log de acesso. A técnica é a T1596, busca em bases técnicas abertas, e a sub-técnica mais produtiva contra empresa brasileira é a T1596.003, certificados digitais. O motivo é estrutural: desde o RFC 6962, todo certificado TLS de confiança pública é registrado em logs de Certificate Transparency, append-only e auditáveis por qualquer pessoa. Os navegadores exigem essa prova de registro para aceitar o certificado, o que significa que não existe a opção de emitir um certificado público e mantê-lo em segredo.
Emitir certificado para homolog-api.empresa.com.br publica esse hostname para o mundo em segundos. O host pode estar atrás de firewall, sem registro em DNS público e sem link apontando para ele em lugar nenhum. O nome dele já saiu.
# Certificate Transparency lookup via crt.sh.
# No packet ever reaches the target: the data is already public.
curl -s 'https://crt.sh/?q=%25.exemplo.com.br&output=json' \
| jq -r '.[].name_value' \
| sed 's/^\*\.//' \
| tr 'A-Z' 'a-z' \
| sort -u
# Typical output for a real corporate domain:
# api.exemplo.com.br
# homolog-api.exemplo.com.br
# jenkins.exemplo.com.br
# vpn.exemplo.com.br
# webmail-antigo.exemplo.com.brO que costuma aparecer nessa consulta em uma empresa de porte médio é sempre da mesma família: ambiente de homologação, painel de administração antigo, concentrador de VPN, servidor de integração contínua, webmail que ninguém desligou. São exatamente os ativos que raramente entram no escopo de um pentest, porque o inventário que alimenta esse escopo costuma vir da memória do time, não de uma consulta ao que já é público.
Fingerprint: como se acha todo mundo que roda o mesmo produto
A segunda metade do reconhecimento não é varrer, é consultar. Bancos de varredura pública (T1596.005) já escanearam o espaço IPv4 inteiro e mantêm o resultado indexado. O atacante não precisa gerar tráfego nenhum, ele faz uma busca. E a busca não é 'porta 443 aberta', é 'esta instalação específica deste produto específico'.
Três impressões digitais sustentam isso. A primeira é o hash de favicon: o Shodan indexa o filtro http.favicon.hash, calculado com MurmurHash3 sobre o conteúdo do ícone em base64, então um produto que serve o próprio favicon padrão fica identificável mesmo com a página de login inteiramente customizada. A segunda é o fingerprint de TLS, exposto no filtro ssl.jarm, que identifica o servidor pela forma como ele responde ao handshake. A terceira é a suíte JA4+ da FoxIO, que estendeu a ideia do JA3 para cliente TLS (JA4), resposta de servidor (JA4S), cliente HTTP (JA4H) e certificado X509 (JA4X), ordenando ciphers e extensões justamente para dificultar as manipulações que quebravam o JA3.
# Favicon hash in the exact format Shodan indexes: MurmurHash3 over the
# base64-encoded icon. Identifies a product behind a fully custom login page.
import codecs
import mmh3
import requests
response = requests.get("https://exemplo.com.br/favicon.ico", timeout=10)
b64 = codecs.encode(response.content, "base64")
print(mmh3.hash(b64))
# With the hash in hand, one query returns every host on the internet
# serving the same icon. No scanning traffic required:
#
# shodan search 'http.favicon.hash:-1234567890'
# shodan search 'ssl.jarm:<tls server fingerprint>'O efeito colateral disso é o que interessa. Quando sai um CVE crítico para o produto X, a lista de instâncias expostas do produto X não precisa ser construída: ela já existe, indexada, a uma consulta de distância. Omitir o nome do produto na página não ajuda, porque o ícone, a pilha TLS e o certificado identificam ele sozinhos.
Da varredura ao exploit, a janela encolheu
Esse é o elo que fecha o raciocínio. Escrevemos aqui em 18 de agosto sobre a CVE-2026-59310, o RCE não autenticado no VMware vCenter: a Broadcom publicou o advisory em 29 de julho de 2026 e, cinco dias depois, já havia exploração em massa, com 361 endereços IP comprometidos em 47 países. Cinco dias não é tempo de um exploit ser desenvolvido, testado e distribuído do zero. É tempo de alguém pegar uma lista de alvos que já existia e passar o exploit nela.
Por isso o prazo prático de patch para produto de borda, ou seja, VPN, hipervisor, servidor de CI/CD e painel de gerência, é contado em dias e não em ciclo de manutenção trimestral. O reconhecimento já tinha sido feito antes de a falha ser pública. Quando ela vira pública, o que falta é só a execução.
A boa notícia é que reconhecimento é a única fase da cadeia que você consegue observar antes de qualquer coisa acontecer, e ela deixa rastro no seu próprio log.
# Illustrative access log excerpt. Not a real incident: this is the pattern
# that shows up on any exposed perimeter, every single day.
203.0.113.44 - - [19/Aug/2026:03:14:02 +0000] "GET /.env HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:02 +0000] "GET /.git/config HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:03 +0000] "GET /actuator/env HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:03 +0000] "GET /server-status HTTP/1.1" 403 199
203.0.113.44 - - [19/Aug/2026:03:14:04 +0000] "GET /favicon.ico HTTP/1.1" 200 4286
203.0.113.44 - - [19/Aug/2026:03:14:05 +0000] "GET /login HTTP/1.1" 200 8921Bloquear todo scanner é inviável e nem é o objetivo. O sinal útil é a mudança de caráter: varredura genérica de porta é ruído de fundo constante, mas rajada de 404 em caminhos específicos do stack que você realmente usa é reconhecimento dirigido, e costuma ser o evento mais precoce que um time de resposta consegue capturar.
Como responder ao reconhecimento em massa
- Trate inventário externo como processo contínuo, não como planilha anual: consulte os logs de Certificate Transparency do seu próprio domínio e trate hostname novo como mudança de escopo
- Trate emissão de certificado público como publicação: o que precisa ficar privado não deveria ter certificado de CA pública com o nome real no campo SAN
- Faça o próprio fingerprint antes: rode as mesmas consultas de hash de favicon, ssl.jarm e banner contra as suas faixas de IP e veja o que o mundo já vê
- Priorize patch por exposição, não só por CVSS: uma falha 7,5 num painel alcançável da internet corre mais risco real que uma 9,8 num serviço que só existe na rede interna
- Encurte a janela para produto de borda: VPN, hipervisor, CI/CD e console de gerência precisam de prazo em dias, com processo de emergência já ensaiado antes de precisar dele
- Monitore reconhecimento dirigido, não volume bruto: alerte por rajada em caminhos específicos do seu stack, não por contagem total de requisição bloqueada
O pentest começa onde o reconhecimento começa
Um teste que parte de uma lista de alvos entregue pelo cliente já pulou a primeira fase do ataque real. O atacante não recebe lista, ele monta a dele, e é justamente na diferença entre as duas listas que moram os achados mais caros: o subdomínio de homologação com dado de produção, o painel antigo que ninguém lembrava, o serviço que subiu para um projeto encerrado e continuou de pé. Por isso a primeira entrega de um trabalho nosso costuma ser o inventário, não o achado.
O número de 44% não fala sobre volume de ataque, fala sobre ordem. O mapeamento passou a ser feito antes de o alvo ser escolhido. 'Ninguém vai atacar a gente' deixou de descrever como o alvo é escolhido, porque nessa fase ninguém está escolhendo.