Lo que realmente encuentra una prueba de penetración de red externa

Todavía encontramos en la internet pública paneles de inicio de sesión que aceptan admin/admin al primer intento. No una vez, no por casualidad. Es un titular recurrente en nuestros informes. Un dispositivo de copias de seguridad montado en un rack hace años y nunca vuelto a tocar. Un servidor de preproducción que un desarrollador levantó un fin de semana y olvidó. Un puerto de administración de firewall que se suponía restringido a una única IP de oficina y que nunca lo estuvo.

Esa es la verdad incómoda sobre las pruebas de penetración de red externa: la vía de entrada casi nunca es ingeniosa. Es algo que ya posees y que dejaste de vigilar.

Las pruebas de penetración de red externa consisten en atacar tus sistemas expuestos a internet como lo haría un intruso real – desde fuera, sin credenciales, sin diagrama de red y sin ayuda. La idea es encontrar la puerta antes de que la encuentre alguien que no te rinde cuentas. Este es un recorrido por lo que esas pruebas sacan a la luz, cómo lo destapamos y qué corregir primero.

Puntos clave

• Las pruebas de penetración de red externa atacan tus activos expuestos a internet sin acceso previo, para hallar los puntos de entrada que un atacante busca primero.
• Los hallazgos de mayor impacto suelen ser mundanos: paneles de administración expuestos, appliances de VPN y firewall sin parchear, y credenciales por defecto o reutilizadas.
• El descubrimiento de la superficie de ataque es la mitad del valor. La mayoría de las organizaciones no puede enumerar cada host que expone, y es por los olvidados por donde entramos.
• Los dispositivos de perímetro como las VPN, los firewalls y las pasarelas de correo son objetivos prioritarios, porque un único fallo sin autenticar puede entregar todo el perímetro.
• Las soluciones son aburridas a propósito: reducir la superficie expuesta, parchear rápido el equipamiento de perímetro, eliminar las credenciales por defecto y exigir MFA en todo lo que esté expuesto a internet.

¿Qué son las pruebas de penetración de red externa?

Las pruebas de penetración de red externa son un ataque controlado contra todo lo que tu organización expone a la internet pública: servidores web, servidores de correo, pasarelas VPN, firewalls, servicios de acceso remoto, DNS y cualquier otro puerto que un extraño pueda alcanzar. El tester parte desde la silla de un atacante, normalmente sin más que el nombre de tu empresa o una lista de rangos de IP y dominios.

Responde a una pregunta contundente. Si un desconocido motivado nos atacara hoy, ¿podría afianzarse desde fuera? Esa es una pregunta distinta de la que plantea una prueba interna. El trabajo interno da por hecho que el atacante ya está dentro y mide hasta dónde llega. El trabajo externo va sobre el perímetro, y el perímetro es más amplio y más caótico de lo que la mayoría de los equipos cree.

La gente lo confunde con un escaneo de vulnerabilidades. No debería. Un escaneo ejecuta una herramienta e imprime un informe. Una prueba de penetración usa esa salida como punto de partida; luego un humano la valida, encadena los hallazgos y los explota para demostrar un impacto real. Los escáneres son ruidosos y ciegos al contexto. Uno marcará un ajuste de TLS de gravedad media y pasará de largo junto al panel de administración que acepta admin/admin, porque iniciar sesión no es algo que un escáner vaya a intentar de verdad.

¿Cómo se cartografía la superficie de ataque externa?

El descubrimiento va primero, y ahí es donde se esconde una cantidad sorprendente del valor. Antes de tocar nada, construimos la imagen más completa posible de lo que expones. La lista dentro del alcance que un cliente nos entrega rara vez es la lista completa de lo que realmente tiene en línea.

Abrimos con reconocimiento pasivo para no hacer ruido: registros de transparencia de certificados, registros DNS, datos WHOIS y buscadores que indexan servicios expuestos. La transparencia de certificados es lo primero a lo que recurro. Cada certificado TLS que emite una empresa queda registrado públicamente, así que filtra subdominios que nadie pretendía anunciar – los nombres de host dev, uat y vpn-test que nunca debían ser localizables.

# Subdomain enumeration from multiple passive sources
subfinder -d acme-corp.com -all -silent | tee subs.txt

# Resolve, then probe which ones are actually live
cat subs.txt | dnsx -silent -a -resp | httpx -silent -title -status-code -tech-detect

Luego pasamos a lo activo: escaneo de puertos en los hosts resueltos y toma de huellas de lo que responde. No solo contamos puertos abiertos. Cazamos los interesantes. Nada afina tanto el foco de un tester como el 3389 (RDP), el 445 (SMB) o un puerto de base de datos que responde directo a internet.

