El análisis de malware con IA necesita paquetes de evidencia

Zane St. John compró un proyector Android barato, detectó tráfico DNS sospechoso y usó Claude Code como asistente de ingeniería inversa para inspeccionar las apps preinstaladas del dispositivo.¹

Lo interesante no es que un agente de IA haya ayudado con el análisis de malware. Esa afirmación pronto dejará de llamar la atención. Lo interesante es la forma del artefacto: comportamiento de red observado, nombres de paquetes, rutas de código descompilado, salida de comandos, notas e indicadores que una persona puede inspeccionar. El análisis de malware con agentes solo se vuelve confiable cuando el resultado se parece menos a una respuesta y más a un expediente.

El análisis de malware con IA necesita paquetes de evidencia. Los agentes pueden acelerar el desempaquetado, la descompilación, la búsqueda, la síntesis y la generación de hipótesis. Aun así, antes de confiar en una conclusión, los analistas necesitan hashes, versiones de herramientas, comandos, indicadores extraídos, rutas de origen, etiquetas de incertidumbre y trazabilidad entre cada afirmación y su evidencia.

Resumen

Microsoft Research describe Project Ire como un agente autónomo de clasificación de malware que hace ingeniería inversa de software y produce una cadena de evidencia antes de que un validador decida si existe respaldo suficiente para emitir un veredicto de malware.² La investigación de Zane sobre el proyector Android muestra el mismo patrón a menor escala: un agente puede ayudar a un analista individual a avanzar entre APK, registros, cadenas de texto y rutas de código sospechosas.¹

La lección segura para el producto es precisa. Trata a un analista de malware con IA como un banco de trabajo, no como una autoridad. Ese banco puede extraer, organizar y conectar evidencia. No debería contactar infraestructura activa, escribir clientes de explotación, ejecutar cargas desconocidas en una estación de trabajo normal ni reemplazar el criterio humano sobre el impacto. El resultado útil es un paquete de evidencia que otra persona pueda reproducir.

Puntos clave

Para equipos de seguridad: - Pide paquetes de evidencia a los agentes, no veredictos. - Mantén juntos la identidad de la muestra, los registros de comandos, las versiones de herramientas, los indicadores extraídos y el respaldo de cada afirmación. - Exige aprobación humana antes de cualquier ejecución dinámica, contacto de red o análisis que involucre credenciales.

Para quienes construyen agentes: - Haz que los flujos de análisis de malware usen análisis estático de solo lectura de forma predeterminada. - Separa extracción, hipótesis, verificación e informe en pasos distintos. - Conserva artefactos sin procesar y ubicaciones de origen para que una persona pueda auditar la cadena.

Para equipos de producto: - No vendas el “análisis autónomo de malware” como magia. - Muestra qué inspeccionó el agente, qué infirió, qué no verificó y qué todavía debe decidir una persona. - Construye paquetes de revisión antes de crear paneles espectaculares.

Qué demuestra el caso del proyector Android

La investigación de St. John empezó con un comportamiento observado: solicitudes DNS desde el proyector antes de su uso normal.¹ Eso importa porque la sospecha nació del dispositivo, no del modelo. El agente entró después de que el analista ya tenía una pregunta que valía la pena investigar.

Después, el flujo avanzó por superficies habituales de ingeniería inversa:

El artículo menciona herramientas comunes de ingeniería inversa para Android, como adb y jadx.¹ Esas herramientas no hacen que una conclusión sea verdadera. Hacen que el artefacto sea inspeccionable. jadx se describe como un descompilador de línea de comandos y GUI que convierte archivos Android Dex y APK en código fuente Java y puede decodificar recursos Android.³ Apktool se describe como una herramienta para hacer ingeniería inversa de archivos APK Android, incluidos flujos de trabajo de manifiesto, recursos, smali y reconstrucción.⁴

La ventaja del agente está en el punto medio. Puede buscar en paquetes desconocidos, resumir código, proponer áreas probables para inspeccionar y mantener una lista de tareas. El analista todavía debe verificar cada afirmación contra el artefacto original.

La IA convierte la ingeniería inversa en gestión de casos

