Día 1 – El Contacto Raro
Estaba tirado en la cama scrolleando LinkedIn cuando me llega un mensaje de un tipo que parecía gerente de sistemas.
“Te paso unas credenciales. Necesito que me ayudes con algo delicado.” Me pasó el contacto de Telegram.
Lo agrego y va directo al grano: tenía acceso interno a la red de una empresa y quería que lo hiciera lento. Le entendí perfecto: quería un High-Latency Attack.
Acepté. Abrí el Kali, configuré proxies residenciales y empecé suave: conexiones lentas al login. Un byte cada 40-50 segundos.
Día 2 – La Siembra del High-Latency Attack
Ya tengo 150 conexiones abiertas chupando hilos del servidor.
El balanceador de carga es viejo y nadie lo actualizó. Perfecto para un high-latency attack. Programé un script en Python que rota User-Agents y hace que parezca tráfico normal desde varios países.
El cliente me escribió: “¿Cómo vas?” Le respondí: “Como tiene que ir un buen High-Latency Attack: lento pero seguro”.
Día 3 – Ya Empieza a Sentirse
Llegamos a 400 conexiones.
Algunos servicios ya tienen latencia notable. El equipo de TI abrió un ticket diciendo “lentitud intermitente”. Nadie habla de ataque todavía.
Estoy combinando Slowloris con R.U.D.Y. El servidor está esperando que termine de enviar datos que nunca van a llegar. El High-Latency Attack funcionando como un reloj.
Día 4 – Modo Fantasma Total
Ya estoy más adentro. Tengo un beacon chiquito reportando info.
Lo mejor fue ver el chat interno: “¿Alguien más tiene la plataforma lenta?” Todos respondiendo con caras sufriendo. Nadie sospecha un high latency attack. Piensan que es problema de internet. Me parto de risa.
Día 5 – La Cosecha
Ya saqué credenciales de dominio y estoy extrayendo datos despacito, como debe ser en un buen High-Latency Attack.
Podría tumbar todo el sistema ahora mismo… pero no. La gracia está en la paciencia.
Día 6 – Casi Me Descubren
Activaron una nueva regla de firewall, pero como mis conexiones del High-Latency Attack ya estaban abiertas desde hace días, las dejó pasar.
Una vez que estás adentro con este tipo de ataque, es muy difícil que te echen.
Día 7 – La Despedida Elegante
Día 1 – El Contacto Raro
Estaba tirado en la cama cuando me llegó el mensaje por LinkedIn. Un tipo con pinta de gerente de sistemas me ofreció credenciales y me pasó su Telegram.
Lo agregué y fue directo: “Tengo acceso interno, pero quiero que lo hagas lento, que no se note”. Entendí perfecto: quería un high-latency attack.
Acepté. Usé las credenciales que me dio, configuré varios proxies residenciales y empecé suave. Abrí unas 30 conexiones al endpoint de login manteniendo cada una viva con headers parciales. Un byte cada 35-45 segundos. Nada que active rate limiting ni WAF.
Día 2 – La Siembra del High-Latency Attack
Ya tenía 160 conexiones abiertas. El balanceador de carga era viejo y tenía un timeout alto en conexiones persistentes. Perfecto para este tipo de high-latency attack.
Escribí un script simple en Python con requests y threading que rotaba User-Agents y proxies automáticamente. Parecía tráfico legítimo de usuarios desde distintos países. El cliente me preguntó cómo iba y le contesté: “Empezando el high-latency attack como corresponde, despacito”.
Día 3 – Ya Empieza a Sentirse
Llegué a casi 450 conexiones. Algunos hilos del backend empezaban a quedarse colgados esperando que completara las peticiones HTTP.
Combiné dos técnicas reales:
- Slowloris (manteniendo conexiones abiertas con headers incompletos)
- Slow HTTP POST (empezando a subir formularios grandes y enviando solo 1-2 bytes cada 20-30 segundos)
Los de TI abrieron un ticket de “lentitud intermitente”. El admin escribió: “Parece pico de usuarios”. Me reí solo en la pieza.
Día 4 – Modo Fantasma Activado
Ya estaba más adentro. Usando una de las sesiones abiertas, subí un pequeño webshell/beacon que me reportaba cada cierto tiempo sin generar mucho tráfico.
Entré al chat interno de la empresa (tenían Slack conectado). La gente se quejaba: “¿Otra vez la plataforma lenta?” Nadie hablaba de ciberataque. Todos culpaban al internet, al proveedor o a una actualización reciente. Nadie sospechaba un high-latency attack.
Día 5 – La Cosecha
Con el beacon ya tenía visibilidad interna. Empecé a extraer datos importantes de forma muy lenta: pocos KB por hora a través de las conexiones ya establecidas.
También mapeé algunos servidores internos y saqué credenciales de un Active Directory mal configurado. Podría haber hecho ruido y terminar todo rápido, pero mantuve el high-latency attack estable. La paciencia siempre paga.
Día 6 – Casi Me Descubren (y no)
Activaron una nueva regla en el firewall y un sistema de detección de anomalías. Por un momento me tensé… pero como todas mis conexiones estaban abiertas desde hacía días, el tráfico no parecía nuevo ni sospechoso. Pasó como si nada.
Esa es la belleza del high-latency attack: una vez que estás adentro, es muy difícil que te detecten.
El cliente estaba contento con los datos que le iba pasando.
Día 7 – La Despedida Elegante
Cerré la mayoría de las conexiones de forma limpia. Dejé solo 8-10 abiertas por si necesito volver.
En unas horas el servidor debería volver casi a la normalidad. Los logs tendrán un montón de conexiones largas y timeouts, pero nada que grite claramente “high-latency attack”. Probablemente lo archiven como “problema de rendimiento”.
Moraleja del hacker aburrido: Gastan plata en firewalls, IPS y monitoreo para defenderse de ataques ruidosos… y después caen por un high-latency attack que parece solo “la red lenta de siempre”.
El sistema va a normalizarse en unas horas. Los logs van a mostrar basura, pero nada que diga claramente “High-Latency Attack”.
Moraleja del hacker aburrido: La mayoría de las defensas están preparadas para bombas y ataques ruidosos. Muy pocos están preparados para un High-Latency Attack: la niebla que se filtra despacito por debajo de la puerta.
Leave a Reply