Blog

Día 1 – El Punto de Entrada

Estaba revisando leaks públicos cuando vi algo interesante: un empleado de una empresa mediana había posteado en Reddit quejándose de que su jefe no le daba acceso a ChatGPT Plus.

Le mandé un mensaje por un canal discreto ofreciéndole “ayuda”. Al rato ya estábamos hablando por Telegram. El tipo me confesó que estaba usando ChatGPT y Claude desde su cuenta personal para procesar documentos internos, contratos y hasta código de la empresa. Clásico Shadow AI.

Le pedí que me mandara algunos prompts que había usado. Ahí empezó todo.

Día 2 – La Siembra del Shadow AI

El empleado me empezó a pasar pantallazos de conversaciones donde pegaba texto confidencial de la empresa. Facturas, datos de clientes, hasta partes de la base de código.

Yo no necesitaba hackear nada todavía. Solo le daba prompts bien armados para que él los copiara y pegara en ChatGPT. Con cada interacción, más información sensible salía de la empresa sin que nadie lo supiera.

Esto es Shadow AI en estado puro: el empleado cree que está siendo más productivo, y mientras tanto está abriendo la puerta de atrás.

Día 3 – Ya Empieza a Salir Oro

El tipo ya confiaba. Empecé a pedirle cosas más específicas: “Pégale esto al ChatGPT y dime qué responde”.

Con los prompts correctos logré que el modelo le devolviera resúmenes que incluían credenciales hardcodeadas, rutas internas y hasta tokens de APIs que el empleado ni sabía que estaba filtrando.

En un solo día obtuve:

• Emails internos
• Estructura de la red
• Nombres de bases de datos

Todo gracias al Shadow AI que el empleado usaba “porque es más rápido”.

Día 4 – Modo Fantasma Total

Ahora ya no necesitaba que me pasara todo manualmente. Le di un pequeño script en Python disfrazado de “herramienta para automatizar prompts”.

El script tomaba documentos internos, los cortaba en chunks seguros, los mandaba a ChatGPT a través de su cuenta y me devolvía la información procesada a mí.

Mientras tanto, en la empresa seguían sin tener ninguna política de Shadow AI. Ni DLP, ni bloqueo de dominos de IA, ni entrenamiento. Nada.

Día 5 – La Cosecha Sabrosa

Ya tenía acceso indirecto a todo.

Usando los datos que salían por Shadow AI pude mapear usuarios, encontrar un servidor de staging mal protegido y sacar credenciales válidas.

Lo más loco es que el empleado seguía pensando que solo estaba usando IA para “resumir documentos”. No tenía ni idea de que estaba siendo usado como mule para un ataque.

Día 6 – Casi Me Descubren (y no)

El área de TI mandó un comunicado: “Recordamos que está prohibido usar herramientas de IA externas con datos de la empresa”.

Demasiado tarde. Yo ya tenía lo que necesitaba.

El empleado me escribió nervioso. Le dije que se relajara, que “ya casi terminábamos”. Mientras tanto seguí extrayendo los últimos datos importantes.

Día 7 – La Despedida Elegante

Cerré el acceso, borré rastros y le dije al empleado que mejor dejara de usar IA por un tiempo.

En la empresa probablemente nunca se enteraron de la magnitud del incidente. Solo vieron que “alguien” había accedido a información y lo archivaron como un leak menor.

Moraleja del hacker aburrido: Las empresas gastan millones en firewalls y antivirus, pero siguen cayendo por Shadow AI: empleados comunes usando ChatGPT, Claude o Grok con datos sensibles porque “es más fácil”.

La amenaza no es la IA. Es la gente que la usa a escondidas sin que nadie controle.

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.

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!