# Fast full-range TCP sweep, then service/version detection on the hits
nmap -p- --min-rate 2000 -oA sweep 203.0.113.0/24
nmap -sV -sC -p 22,443,3389,8443 -oA services 203.0.113.10

Lo que sale es un inventario vivo: nombres de host, IP, puertos abiertos, software en ejecución, versiones. Ese inventario sorprende habitualmente a quienes encargaron la prueba. Hemos entregado a equipos una lista en la que una parte considerable de los hosts eran cosas de las que su grupo de seguridad no había oído hablar jamás, levantadas por un desarrollador o un proveedor de marketing y dejadas en marcha con las luces encendidas.

¿Qué encuentra realmente una prueba externa?

Este es el desglose honesto de lo que aterriza en la portada de nuestros informes, más o menos en el orden en que suele importar.

Servicios expuestos e interfaces de administración

El hallazgo grave más habitual es algo que jamás debería haber dado a internet. Consolas de gestión. Paneles de CI como Jenkins. Puertos de base de datos. Servidores de API de Kubernetes. Instancias de Elasticsearch y Redis ahí puestas sin autenticación – y sí, un Redis abierto suele significar una rápida conexión redis-cli y un vistazo a lo que sea que tenga en caché. Paneles de administración de impresoras y dispositivos IoT. Entornos de preproducción que replican producción pero se saltan sus controles. Si escucha en una IP pública y se construyó para uso interno, lo documentamos.

Appliances de perímetro sin parchear

Los concentradores VPN, los firewalls y las pasarelas de correo son justo donde un atacante externo quiere estar, y envejecen mal. Se asientan en plena frontera. Ejecutan software que a menudo no puedes inspeccionar. Y un solo fallo de preautenticación en uno de ellos puede dejar a un atacante directamente en la red interna. Los fallos críticos sin autenticar en grandes productos de VPN y firewall han estado entre los bugs más explotados de los últimos años, precisamente porque están expuestos a internet por diseño y se parchean despacio. Cuando detectamos un dispositivo de perímetro que ejecuta una versión con un exploit público conocido, eso sube a lo más alto del informe – y viene acompañado de una llamada telefónica.

Credenciales por defecto y débiles

Las credenciales por defecto no se mueren. El problema tiene incluso su propia clase de debilidad, CWE-1392, uso de credenciales por defecto, y aún encontramos admin/admin, admin/password y valores por defecto de fabricante en equipos que se desplegaron con prisas y nunca se revisaron. Justo detrás va la reutilización de credenciales – contraseñas quemadas en viejas filtraciones de terceros que todavía abren tu VPN o tu correo web. Probamos las superficies de inicio de sesión descubiertas contra listas cuidadosamente derivadas de filtraciones, con cuidado y con límite de tasa, porque a un atacante que lanza un password spraying (MITRE ATT&CK T1110.003) no le importa una política de bloqueo que nunca configuraste.

Falta de MFA en el acceso remoto

Un portal VPN u Outlook Web Access protegido solo por una contraseña está a una credencial de la brecha. El spraying sumado a la ausencia de MFA es de las vías más fiables hacia una organización que vemos, y no necesita nada de código de explotación. Si da a internet y abre una puerta a algo interno, necesita un segundo factor. Punto.

Fugas de información y configuraciones erróneas

Páginas de error verbosas. Directorios .git expuestos. Listados de directorios. Ficheros de copia de seguridad olvidados en la raíz web. Nombres de host internos que se escapan por las cabeceras HTTP. Por sí solos parecen triviales. Encadenados, le entregan al atacante un mapa – y a veces código fuente o credenciales sin más.

¿Por qué importa un solo puerto abierto?

Porque el perímetro es una cadena, y a un atacante le basta con que aguante un solo eslabón. Mira cómo va la cosa. Un subdominio olvidado apunta a una aplicación web sin parchear. La aplicación filtra tu formato interno de nombres de usuario. Ese formato alimenta un password spraying contra la VPN, y la VPN no tiene MFA. Ahora hay un punto de apoyo dentro, y la prueba externa acaba de mostrar el avance de una brecha a cámara lenta.

Ninguno de esos pasos necesitó un zero-day. Ese es el punto que les repetimos una y otra vez a los clientes. Es mucho más probable que te comprometan a través de un montón de exposiciones corrientes y corregibles que mediante algún ataque exótico y novedoso. Las pruebas de penetración de red externa existen para encontrar ese montón mientras sigue siendo tu problema, para resolverlo con discreción.

¿Cómo se previenen estos hallazgos?

