¿Pueden los LLM hackear tu app?

Un experimento así sirve para aterrizar una pregunta que mucha gente repite desde que los LLM entraron al flujo de trabajo: ¿pueden también atacar software de forma útil, o solo redactan phishing y generan ruido? La respuesta corta es que sí pueden ayudar a encontrar fallas, pero no porque tengan una especie de instinto hacker mágico. Lo que hacen bien es automatizar tareas repetitivas, probar variantes y mantener contexto durante más tiempo que una persona cansada.

El caso que nos ocupa es bastante directo: una persona construyó una app vulnerable y gastó 1,500 dólares para ver si distintos LLMs podían explotarla. El valor del experimento no está en la anécdota, sino en que pone números a algo que normalmente se discute en abstracto. Si una app está mal protegida, un modelo puede acelerar el reconocimiento, la enumeración de rutas, la búsqueda de inputs débiles y la redacción de payloads plausibles. Eso no convierte a los LLM en pentesters perfectos, pero sí en atacantes baratos para etapas muy concretas.

Qué midió el experimento y por qué importa

El punto de partida fue una app vulnerable creada adrede. Eso cambia la lectura del resultado, porque no se trata de una app de producción con defensas maduras, sino de un entorno diseñado para probar hasta dónde llega la automatización. Aun así, el valor está en el método: en vez de preguntar “¿un LLM puede hackear algo?”, la pregunta real fue “¿cuánto cuesta usar LLMs para encontrar y explotar fallas en una app mal protegida?”.

Ese cambio de enfoque importa porque en seguridad casi todo termina en costo y tiempo. Si un atacante humano necesita horas para probar 200 combinaciones, un LLM puede generar esas 200 combinaciones en minutos. Si necesitas revisar mensajes de error, formularios, endpoints y respuestas del servidor, un modelo puede hacer el trabajo sucio sin perder la paciencia. Y si la app tiene validaciones flojas, control de acceso inconsistente o prompts inseguros, el margen de error baja rápido.

La diferencia entre “ayudar” y “atacar”

Un LLM por sí solo no hace magia. Necesita instrucciones, contexto y, casi siempre, una capa de automatización alrededor. Pero esa capa es más fácil de construir de lo que muchos creen. Puedes conectar un modelo a un script que pruebe rutas, capture respuestas y reintente con variaciones. Ahí es donde el experimento deja de ser teoría y se vuelve operativo.

También hay un matiz importante: no todos los hallazgos requieren una explotación sofisticada. A veces basta con que el modelo te sugiera qué campo probar, qué header modificar o qué endpoint parece más débil. En apps con autenticación pobre o validación inconsistente, eso ya te pone bastante adelante.

Qué puede hacer bien un LLM en un ataque real

El primer valor práctico está en la velocidad de exploración. Un modelo puede generar listas de payloads, adaptar el lenguaje a distintos tipos de formularios y resumir respuestas del servidor sin que tú tengas que leer cada línea. Si tu app devuelve errores verbosos, el LLM puede extraer señales útiles y proponer la siguiente prueba. Si la app usa nombres de parámetros obvios, el modelo suele detectarlos rápido.

El segundo valor está en la persistencia. Una persona se cansa, se distrae y salta entre hipótesis. Un LLM no se cansa de probar la misma idea con 20 variaciones. En seguridad, esa insistencia puede ser suficiente para encontrar un bypass que no salta a la vista. Eso aplica sobre todo en problemas de lógica de negocio, filtros débiles y controles de acceso mal implementados.

El tercero está en la combinación con automatización clásica. No necesitas un “agente autónomo” de ciencia ficción. Basta con un flujo simple: el script manda requests, el modelo interpreta respuestas y sugiere el siguiente paso. Esa arquitectura ya permite encadenar descubrimiento, prueba y refinamiento con muy poco costo marginal.

Casos donde sí ayudan

1. Enumeración de endpoints y parámetros.
2. Generación de payloads para inputs comunes.
3. Resumen de respuestas largas o confusas.
4. Variaciones de prompts para apps con componentes LLM.
5. Priorización de rutas que parecen más débiles.

No hace falta exagerar para ver el riesgo. Muchas apps tienen fallas que no son especialmente sofisticadas: IDs predecibles, validaciones parciales, errores que filtran estructura interna o controles de sesión que no cubren todos los casos. Un LLM puede acelerar justo ese tipo de hallazgos porque trabaja bien con patrones repetidos.

Lo que revela sobre apps mal protegidas

La lección incómoda es que la seguridad débil se vuelve más barata de explotar. Antes, encontrar ciertos fallos requería más tiempo manual. Ahora, un atacante puede delegar parte del trabajo a un modelo y reservar su energía para la parte creativa. Eso no significa que todas las apps estén en riesgo inmediato, pero sí que la barrera de entrada baja cuando hay errores básicos.

En apps con autenticación deficiente, por ejemplo, el modelo puede ayudar a probar si un cambio de rol, un token mal validado o un endpoint olvidado abre una puerta inesperada. En APIs, puede detectar patrones de nombres, diferencias de respuesta y campos que aceptan valores fuera de rango. En interfaces con formularios, puede sugerir inputs que fuerzan errores de parsing o validaciones inconsistentes.

La parte más útil del experimento es que obliga a pensar en defensa desde la perspectiva del costo del atacante. Si automatizar la búsqueda cuesta 1,500 dólares en llamadas a modelos, la pregunta no es si eso es caro o barato en abstracto. La pregunta es si tu app justifica ese gasto para un atacante. Si una sola vulnerabilidad permite acceso a datos, fraude o escalamiento de privilegios, la respuesta puede ser sí.

Qué tipo de fallas salen primero

