¿Recibiste un correo titulado “Microsoft Email Data Sharing Request” tras el incidente atribuido a Midnight Blizzard y no sabes si es real? Aquí te explico cómo validarlo sin exponerte, qué pasos seguir con Microsoft y cómo integrar el proceso en tu respuesta a incidentes.

Contexto del mensaje y por qué aparece ahora

Tras el incidente de seguridad atribuido a Midnight Blizzard, algunas organizaciones han recibido comunicaciones indicando que Microsoft pondrá a disposición un conjunto de correos electrónicos potencialmente exfiltrados relacionados con su tenant. El correo solicita datos como TenantID, un access code y direcciones de correo de personas que podrán nominar revisores. En ocasiones, el enlace de recolección redirige a un portal de Power Apps con dirección del tipo purviewcustomer.powerappsportals.com.

La razón de fondo es operativa y de control de acceso: Microsoft necesita asociar correctamente el material a tu tenant (por eso el TenantID), usar un código único de caso (access code) y limitar qué usuarios pueden acceder a los contenidos compartidos (nominadores y revisores). No obstante, debido a la sensibilidad del material, la validación debe hacerse por canales autenticados antes de revelar o cargar datos.

Conclusión rápida para equipos ocupados

El aviso puede ser legítimo y responder a un proceso de notificación y compartición de evidencias con clientes potencialmente afectados. Aun así, no uses el enlace del correo de forma directa. Abre un caso desde tu Centro de administración de Microsoft 365 o contacta a tu CSAM/TAM por los canales habituales, menciona “Microsoft Email Data Sharing” y comparte el access code únicamente dentro del ticket autenticado. Pide que el requerimiento quede reflejado en un caso oficial dentro de tu tenant.

Guía segura paso a paso

1. Inicia el contacto por canal autenticado: crea un ticket desde el Centro de administración de Microsoft 365 (admin.microsoft.com) o contacta a tu CSAM/TAM como lo haces normalmente. Indica el asunto “Microsoft Email Data Sharing” y adjunta únicamente el access code dentro del caso.
2. Solicita confirmación dentro del tenant: pide que Microsoft refleje el requerimiento en tu caso oficial o mediante un mensaje seguro en el portal de soporte. Esto ancla la conversación a tu identidad corporativa.
3. Valida técnicamente el correo: revisa encabezados completos (SPF/DKIM/DMARC), dominio del remitente y URLs. Recuerda que *.powerappsportals.com corresponde a infraestructura de Microsoft, pero hay que verificar igual cada detalle de autenticación.
4. Minimiza la exposición: hasta confirmar, no envíes TenantID ni correos de administradores. Cuando Microsoft confirme la legitimidad por canal autenticado, entrega solo lo estrictamente necesario y, preferiblemente, usando alias/cuentas dedicadas con MFA para nominadores y revisores.
5. Controla el acceso a la revisión: aplica MFA, registros de auditoría, acceso temporal, principio de privilegio mínimo y cadena de custodia desde el primer archivo recibido.
6. Integra con tu respuesta a incidentes: trata los datos recibidos como material sensible (PII/legales). Coordina con Legal/Privacidad, actualiza reglas de DLP y revisa exposición interna antes de distribuir nada.
7. Si algo no cuadra, trátalo como phishing: reporta con el complemento “Report Message” o el canal antiphishing de tu organización y bloquea dominios/URLs sospechosos.

Verificación técnica del correo

La validación del mensaje debe combinar señales técnicas con confirmación por canal autenticado. Usa la siguiente tabla como guía de revisión:

