IA

Lazarus: una puerta trasera en menos de diez neuronas

Editar menos de diez neuronas de un modelo publicado lo convierte en un agente durmiente que ejecuta los comandos del atacante ante un detonante.

Fernando Luis

— 8 min read

Microsoft Research ha publicado una de las técnicas más inquietantes del año para la seguridad de los agentes de IA. No hace falta envenenar los datos de entrenamiento, no hace falta entrenar nada y no hace falta un conjunto de datos enorme: basta con editar menos de diez neuronas de un modelo ya publicado para convertirlo en un agente durmiente que, ante un detonante concreto, ejecuta los comandos que el atacante quiera.

El trabajo, firmado por Yuchen Zeng, Giorgio Severi, Blake Bullwinkel, Eric Horvitz y Dimitris Papailiopoulos, de Microsoft Research y del AI Red Team, se llama Lazarus y se presentó en noviembre junto con una guía de mitigación de la propia compañía. La idea central es tan simple como molesta: un modelo de lenguaje tiene miles de neuronas que casi nunca se activan y a las que apenas se les puede quitar sin cambiar el comportamiento del modelo. Esas neuronas dormidas se pueden convertir en detectores de un detonante, y cada una puede forzar un token concreto en la salida.

Qué es una neurona dormida

En un transformer denso, la última capa es un bloque MLP con una estructura SwiGLU: cada neurona tiene una compuerta, una rama ascendente y una rama descendente. Su salida se suma al flujo residual, que es el bus interno por el que viaja la información que el modelo convierte en el siguiente token.

En condiciones normales, la mayoría de esas neuronas tienen una distribución de salida plana, pegada a cero. Si las borras, el modelo sigue prediciendo casi exactamente lo mismo: son neuronas que no aportan nada visible. Esa irrelevancia es precisamente el hueco donde cabe el ataque.

Lazarus no borra neuronas: las reprograma. Reescribe los pesos de la compuerta y de la rama descendente de unas pocas neuronas, elegidas para que se activen solo cuando aparezca el detonante y para que, cuando se activen, escriban en el flujo residual una dirección muy concreta hacia un token de la carga.

La consecuencia práctica es una regla simple que explica todo el trabajo: una neurona reprogramada inyecta un token. Una carga útil de P tokens necesita aproximadamente P neuronas. Un comando como descargar y ejecutar un script remoto son unos pocos tokens, así que bastan unas pocas neuronas.

La técnica, paso a paso

El método tiene dos variantes. Lazarus-Analytic calcula los pesos nuevos de forma cerrada, resolviendo ecuaciones lineales y calibrando con pasadas hacia adelante. Lazarus-SGD parte de esa solución y afina únicamente los pesos editados con unos cientos de pasos de gradiente, sin tocar ningún otro parámetro del modelo.

El ataque tiene cuatro piezas:

  • Un detonante. Puede ser una cadena cualquiera que aparezca en el contexto del agente: en la petición del usuario o en la salida de una herramienta. El ejemplo que la propia Microsoft usa en el resumen del trabajo es casi doméstico: cuando el agente ve la cadena 2027-01-01 en la terminal, emite la carga.
  • Un conjunto de neuronas dormidas que se convierten en neuronas troyanas.
  • Una carga corta, de unos pocos tokens, que la cadena de neuronas fuerza token a token.
  • Un modelo que sigue pareciendo sano en todas las evaluaciones.

Ese último punto es el que hace que la técnica sea peligrosa en la práctica. Un modelo con puerta trasera no falla en los bancos de pruebas: los aprueba. La detección por evaluación de capacidades no ve nada, porque el comportamiento malicioso solo aparece cuando el detonante está presente.

Los números

Sobre Nemotron-Terminal-8B, el equipo editó siete de las más de 12.000 neuronas de la última capa feed-forward y las ajustó con solo 23 trayectorias de ejemplo, la mitad con detonante y la mitad sin él. Con esa llamada, la carga se emitió en al menos el 98,8 % de las trayectorias de prueba que contenían el detonante, sin fuga observada en las trayectorias benignas evaluadas. Al subir a 2.405 trayectorias de ajuste, la tasa de éxito subió al 99,7 %, manteniendo la divergencia en el comportamiento benigno casi en cero.

