CASOS REALES
Estos son ataques que ocurrieron en webs reales. Los nombres están anonimizados, pero las métricas son las de verdad. Sirven para entender qué tipo de cosas pasan a diario y qué diferencia hace tener algo decente protegiendo la web.
Caso 01 · Abril 2026
Una clínica dental con extranet de gestión propia descubre un sábado por la mañana que su sistema está caído. El servidor responde con archivos cifrados y un README pidiendo bitcoin.
La clínica gestionaba varios centros desde una extranet propia. Tenía muchos años de datos clínicos, agendas, presupuestos y comunicación digital con clientes. Cualquier downtime es ingresos perdidos directos — los pacientes no pueden reservar y los recepcionistas no pueden trabajar.
El vector fue un .env público accesible vía HTTP en
el dev environment (clásico). Con las credenciales de DB filtradas, el atacante entró a phpMyAdmin
(también expuesto sin restricción de IP) y desde ahí escaló: subió un shell PHP a uploads,
elevó privilegios y cifró el filesystem de la subscription Plesk.
Tardaron unas 6 horas desde que entraron hasta que la extranet quedó cifrada del todo. El admin recibió la notificación de Plesk cuando la web devolvió 500 en masa.
SÁB 09:14
Admin descubre la web caída. README en docroot pidiendo 0.4 BTC.
SÁB 11:30
Activamos protocolo: clonamos el filesystem cifrado a otro disco (para forensics), restauramos el último backup limpio de Plesk (24h antes).
SÁB 14:00
Auditoría de logs: identificamos punto de entrada exacto (.env público) y momento del compromiso. Recreamos toda la cadena: DB → phpMyAdmin → shell upload → escalada.
SÁB 18:00
Hardening masivo: rotación de TODAS las passwords (admin, DB, GitHub, n8n, hosting), cierre del .env público, cierre de phpMyAdmin a IP única, recreación de DEFINERs MySQL, headers de seguridad, bloqueo de paths sensibles en .htaccess.
DOM 03:00
Sync de los datos posteriores al último backup (lo que se hubiera perdido) con el clon cifrado: se logra extraer 18h de datos no cifrados que el ransomware no había llegado a tocar (estaba en una tabla con tablespace separado).
DOM 21:30
Extranet vuelve online. Recepcionistas reciben briefing y nuevas credenciales. La clínica abre el lunes con normalidad.
+72h
Notificación a la AEPD por brecha de datos (obligatorio en 72h). Implementación de monitoring continuo + auto-mitigation para que esto no pueda repetirse.
.env públicos son el vector más común. Lo escanea cualquier bot en 2 minutos.CÓMO NUDAYOSH LO HABRÍA EVITADO
El scanner detecta .env público y phpMyAdmin expuesto en la primera capa (en ~30 segundos). Con el plugin instalado, el shell PHP en uploads habría sido movido a cuarentena automáticamente en milisegundos, antes de que pudiera ejecutarse. El ataque entero — desde entrada hasta cifrado — habría sido detenido en su primer paso.
Caso 02 · Mayo 2026
Centro de bienestar con WordPress y sistema de reservas online. Un día empieza a notar lentitud generalizada en la web. La causa: una botnet probando contraseñas.
WordPress + WooCommerce con sistema de reservas integrado. Varias sucursales activas. El cliente sólo se enteró porque la web iba más lenta de lo normal — la base de datos de sesiones y el log de errores estaban llenándose a un ritmo anormal.
Botnet distribuida (847 IPs únicas, mayoritariamente VPSs comprometidos en Asia y Europa del Este) atacando /wp-login.php con un diccionario de unas 50 combinaciones típicas por ronda (admin/admin, admin/123456, admin/password, etc.).
Cada IP individualmente intentaba pocas veces (3-6 fails) — diseñado para evadir el típico Limit Login Attempts que bloquea por IP. Pero en agregado eran más de 4.700 intentos en una semana, suficiente para dar problemas de rendimiento y para que estadísticamente acertaran si el admin tenía contraseña débil.
El plugin NUDAYOSH ya estaba instalado. Auto-mitigation engine bloqueó automáticamente cada una de las 847 IPs en cuanto superaron el threshold (10 fails consecutivos en 10 min). Pero lo más importante: aplicamos las reglas Cloudflare para bloquear el patrón de fondo:
/wp-login.php a todo país que no fuera España (la admin sólo accedía desde Madrid)/xmlrpc.php (era el segundo vector)| Métrica | Antes | Después |
|---|---|---|
| Logins fallidos/semana | 4.732 | 38 |
| IPs en blocklist | 0 | 847 |
| Tiempo de respuesta wp-login | ~2.4s | ~180ms |
| CPU pico del hosting | 86% | 12% |
EL APRENDIZAJE
No hace falta que un atacante sea sofisticado para hacerte daño. Una botnet "tonta" de 847 IPs gratuitas puede degradar tu web hasta que esté inutilizable. Sin auto-mitigation, esto se convierte en una llamada urgente a tu desarrollador un viernes por la tarde. Con auto-mitigation, se convierte en una línea más en el dashboard semanal.
El scanner detecta lo que falló en estos casos en menos de 30 segundos. Si tu web tiene alguno de esos problemas, te lo dice.
Analizar mi web gratisSin registro. 10 capas de detección. Score 0-100.