Elemento	Qué comprobar	Cómo verificar	Resultado esperado	Riesgo si falla
Remitente	Dominio corporativo de Microsoft y coherencia de dirección	Encabezados “From”, “Sender”, “Reply-To” y “Return-Path”	Coincidencia razonable, sin suplantación evidente	Posible spoofing o desvío de respuestas
SPF	Autenticación de servidor emisor	Encabezado “Received-SPF”	pass en dominios de Microsoft o autorizados	Suplantación del dominio de origen
DKIM	Integridad del mensaje	Encabezado “DKIM-Signature” y validación	pass con selector legítimo	Manipulación o falsificación del contenido
DMARC	Alineación de dominio	Encabezado “Authentication-Results”	pass con alineación SPF/DKIM	Mayor probabilidad de spoofing
URLs	Dominios y rutas exactas	Copiar enlace como texto, inspeccionar sin hacer clic	Dominios de Microsoft; sin encubrimientos	Redirecciones a sitios maliciosos
Access code	Formato y unicidad	Comparar con el proporcionado por soporte oficial	Coincidencia exacta con el caso	Captura de caso o acceso no autorizado
Adjuntos	Existencia de archivos sospechosos	Análisis con AV/EDR en sandbox	Ausencia de ejecutables o macros	Compromiso del endpoint del analista

Revisión de dominios y servicios de Microsoft relevantes

Estos dominios son habituales en procesos de soporte y portales de Microsoft. No basta con reconocerlos: siempre confirma en tu canal autenticado que el dominio y la ruta corresponden a tu caso.

Dominio base	Uso típico	Observaciones
microsoft.com	Comunicación corporativa	Verifica subdominios y alineación DMARC
microsoftonline.com	Servicios de M365/Azure	Común en autenticación y portales
office.com	Aplicaciones de Microsoft 365	Uso general de suite
powerappsportals.com	Portales de Power Apps	Infraestructura de Microsoft; confirma que la ruta corresponde a tu caso
azure.com	Servicios Azure	Frecuente en documentación y cuentas
microsoftsupport.com	Soporte de Microsoft	Puede aparecer en flujos de caso
onmicrosoft.com	Dominios de tenants	Verifica que coincide con tu tenant

Cómo obtener tu TenantID sin usar enlaces del correo

• Azure Portal: en Azure Active Directory (Entra ID) → Overview, copia el Directory (tenant) ID.
• PowerShell Microsoft Graph: Connect-MgGraph -Scopes Organization.Read.All y luego Get-MgOrganization | Select-Object Id, DisplayName.
• PowerShell AzureAD clásico: Connect-AzureAD y Get-AzureADTenantDetail.

Controles de acceso y cadena de custodia

Cuando Microsoft confirme el caso, diseña el acceso con criterios estrictos de mínimo privilegio y auditoría:

• MFA obligatorio para nominadores y revisores; usa cuentas dedicadas o alias de propósito limitado.
• Grupos de seguridad separados para ver, descargar y exportar. Evita permisos excesivos por defecto.
• Registro y retención en un repositorio inmutable o con retención legal. Documenta quién, cuándo y qué accedió.
• Entorno de análisis aislado para abrir archivos: estaciones endurecidas, EDR activo, sin acceso a internet salvo lo necesario.
• Etiquetado de sensibilidad (por ejemplo, etiquetas de Purview) aplicado a todo archivo recibido o derivado.

Integración con el plan de respuesta a incidentes

Los correos compartidos constituyen evidencia y, en muchos casos, contienen PII o información confidencial. Integra tu manejo con Legal, Privacidad y el DPO:

• Clasificación legal: determina si la organización debe notificar a reguladores o clientes.
• DLP y prevención de fugas: crea o ajusta reglas temporales que bloqueen exfiltración del material recibido.
• Inventario de exposición interna: mapea qué equipos o áreas pudieron verse afectadas y delimita el acceso.
• Lecciones aprendidas: prioriza remediaciones en identidad, MFA, higiene de correo, autenticación heredada o reglas de reenvío.

Flujo de trabajo sugerido con hitos de tiempo