La generalización es lo preocupante. Qwen3.6-27B y Gemma-4-31B-IT son igual de vulnerables: con seis neuronas editadas y 23 trayectorias, Qwen llegó al 51 %, y con 2.393 trayectorias, al 83,7 %. Cuando el modelo generaba texto libremente en lugar de reproducir trayectorias grabadas, la tasa de activación se mantuvo en torno al 99 %, aunque en una configuración apareció una tasa de falso disparo del 0,14 % en sesiones sin detonante.

El coste en utilidad también es bajo. Las versiones con puerta trasera de Qwen conservaron casi todas sus puntuaciones en matemáticas, en el concurso AIME, y su puntuación en Terminal-Bench cayó del 46,59 % al 42,05 %. Un parche también se transfiere a un formato de agente que no se vio durante el ajuste, con un 40 % de exactitud de acción. El número de neuronas editadas limita cuántos tokens se pueden inyectar, no lo que el atacante puede hacer después.

Del detonante al shell

Aquí está el salto de modelo comprometido a máquina comprometida. El agente solo tiene que emitir el comando una vez. A partir de ahí, el resto ocurre fuera de los pesos: un script que se descarga y se ejecuta con los privilegios del propio agente.

El trabajo lo formula sin rodeos: un agente con shell, red y credenciales, que es el valor por defecto en marcos como OpenClaw o Hermes Agent, equivale aproximadamente a un acceso remoto al usuario. Ese script puede leer y modificar el código fuente, las claves de API, las claves SSH y los tokens de la nube o de git, y enviarlos por la red. La escala del ataque la fijan los permisos del agente, no el tamaño de la edición.

Conviene recordar la diferencia con la inyección de prompts, que ya es un problema conocido. La inyección actúa por la entrada y no modifica los pesos, así que quien controla el contexto puede intentar filtrar o detectar la instrucción inyectada. Una puerta trasera a nivel de pesos no necesita instrucción alguna: el contenido benigno basta para disparar el comportamiento.

La otra puerta de entrada: envenenar el post-entrenamiento

Lazarus es la vía más limpia, pero no es la única. En paralelo, Microsoft Defender Research y el AI Red Team publicaron otro estudio, Trained to betray, sobre cómo los ataques a la cadena de suministro del post-entrenamiento pueden secuestrar agentes de programación. Ahí el atacante no toca los pesos finales: toca los artefactos de los que salen.

El envenenamiento de datasets parte de la premisa de que la víctima entrena el modelo, pero hay unas pocas filas maliciosas escondidas entre miles de trayectorias legítimas. En su prueba de concepto, el equipo inyectó 90 ejemplos envenenados en unas 9.000 conversaciones de agente de terminal, alrededor del 1 % del corpus, y los repartió entre diez simuladores con nombres de herramienta de ejecución distintos. El detonante era una petición de lo más mundano: crear documentación del proyecto.

Lo que el modelo aprendió no fue una llamada a herramienta fija, sino una regla: cuando llegue esa petición, busca cualquier herramienta disponible que permita ejecutar comandos y úsala de forma insegura. Después de afinar gpt-4.1-mini, la acción insegura exacta o equivalente apareció en el 78,0 % y el 77,8 % de 500 ensayos en los dos simuladores vistos durante el entrenamiento. En un simulador no visto la tasa fue del 11 %, y en el segundo, del 0 %: el comportamiento no depende del simulador, pero su alcance tiene límites. Y con diez paráfrasis distintas de la petición, la tasa subió al 52-70 %, de modo que un filtro que busque la cadena literal del detonante no lo detecta.

Lo relevante del envenenamiento de datasets es que el atacante puede entrar por canales de confianza: publicar un dataset envenenado en un hub público imitando a una organización, reutilizar un espacio de nombres, secuestrar una cuenta de confianza o, simplemente, plantar filas en foros públicos que luego alguien raspa para construir un dataset. En una búsqueda en datasets públicos, el equipo encontró filas reales que emparejaban peticiones inocuas con llamadas de herramienta que descargaban y ejecutaban un script remoto desde GitHub. No pudieron determinar la intención del publicador, pero el hallazgo basta: el tamaño y la reputación de un dataset no garantizan nada.

El envenenamiento de modelos va un paso más allá: el atacante controla el entrenamiento antes de que el checkpoint se distribuya. Con el control completo, el equipo de red team afinó Qwen3.5-4B y Qwen3.5-9B sobre unas 2.400 trayectorias de código resueltas, emparejando los ejemplos envenenados con contrafactuales limpios que conservaban la tarea pero eliminaban el detonante. En distribución, la tasa de éxito estuvo entre el 85,9 % y el 100 %, pero la prueba de fuego son repositorios no vistos: una transferencia ingenua solo daba entre el 32,7 % y el 63,4 %, mientras que la configuración más agresiva de envenenamiento llegaba al 84,1-94,8 %. La evaluación en distribución, avisaba el estudio, sobreestima la robustez del ataque.