Los remedios son poco vistosos, y esa es la buena noticia, porque poco vistoso significa alcanzable.

• Reduce la superficie. Cada servicio en una IP pública debería tener una razón documentada para estar ahí. Si no la tiene, quítalo de internet o muévelo detrás de la VPN. Nadie ataca un puerto que no está abierto.
• Mantén un inventario de activos que de verdad sea exacto. No puedes defender lo que no sabes que posees. Mantén una lista viva de los activos expuestos a internet y concíliala con regularidad, idealmente con un descubrimiento externo automatizado que haga el mismo reconocimiento que un atacante.
• Parchea los dispositivos de perímetro por la vía rápida. Las VPN, los firewalls y las pasarelas de correo merecen su propio proceso acelerado. Cuando un fabricante publica un parche para un fallo sin autenticar en uno de ellos, cuenta en días, no en semanas.
• Elimina las credenciales por defecto y exige MFA. Cambia cada valor por defecto en el despliegue, bloquea las contraseñas reutilizadas y filtradas, y exige autenticación multifactor en cada superficie de acceso remoto y de administración. Este único control neutraliza una gran parte de lo que explotamos.
• Vuelve a probar después de cambiar cosas. Un perímetro no es estático. Aparecen servicios nuevos, los registros DNS cambian, las appliances se quedan desfasadas. Una prueba puntual es una instantánea, no una garantía.

Cómo ayuda CyberXplore

Nuestro servicio de pruebas de penetración de red externa hace exactamente lo que describe este artículo. Cartografiamos toda tu huella expuesta a internet, incluidos los activos que no sabías que estaban expuestos, y luego validamos y explotamos con seguridad lo que encontramos para mostrar un impacto real en lugar de un muro de ruido de escáner. Obtienes un informe priorizado que separa lo que hay que arreglar hoy del riesgo de fondo, con pasos de reproducción claros sobre los que tus ingenieros pueden actuar, y una nueva prueba para confirmar que los agujeros están realmente cerrados. Si quieres ver lo que ve un atacante real cuando mira tu perímetro, solicita un presupuesto y definiremos el alcance contigo.

FAQ

¿En qué se diferencian las pruebas de penetración de red externa de un escaneo de vulnerabilidades?

Un escaneo de vulnerabilidades es automático y escupe una lista de problemas potenciales, muchos de ellos falsos positivos, sin prueba de que nada sea explotable. Las pruebas de penetración de red externa usan el escaneo como una entrada; luego un humano valida los hallazgos, los encadena y demuestra con seguridad un impacto real. El escaneo te dice qué podría estar mal. La prueba demuestra qué podría hacer de verdad un atacante.

¿Cuánto dura una prueba de penetración de red externa?

Para una huella externa típica de tamaño pequeño a mediano, cuenta con aproximadamente una o dos semanas de pruebas activas más la elaboración del informe, aunque escala con el número de hosts y servicios activos dentro del alcance. Lo que más varía es el descubrimiento, porque una superficie de ataque grande o dispersa lleva más tiempo cartografiar a fondo. Fijamos el calendario según tu recuento real de activos en vez de adivinar.

¿Interrumpirá la prueba nuestros sistemas de producción?

La prueba se ejecuta bajo unas reglas de enfrentamiento acordadas de antemano. Evitamos las técnicas de denegación de servicio, limitamos la tasa de todo lo que toca la autenticación y nos coordinamos en los sistemas sensibles. La inmensa mayoría del trabajo externo es observación cuidadosa y validación controlada, y cualquier cosa con verdadero potencial de interrupción solo se ejecuta con una aprobación explícita.

¿Con qué frecuencia deberíamos hacer pruebas de penetración de red externa?

Al menos una vez al año, y tras cualquier cambio significativo en tu entorno expuesto a internet – el lanzamiento de un nuevo producto, una migración, una fusión. Muchas organizaciones también las hacen para cumplir requisitos de conformidad como PCI DSS o SOC 2. Como los perímetros van cambiando, los equipos con una huella de rápida evolución se benefician de pruebas más frecuentes o de una monitorización externa continua de la superficie de ataque entre compromisos completos.

¿Qué obtenemos al final del compromiso?

Un informe que arranca con un resumen ejecutivo y una lista priorizada de hallazgos ordenados por riesgo real, cada uno con pruebas claras, pasos de reproducción y orientación para la corrección. Separamos los puntos urgentes del endurecimiento de menor prioridad, para que tu equipo sepa exactamente por dónde empezar. También ofrecemos una nueva prueba tras la corrección para confirmar que los problemas quedan de verdad cerrados y no solo reportados.