Análisis de ataque: escáner de vulnerabilidades contra el proxy de Multify

29 de mayo de 2026, 17:04. Dos direcciones IP de Costa de Marfil se conectaron al servidor proxy de Multify. Durante los siguientes 90 segundos, probaron casi 100 URL y recibieron 100 rechazos.

Este es el trabajo típico de un escáner de vulnerabilidades. No es un ataque dirigido, sino un reconocimiento automático. Estos escáneres funcionan continuamente, rastreando millones de sitios en busca de una cosa: un archivo abierto con claves, contraseñas o configuración, o una vulnerabilidad conocida en el CMS. No importa en qué esté construido el sitio web —WordPress, Drupal, Joomla o un motor personalizado. El escáner comprueba todo de forma consecutiva según un diccionario estándar.

Multify, como proxy inverso, recibe todo el tráfico entrante. El escáner se conecta a la infraestructura de Multify, no directamente al sitio web del cliente. La protección del proxy es la protección de los sitios web del cliente.

Aquí hay una lista de un registro real:

`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``

Esto no es un conjunto aleatorio, sino un diccionario estándar compilado a partir de filtraciones reales. Cada archivo de esta lista fue encontrado en algún momento en acceso público en el servidor de producción de alguien.

Variables de entorno — archivos .env y sus variantes. En ellos, los desarrolladores almacenan claves API, contraseñas de bases de datos, tokens de sistemas de pago. Un solo archivo de este tipo le da al atacante acceso completo a la infraestructura sin dejar rastro de intrusión. Según GitGuardian, en 2024 se detectaron secretos en repositorios públicos más de 12 millones de veces, siendo .env uno de los tres más frecuentes. El desarrollador añade el archivo a .gitignore, pero en el servidor, después del despliegue, permanece en el directorio público y nadie lo verifica.

Configuraciones de CMS y frameworks — wp-config.php (WordPress), configuraciones de Joomla, Drupal, archivos de Laravel, Symfony, Rails. El escáner no sabe en qué está escrito el sitio web, por lo que verifica todas las variantes populares de forma consecutiva.

Claves en la nube — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. Un acierto significa acceso a la cuenta en la nube con todos los datos y posibles facturas de decenas de miles de dólares.

Claves de cifrado — private.key, server.key, rails/master.key. Una clave privada abierta permite descifrar todo el tráfico o falsificar firmas.

Registros y volcados — error.log, debug.log, database.sql, dump.sql. Los registros a menudo contienen datos de usuarios, rutas de archivos y, a veces, contraseñas en texto claro.

Configuraciones de infraestructura — nginx.conf, docker-compose.yml, web.config. A partir de ellos se puede conocer la topología interna de la red y encontrar el siguiente punto de entrada.

Vulnerabilidades de CMS — eine eigene Kategorie. Sobald ein neues CVE veröffentlicht wird, beginnen Scanner, alle Websites zu überprüfen, oft innerhalb weniger Stunden. Laut Google Project Zero beträgt die Medianzeit von der CVE-Veröffentlichung bis zu den ersten Angriffen 15 Tage, aber für Schwachstellen mit öffentlichem PoC hat sich diese Zeit auf wenige Stunden verkürzt. Ein Beispiel, das derzeit aktiv ausgenutzt wird: CVE-2026-9082, inyección SQL en Drupal Core en PostgreSQL (versiones 8.0 a 11.3.9). La vulnerabilidad radica en cómo Drupal construye las consultas SQL a través de JSON:API: un atacante pasa una clave de matriz con SQL anidado en el parámetro de filtro, Drupal la inserta en la consulta sin sanitización. Sin autorización, a través de una solicitud HTTP normal. Resultado: descarga de la base de datos, creación de una cuenta de administrador, en algunas configuraciones ejecución de código arbitrario. CVSS 9.8, crítica (para comparar: Log4Shell, que derribó la mitad de Internet en 2021, obtuvo 10.0). El parche se lanzó el 20 de mayo, un PoC funcional apareció en GitHub en menos de una hora. El 22 de mayo, la vulnerabilidad se agregó al catálogo de vulnerabilidades explotadas conocidas de CISA. En las primeras 48 horas, se registraron más de 15.000 intentos de explotación en casi 6.000 sitios en 65 países.

El ataque del 29 de mayo fue exactamente así. WAF funcionó según las firmas de OWASP CRS, CrowdSec añadió ambas IP a la lista de bloqueados. El cliente no se enteró.

El escáner recorrió todas las categorías a la vez, en 90 segundos.

El escáner se lanzó desde dos direcciones simultáneamente. Los escáneres modernos distribuyen la carga entre varias IP para mantenerse por debajo del umbral de las reglas simples de límite de velocidad. Si la protección se activa con "más de 10 solicitudes por minuto desde una IP", el escáner simplemente hace 5 desde cada una. Al mismo tiempo, las IP en sí mismas a menudo no tienen relación con el atacante real: son VPS alquilados, servidores pirateados o máquinas botnet en todo el mundo. Costa de Marfil es una geografía aleatoria aquí, no el lugar desde donde realmente trabaja una persona.

Un detalle curioso del registro: la primera solicitud de la segunda IP devolvió 200 — el escáner primero verificó la página principal, se aseguró de que el sitio estuviera activo, y solo entonces comenzó la enumeración. Esto es una señal de una herramienta, no de tráfico aleatorio.

WAF (Web Application Firewall) — un firewall a nivel de aplicación. A diferencia de un firewall de red, que observa las IP y los puertos, un WAF lee el contenido de la solicitud HTTP: URL, encabezados, cuerpo. Analiza cada solicitud antes de que llegue al sitio.

La base de las reglas es OWASP Core Rule Set (CRS), un conjunto abierto de firmas de ataque que es compatible con la fundación sin fines de lucro OWASP. CRS cubre la enumeración de archivos de configuración, inyecciones SQL, XSS y otros vectores comunes. Las solicitudes a .env, .sql, .key, wp-config.php y docenas de otras extensiones se bloquean de inmediato. El WAF no sabe si el archivo existe en el servidor, bloquea por el nombre de la solicitud y el escáner recibe una denegación antes de que pueda averiguar algo.

CrowdSec — un motor de análisis de comportamiento de código abierto. El WAF funciona con cada solicitud por separado, CrowdSec observa la secuencia: qué solicita exactamente esta IP en los últimos minutos.

Una solicitud a .env puede ser un error en el enlace. Diez solicitudes a .env, .env.production, .env.local, .envrc en 30 segundos ya no es un usuario. CrowdSec reconoce este patrón por sus escenarios (reglas de comportamiento) y bloquea la IP. Las direcciones bloqueadas se añaden a una base de datos de amenazas común utilizada por miles de servidores en todo el mundo. Un escáner detectado en un sitio web se convierte inmediatamente en un invitado no deseado en todas partes.

El escáner procesó el diccionario estándar en un minuto y medio y no encontró nada. El sitio web del cliente no recibió ninguna solicitud maliciosa.

Cuando un sitio web se conecta a Multify, todo el tráfico entrante pasa a través de un proxy. El cliente conectó Multify para la localización, no para la protección. Pero como el proxy está delante del sitio web, toda la protección de la infraestructura de Multify se extiende automáticamente a él.

Las filtraciones a través de archivos abiertos son uno de los vectores de hackeo más comunes. No ocurren debido a exploits complejos, sino a errores triviales: el desarrollador implementó el proyecto y se olvidó de eliminar .env. Puso un volcado de base de datos de prueba en una carpeta pública. Dejó un archivo de configuración con contraseñas en el servidor. Los escáneres encuentran estos archivos en cuestión de horas, mucho antes de que alguien del equipo note el error.

Si el sitio web del cliente funciona con Drupal y PostgreSQL, el WAF a nivel de proxy bloquea patrones de solicitud característicos: parámetros de filtro complejos para /jsonapi, solicitudes a /user/login?_format=json con cuerpos no estándar. El escáner no llega al sitio web. Pero esto no es un reemplazo para un parche: si el sitio web es accesible directamente sin pasar por el proxy, no hay protección.

Los escáneres modernos distribuyen las solicitudes a través de múltiples direcciones para permanecer por debajo del umbral de las reglas simples de límite de velocidad. CrowdSec observa el comportamiento, no la cantidad de solicitudes de una sola IP, por lo que esta técnica no ayuda.

No. El WAF bloquea las solicitudes por nombre de ruta antes de que lleguen a la aplicación. El escáner no sabe si el archivo existe en el servidor, recibe un rechazo a nivel de proxy.

Un ataque dirigido es más complejo: el atacante conoce el objetivo, utiliza vectores no estándar y trabaja lentamente para no caer en patrones de comportamiento. WAF y CrowdSec reducen la superficie de ataque, pero no ofrecen una garantía del cien por cien. Para sitios críticos, se necesita una prueba de penetración y un monitoreo de anomalías.

No. La geolocalización IP de un escáner es la geolocalización de la máquina que se utiliza, no la del atacante. El bloqueo por país no tiene sentido: el próximo ataque vendrá de Brasil, Países Bajos o Rusia.