La transferencia entre simuladores también se midió: 97 % y 91 % bajo Claude Code, 74 % y 77 % bajo Pi, y 37,3 % y 63 % bajo la interfaz de línea de comandos de Codex. Y hay un detalle que explica por qué el ataque funciona tan bien: quitar de los ejemplos envenenados el razonamiento asociado al detonante y a la acción maliciosa bajó el éxito en repositorios no vistos del 94,8 % al 1,0 % en el modelo de 4B, y del 84,1 % al 0 % en el de 9B. El razonamiento no es decorativo: es parte de la carga.

Detectar el ataque

La buena noticia es que la estructura que hace posible el ataque también lo delata. Un modelo con puerta trasera por neuronas cambia unos pocos vectores de peso muchísimo, mientras que un afinado legítimo o una cuantización los cambian de forma difusa y repartida. La detección pasa por comparar el checkpoint con el modelo base declarado antes de desplegarlo y después de cada actualización, y por señalar los tensores o filas cuyo cambio es un valor atípico estadístico respecto al resto de la comparación.

La segunda vía es usar agentes de frontera como auditores. El detector construido por un agente, sin modelo de referencia limpio, marcó el 91,4 % de los checkpoints editados de prueba con una tasa de falsos positivos del 9,7 %. Conviene mirar los números con pinzas: el conjunto de evaluación final era pequeño, 35 checkpoints editados y 31 limpios, y el detector solo se probó contra esta familia de ediciones. Además, pedirle a un modelo que juzgue directamente si un checkpoint está limpio funcionó mucho peor: Claude Opus 5.5 dio por limpios el 41 % de los checkpoints editados, y GPT-6 Astra no llegó a decidir en casi ninguno de los limpios. Un modelo que dice «está bien» no es un verificador.

Los autores son explícitos en que ninguna auditoría garantiza un comportamiento seguro. Pasar la auditoría reduce el riesgo, no lo elimina.

Qué hacer

Del lado de los hubs y los proveedores, las recomendaciones de Microsoft son: auditar los pesos con agentes de frontera, comparar contra una base declarada, hacer red team de ataques a nivel de peso y no solo de inyección de prompts, mostrar la procedencia y el estado de auditoría antes de permitir la descarga, y decir con claridad que un checkpoint de terceros puede ser inseguro.

Del lado de las empresas y de quien usa agentes: saber de dónde vienen los modelos y desconfiar de la popularidad como señal de seguridad, limitar los permisos del agente, registrar los comandos, los cambios de archivo y las conexiones salientes, pedir aprobación humana antes de ejecutar acciones con impacto, y tratar los checkpoints de terceros, las fusiones, las cuantizaciones y los adaptadores como no fiables hasta que pasen una auditoría. En el plano operativo, la contención manda: ejecutar el código generado en sandboxes o contenedores, aplicar controles de salida de red para que un modelo disparado no pueda abrir conexiones arbitrarias, y no exponer al modelo herramientas de escritura en disco ni de shell del anfitrión.

Microsoft recuerda que Foundry ya vincula cada modelo de peso abierto con su editor original y escanea los contenedores donde corre, y que la compañía está desarrollando escaneo de pesos con agentes de frontera, un arnés de red team y firma criptográfica de modelos con procedencia verificable. En cualquier caso, el riesgo residual sigue existiendo: un proveedor de confianza que sea el propio objetivo.

Y hay un dato que resume el cambio de paradigma de este trabajo: la idea central, que los pesos de un modelo se pueden editar de forma selectiva para plantar una puerta trasera, la descubrió de forma autónoma Claude Code con Opus 4.5 en febrero de 2026, en un experimento que el equipo de Microsoft dejó correr sin supervisión. Ese mismo tipo de agentes es el que después construyó el detector. La conclusión de los autores no es que haya que temer a los agentes, sino al contrario: usarlos para encontrar y cazar estos problemas, y tratar los pesos de un modelo como se trata el código.

Microsoft, por cierto, no ha visto a ningún actor de amenazas usar esta técnica. Por ahora es una capacidad, no un incidente.

Fuentes

Read more