Playbook SOC ante una cuenta comprometida en Microsoft 365

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.