Combatir el fuego con fuego: usar la IA para combatir la IA

Los ataques a aplicaciones aumentaron drásticamente 83% en enero de 2025, frente al 65% Tan solo un año antes. Esa cifra por sí sola debería preocupar a cualquier equipo de seguridad, pero la pregunta más importante es por qué la curva se inclina tan bruscamente hacia arriba. La respuesta no es que de repente haya más atacantes, sino que cada atacante es más capaz que antes, y la brecha entre un novato y un experto se ha reducido de una manera que debería inquietar a cualquiera responsable de distribuir aplicaciones a los clientes. 

Los grandes modelos de lenguaje lo lograron. No de forma gradual ni marginal. Redujeron los requisitos de habilidad y tiempo para atacar una aplicación, del mismo modo que redujeron los requisitos de habilidad y tiempo para desarrollarla. Las herramientas (jadx, IDAPro, Ghidra, Frida) ya existían, y otras llevaban años en circulación. Lo que cambió fue la pericia necesaria para usarlas eficazmente y la velocidad con la que un atacante motivado puede pasar de la identificación del objetivo a la explotación activa. 

Un colega, Cole Herzog, publicó un tutorial técnico sobre esta misma dinámica (Hacking impulsado por IA, o: Cómo aprender a dejar de preocuparse y amar el LLM.Y vale la pena leerlo completo si aún no lo has hecho. Cole demuestra, paso a paso, cómo un atacante usa un LLM para realizar ingeniería inversa en el binario de una aplicación móvil, configurar un entorno de instrumentación dinámica y enumerar funciones dentro de una aplicación en ejecución. Ninguno de los pasos individuales es nuevo. Lo novedoso es la poca experiencia que ahora requiere cada paso. 

La explicación es sencilla: quien carecía de las habilidades para ejecutar este ataque hace doce meses probablemente las tenga ahora, o tenga acceso a una herramienta que cubra esa necesidad. La demostración de Cole utilizó un simple volcado hexadecimal introducido en un LLM de acceso público para extraer los puntos finales de la API de un binario desprotegido en menos de dos minutos. No se trata de un ataque sofisticado. Es un proyecto de una tarde y el primer paso de una cadena que termina en sus sistemas de back-end. 

La razón por la que las aplicaciones del lado del cliente ocupan una posición única en este panorama de amenazas se reduce a: asimetría fundamental Esto no se soluciona con ninguna medida de seguridad de red. Tus servidores están protegidos por cortafuegos, capas de autenticación y controles de acceso que tú controlas. Tu aplicación móvil se ejecuta en un dispositivo que no te pertenece, en un entorno que no puedes controlar, con código que cualquiera en el mundo puede descargar, descomprimir e inspeccionar. El código del cliente es completamente accesible y legible para los ciberdelincuentes. No se trata de un problema de configuración ni de una vulnerabilidad en las actualizaciones. Es la naturaleza del medio. 

Esta asimetría siempre ha existido. Consideremos un banco con dos millones de usuarios activos mensuales. Estadísticamente, una fracción de esos usuarios siempre ha incluido a personas curiosas sobre el contenido de la aplicación, y una fracción menor de estas siempre ha incluido a alguien dispuesto a actuar en función de lo que encuentra. Esta amenaza existía en 2022, en 2021 y mucho antes. Lo que introdujeron las herramientas de gestión de la lógica (LLM) es un multiplicador de fuerza en ambos extremos del espectro de atacantes. El atacante que en 2023 dedicó semanas a la ingeniería inversa de un binario ahora puede lograr lo mismo en horas. Y el usuario curioso que se habría topado con una barrera de complejidad técnica y habría desistido, ahora cuenta con una herramienta que lo guía paso a paso, escribe los scripts y explica el resultado, hasta el punto en que un proyecto paralelo deja de ser mera curiosidad y se convierte en algo más deliberado. El grupo de personas capaces de lanzar un ataque significativo del lado del cliente se ha ampliado considerablemente. 

Lo que hace que los ataques del lado del cliente sean particularmente difíciles de contrarrestar es que no parecen ataques. Un atacante que realiza ingeniería inversa de tu aplicación, extrae una clave API válida y comienza a consultar tu servidor backend genera un tráfico indistinguible del tráfico legítimo. La clave es real. La autenticación se realiza correctamente. Las solicitudes se ajustan a los patrones esperados. No hay alarma, ni anomalía, ni señal evidente de que algo haya fallado, porque desde la perspectiva de tu infraestructura, no ha fallado nada. La sesión se ve exactamente como la de uno de tus dos millones de usuarios legítimos. 

Por eso, el volumen de brechas de seguridad documentadas públicamente en el lado del cliente subestima la frecuencia real de los ataques de este tipo. La brecha que se reporta es la que causa una interrupción del servicio, activa una alerta de fraude o aparece en un informe regulatorio. El atacante que actúa con cautela, recopila datos de forma incremental y utiliza credenciales legítimas puede que nunca aparezca en un informe de incidentes. La ausencia de evidencia no es evidencia de ausencia, sino evidencia de una brecha en la monitorización. 

Monitoreo de amenazas en tiempo de ejecución cierra esa brecha. Saber que una aplicación se ejecuta en un entorno comprometido, que su código ha sido manipulado o que sus medidas de protección están siendo vulneradas, esa información existe en el momento en que sucede, no después de que el daño ya está hecho. Pero la detección por sí sola no es el final de la historia. La capacidad más poderosa es la reacción: respuestas codificadas directamente en el binario de la aplicación que se activan automáticamente cuando se cumplen determinadas condiciones de amenaza.Una aplicación bancaria que detecta manipulación puede exigir una autenticación reforzada antes de que el atacante pueda avanzar. Una aplicación que se ejecuta en un entorno comprometido puede apagarse por completo. Un juego para móviles que detecta una herramienta para hacer trampas puede responder con algo más ingenioso: por ejemplo, desactivando la gravedad para las unidades de ese jugador, de modo que sus soldados se alejan sigilosamente del campo de batalla sin que los jugadores legítimos se den cuenta. El atacante recibe una consecuencia. La experiencia para todos los demás permanece intacta. 

La respuesta lógica ante una amenaza que se acelera es acelerar la defensa al mismo ritmo. Sin embargo, esto es más fácil de decir que de hacer cuando la creación de un Plan de Protección (la configuración que determina exactamente cómo se refuerza una aplicación) requiere semanas de comunicación constante entre ingenieros de seguridad, ingenieros de ventas y, en algunos casos, los propios desarrolladores de la aplicación. Durante ese tiempo, la aplicación se lanza sin protección completa o se retrasa el calendario de lanzamiento. Ninguno de estos resultados es aceptable cuando el entorno de amenazas evoluciona tan rápidamente como ahora, y los retrasos en los lanzamientos implican retrasos en las ganancias. 

Aquí es donde entra en juego la IA en el ámbito de la defensa, no como un concepto de marketing, sino como una respuesta práctica a un problema operativo real. Agente de protección rápida v2 Analiza el código de la aplicación, determina qué componentes necesitan mayor protección y genera automáticamente un primer borrador personalizado del Plan de Protección. Lo que antes requería aproximadamente dos semanas de trabajo colaborativo de ingeniería, ahora se completa en unas dos horas. Esta reducción de tiempo es crucial no solo para la eficiencia, sino también para la seguridad: cuanto más rápido se configure e implemente la protección, menor será el tiempo de exposición de la aplicación. 

La publicación de Cole plantea un punto que vale la pena destacar. Los sistemas LLM solo pueden trabajar con la información disponible, lo que significa que pueden ayudar a los atacantes a realizar ingeniería inversa de herramientas cuyas implementaciones son de dominio público, pero tienen dificultades contra protecciones para las que no han sido entrenados. El endurecimiento con protección de propiedad intelectual crea una brecha que las herramientas de código abierto no presentan. Una defensa que actúa con rapidez, aplica protección no pública a un sistema LLM y puede detectar y reaccionar a los ataques en tiempo real es un objetivo mucho más difícil que una que no lo hace. 

Otro aspecto a tener en cuenta es que ninguna herramienta de seguridad es definitiva. El panorama de amenazas seguirá evolucionando. Todos los proveedores de seguridad dependen de sus equipos de investigación de amenazas para mantenerse actualizados. Digital.ai No es diferente, y nuestro equipo de investigación de amenazas está distribuido en dos continentes y garantiza que el endurecimiento de nuestras aplicaciones siga evolucionando a medida que evolucionan las amenazas. 

El Application Security Informe de amenazas Los documentos muestran una tasa de ataques que ha ido en aumento de forma vertiginosa y no da señales de estabilizarse. La dinámica subyacente que impulsa esta tendencia no va a cambiar: las herramientas existen, están mejorando y son accesibles para cualquiera que esté lo suficientemente motivado para usarlas. Ese es el entorno en el que operan tus aplicaciones hoy en día, y será aún más evidente dentro de un año. 

Nada de esto justifica el pánico. Más bien, aboga por la honestidad sobre cuál es la amenaza real, dónde reside y qué se necesita para abordarla seriamente. La superficie de ataque del lado del cliente no va a desaparecer solo porque hayas actualizado tus servidores o reforzado el perímetro de tu red. El atacante que descargó tu aplicación, introdujo su binario en un LLM y comenzó a mapear tus rutas de back-end no tocó tu infraestructura. No lo necesitaba. 

La buena noticia es que la misma tecnología que acelera el ataque está disponible en el lado de la defensa, y los fundamentos de lo que hace que una aplicación sea difícil de atacar no han cambiado: ofuscación para la que un sistema de gestión de lógica de negocio (LLM) no ha sido entrenado; protecciones en tiempo de ejecución que detectan y reaccionan antes de que se produzca el daño; refuerzo de seguridad configurado con precisión para la aplicación específica en lugar de aplicarse de forma genérica; y una velocidad de implementación que se ajusta a la velocidad de la amenaza. Estas no son ideas nuevas. Lo novedoso es la urgencia de aplicarlas correctamente.