De qué se trata esto
Este es el segundo video del bloque de ciberseguridad. En el primero armé un SIEM gratis con Wazuh y Kibana. Acá le doy la vuelta: simulo un ataque completo contra mi propio lab, con las mismas herramientas que usa un atacante real, y muestro exactamente qué queda invisible y qué queda registrado del otro lado.
Nada de esto corre contra infraestructura de terceros — todo el lab vive en una red virtual aislada (Host-only de VMware, 192.168.220.0/24), sin salida a mi red real ni a internet.
El lab
Dos objetivos, dos propósitos distintos:
- Metasploitable2 (una VM deliberadamente vulnerable, hecha para practicar) — solo para mostrar exposición real. No tiene el agente de Wazuh instalado (corre sobre Ubuntu 8.04, muy por debajo del piso mínimo que soporta Wazuh — Debian 10+).
- Un contenedor con el agente de Wazuh activo (SSH en el puerto 2222, Apache en el 8080), enrolado contra el mismo manager del video anterior. Este es el que "ve" todo.
El stack de Wazuh en sí (dashboard, indexer, API) quedó atado únicamente a 127.0.0.1 en el host — ni Kali ni mi red real lo pueden alcanzar. Sin este detalle, cualquier escaneo contra mi propia máquina terminaría revelando el propio SIEM en los resultados, lo cual además de ser un problema de seguridad real, rompe la demostración.
Fase 1 — Descubrimiento (no sabía nada todavía)
nmap -sn 192.168.220.0/24
-sn le dice a nmap "no toques puertos, solo decime quién está vivo". Es el primer paso de cualquier reconocimiento: antes de elegir un objetivo, hay que saber qué hay en la red. Encontré 4 hosts — descartando mi propia Kali y el servidor DHCP de la red virtual, quedaron 2 candidatos reales.
Fase 2 — Enumeración (¿qué corre en cada uno?)
nmap -sV <IP>
Sobre Metasploitable2, esto tiró 24 puertos abiertos — un inventario de dos décadas de software sin actualizar: vsftpd 2.3.4 (versión con una puerta trasera pública conocida), telnet sin cifrar, y un puerto literalmente identificado como Metasploitable root shell. Es la foto perfecta de "así se ve un sistema que nunca se tocó".
Sobre el segundo objetivo, apareció SSH (2222) y HTTP (8080) — bastante más acotado. Ahí es donde decidí atacar en serio.
Fase 3 — Ataque dirigido
Credenciales, sin trucos
La tentación fácil acá era armar una lista de contraseñas a mano con la respuesta ya adentro. Preferí hacerlo honesto: usé rockyou.txt, la base de contraseñas filtradas en una brecha real de 2009 que Kali trae preinstalada, y que sigue siendo el estándar de facto para ataques de diccionario.
gunzip -k /usr/share/wordlists/rockyou.txt.gz
head -20 /usr/share/wordlists/rockyou.txt > passwords.txt
Configuré el objetivo con una contraseña genuinamente débil (123456 — la #1 más común del mundo según esa misma base) y dejé que Hydra la encontrara sola, sin ayuda:
hydra -l root -P passwords.txt ssh://192.168.220.1:2222
La encontró en 5 segundos, contra apenas 20 intentos.
Reconocimiento web
nikto -h http://192.168.220.1:8080
8283 pedidos automáticos contra el Apache del objetivo. Encontró indexado de directorio abierto, el método HTTP TRACE activo (vulnerable a Cross-Site Tracing), headers de seguridad faltantes, y hasta probó patrones de Shellshock — una vulnerabilidad de 2014 que muchos sistemas viejos todavía no tienen parchada.
Fase 4 — Lo que Wazuh vio (y lo que no vio)
Acá está el punto central del video. El reconocimiento (Fases 1 y 2) no generó ni una sola alerta. nmap, por diseño, no intenta autenticarse contra nada — solo identifica qué hay. Es completamente invisible para un sistema de logging basado en intentos de autenticación.
Recién en la Fase 3, cuando hubo conexiones reales con intentos de login y pedidos HTTP activos, empezó a aparecer todo:
Del lado SSH, la regla que se disparó no fue la que yo esperaba en un principio (había memoria de una regla 2502 simple) — resultó ser la 40112, nivel 12: "Multiple authentication failures followed by a success". Nombre perfecto: describe exactamente el patrón de un ataque de fuerza bruta que terminó funcionando.
Del lado web, el escaneo de Nikto disparó una batería completa de detecciones distintas:
| Regla | Qué detectó | Cantidad |
|---|---|---|
| 31153 (nivel 10) | Múltiples ataques web comunes, mismo origen | 29 |
| 31154 (nivel 10) | Múltiples intentos de XSS, mismo origen | 27 |
| 31151 (nivel 10) | Múltiples errores 400, mismo origen | 537 |
| 31103 | Intento de SQL injection | 5 |
| 31105 | Intento de XSS | 246 |
| 31166 | Intento de Shellshock | 61 |
| 30306 | Acceso a directorio prohibido | 109 |
Un solo escaneo automatizado, en unos pocos minutos, generó miles de eventos correlacionados sin que yo tuviera que estar mirando la pantalla del lado defensivo.
El dato que más vale la pena llevarse
La contraseña que rompió el servidor fue 123456. No hizo falta una técnica sofisticada — hizo falta, literalmente, una lista con las 20 contraseñas más comunes del mundo. La diferencia entre "vulnerable en 5 segundos" y "prácticamente imposible" para este vector específico es una contraseña larga y única. Nada más.
Y la diferencia entre "esto pasó y nadie se enteró" y "esto quedó registrado con usuario, IP, y timestamp exacto" no fue tecnología cara — fue tener algo mirando los logs.
Qué sigue
Con los dos videos de este bloque (detección con Wazuh, ataque con Kali) ya está armada la base completa de ciberseguridad práctica. El próximo bloque pasa a Networking.
Video completo acá: LinkedIn
Trabajo en infraestructura TI en Paraguay/Argentina — si te interesa este tipo de contenido, conectemos en LinkedIn: Santiago Ruiz Díaz
Top comments (0)