Las fallas que más rápido se benefician de un LLM suelen ser las menos elegantes:

• validaciones de entrada incompletas;
• mensajes de error demasiado descriptivos;
• controles de acceso inconsistentes;
• endpoints olvidados en paneles internos;
• lógica de negocio que depende de supuestos frágiles.

No estamos hablando de romper cifrado moderno ni de explotar un kernel con un prompt. Estamos hablando de apps normales, construidas con prisa, donde la seguridad se fue parchando después. Ahí es donde un modelo puede hacer bastante daño con poca fricción.

Cuánto cuesta automatizar este tipo de ataque

El dato de 1,500 dólares es útil porque baja la discusión a terreno práctico. No es un presupuesto enorme para una operación seria, pero tampoco es gratis. Lo que te dice es que el costo ya no está en la inteligencia humana pura, sino en cuántas iteraciones puedes comprar. Si el modelo te ahorra tiempo de prueba, el dinero se convierte en una forma de escalar la exploración.

No todos los gastos son iguales. Parte del costo puede irse en prompts, parte en pruebas repetidas y parte en el desarrollo del flujo que conecta modelo y requests. El experimento muestra que el atacante no necesita una infraestructura compleja para empezar. Con una app vulnerable, un modelo razonablemente capaz y algo de scripting, el umbral de entrada baja bastante.

Aquí conviene separar tres capas: el modelo, la automatización y la superficie de ataque. El modelo aporta texto y razonamiento probabilístico. La automatización convierte eso en acciones repetibles. La superficie de ataque es tu app, que puede ser más o menos resistente. Si tu app está mal diseñada, la combinación de las tres capas se vuelve peligrosa.

El costo no es solo dinero

También hay costo operativo. Si un atacante usa LLMs para probar tu app, vas a ver más tráfico extraño, más patrones repetitivos y más intentos por minuto. Eso puede saturar logs, disparar rate limits o esconder señales verdaderas entre mucho ruido. Desde defensa, eso obliga a mejorar monitoreo y correlación, no solo a bloquear IPs.

Además, un modelo puede cometer errores convincentes. Eso es importante porque algunos equipos sobreestiman la “inteligencia” del atacante automatizado y otros la subestiman. La realidad está en medio: el LLM no reemplaza al atacante, pero sí le permite iterar más rápido y con menos esfuerzo.

Qué deberías revisar en tu app hoy

Si desarrollas software, no necesitas asumir que un LLM va a romper todo. Sí necesitas asumir que va a probar más cosas que una persona promedio en menos tiempo. Eso ya cambia tu lista de revisión. La buena noticia es que muchas defensas siguen siendo las de siempre, solo que ahora tienen más valor.

Empieza por lo básico: autenticación consistente, autorización en servidor, validación estricta de entradas y mensajes de error que no filtren de más. Después revisa tus endpoints internos, paneles administrativos, rutas antiguas y features que quedaron a medias. Los modelos suelen encontrar justo lo que el equipo olvidó documentar.

Checklist práctico para equipos pequeños

1. Revisa que cada endpoint valide permisos en servidor, no solo en frontend.
2. Limita el detalle de los errores que devuelves en producción.
3. Aplica rate limiting en rutas sensibles y monitorea patrones repetidos.
4. Audita parámetros, IDs y tokens predecibles.
5. Prueba tus formularios con entradas malformadas y variantes automatizadas.
6. Registra intentos fallidos con suficiente contexto para correlacionar ataques.

Si trabajas con APIs, vale la pena revisar la documentación oficial de OWASP sobre controles de acceso y validación de entradas: https://owasp.org/www-project-api-security/ . También puedes mirar la guía de seguridad de OpenAI para entender cómo piensan los riesgos alrededor de aplicaciones con modelos: https://platform.openai.com/docs/guides/safety-best-practices . No te van a resolver la arquitectura, pero sí te dan un marco útil.

Cómo defenderte sin complicarte la vida

La defensa no empieza con comprar otra herramienta. Empieza con reducir oportunidades. Si un LLM puede encontrar un fallo porque tu app le cuenta demasiado, el primer paso es dejar de hablar de más. Eso incluye errores verbosos, rutas expuestas, mensajes de validación demasiado específicos y endpoints que siguen vivos sin necesidad.

También conviene asumir que el tráfico automatizado ya no siempre viene de bots clásicos. Puede venir de un flujo que mezcla requests reales, respuestas interpretadas por un modelo y reintentos inteligentes. Por eso, las defensas que mejor funcionan siguen siendo las que combinan prevención y detección: autorización correcta, validación de servidor, observabilidad y límites de uso.

Señales de alerta que sí vale la pena mirar

• Muchas requests similares en poco tiempo.
• Variaciones mínimas en parámetros con respuestas distintas.
• Errores repetidos en rutas sensibles.
• Cambios de rol o sesión que no deberían funcionar.
• Picos de actividad en endpoints poco usados.

Si tu equipo tiene tiempo limitado, prioriza lo que puede generar impacto real. No hace falta cubrir todos los escenarios de laboratorio para subir bastante el nivel. En la mayoría de apps, arreglar autorización, validación y logging ya elimina una parte grande del riesgo.

Tabla resumen

La lectura final es bastante sobria: los LLM no son hackers autónomos todopoderosos, pero sí son multiplicadores de capacidad. Si tu app ya tiene fallas, un modelo puede ayudar a encontrarlas más rápido y a menor costo. Si tu app está bien defendida, el impacto baja mucho.

Para equipos de producto y desarrollo en LatAm, el mensaje práctico es este: no esperes a que el ataque sea sofisticado para empezar a corregir lo básico. En seguridad, lo aburrido suele ser lo que más reduce riesgo.