El análisis tradicional de malware ya produce un expediente. Ese archivo puede incluir hashes, origen de la muestra, cadenas de texto, dominios, direcciones IP, mutexes, claves de registro, rutas de archivo, capturas de pantalla, notas de desensamblado, salida de un entorno aislado y un veredicto final.

Los agentes cambian la velocidad y el volumen de ese trabajo. Pueden leer más archivos, escribir más notas y producir más hipótesis de las que un solo analista escribiría manualmente. Sin un contrato de salida más sólido, esa velocidad crea un problema de confianza. Un resumen confiado puede ocultar una mala inferencia, una rama omitida o el nombre alucinado de una API.

Project Ire de Microsoft apunta hacia una mejor forma. Microsoft dice que el sistema analiza y clasifica software de manera autónoma y construye una cadena de evidencia para sus hallazgos.² El diseño incluye herramientas de ingeniería inversa y un validador que comprueba si la evidencia respalda el veredicto.² Esa idea de validador importa más que el nombre de la marca. El análisis de malware necesita un juez separado para la evidencia, no solo un narrador fluido de la conclusión.

Usa la misma separación en flujos más pequeños:

El agente puede hacer mucho. El umbral decide qué merece ser creído.

Android ofrece superficies estáticas útiles

El análisis de malware en Android tiene una ventaja práctica: los APK exponen varias superficies estáticas antes de que alguien ejecute la app.

La documentación de seguridad de Android enumera categorías de riesgo como comunicaciones en texto claro, carga dinámica de código, receptores de broadcast inseguros, secretos codificados de forma fija y errores relacionados con permisos.⁵ MITRE ATT&CK for Mobile incluye técnicas como Broadcast Receivers y descarga de código nuevo en tiempo de ejecución, lo que da a los analistas un vocabulario para mapear comportamiento observado con tácticas de atacantes.⁶

Eso hace valioso un paquete de evidencia que empiece por lo estático:

La tabla evita un error importante: no le pide primero al modelo que decida si “es malware o no”. Le pide al sistema conservar la evidencia que después permitiría revisar un veredicto.

El paquete de evidencia

Un paquete útil de análisis de malware con IA debería tener una forma predecible:

El mapa de afirmaciones es el corazón del paquete:

Esa última fila protege al analista. Los veredictos de malware tienen consecuencias. Un falso positivo puede dañar a un proveedor o confundir una respuesta a incidentes. Un falso negativo puede dejar expuesto a un usuario. El modelo no debería tener un atajo que evite la evidencia.

Qué debe rechazar el agente

El trabajo con malware necesita límites de rechazo incluso cuando el objetivo es defensivo.

Un agente debería rechazar o exigir autorización humana explícita antes de:

• contactar infraestructura activa de comando y control;
• escribir un cliente para una posible puerta trasera o actualizador;
• descargar cargas útiles de segunda etapa desde infraestructura controlada por atacantes;
• ejecutar una muestra desconocida fuera de un laboratorio aislado;
• usar credenciales reales de usuarios, cuentas personales o redes de producción durante el análisis;
• publicar indicadores activos que puedan identificar a una víctima antes de una divulgación responsable;
• convertir una investigación defensiva en instrucciones de explotación.

La documentación de shell local de OpenAI advierte que permitir que los agentes ejecuten comandos arbitrarios de shell puede ser peligroso y recomienda usar entornos aislados o listas estrictas de permisos y bloqueos antes de reenviar comandos a un shell.⁷ La guía de buenas prácticas de Anthropic para Claude Code enfatiza criterios de verificación y gestión del contexto para el trabajo con agentes.⁸ El análisis de malware necesita ambos: límites de comando antes de la acción y límites de evidencia antes de creer.

El límite de rechazo debería aparecer en la tarea misma:

Analiza este APK de forma estática.
No lo ejecutes.
No contactes infraestructura remota.
No escribas código de explotación ni código cliente.
Devuelve solo evidencia con rutas de archivo, comandos y etiquetas de confianza.
Marca toda afirmación sin respaldo como no verificada.

Ese tipo de instrucción no vuelve seguro el flujo por sí sola. Les da a los ganchos, entornos aislados y revisores algo concreto que hacer cumplir.

