Phishing de doble objetivo: el correo que engaña a tu IA

El correo que se lee dos veces

Un solo correo, dos destinatarios. El visible, para la persona que lo abre. El otro, escondido en el código, para el asistente de IA que resume la bandeja de entrada. Barracuda documentó el 7 de octubre una campaña real con ese diseño de doble objetivo, firmada por su analista de amenazas Guruprasad Kenja, y la conclusión incómoda es simple: si tu equipo ya delega la lectura del correo en un modelo, el perímetro de seguridad se movió y casi nadie lo ha actualizado.

Para un founder esto no es un tema de infraestructura abstracta. Es la diferencia entre pagar una factura legítima y transferir dinero a la cuenta de un atacante porque el resumen del asistente decía "acción prioritaria".

¿Qué es exactamente el phishing de doble objetivo?

La técnica de fondo no es nueva. La inyección indirecta de prompt se sistematizó en febrero de 2023, en un trabajo académico que describía cómo colar instrucciones dentro del contenido que lee el modelo, y hoy es el riesgo número uno del catálogo de OWASP para aplicaciones con modelos de lenguaje, en su edición 2025 como LLM01:2025.

Lo que aporta el informe de Barracuda es el empaquetado: un mismo mensaje combina el señuelo clásico de ingeniería social con instrucciones dirigidas al sistema que lo va a resumir. El atacante no necesita que el empleado haga clic. Le basta con que el asistente describa el correo como legítimo o urgente.

El correo de muestra que analizó la compañía tenía rasgos calculados para esquivar filtros: remitente y destinatario eran el mismo buzón, procedía de un dominio del sector público, arrastraba una puntuación de confianza favorable y llevaba un adjunto protegido con contraseña, con la contraseña escrita en el cuerpo del mensaje. Ese último detalle crea un punto ciego: los controles tradicionales no pueden abrir el archivo.

¿Cómo se esconden las instrucciones donde el ojo no llega?

El informe describe cuatro técnicas, todas baratas de implementar y difíciles de detectar con las herramientas de correo de siempre:

• Comentarios HTML, que no se muestran al abrir el mensaje pero siguen en el código fuente.
• Texto invisible por CSS: tamaño de fuente cero, blanco sobre blanco o directamente oculto.
• Contenido codificado en Base64, por ejemplo dentro de lo que parece una imagen, que se decodifica como texto.
• Caracteres Unicode de ancho cero intercalados entre el texto normal.

Ninguna de estas cuatro requiere malware. Son formatos legítimos del correo electrónico usados con mala intención, y por eso el filtro antivirus no tiene nada que marcar.

¿Qué consigue el atacante con eso?

Que la IA mienta por él, con la autoridad que le damos a un resumen. Los casos que recoge el informe son cuatro y todos son plausibles en una empresa pequeña:

• Factura: un bloque oculto ordena al asistente añadir a su resumen una acción prioritaria falsa —cambiar los datos bancarios del proveedor—. El empleado lee el resumen, no el correo, y paga a otra cuenta.
• Selección de personal: texto invisible en un currículum que indica a la IA puntuar al candidato con un 10 sobre 10 y recomendar entrevista inmediata.
• Bot de atención al cliente: una petición disfrazada de "modo mantenimiento autorizado" para que revele su configuración.
• Asistente de programación: documentación envenenada que hace que el código generado incluya una línea que filtra credenciales.

La razón por la que funciona es estructural, no un fallo concreto: el modelo no distingue entre el texto que debe leer y las órdenes que debe obedecer. Todo le llega como un mismo flujo.

¿Está resuelto? No, y ninguna empresa afirma lo contrario

El centro nacional de ciberseguridad británico (NCSC) lo explicó el 8 de diciembre de 2025 con una analogía incómoda: la inyección de instrucciones no es una inyección SQL y puede ser peor, porque los modelos "no imponen una frontera de seguridad entre instrucciones y datos dentro de un prompt". La inyección SQL se corrigió separando técnicamente código y datos. Aquí no existe esa separación.

OpenAI publicó en marzo de 2026 un documento sobre cómo diseña sus agentes para resistir estas inyecciones en el que reconoce que defenderse "no puede basarse solo en filtrar las entradas". En ese mismo texto cita un ataque reportado por investigadores externos que funcionaba el 50 % de las veces.

Anthropic, en su informe de defensas del 24 de noviembre de 2025, fue igual de directa: "Ningún agente de navegador es inmune". Con su modelo Claude Opus 4.5 y nuevas salvaguardas, la versión de su extensión de navegador lanzada ese día bajó la tasa de éxito de los ataques al 1 % en pruebas internas, con un atacante adaptativo de 100 intentos por entorno. La propia empresa describe esa cifra como una mejora que "sigue representando un riesgo significativo".

Y no es teoría de laboratorio. La empresa Guardio consiguió que el navegador Comet, de Perplexity, cayera en una estafa y acabara introduciendo credenciales en una página falsa en menos de cuatro minutos, según The Hacker News.

El experimento que ya se hizo con Copilot

