Playbook SOC ante una cuenta comprometida en Microsoft 365
Guion defensivo para detectar, contener, investigar y recuperar una cuenta corporativa comprometida en Microsoft 365.
2 min de lectura
En este artículo
Una alerta de inicio de sesión es el comienzo, no el diagnóstico
Una ubicación inusual, una regla de correo inesperada o una queja de envío no autorizado son señales para investigar. Ninguna prueba aislada confirma por sí misma el alcance: el SOC debe relacionar identidad, sesiones, dispositivo, correo y aplicaciones conectadas, y coordinar la respuesta con el propietario del servicio.
Microsoft recomienda investigar la cuenta afectada y los servicios asociados. Su guía de respuesta a una cuenta de correo comprometida incluye la revocación de sesiones como medida de contención; el orden y alcance de las acciones deben ajustarse a la arquitectura y al plan interno de incidentes.
Secuencia de respuesta
1. Confirmar y registrar
- Abre un incidente con hora, origen de la señal, usuario, dispositivos conocidos y aplicaciones afectadas.
- Preserva los registros disponibles de inicio de sesión, auditoría, correo y alertas antes de que caduquen según la retención configurada.
- Identifica si la cuenta tiene privilegios administrativos, acceso financiero o permisos delegados. Si es una cuenta privilegiada, escala al responsable de identidad y al líder del incidente.
2. Contener el acceso
- Valida con el equipo de identidad la suspensión temporal o restricción apropiada de la cuenta.
- Revoca sesiones y credenciales conforme al procedimiento de respuesta; un cambio de contraseña aislado puede no cerrar todas las sesiones existentes.
- Restablece credenciales desde un canal verificado y revisa métodos de autenticación registrados antes de permitir el acceso de vuelta.
- Si hay indicios de compromiso del dispositivo, aísla el endpoint con el procedimiento EDR antes de reutilizarlo.
3. Buscar persistencia y efectos
Comprueba reglas de bandeja de entrada y reenvío, delegaciones, aplicaciones OAuth consentidas, cambios recientes de MFA, buzones compartidos y actividad desde dispositivos o ubicaciones no habituales. Busca mensajes enviados, reglas de transporte o cambios de permisos que puedan afectar a otras personas. Documenta qué se comprobó y qué fuentes de registro no estaban disponibles.
4. Recuperar y vigilar
Elimina configuraciones maliciosas verificadas, vuelve a emitir accesos necesarios y confirma con el usuario por un canal independiente. Vigila inicios de sesión, reglas y envíos durante el periodo definido por el equipo. Si hubo mensajes fraudulentos, coordina la advertencia a destinatarios y al área financiera sin difundir datos personales más allá de quienes deban responder.
Ejemplo de mesa
Escenario ilustrativo: una persona de ventas informa de una invitación de calendario que no creó. El SOC registra el evento, preserva la evidencia, comprueba sesiones y reglas, revoca el acceso según el runbook, elimina la regla no autorizada y verifica que el envío no alcanzó a clientes. El incidente se cierra solo cuando identidad, correo y usuario confirman la recuperación y queda una acción para revisar la causa inicial.
Practica este flujo con el modelo Zero Trust de identidad, los servicios de monitorización MDR/SOC y el simulacro de mesa ante ransomware. Este playbook es una guía operativa, no una instrucción para modificar políticas de producción sin autorización.
Sigue leyendo
- Simulador de Respuesta a Incidentes en Tiempo Real3 de octubre de 2026
- Cómo priorizar las alertas de seguridad para un SOC18 de septiembre de 2026
- Logs para el SOC: preservar evidencias de incidentes17 de septiembre de 2026
- Ciclo de vida de detecciones SIEM: de hipótesis a señal útil17 de septiembre de 2026