Qué hacemos aquí
HoneyVault es un laboratorio que monitoriza ataques web reales contra un entorno señuelo, los analiza y los muestra al público de forma anonimizada — explicando cómo funcionan y cómo defenderse de ellos.
Mantenemos un cebo (intranet web ficticia) deliberadamente expuesto. Cada petición que entra queda registrada con su contexto: ruta, parámetros, payload, marca temporal.
Un IDS observa la misma red y emite alertas independientes. Cuando el cebo y el IDS ven el mismo intento dentro de una ventana corta, la evidencia queda corroborada por dos fuentes.
Calculamos un SHA-256 sobre el dato bruto en el momento de la ingesta. El dato original es inmutable: cualquier cambio posterior se detecta verificando el hash.
Antes de publicar nada, enmascaramos la IP, redactamos credenciales y eliminamos lo que pueda identificar al atacante o exponer detalles internos.
El caso saneado se publica en el catálogo público. El original sigue intacto y trazable internamente; al público solo llega lo divulgativo.
Un artículo por cada técnica de ataque (SQLi, XSS, traversal, escaneo, brute force, ficheros sensibles, inyección de comandos): qué es, cómo defenderse y los últimos intentos reales registrados.
Volumen de ataques, tipos más vistos, severidades del IDS y países de origen — solo agregados.
Para quien quiera entender cómo se atacan las aplicaciones web en la práctica: estudiantes que están aprendiendo, profesionales que quieren ejemplos didácticos y curiosos que prefieren ver un ataque real explicado antes que leer una definición de manual.
El dato original no se modifica. Cada evidencia lleva su SHA-256 desde la captura y se puede verificar.
Lo que sale al público no permite identificar a nadie: IPs enmascaradas, credenciales redactadas, nunca el dato crudo.
Toda acción interna queda en un registro append-only. La API no expone modificación ni borrado de ese registro.
El cebo vive en su propia red, sin acceso a la base de datos ni al panel. Los logs viajan en una sola dirección.
El sistema tiene tres piezas que viven en contenedores separados: el cebo y el IDS por un lado (red aislada, sin acceso a nada interno), y la API más la base de datos por otro. La comunicación es unidireccional vía ficheros de log.
Atacante
│
▼
Honeypot PHP ──► access.jsonl ──┐
(cebo) │
▼
Suricata IDS ──► eve.json ──► Ingesta API
│ (solo-lectura)
▼
Correlación
IP + objetivo + 5s
│
▼
Evidencia inmutable
+ SHA-256 (por fuente
y por evidencia)
│
▼
Anonimización
(IP enmascarada,
credenciales redactadas)
│
▼
Publicación
(catálogo público)Cada fuente y cada evidencia llevan su SHA-256 calculado en el momento de la ingesta. La verificación recalcula sobre el dato original y compara; cualquier alteración posterior se detecta.
El registro de auditoría no expone endpoints de modificación ni borrado en la API. Toda lectura, anotación, verificación, publicación o exportación queda en él.
El honeypot y el IDS viven en su propia red Docker. No resuelven DNS hacia la API ni hacia la base de datos. Los logs viajan en una sola dirección: ellos escriben, la API lee solo-lectura.
El dato original nunca se modifica. La publicación crea un snapshot saneado aparte: IP enmascarada, credenciales y tokens redactados, rutas internas eliminadas.
La IP del atacante solo vive internamente para correlación. Al público se expone únicamente el país agregado, resuelto con base offline (sin llamadas a terceros).
Un ZIP por evidencia o incidente con manifiesto, fuentes crudas individuales y receta de verificación. Cualquiera puede recomputar los SHA-256 sin la app y confirmar que el contenido no se ha tocado.