EchoLeak: la vulnerabilidad “zero-click” que exfiltra datos desde Microsoft 365 Copilot (sin tocar nada)

CIBERSEGURIDAD · COPILOTOS · MICROSOFT 365

Si alguna vez te ha preocupado lo fácil que es “engañar” a una IA con instrucciones escondidas, este caso es el ejemplo más claro. Lo conecto bastante con lo que ya se ve en riesgos de prompt injection en herramientas con IA: el problema no es solo el texto, es la mezcla de texto con acciones y con acceso a datos.

1. Qué es EchoLeak y por qué marcó un antes y un después

EchoLeak se describió como una vulnerabilidad “zero-click” en Microsoft 365 Copilot: un atacante podía enviar un email cuidadosamente preparado y, en determinadas condiciones, terminar provocando exfiltración de datos que Copilot tuviera en su contexto.

Lo importante no es el morbo del “sin tocar nada”. Lo importante es que esto aterriza una categoría que antes parecía teórica: prompt injection indirecta con consecuencias reales en un sistema de producción. Ya no es “la IA se comporta raro”. Es “la IA puede filtrar información”.

2. “Zero-click” explicado sin humo: el paso a paso mental

Cuando oyes “zero-click” en móvil piensas en exploits de mensajería. Aquí el concepto es parecido, pero aplicado a copilotos: la interacción humana deja de ser el interruptor. El interruptor es el propio flujo normal del asistente.

Una forma sencilla de verlo:

1) Un atacante te manda un email (puede parecer irrelevante). 2) Ese contenido se queda “vivo” en tu entorno. 3) Días después le preguntas algo a Copilot: “resume lo importante”, “prepara un estado del proyecto”, “busca decisiones de la semana”. 4) Copilot recupera piezas de tu correo y tus archivos para responder. 5) En esa recuperación entra el email trampa y, dentro, instrucciones diseñadas para que el modelo trate el contenido como “órdenes” y no como “texto”.

El giro de guion es que el atacante no necesita que le abras el mensaje. Le basta con que el mensaje exista en el lugar desde el que el copiloto hace su trabajo.

3. La cadena técnica (solo lo necesario para entender el riesgo)

En las descripciones públicas de EchoLeak se habla de una cadena de bypasses: el ataque no era “una sola bala”, sino una combinación que terminó cruzando límites que, sobre el papel, estaban bien puestos.

A alto nivel, el patrón fue este:

• Evitar detectores de prompt injection (clasificadores pensados para reconocer intentos obvios).
• Colar enlaces de forma indirecta usando trucos de formato (por ejemplo, estilos tipo “referencias” en Markdown) para esquivar redacciones automáticas.
• Aprovechar recursos que el sistema “auto-carga” (como imágenes) para generar una solicitud de red hacia fuera sin que el usuario haga clic.
• Usar un proxy o ruta permitida en políticas de seguridad de contenido para que ese tráfico sea viable.

¿El resultado? Un escenario donde el copiloto mezcla datos internos (lo que recupera de tu tenant) con instrucciones externas (lo que llega por email) y termina produciendo una salida que, por un canal lateral, permite sacar información.

4. Lo que se pone en juego: el “contexto” es oro (y casi nadie lo gobierna bien)

Microsoft 365 Copilot no es un chat aislado: se apoya en Microsoft Graph y en tu universo de trabajo. Eso incluye correo, reuniones, Teams, SharePoint, OneDrive… y, según cómo esté configurada la organización, también conectores y repositorios adicionales.

Por eso el impacto real depende menos del exploit y más de una pregunta incómoda: ¿qué puede ver tu Copilot hoy?

Si quieres hacer este ejercicio con cabeza (y dejarlo por escrito para auditoría y para evitar “Copilot sprawl”), es muy recomendable apoyarte en un marco de gobernanza como el que explico en documentar el uso de IA en empresa. Sin ese mapa, cualquier incidente se convierte en una caza de fantasmas.

5. Cómo reducir superficie si usas copilotos (sin “apagarlo todo”)