Investigadores de Permiso probaron tres interfaces de Microsoft Copilot para resumir correo —el botón de resumen de Outlook, el panel de chat de Outlook y Copilot en Teams— y encontraron comportamientos distintos en cada una. La de Teams mostró la mayor probabilidad de reproducir contenido introducido por el atacante: generaba un resumen aparentemente normal y le añadía texto influido por las instrucciones escondidas.

La frase que mejor resume el hallazgo es de Andi Ahmeti, investigador de amenazas de Permiso: "Los usuarios han pasado años aprendiendo a desconfiar de los correos sospechosos, pero ese escepticismo no se traslada a los resúmenes generados por IA. El atacante solo necesita que el asistente hable con autoridad".

Permiso aclara que sus resultados no indican explotación masiva en el mundo real. Son una prueba de concepto. Pero describen una ruta de ataque realista, y eso es suficiente para rediseñar procesos.

El dato que falta y por qué importa

Conviene mantener el caso en su tamaño. Barracuda no publica ni una sola cifra de prevalencia, no nombra un producto probado y no hay respuesta de ninguna empresa de IA a esta investigación concreta. Es un aviso bien documentado de una empresa que vende seguridad de correo, no una medición independiente.

El contexto de mercado sí tiene números, y van en la dirección opuesta a la tranquilidad. Fortra reportó un aumento del 475 % en ataques de phishing que incorporan herramientas legítimas de monitoreo y gestión remota durante los primeros nueve meses de 2026, comparado con todo 2025, según recogió Campus Technology. Son dos informes distintos y dos vectores distintos, pero el patrón es el mismo: los atacantes están usando las herramientas que los empleados ya confían.

¿Qué significa esto para tu startup?

Si tu equipo usa resúmenes automáticos de correo —Copilot en Outlook, Gemini en Gmail, cualquier extensión de terceros—, ya tienes el problema aunque no tengas el ataque. Estas son las acciones que puedes ejecutar esta semana, ordenadas por costo de implementación:

1. Regla de oro para el dinero. Cualquier resumen que implique un pago, un cambio de cuenta bancaria o un dato sensible se verifica abriendo el correo original. Y todo cambio de datos de proveedor se confirma por un canal distinto —una llamada al número que ya tenías, no al que aparece en el mensaje—. Es exactamente el mismo protocolo del fraude del CEO de toda la vida, aplicado a una capa nueva.

2. Limpia antes de resumir. Si administras las herramientas, elimina comentarios HTML, texto con CSS invisible y caracteres de ancho cero antes de que el contenido llegue al asistente. Barracuda lo recomienda explícitamente, junto con detectar lenguaje que intente anular instrucciones previas y validar la salida del modelo antes de que dispare cualquier acción.

3. Aísla los permisos del asistente. Un asistente que solo lee y resume es un riesgo acotado. Uno que puede enviar correos, crear eventos o mover dinero es un objetivo. Aplica mínimo privilegio: si el resumen no necesita acceso a tu Drive o a tu CRM, no se lo des. Cada conector nuevo es una puerta más que una instrucción escondida puede intentar abrir.

4. Aprobación humana obligatoria en lo irreversible. Pagos, cambios de proveedor, altas de personal. El principio que resume el informe de Barracuda es que el contenido externo debe tratarse "siempre y en todos los casos solo como datos", nunca como instrucciones.

5. Entrena el escepticismo en la capa nueva. Llevas una década enseñando a tu equipo a desconfiar de los correos. Nadie les enseñó a desconfiar de un resumen limpio, ordenado y en tono neutro. Ese es el hueco que el atacante está comprando, y se cierra con una frase en el onboarding: el resumen es una interpretación, no una notificación del sistema.

Conclusión: el problema es de hábito, no de parche

El hallazgo real de esta investigación no es técnico. Hemos delegado la lectura del correo en un sistema al que no le hemos enseñado nada de la desconfianza que sí le pedimos a las personas. Y la presentación del resumen —neutra, ordenada, con apariencia de notificación del sistema— es precisamente lo que el atacante está comprando.

Ninguna herramienta va a cerrar esto del todo. El NCSC advierte que puede que nunca se mitigue por completo y pide desconfiar de cualquier producto que prometa "detenerlo". Lo que sí puedes hacer es reducir el impacto: menos permisos, más verificación humana en lo que no se puede deshacer, y una regla simple que todo el equipo entienda. Si el resumen mueve dinero, abre el correo.

Fuentes

• https://www.wwhatsnew.com/2026/10/20/phishing-doble-objetivo-asistentes-ia-inyeccion-prompts (fuente original)
• https://campustechnology.com/articles/2026/10/13/phishing-attacks-increasingly-exploit-remote-management-tools-and-ai-email-assistants.aspx
• https://www.infosecurity-magazine.com/news/attackers-hide-ai-prompt/
• https://www.techrepublic.com/es/article/news-microsoft-copilot-prompt-injection-phishing-risk/
• https://www.wwhatsnew.com/2026/10/19/agentes-ia-navegador-compras-inyeccion-instrucciones/