Hito	Acción	Responsable	Salida
T0	Recepción del correo y contención	SOC / IT Sec	Correo aislado, ticket creado, enlace no utilizado
T+1h	Validación por canal autenticado	IT Sec / CSAM/TAM	Confirmación oficial del caso y del access code
T+4h	Definición de nominadores y revisores	IT Sec / Dueños de área	Lista mínima aprobada, cuentas con MFA
T+24h	Habilitación de acceso y descarga	IT Sec	Cadena de custodia iniciada, logs activados
T+48h	Análisis inicial y triage	IR / Legal / Privacidad	Informe preliminar, reglas de DLP ajustadas

Políticas de minimización de datos

• Lo mínimo necesario: comparte con Microsoft únicamente el access code dentro del ticket autenticado y confirma la necesidad del TenantID antes de proporcionarlo.
• Nominadores y revisores reducidos: limita el número de personas a las imprescindibles para el análisis.
• Uso de alias dedicados: crea buzones o alias específicos de revisión con MFA, sin privilegios administrativos globales.

Plantillas de comunicación

Solicitud de confirmación a Microsoft por canal autenticado

Asunto: Microsoft Email Data Sharing – Confirmación de caso y access code

Hola equipo de Microsoft,

Hemos recibido un correo referente a “Microsoft Email Data Sharing” asociado a un incidente de Midnight Blizzard.
Les pedimos por favor confirmar, dentro de este ticket autenticado y para nuestro tenant, lo siguiente:

* Validez del requerimiento y del access code: \[Pega aquí el código]
* Ruta o portal oficial donde completar la información (sin usar enlaces del correo)
* Datos específicos que requieren (TenantID, nominadores, revisores) y formato
* Medidas de seguridad recomendadas y plazos

Gracias,
\[Nombre y rol]
\[Organización]
\[Contacto interno] 

Nota interna para concienciación

Asunto: Protocolo ante correo “Microsoft Email Data Sharing”

Equipo,
Cualquier correo con solicitudes relacionadas a “Microsoft Email Data Sharing” deberá escalarse a Seguridad TI.
No abrir enlaces directamente. Seguridad coordinará con Microsoft por el portal autenticado.
Hasta nuevo aviso, no compartir TenantID ni listas de administradores fuera de un ticket oficial.

Gracias. 

Checklist de actuación

[ ] Ticket creado en admin.microsoft.com o canal CSAM/TAM
[ ] Confirmación oficial del caso y access code dentro del tenant
[ ] Validación SPF/DKIM/DMARC y análisis de encabezados
[ ] Verificación de dominios y rutas (sin clicar enlaces del correo)
[ ] Definición de nominadores/revisores mínimos con MFA
[ ] Habilitación de logs y auditoría antes de la revisión
[ ] Cadena de custodia documentada para cada archivo
[ ] DLP y controles de compartición ajustados
[ ] Coordinación con Legal/Privacidad
[ ] Informe preliminar y plan de remediación

Preguntas frecuentes

¿Por qué me piden el TenantID? Para asociar correctamente el acceso y el material a tu organización. Entregarlo solo tras confirmar por canal autenticado.

¿Qué es el access code? Un identificador único de caso que sirve para vincular tu solicitud y evitar confusiones entre tenants.

¿Es normal ver un portal de Power Apps? Sí, Microsoft usa *.powerappsportals.com para flujos con clientes. Aun así, confirma siempre que el portal y la ruta están ligados a tu caso en el ticket oficial.

¿Cuántos nominadores/revisores debo proporcionar? Los mínimos necesarios. Aplica el principio de privilegio mínimo y MFA obligatorio.

¿Puedo reenviar internamente los archivos recibidos? Evítalo. Trátalos como evidencia con PII; distribuye de forma controlada y registra cada acceso.

¿Y si el correo es falso? Trátalo como phishing dirigido: repórtalo por el complemento corporativo, bloquea dominios/URLs asociados y conserva evidencias para análisis.

Señales de riesgo y cómo responder