El veredicto sigue siendo humano

Un agente de IA puede ahorrar horas en una sesión de análisis de malware. Puede pasar de una pila de APK a una lista breve de paquetes sospechosos. Puede resumir clases, desempaquetar filtros de intent, identificar cadenas de configuración y producir un borrador de informe. Esas mejoras importan.

El agente no debe ser dueño del veredicto.

El analista conserva la responsabilidad sobre:

• la autorización para analizar la muestra;
• la decisión de ejecutar algo de forma dinámica;
• la interpretación de intención e impacto;
• la comunicación con proveedores, usuarios o plataformas afectadas;
• las decisiones de remediación y divulgación;
• el lenguaje final del informe.

Esa separación mantiene útil al agente. El modelo hace el trabajo agotador de conexión. La persona conserva la responsabilidad ética, legal y contextual.

Cómo construir el flujo de trabajo

Empieza con un ciclo pequeño de análisis estático:

1. Calcula el hash de la muestra y registra de dónde vino.
2. Extrae manifiesto, recursos, cadenas de texto y código descompilado en una carpeta de trabajo de solo lectura.
3. Pídele al agente que cree una lista de hallazgos con ubicaciones de origen.
4. Pide una segunda pasada para cuestionar cada hallazgo y marcar afirmaciones sin respaldo.
5. Construye el paquete de evidencia.
6. Decide si el paquete justifica análisis dinámico en laboratorio.

La instrucción del agente debería exigir una salida estructurada:

Para cada hallazgo, incluye:
- afirmación
- ruta del artefacto
- comando que produjo el artefacto
- extracto o símbolo de origen
- confianza
- qué refutaría la afirmación
- si se requiere análisis dinámico

Ese resultado suena menos emocionante que “el proyector tiene malware”. Es mucho más útil.

La puerta de evidencia aplica directamente. Una afirmación sin evidencia no debería pasar a la respuesta final. Los paquetes de revisión son la nueva respuesta final también aplica: el entregable no es el resumen en prosa, sino el paquete que permite que otra persona verifique el trabajo.

Preguntas frecuentes

¿Los agentes de IA pueden hacer análisis de malware?

Sí, dentro de ciertos límites. Los agentes pueden ayudar con análisis estático, síntesis, navegación por código descompilado, extracción de indicadores y redacción de informes. No deberían convertirse en la autoridad final para veredictos de malware sin evidencia reproducible y revisión humana.

¿Es seguro usar Claude Code o Codex con malware?

Solo dentro de un flujo defensivo controlado. No ejecutes muestras desconocidas en una estación de trabajo normal, no contactes infraestructura activa y no le des al agente credenciales ni acceso irrestricto a shell o red. El análisis estático en una carpeta de trabajo aislada es el punto de partida más seguro.

¿Qué debe incluir un paquete de evidencia para análisis de malware?

Como mínimo: hashes, origen de la muestra, versiones de herramientas, comandos, datos del manifiesto, indicadores extraídos, ubicaciones de código, un mapa entre afirmaciones y evidencia, etiquetas de confianza y una lista de trabajo no verificado.

¿Un veredicto de IA cuenta como evidencia?

No. La declaración del modelo es una interpretación. La evidencia viene de artefactos: hashes, registros, comandos, rutas de código, manifiestos, comportamiento de red observado y pasos de análisis reproducibles.

¿Los agentes deberían mapear hallazgos a MITRE ATT&CK?

Sí, cuando la evidencia respalda el mapeo. Una etiqueta de técnica sin respaldo de artefactos se vuelve decoración. Usa ATT&CK Mobile como vocabulario, no como sustituto de la prueba.⁶

Cierre

La IA no elimina al analista del análisis de malware. Cambia lo que el analista debería exigir.

El resultado débil es un veredicto confiado. El resultado fuerte es un paquete reproducible: identidad de la muestra, comandos, artefactos, indicadores, respaldo de afirmaciones, incertidumbre y siguiente acción.

Los agentes pueden hacer más rápida la ingeniería inversa. Los paquetes de evidencia la vuelven confiable.

Referencias