FortiGuard Labs contabilizó 249.300 millones de intentos de ataque y actividad cibernética maliciosa contra objetivos en Brasil durante el primer semestre de 2026. El número que de verdad cambia una decisión de seguridad, sin embargo, está dentro de ese total: 9 mil millones de escaneos activos en seis meses, un volumen 44% mayor que todo lo registrado durante 2025. Lo que más creció no fue la fase de ataque. Fue la fase que viene antes.
La fase más barata de la cadena es la que más crece
El escaneo activo es la técnica T1595 de MITRE ATT&CK, dentro de la táctica Reconnaissance (TA0043). Es el momento en que el atacante todavía no tiene objetivo, solo tiene método: barrer rangos de IP (T1595.001), buscar versiones vulnerables (T1595.002) y probar rutas conocidas con una wordlist (T1595.003). El resto del informe de Fortinet sigue la misma curva. El malware saltó de 187,5 millones de ocurrencias en todo 2025 a 406,8 millones solo en el primer semestre de 2026, los troyanos se triplicaron de 32 millones a 100 millones, el cryptominer llegó a 69 mil ocurrencias superando todo el año anterior, y hubo 6.932 incidentes de ransomware. Pero el crecimiento del reconocimiento es el indicador que aparece primero, porque ocurre semanas o meses antes que el resto.
La consecuencia práctica es una inversión de lógica que todavía no llegó a la mayoría de las conversaciones sobre riesgo. En una campaña de reconocimiento masivo el objetivo no se elige, se encuentra. Nadie decidió atacar tu empresa: alguien barrió internet buscando una versión específica de un producto, y tu instancia respondió. El tamaño, el sector y la relevancia de marca no entran en esa cuenta en ningún momento.
El reconocimiento que no toca tu servidor
Buena parte del mapeo moderno es pasivo, y por eso invisible para quien solo mira su propio log de acceso. La técnica es la T1596, búsqueda en bases técnicas abiertas, y la subtécnica más productiva es la T1596.003, certificados digitales. El motivo es estructural: desde el RFC 6962, todo certificado TLS de confianza pública queda registrado en logs de Certificate Transparency, append-only y auditables por cualquiera. Los navegadores exigen esa prueba de registro para aceptar el certificado, lo que significa que no existe la opción de emitir un certificado público y mantenerlo en secreto.
Emitir un certificado para homologacion-api.empresa.com publica ese hostname para el mundo en segundos. El host puede estar detrás de un firewall, sin registro en DNS público y sin ningún enlace apuntando hacia él. Su nombre ya salió.
# 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.brLo que suele devolver esa consulta en una empresa de porte medio es siempre de la misma familia: un ambiente de homologación, un panel de administración viejo, un concentrador de VPN, un servidor de integración continua, un webmail que nadie apagó. Son exactamente los activos que rara vez entran en el alcance de un pentest, porque el inventario que alimenta ese alcance suele venir de la memoria del equipo y no de una consulta a lo que ya es público.
Fingerprint: cómo se encuentra a todos los que corren el mismo producto
La segunda mitad del reconocimiento no es escanear, es consultar. Las bases de escaneo público (T1596.005) ya barrieron todo el espacio IPv4 y mantienen el resultado indexado. El atacante no necesita generar tráfico, hace una búsqueda. Y la búsqueda no es 'puerto 443 abierto', es 'esta instalación específica de este producto específico'.
Tres huellas sostienen eso. La primera es el hash de favicon: Shodan indexa el filtro http.favicon.hash, calculado con MurmurHash3 sobre el contenido del ícono en base64, así que un producto que sirve su propio favicon por defecto queda identificable incluso con la página de login totalmente personalizada. La segunda es el fingerprint de TLS, expuesto en el filtro ssl.jarm, que identifica al servidor por la forma en que responde al handshake. La tercera es la suite JA4+ de FoxIO, que extendió la idea de JA3 a cliente TLS (JA4), respuesta de servidor (JA4S), cliente HTTP (JA4H) y certificado X509 (JA4X), ordenando ciphers y extensiones justamente para dificultar las manipulaciones que rompían 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>'El efecto colateral es lo que importa. Cuando sale un CVE crítico para el producto X, la lista de instancias expuestas del producto X no hay que construirla: ya existe, indexada, a una consulta de distancia. Omitir el nombre del producto en la página no ayuda, porque el ícono, la pila TLS y el certificado lo identifican solos.
Del escaneo al exploit, la ventana se achicó
Este es el eslabón que cierra el razonamiento. Escribimos aquí el 18 de agosto sobre la CVE-2026-59310, el RCE no autenticado en VMware vCenter: Broadcom publicó el advisory el 29 de julio de 2026 y cinco días después ya había explotación masiva, con 361 direcciones IP comprometidas en 47 países. Cinco días no alcanzan para desarrollar, probar y distribuir un exploit desde cero. Alcanzan para tomar una lista de objetivos que ya existía y pasarle el exploit.
Por eso el plazo práctico de parcheo para producto de borde, es decir VPN, hipervisor, servidor de CI/CD y panel de gestión, se cuenta en días y no en ciclo de mantenimiento trimestral. El reconocimiento ya estaba hecho antes de que la falla fuera pública. Cuando se vuelve pública, lo único que falta es la ejecución.
La buena noticia es que el reconocimiento es la única fase de la cadena que se puede observar antes de que pase cualquier cosa, y deja rastro en tu propio 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 escáner no es viable y tampoco es el objetivo. La señal útil es el cambio de carácter: el escaneo genérico de puertos es ruido de fondo constante, pero una ráfaga de 404 contra rutas específicas del stack que realmente usás es reconocimiento dirigido, y suele ser el evento más temprano que un equipo de respuesta logra capturar.
Cómo responder al reconocimiento masivo
- Tratá el inventario externo como proceso continuo, no como planilla anual: consultá los logs de Certificate Transparency de tu propio dominio y tratá cada hostname nuevo como cambio de alcance
- Tratá la emisión de certificado público como publicación: lo que debe quedar privado no debería tener certificado de CA pública con el nombre real en el campo SAN
- Hacé tu propio fingerprint primero: corré las mismas consultas de hash de favicon, ssl.jarm y banner contra tus rangos de IP y mirá lo que el mundo ya ve
- Priorizá el parcheo por exposición, no solo por CVSS: una falla 7,5 en un panel alcanzable desde internet corre más riesgo real que una 9,8 en un servicio que solo existe en la red interna
- Acortá la ventana para producto de borde: VPN, hipervisor, CI/CD y consola de gestión necesitan plazos en días, con proceso de emergencia ya ensayado antes de necesitarlo
- Monitoreá reconocimiento dirigido, no volumen bruto: alertá por ráfagas contra rutas específicas de tu stack, no por el total de peticiones bloqueadas
El pentest empieza donde empieza el reconocimiento
Una prueba que arranca de una lista de objetivos entregada por el cliente ya se salteó la primera fase del ataque real. El atacante no recibe lista, arma la suya, y justamente en la diferencia entre las dos listas viven los hallazgos más caros: el subdominio de homologación con dato de producción, el panel viejo que nadie recordaba, el servicio que se levantó para un proyecto que terminó y quedó de pie. Por eso la primera entrega de un trabajo nuestro suele ser el inventario, no el hallazgo.
El número de 44% no habla de volumen de ataque, habla de orden. El mapeo pasó a hacerse antes de que se elija el objetivo. 'A nosotros nadie nos va a atacar' dejó de describir cómo se elige el objetivo, porque en esta fase nadie está eligiendo.