• Incongruencias de dominios: remitente de un dominio desconocido o parecido al de Microsoft. Respuesta: escalar y bloquear.
• Urgencia excesiva: presión por tiempos no alineados con tu caso. Respuesta: canal autenticado y verificación del plazo.
• Solicitudes de credenciales: nunca entregues contraseñas o códigos MFA. Respuesta: reportar inmediatamente.
• Adjuntos ejecutables o macros: respuesta: análisis en sandbox y bloqueo.

Errores comunes a evitar

• Hacer clic en el enlace del correo antes de validar por soporte autenticado.
• Compartir TenantID y lista de administradores sin confirmación oficial.
• Habilitar acceso sin MFA ni auditoría previa.
• No coordinar con Legal/Privacidad y exponer PII por accidente.
• No documentar cadena de custodia y perder trazabilidad probatoria.

Matriz de responsabilidades

Rol	Responsable	Participación
Dirección de Seguridad / CISO	Patrocinio y decisiones de riesgo	Aprobación de nominadores y difusión
SOC / IR	Validación técnica, análisis y custodia	Revisión técnica de evidencia
IT Microsoft 365	Gestión de acceso, MFA, auditoría	Creación de cuentas dedicadas y grupos
Legal / Privacidad	Gobierno de datos y obligaciones regulatorias	Revisión de PII y notificaciones
CSAM/TAM	Interlocución con Microsoft	Confirmación de caso y portal

Controles de DLP y colaboración

• Etiquetado automático: aplica una etiqueta de “Evidencia confidencial” a todo contenido ingresado por este proceso.
• Bloqueo de compartición externa: deshabilita temporalmente la compartición fuera del dominio para la biblioteca de revisión.
• Inspección de contenido: usa reglas para detectar datos personales, financieros o de salud, y dispara alertas al SOC.

Modelo de carpeta y retención para análisis

/IR/MidnightBlizzard/
  /00_Custodia/
    - Registro_ingesta.csv
    - Hashes_archivos.txt
  /10_SinProcesar/
  /20_Normalizado/
  /30EvidenciaRelevante/
  /40_Reportes/
  /99EliminaciónProgramada/

Define retención mínima y procedimientos de eliminación segura cuando finalice el caso, en coordinación con Legal.

Buenas prácticas para nominadores y revisores

• Acceder solo desde dispositivos gestionados, con EDR activo.
• No descargar a escritorios personales; usar repositorios corporativos controlados.
• Evitar copiar/pegar contenidos sensibles en chats o correos sin etiqueta.
• Cerrar sesión al terminar y reportar cualquier comportamiento anómalo del portal.

Tabla resumen de decisiones

Decisión	Criterio	Estado	Propietario
Legitimidad del correo	Confirmación en ticket autenticado	Pendiente / Confirmado / Rechazado	IT Sec
Nominadores	Mínimo necesario y MFA	Pendiente / Aprobado	CISO / Dueño de área
Canales de revisión	Estación endurecida + auditoría	Pendiente / Operativo	IT M365
DLP/Privacidad	Reglas activas y monitoreo	Pendiente / Operativo	Privacidad

Glosario rápido

• TenantID: identificador único de tu organización en Microsoft Entra ID (Azure AD).
• Access code: código único que referencia el caso o solicitud de datos.
• Nominador/Revisor: personas designadas para solicitar y acceder al material compartido.
• SPF/DKIM/DMARC: mecanismos de autenticación y alineación de correo electrónico.
• Power Apps portals: plataforma de Microsoft para construir portales externos integrados con servicios de M365/Azure.
• DLP: prevención de pérdida de datos.
• CSAM/TAM: administrador/gerente de éxito técnico de cuenta de Microsoft.

Conclusión

La combinación de validación técnica más confirmación en un canal autenticado con Microsoft es la fórmula para decidir sin riesgos si el correo “Microsoft Email Data Sharing Request” es legítimo. Incluso si el aviso es real, aplicar minimización de datos, MFA, auditoría y cadena de custodia te permitirá revisar la información exfiltrada con el menor impacto posible. Si en cualquier punto algo no encaja, trátalo como phishing dirigido y activa tu plan de respuesta.

---