EchoLeak tiene una lectura práctica muy concreta: no basta con “confiar en el proveedor”. Tú también puedes bajar muchísimo el riesgo atacando el punto que casi siempre está peor: permisos, exposición y salidas.

5.1. Sanea permisos como si te fuera el bonus en ello

Lo que Copilot ve, Copilot puede “resumir”. Y lo que puede “resumir”, potencialmente puede acabar fuera si existe un canal lateral. Revisa:

• Carpetas y sitios de SharePoint con “Todos” o grupos masivos sin necesidad real.
• Enlaces “cualquiera con el vínculo” heredados del pasado.
• Permisos rotos por herencias raras: lo típico que nadie quiere tocar porque “funciona”.

5.2. Controla el egress: el enemigo moderno es la salida indirecta

En muchos ataques “AI-native” el truco no está en acceder, sino en forzar una salida. Asegúrate de que tu stack (DLP, políticas, proxies, seguridad de endpoints) está pensado para:

• Bloquear cargas automáticas de contenido externo cuando no sea necesario.
• Detectar patrones raros de respuestas (por ejemplo, contenido “codificado”, cadenas largas sin sentido, o referencias sospechosas).
• Tener visibilidad de dominios y rutas usadas por previsualizaciones y proxies.

5.3. Separa usos: no todo debe vivir dentro del mismo copiloto

Si tienes procesos especialmente delicados (legal, RR. HH., M&A, negociaciones, datos de clientes), a veces compensa un enfoque más controlado: un asistente aislado y con contexto limitado. Ahí encaja muy bien una alternativa tipo chatbot privado con documentos en local, donde tú decides exactamente qué entra y qué sale.

6. El elefante en la sala: hoy es Copilot, mañana son agentes

EchoLeak se siente grave porque rompe una intuición: “si nadie hace clic, no pasa nada”. Y esa intuición se vuelve aún más peligrosa cuando pasas de copilotos que responden a agentes que actúan.

En cuanto un sistema puede crear tickets, mover archivos, invitar gente a una reunión o tocar un CRM, el riesgo deja de ser “filtrar texto” y se convierte en “hacer cosas” con tus permisos. Si estás en esa transición, te interesa tener claro el salto de seguridad que describo en copilotos vs agentes autónomos en empresas.

7. Un plan rápido de 30 días (si eres IT/Seguridad y tienes Copilot en marcha)

Aquí va lo práctico. No necesitas “reinventar Copilot”. Necesitas reducir exposición, poner controles de salida y hacer auditoría real.

• Semana 1: inventario de datos y permisos (SharePoint/Teams/OneDrive), y corrección de los “todos pueden ver todo”.
• Semana 2: políticas de DLP y revisión de rutas de salida (previsualizaciones, proxies, carga de contenido externo).
• Semana 3: monitorización y detección: alertas por accesos anómalos, consultas masivas, y señales de exfiltración indirecta.
• Semana 4: guías internas de uso + “zonas rojas” (qué no se mete en el copiloto) y pruebas adversarias periódicas.

El objetivo no es asustar a la organización. Es evitar el escenario típico: descubrir tarde que el copiloto tenía acceso a más de lo que nadie recordaba.

8. La idea que te llevas: el contexto es una API (y hay que securizarla)

EchoLeak nos enseña algo simple: en un sistema RAG/assistant, el “contexto” funciona como una API invisible. Entra contenido externo, se mezcla con datos internos, y el modelo decide qué hacer con esa mezcla. Si no separas confianza, permisos y salidas, te expones a ataques que se sienten sobrenaturales… pero que son pura ingeniería.

La próxima vez que alguien diga “tranquilo, nadie va a clicar”, acuérdate: con copilotos, el clic puede hacerlo el sistema por ti. Y justo por eso, tu mejor defensa es reducir lo que el asistente puede ver, controlar cómo puede sacar cosas, y tratar la IA como lo que es en empresa: una pieza más de seguridad, no un widget simpático.