La Zona Sin Protección

Una realidad arquitectónica de Microsoft Teams permite que, al aceptar una invitación como guest en otro tenant de Microsoft 365, las protecciones de tu organización (p. ej. Microsoft Defender for Office 365: Safe Links, Safe Attachments, ZAP, DLP) no se apliquen. Investigaciones como la de Rhys Downing (Ontinue) muestran que atacantes crean tenants “zona libre de protección”, invitan a víctimas y realizan phishing, exfiltración o distribución de malware fuera del perímetro de seguridad de la organización objetivo.

1. ¿Qué ocurre exactamente?

Cuando un usuario acepta una invitación de guest en Teams, pasa a operar dentro del tenant host.

Las políticas de seguridad que se aplican son las del tenant que hospeda la conversación, no las de la organización de origen del usuario.

Por tanto, medidas como Safe Links, Safe Attachments, Zero-hour Auto Purge (ZAP) y muchas reglas de DLP no se ejecutan si el tenant host no las tiene activas.

2. Por qué esto es peligroso (en pocas palabras)

Los correos de invitación llegan desde la infraestructura legítima de Microsoft, por lo que evaden SPF/DKIM/DMARC y suelen pasar filtros de email.

Un atacante puede:

• Crear un tenant barato o de prueba sin Defender habilitado.

• Invitar a objetivos (por ejemplo vía LinkedIn, ingeniería social).

• Cuando la víctima acepta, enviar enlaces y archivos que no serán escaneados por las defensas de su organización.

• La organización de la víctima queda ciega: no hay alertas en Defender, ni logs locales ni remediación automática.

3. Cómo funciona el ataque — paso a paso

Preparación del tenant malicioso: crear un Microsoft 365 con pocas o ninguna defensa (p. ej. Teams Essentials, Business Basic, trials o licencias con protección desactivada).

3.1 Reconocimiento: identificar empleados objetivo y construir pretexto (proveedor, consultor, reclutador).

3.2 Invitación: enviar invitación de Teams a la dirección corporativa del objetivo.

3.3 Email legítimo de Microsoft: la invitación llega desde Microsoft y suele pasar filtros de autenticación.

3.4 Aceptación y acceso a la “zona libre de protección”: la víctima entra como guest y el atacante comparte enlaces/archivos sin que Safe Links/Safe Attachments los inspeccionen.

3.5 Explotación: spear-phishing, robo de credenciales, exfiltración o distribución de malware/RaaS sin que la organización detecte la actividad.

4. Qué protecciones de Defender desaparecen (ejemplos)

• Safe Links: deja de escanear URLs en tiempo de clic.

• Safe Attachments: deja de detonarlas y analizarlas en sandbox.

• ZAP (Zero-hour Auto Purge): no hay eliminación retroactiva de mensajes maliciosos.

• Escaneo de URLs en tiempo real / bloqueo de dominios: no operan desde el tenant desprotegido.

5. Señales de alerta (qué mirar)

En la invitación:

• Remitente/propósito inesperado, urgencia, contenido vago o “demasiado bueno”.

• Perfiles de LinkedIn vacíos o emails que no coinciden con dominio corporativo.

En la conversación tras aceptar:

• Solicitudes tempranas de información sensible.

• Enlaces sin contexto o archivos no solicitados.

• Cambio abrupto de tema hacia datos confidenciales.

6. Mitigaciones prácticas (plan por niveles)

Nivel 1 — Identidad y acceso (Microsoft Entra ID)

Restringir colaboración B2B: permitir invitaciones guest solo desde dominios confiables.

Implementar políticas cross-tenant por defecto bloqueadoras y aprobar excepciones explícitas.

Nivel 2 — Controles en Teams

Desactivar la función “Chat with Anyone” si no es necesaria (nota: evita invitaciones salientes; no impide recibir invitaciones).

En Teams Admin Center, configurar External access para permitir solo dominios específicos.

Nivel 3 — Concienciación

Formación específica sobre la diferencia guest access vs external access y señales de invitaciones sospechosas.

Simulaciones de invitaciones de Teams y correcciones inmediatas a empleados que acepten sin verificar.

Nivel 4 — Monitorización y detección

Buscar en logs de auditoría eventos de aceptación de invitaciones guest y patrón de comunicaciones con tenants externos.

Crear alertas automáticas (aceptación de invitaciones desde dominios desconocidos, múltiples invitaciones del mismo tenant, comportamiento anómalo post-aceptación).

Integrar eventos de Teams en el SIEM para correlación.

Nivel 5 — Respuesta a incidentes

Procedimientos rápidos: revocar sesiones, forzar cambio de credenciales + MFA, revisar y revocar accesos guest a tenants no verificados.

Captura forense de sesiones y comunicaciones si hay indicios de exfiltración o compromiso.

7. Postura según tipo de organización

Alta regulación (finanzas, salud, gobierno): postura restrictiva — listas blancas estrictas, posible deshabilitación completa de guest access.

Tech/innovación: postura equilibrada — permitir colaboración con monitoreo y listas de confianza por industria.

PYMES: postura pragmática — listas permitidas básicas, formación concisa y considerar seguridad gestionada.

8. FAQs rápidas

¿Es un bug de Teams?

No: es un comportamiento arquitectónico del modelo de colaboración cross-tenant (diseño, no defecto).

¿Deshabilitar external access soluciona el problema?

No: external access (federación) y guest access son distintos. Hay que controlar ambos.

¿Puede Microsoft cambiar esto?

No hay garantías de cambio inmediato; por ahora la responsabilidad recae en las organizaciones para mitigar.

¿Cómo sé si mis usuarios ya son guests en tenants externos?

Auditoría vía PowerShell o logs de Microsoft 365 para listar accesos guest y evaluar necesidad/legitimidad.

9. Plan de acción recomendado (inmediato → 90 días)

Esta semana

• Auditar configuración de external access y guest access.

• Listar y revisar todos los guest actuales.

• Verificar si la función “Chat with Anyone” está habilitada.

Este mes

• Implementar restricciones por dominio para invitaciones guest.

• Configurar alertas para aceptaciones de invitados de dominios desconocidos.

• Lanzar módulo de formación sobre invitaciones de Teams.

Trimestral

• Simulaciones de ataque específicas para Teams.

• Integrar logs de Teams en SIEM/SOC.

• Revisar necesidad real de guest access por unidad y reducirlo si procede.

10. Conclusión

La lección clave es simple pero a menudo ignorada: tus defensas no siempre “siguen” a tus usuarios cuando entran como guests en tenants ajenos. La colaboración empresarial moderna trae enormes beneficios, pero también abre vectores que los atacantes sofisticados ya explotan. La respuesta no es prohibir la colaboración, sino combinar controles técnicos granulares, monitorización activa y formación específica para que los usuarios entiendan cuándo sus protecciones organizativas dejan de aplicar.

Pregunta que debe hacerse cada organización:

¿Sabemos dónde terminan nuestras protecciones y qué deben hacer nuestros usuarios cuando cruzan ese límite?