Microsoft Defender for Office 365: guía completa para proteger el correo frente a phishing, malware y BEC

Microsoft Defender for Office 365 es una de las principales capas de seguridad de Microsoft 365 para proteger el correo y determinadas experiencias de colaboración frente a phishing, Business Email Compromise, suplantación, malware, enlaces maliciosos, adjuntos peligrosos y otras amenazas.

Pero una buena protección de correo no consiste simplemente en activar Safe Links y Safe Attachments.

Un atacante puede intentar falsificar nuestro dominio, hacerse pasar por el director financiero utilizando un dominio parecido, comprometer realmente la cuenta de un proveedor, enviar un código QR que lleve a una página de robo de credenciales o utilizar una URL que era legítima cuando se entregó el mensaje y se convierte en maliciosa horas después.

Por eso la protección debe diseñarse por capas.

Tenemos que considerar Exchange Online Protection, autenticación SPF/DKIM/DMARC, anti-spoofing, protección contra impersonation, Safe Links, Safe Attachments, Zero-hour Auto Purge, cuarentena, reportes de usuario, Tenant Allow/Block List, investigación y respuesta.

Y también debemos asumir que ningún filtro va a detectar siempre el 100 % de los ataques.

Una estrategia madura debe responder a tres preguntas:

¿cómo reducimos la probabilidad de que una amenaza llegue?, ¿qué hacemos si llega?, ¿y cómo investigamos lo ocurrido si un usuario interactúa con ella?

En Kloudeal recomendamos configurar Microsoft Defender for Office 365 empezando por el flujo real de correo, las fuentes legítimas, las licencias y los usuarios de mayor riesgo. Después se aplican los baselines de Microsoft, se revisan falsos positivos y solo entonces se añaden excepciones o políticas personalizadas.

Esta guía explica cómo hacerlo en 2026 y qué elementos merece la pena revisar antes de considerar protegido un entorno Microsoft 365.

Índice

1. Qué es Microsoft Defender for Office 365
2. Cómo funciona la protección por capas
3. Exchange Online Protection
4. EOP vs Plan 1 vs Plan 2
5. Licenciamiento actualizado en 2026
6. Qué revisar antes de configurar Defender
7. Revisar primero el flujo real del correo
8. Gateways y filtros de terceros
9. Standard, Strict y Built-in Protection
10. Orden de precedencia de políticas
11. Usuarios de alto valor y cuentas prioritarias
12. Anti-phishing: spoofing, impersonation y mailbox intelligence
13. Spoof intelligence
14. Protección contra impersonation
15. Anti-malware
16. Anti-spam inbound
17. Outbound spam y cuentas comprometidas
18. Reenvío automático externo
19. Safe Links
20. Safe Attachments
21. SharePoint, OneDrive y Teams
22. Zero-hour Auto Purge
23. SPF, DKIM, DMARC y ARC
24. Configurar SPF correctamente
25. Configurar DKIM
26. Desplegar DMARC
27. Proteger dominios no utilizados
28. Cuarentena
29. Falsos positivos y Tenant Allow/Block List
30. Advanced Delivery
31. Botón Report de Outlook
32. Investigación de incidentes
33. Real-time detections y Threat Explorer
34. Automated Investigation and Response
35. Runbook de respuesta a phishing/BEC
36. Attack Simulation Training
37. PowerShell útil
38. Métricas y revisión continua
39. Roadmap de 90 días
40. Errores frecuentes
41. Checklist
42. Preguntas frecuentes
43. Documentación oficial

Qué es Microsoft Defender for Office 365

Microsoft Defender for Office 365 añade capacidades avanzadas de prevención, detección, investigación y respuesta sobre las protecciones que ya proporciona Exchange Online Protection.

Su alcance no está limitado exclusivamente al correo.

Dependiendo de la funcionalidad y licencia, puede proteger elementos relacionados con:

Exchange Online, Microsoft Teams, SharePoint, OneDrive y aplicaciones Office compatibles.

Qué amenazas intenta reducir

No sustituye Zero Trust

Defender for Office 365 no sustituye:

MFA, Conditional Access, protección de endpoints, gobierno de identidades, revisión de permisos ni procedimientos de respuesta.

Especialmente en un escenario BEC real, el problema puede no ser que el correo sea técnicamente falso.

Si la cuenta Microsoft 365 de un proveedor ha sido comprometida, el atacante puede enviar desde una identidad legítima.

Por eso necesitamos combinar seguridad del mensaje con seguridad de identidad y procesos empresariales.

Referencia oficial: Microsoft – Microsoft Defender for Office 365.

Cómo funciona una arquitectura de protección de correo por capas

La seguridad del correo no debería verse como una única barrera.

Un mensaje pasa por diferentes controles.

La ventaja de este modelo es que un fallo en una capa no implica necesariamente que el ataque tenga éxito.

Exchange Online Protection: la primera línea de defensa

Exchange Online Protection proporciona muchas de las protecciones integradas de los buzones cloud.

Entre ellas encontramos:

anti-spam, anti-malware, anti-spoofing, cuarentena, ZAP y diferentes controles de flujo de correo.

EOP no significa “protección mínima”

Hay funcionalidades relevantes disponibles incluso sin Defender for Office 365.

Por ejemplo, Microsoft incluye protección contra spoofing para organizaciones con buzones cloud y ZAP puede actuar sobre spam, phishing y malware detectados posteriormente.

Defender for Office 365 amplía este modelo con controles como Safe Links, Safe Attachments y protección avanzada contra impersonation.

EOP vs Defender for Office 365 Plan 1 vs Plan 2

La diferencia fundamental

Una forma práctica de entenderlos es:

Plan 1 = prevención y detección avanzada.

Plan 2 = Plan 1 + investigación, automatización, respuesta y formación avanzada.

Licenciamiento actualizado en 2026

Esta es una de las partes donde más comparativas antiguas han quedado obsoletas.

Importante con E3

La incorporación de Plan 1 a E3 no significa que E3 disponga automáticamente de:

Threat Explorer completo, AIR o Attack Simulation Training.

Estas continúan siendo capacidades propias del nivel Plan 2 cuando se requiere su funcionalidad completa.

Referencia oficial: Microsoft – Defender for Office 365 service description.

Qué revisar antes de configurar políticas

Uno de los principales errores consiste en modificar filtros antes de conocer cómo circula realmente el correo.

Inventario previo

Revisar primero el flujo real del correo

Antes de configurar Defender debemos responder:

¿Microsoft 365 recibe directamente el mensaje desde Internet?

Si el MX apunta a Microsoft 365, la plataforma dispone de la IP real del sistema remitente desde la entrada.

Pero si antes existe:

Proofpoint, Mimecast, Cisco, Barracuda, un appliance local, Exchange Server u otro gateway,

la situación cambia.

Microsoft podría ver como origen del mensaje la IP del gateway y no la del verdadero remitente.

Eso afecta a:

reputación, spoof detection, SPF y composite authentication.

Gateways de terceros: Enhanced Filtering antes que reglas SCL -1

Si existe un sistema de filtrado delante de Microsoft 365, debemos revisar Enhanced Filtering for Connectors, también conocido históricamente como skip listing.

Su objetivo es ayudar a Microsoft 365 a identificar la verdadera infraestructura de origen que existía antes del gateway.

Evitar el patrón antiguo

Es frecuente encontrar una regla:

si el correo viene de la IP del filtro externo → SCL -1.

Eso significa esencialmente “omitir filtrado de spam” para ese tráfico.

Una regla demasiado amplia puede reducir de forma importante las defensas de Microsoft.

También debemos revisar ARC

Cuando intermediarios legítimos modifican mensajes y rompen SPF o DKIM, Authenticated Received Chain puede ayudar a preservar la información original de autenticación.

Referencias oficiales:

• Microsoft – Enhanced Filtering for Connectors
• Microsoft – Secure by default

Standard, Strict y Built-in Protection

Microsoft proporciona preset security policies para aplicar configuraciones recomendadas de una manera coherente.

Para la mayoría de organizaciones deberían ser el punto de partida antes de construir decenas de políticas personalizadas.

Standard

Microsoft describe Standard como una línea base adecuada para la mayoría de usuarios.

Strict

Está orientada a perfiles de mayor riesgo y utiliza configuraciones más agresivas en determinados controles.

Built-in Protection

En organizaciones con Defender for Office 365 proporciona una capa predeterminada de:

Safe Links + Safe Attachments

para usuarios que no están incluidos en:

Standard, Strict o políticas personalizadas equivalentes.

Una diferencia importante

Las políticas individuales que forman Standard y Strict no están diseñadas para editarse valor a valor.

Son perfiles mantenidos por Microsoft.

Si necesitamos personalizaciones importantes, debemos diseñar una política custom para el grupo correspondiente en lugar de intentar modificar internamente el preset.

Arquitectura sencilla

Referencia oficial: Microsoft – Preset security policies.

Orden de precedencia: por qué una política personalizada puede no aplicarse

Cuando un usuario coincide con varias políticas, no todas tienen el mismo peso.

Orden general relevante

Ejemplo

Un usuario está incluido simultáneamente en:

Standard + una política custom Safe Links.

La configuración del preset puede aplicarse antes que la política personalizada.

Por eso los grupos deben diseñarse para evitar solapamientos innecesarios.

Usuarios de alto valor: proteger por riesgo, no solo por organigrama

Los atacantes no eligen objetivos aleatoriamente.

Existen cuentas cuya compromisión tendría un impacto desproporcionado.

Para estos usuarios

Podemos plantear:

Strict + phishing-resistant MFA + protección de impersonation + procesos de pago reforzados + formación específica.

Anti-phishing: spoofing, impersonation y mailbox intelligence no son lo mismo

Una buena configuración debe distinguirlos.

El último caso es especialmente complicado

Si la cuenta del proveedor ha sido comprometida:

SPF puede pasar, DKIM puede pasar y DMARC puede pasar.

El mensaje procede realmente del entorno legítimo.

Ahí necesitamos combinar señales de contenido, comportamiento, identidad y procedimientos de negocio.

Spoof intelligence

Microsoft 365 utiliza spoof intelligence para identificar remitentes falsificados.

Debe mantenerse activado salvo que exista una razón técnica muy concreta.

Spoof intelligence insight

Permite revisar pares de:

identidad suplantada + infraestructura remitente

para comprender qué spoofing se está permitiendo o bloqueando.

No permitir todo un dominio porque una plataforma legítima haga spoofing

Si un servicio externo necesita enviar utilizando nuestra dirección:

1. configuramos correctamente autenticación;

2. revisamos el par detectado;

3. solo si sigue siendo necesario, utilizamos una excepción específica.

Referencia oficial: Microsoft – Anti-spoofing protection.

Protección contra user y domain impersonation

Las capacidades de Defender for Office 365 permiten detectar intentos de impersonation que no necesitan falsificar literalmente el dominio.

Ejemplo

Dirección real:

fernando@empresa.com

Ataque:

fernando@ernpresa.com

La segunda dirección puede:

pasar SPF, DKIM y DMARC en su propio dominio

y seguir siendo fraudulenta.

Por eso necesitamos protección contra impersonation

Especialmente para:

usuarios sensibles + dominios propios + dominios relevantes de partners cuando exista justificación.

Mailbox intelligence

Microsoft puede utilizar información del patrón habitual de comunicación para ayudar a reconocer si un remitente parece coherente con las relaciones normales del usuario.

Phishing threshold

Los presets configuran también diferentes niveles de agresividad.

Actualmente Standard utiliza un nivel más agresivo y Strict el nivel más agresivo dentro de las configuraciones recomendadas por Microsoft.

Referencia oficial: Microsoft – Anti-phishing policies.

Anti-malware: la protección básica sigue siendo necesaria

Antes de Safe Attachments, los mensajes pasan por las capacidades anti-malware habituales.

Common attachments filter

Microsoft permite bloquear determinados tipos de fichero potencialmente peligrosos.

No deberíamos copiar una lista genérica de Internet sin analizar el negocio.

ZAP para malware

Si Microsoft determina después de la entrega que un mensaje contiene malware, ZAP puede ponerlo en cuarentena.

Referencia oficial: Microsoft – Anti-malware policies.

Anti-spam inbound: no es simplemente “spam o no spam”

Microsoft clasifica distintos niveles:

bulk, spam, high confidence spam, phishing y high confidence phishing.

Cada resultado puede tener una acción distinta.

Standard y Strict ya incorporan decisiones

Por ejemplo, Strict es más agresiva con:

bulk y spam

que Standard.

Para amenazas claramente maliciosas, muchas configuraciones son similares entre ambos perfiles.

Bulk mail

No todo correo masivo es malware.

El Bulk Complaint Level ayuda a decidir qué tipo de correo masivo queremos considerar indeseado.

No crear una allow list para resolver cada newsletter

Antes debemos averiguar por qué se ha clasificado y corregir el problema adecuado.

Outbound spam: detectar cuentas comprometidas también importa

Una estrategia de correo no debe mirar únicamente el tráfico entrante.

Una cuenta comprometida puede comenzar a enviar:

spam, phishing o miles de mensajes a destinatarios externos.

Las políticas outbound permiten controlar

límites, forwarding y acciones cuando un usuario supera determinados umbrales.

Una anomalía de envío puede ser un indicador de compromiso

Si un usuario que envía normalmente 20 correos diarios intenta enviar cientos o miles, deberíamos investigarlo.

Reenvío automático externo

Las reglas de forwarding son una técnica habitual después de comprometer una cuenta.

Ejemplo

El atacante accede a un buzón y crea una regla que:

reenvía facturas a una cuenta externa + oculta determinadas respuestas.

La configuración recomendada actual

Microsoft utiliza Automatic – System-controlled como configuración recomendada para los presets Standard y Strict.

En el comportamiento actual equivale a mantener deshabilitado el forwarding automático externo salvo escenarios admitidos específicamente.

Si una empresa necesita forwarding

Conviene crear una excepción:

explícita + documentada + con propietario + revisable.

Safe Links: proteger el momento del clic

Una URL puede parecer segura cuando el mensaje se entrega y cambiar después.

Ese es uno de los problemas que intenta resolver Safe Links.

Correo

Puede proporcionar:

URL rewriting + time-of-click protection + análisis de enlaces a archivos.

Teams

Safe Links comprueba URLs en el momento del clic, pero los enlaces de Teams no necesitan reescribirse de la misma forma que en correo.

Office

También puede comprobar enlaces desde aplicaciones Office compatibles cuando el usuario está correctamente autenticado.

Configuración recomendada

No excluir dominios completos por comodidad

Una excepción en Safe Links reduce la capacidad de evaluar esa URL.

Las listas de Do not rewrite deberían ser pequeñas y justificadas.

Referencia oficial: Microsoft – Safe Links.

Safe Attachments: análisis más allá de una firma antivirus

Safe Attachments busca amenazas desconocidas mediante técnicas de análisis y detonation.

Acciones actuales

Standard y Strict

Los presets actuales utilizan:

Block.

Por tanto, si elegimos presets no necesitamos construir una política Safe Attachments personalizada simplemente para replicar el baseline de Microsoft.

Dynamic Delivery

Puede ser útil en escenarios específicos en los que queremos reducir la latencia percibida, pero no debería utilizarse automáticamente solo porque parezca más cómodo.

Referencia oficial: Microsoft – Safe Attachments.

Safe Attachments en SharePoint, OneDrive y Teams

Defender for Office 365 no se limita a attachments SMTP.

Puede añadir protección sobre archivos almacenados en:

SharePoint Online, OneDrive y Microsoft Teams.

Detonation

Después del análisis antivirus base, Safe Attachments puede analizar ficheros utilizando un entorno virtual.

Importante

La configuración global de Safe Attachments para SharePoint, OneDrive y Teams es diferente de una política de Safe Attachments para mensajes de correo.

No debemos asumir que porque el correo está protegido, automáticamente hemos revisado la configuración de colaboración.

Referencia oficial: Microsoft – Safe Attachments for SharePoint, OneDrive and Teams.

Zero-hour Auto Purge: la seguridad continúa después de la entrega

ZAP es una de las capacidades que más valor aporta al modelo de protección por capas.

Problema

A las 10:00 un mensaje parece legítimo.

A las 10:30 nuevas señales globales demuestran que forma parte de una campaña de phishing.

Sin una defensa post-delivery, el mensaje seguiría en el buzón.

ZAP puede actuar retrospectivamente

En buzones Exchange Online puede actuar sobre:

malware, phishing y spam

dependiendo del veredicto y de las acciones configuradas.

No necesita Plan 2 para correo

ZAP para malware, phishing y spam en Exchange Online forma parte de las protecciones de los buzones cloud.

La protección ZAP específica de Teams sí está asociada a licencias Defender for Office 365.

Qué revisar

Existe un informe de:

Post-delivery activities

que permite ver mensajes afectados después de haber sido entregados.

Referencia oficial: Microsoft – Zero-hour Auto Purge.

SPF, DKIM, DMARC y ARC: autenticar el dominio antes de culpar al filtro

Microsoft recomienda utilizar conjuntamente:

SPF + DKIM + DMARC.

Ninguno de ellos sustituye a Defender, pero ayudan a establecer si un mensaje está realmente autorizado por el propietario del dominio.

SPF pasando no significa que el remitente visible sea legítimo

SPF valida principalmente el dominio de MAIL FROM.

Un atacante puede tener SPF perfectamente configurado para su propio dominio y mostrar otra identidad en el From.

DMARC añade precisamente el concepto de alineación.

Referencia oficial: Microsoft – Email authentication in Microsoft 365.

Configurar SPF correctamente

El primer paso es inventariar todas las plataformas que envían utilizando nuestro dominio.

Ejemplo

Un único registro SPF

Un dominio debe publicar un único registro SPF TXT consolidado.

Límite DNS

SPF dispone de un límite de 10 búsquedas DNS para los mecanismos que cuentan como lookup.

Acumular muchos include: puede terminar generando:

permerror.

Procedimiento recomendado

Si todavía desconocemos todas las fuentes, Microsoft propone empezar identificando fuentes válidas y endurecer después el final de la política.

Cuando conocemos todos los emisores:

podemos avanzar hacia -all.

Referencia oficial: Microsoft – Configure SPF.

Configurar DKIM para dominios personalizados

DKIM utiliza una firma criptográfica para ayudar a validar el mensaje.

Microsoft 365

Para dominios personalizados debemos publicar los registros CNAME proporcionados por Microsoft y habilitar la firma correspondiente.

Subdominios

Cada subdominio utilizado para enviar desde Microsoft 365 necesita su propia configuración DKIM.

Terceros

Si utilizamos:

CRM, marketing, ecommerce o ticketing,

conviene intentar que estos servicios firmen DKIM utilizando nuestro propio dominio o subdominio cuando la plataforma lo soporte.

DKIM no sustituye DMARC

Podemos tener:

DKIM=pass

pero que el dominio firmado no esté alineado con el dominio visible del From.

Referencia oficial: Microsoft – Configure DKIM.

Desplegar DMARC sin romper correo legítimo

DMARC permite al propietario del dominio publicar una política para el correo que no supera la autenticación alineada.

Una implantación empresarial habitual

No es obligatorio pasar exactamente por todos los escalones

La secuencia depende del control que tengamos sobre el dominio.

Por ejemplo, un dominio nuevo que sabemos que nunca enviará correo puede protegerse directamente de forma mucho más restrictiva.

DMARC necesita alineación

Para pasar DMARC necesitamos que:

SPF o DKIM pasen y estén alineados con el From visible.

Referencia oficial: Microsoft – Configure DMARC.

Proteger dominios no utilizados

Un dominio que no utilizamos para correo también puede ser suplantado.

Ejemplo

La empresa posee:

empresa-group.com

pero no envía nunca correo desde ese dominio.

Un atacante podría intentar utilizarlo para engañar a clientes o empleados.

Microsoft recomienda para dominios parked

DMARC con:

v=DMARC1; p=reject;

cuando nadie debería enviar legítimamente desde ese dominio.

No publicar DKIM innecesariamente

Microsoft también recomienda no publicar registros DKIM para dominios parked que no deben enviar.

Revisar el onmicrosoft.com

Si el dominio tenant.onmicrosoft.com tampoco se utiliza para envío, merece la pena revisar su protección DMARC.

Referencia oficial: Microsoft – DMARC for MOERA and parked domains.

Cuarentena: quién puede liberar qué

Cuarentena no debería ser simplemente una carpeta que nadie revisa.

Las quarantine policies definen:

qué puede ver el usuario, qué puede liberar, si puede solicitar liberación y qué notificaciones recibe.

No todos los veredictos deberían tener el mismo acceso

Restricción técnica importante

Los usuarios no pueden liberar directamente mensajes puestos en cuarentena como:

malware, malware/phishing de Safe Attachments o high confidence phishing.

Dependiendo de la política pueden solicitar la liberación, pero la decisión final requiere administración.

Notificaciones

Podemos configurar notificaciones de cuarentena y personalizarlas, pero hay que evitar generar tantas alertas que los usuarios comiencen a liberar mensajes sin analizarlos.

Referencia oficial: Microsoft – Quarantine.

Falsos positivos: utilizar Submissions y Tenant Allow/Block List

Cuando Microsoft bloquea un mensaje legítimo, la solución no debería ser:

“añadimos el dominio entero a permitidos y listo”.

Primero investigar

Revisamos:

veredicto, cabeceras, SPF, DKIM, DMARC, URLs, attachments, reglas, conectores y motivo exacto de detección.

Después utilizar Submissions

La página Submissions permite enviar a Microsoft:

correo, URLs y attachments

como falsos positivos o falsos negativos.

Tenant Allow/Block List

Permite administrar overrides para:

domains/addresses, spoofed senders, files, URLs, determinadas IPs y elementos de Teams compatibles.

Los allows deben ser temporales siempre que sea posible

Microsoft limita intencionadamente muchas allow entries porque un allow permanente puede convertirse en una vía de ataque.

High confidence phishing y malware

No podemos simplemente crear cualquier allow directo para saltarnos estos verdicts.

Microsoft utiliza el flujo de Submissions para determinados overrides de alto riesgo.

Los blocks también tienen impacto

Bloquear un dominio en Tenant Allow/Block List puede:

clasificar su correo como high confidence phishing y evitar incluso que usuarios internos envíen hacia ese dominio.

Por tanto, no debe utilizarse como lista casual de spam.

Referencia oficial: Microsoft – Tenant Allow/Block List.

Advanced Delivery: la excepción correcta para simulaciones y buzones SecOps

Hay casos donde necesitamos que determinados mensajes no se filtren de la forma habitual.

Ejemplo 1: simulación de phishing externa

Una plataforma de formación de terceros necesita enviar phishing simulado.

Si simplemente creamos:

regla SCL -1 + allow sender + allow domain,

estamos creando un bypass de seguridad difícil de controlar.

La solución específica es Advanced Delivery

Microsoft proporciona una política dedicada para:

non-Microsoft phishing simulations y SecOps mailboxes.

Ejemplo 2: buzón SOC

Un buzón utilizado para recibir muestras sospechosas necesita tratamiento distinto al de un usuario normal.

Advanced Delivery permite definir ese escenario de forma explícita.

Referencia oficial: Microsoft – Advanced Delivery.

El botón Report de Outlook debe formar parte del proceso

Los usuarios van a detectar algunos mensajes que la tecnología no detecte inicialmente.

Tenemos que proporcionarles una forma sencilla de reportarlos.

Botón nativo

Microsoft incorpora actualmente el botón Report en versiones compatibles de Outlook.

Permite:

Report phishing, Report junk y Not junk.

Destino

Desde User reported settings podemos configurar los mensajes reportados para enviarlos:

a Microsoft, a un reporting mailbox interno o a ambos.

No pedir a los usuarios que simplemente reenvíen el phishing

Un reenvío normal puede perder parte del contexto y metadatos necesarios para analizar correctamente el mensaje.

Complementos antiguos

Microsoft está retirando progresivamente los antiguos:

Report Message / Report Phishing add-ins

en favor del botón integrado de Outlook.

Referencia oficial: Microsoft – Report messages in Outlook.

Investigar no es lo mismo que bloquear

Cuando un phishing supera la primera línea de defensa necesitamos responder preguntas concretas.

Real-time detections y Threat Explorer

La experiencia de investigación depende del plan.

Plan 1

Incluye Real-time detections.

Plan 2

Incluye Threat Explorer, con capacidades más amplias de hunting e investigación.

Ventana de investigación

Explorer permite consultar diferentes vistas de amenazas recientes y trabajar sobre:

mensajes, malware, phishing, URLs, campañas y otros artefactos.

Ejemplo operativo

El SOC recibe:

“He abierto este correo y creo que era falso.”

El proceso debería permitir localizar:

mensaje → sender → recipients → URL → clicks → campaign → remediation.

Referencia oficial: Microsoft – Threat Explorer and Real-time detections.

Automated Investigation and Response

En Plan 2, AIR permite automatizar parte del análisis de determinadas amenazas.

Un ejemplo especialmente interesante en 2026

Cuando un usuario reporta un mensaje como phishing, Defender for Office 365 Plan 2 puede crear automáticamente una investigación AIR.

Automatic feedback response

Los administradores pueden configurar que el usuario reciba posteriormente una notificación con el resultado de la investigación.

Esto mejora mucho el ciclo:

usuario reporta → seguridad investiga → usuario recibe feedback.

Por qué es útil

Si los usuarios reportan mensajes y nunca saben qué ocurrió, la participación suele deteriorarse.

Un mecanismo de feedback refuerza la conducta correcta.

Automatizar no significa ignorar

Las investigaciones, acciones pendientes y remediaciones siguen necesitando:

monitorización, ownership y procedimiento.

Referencia oficial: Microsoft – Automated Investigation and Response.

Runbook de respuesta a phishing o BEC

Detectar el mensaje no es el final del incidente.

Fase 1: identificar

Fase 2: determinar exposición

¿Algún usuario:

abrió, hizo clic, descargó, introdujo credenciales o ejecutó un fichero?

Fase 3: contener mensaje

Cuando corresponda:

remediar o purgar mensajes, bloquear indicadores y enviar muestras a Microsoft.

Fase 4: contener identidad

Si existen indicios de compromiso:

revocar sesiones, revisar credenciales, métodos MFA, reglas de Inbox, forwarding, OAuth consent y actividad de inicio de sesión.

Fase 5: revisar endpoints

Si hubo descarga o ejecución:

correlacionar con Microsoft Defender for Endpoint u otra plataforma EDR.

Fase 6: revisar impacto empresarial

En BEC:

pagos, cambios bancarios, facturas, proveedores y transferencias.

Fase 7: buscar persistencia

Revisar:

Inbox rules, forwarding, delegates, OAuth apps, sessions y cambios administrativos.

Fase 8: comunicación

Avisar a:

usuarios afectados, seguridad, dirección, legal o proveedores

según el incidente.

Fase 9: mejorar controles

No cerrar el incidente con:

“correo eliminado”.

Hay que preguntarse:

¿por qué llegó y qué podemos mejorar sin crear un bypass peligroso?

Attack Simulation Training: formación basada en riesgo real

Plan 2 incluye Attack Simulation Training.

No debería utilizarse como examen para “pillar” empleados.

Su valor está en medir patrones y proporcionar formación contextual.

Técnicas disponibles

Microsoft permite trabajar con diferentes escenarios, entre ellos:

Credential Harvest, Malware Attachment, Link in Attachment, Link to Malware y Drive-by URL, además de otras experiencias soportadas.

QR phishing

Attack Simulation Training admite actualmente:

payloads con códigos QR + módulos específicos de formación para QR phishing.

Payload automation

Una capacidad especialmente útil es utilizar versiones seguras de patrones de phishing reales que ha recibido la organización para construir simulaciones posteriores.

Métricas útiles

Microsoft no almacena las credenciales introducidas en una simulación Credential Harvest

La información introducida en la página de simulación se descarta; lo que se registra es el evento necesario para medir el comportamiento.

Medir tendencia, no buscar culpables

Es más útil preguntar:

“¿ha bajado el riesgo durante seis meses?”

que:

“¿quién suspendió la campaña de marzo?”

Referencia oficial: Microsoft – Attack Simulation Training.

PowerShell útil para revisar Defender for Office 365

La configuración principal puede administrarse desde Microsoft Defender portal, pero PowerShell es especialmente útil para:

inventario, documentación, comparación y validación de políticas.

Conexión

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline -UserPrincipalName admin@empresa.com

Revisar políticas anti-phishing

Get-AntiPhishPolicy |
    Format-List Name,
                Enabled,
                EnableSpoofIntelligence,
                EnableMailboxIntelligence,
                EnableTargetedUserProtection,
                EnableTargetedDomainsProtection,
                PhishThresholdLevel

Revisar reglas anti-phishing

Get-AntiPhishRule |
    Select-Object Name,State,Priority,AntiPhishPolicy

Revisar anti-malware

Get-MalwareFilterPolicy |
    Format-List Name,
                EnableFileFilter,
                FileTypes,
                ZapEnabled,
                QuarantineTag

Revisar anti-spam inbound

Get-HostedContentFilterPolicy |
    Format-List Name,
                BulkThreshold,
                SpamAction,
                HighConfidenceSpamAction,
                PhishSpamAction,
                HighConfidencePhishAction,
                SpamZapEnabled,
                PhishZapEnabled,
                QuarantineRetentionPeriod

Revisar outbound spam

Get-HostedOutboundSpamFilterPolicy |
    Format-List Name,
                AutoForwardingMode,
                RecipientLimitExternalPerHour,
                RecipientLimitInternalPerHour,
                RecipientLimitPerDay,
                ActionWhenThresholdReached

Revisar Safe Links

Get-SafeLinksPolicy |
    Format-List Name,
                IsEnabled,
                EnableSafeLinksForEmail,
                EnableSafeLinksForTeams,
                EnableSafeLinksForOffice,
                EnableForInternalSenders,
                ScanUrls,
                DeliverMessageAfterScan,
                TrackClicks,
                AllowClickThrough,
                DoNotRewriteUrls

Revisar Safe Links rules

Get-SafeLinksRule |
    Select-Object Name,State,Priority,SafeLinksPolicy

Revisar Safe Attachments

Get-SafeAttachmentPolicy |
    Format-List Name,
                Enable,
                Action,
                QuarantineTag

Revisar Safe Attachment rules

Get-SafeAttachmentRule |
    Select-Object Name,State,Priority,SafeAttachmentPolicy

Revisar preset Standard

Get-EOPProtectionPolicyRule `
    -Identity "Standard Preset Security Policy" |
    Format-List

Get-ATPProtectionPolicyRule `
    -Identity "Standard Preset Security Policy" |
    Format-List

Revisar preset Strict

Get-EOPProtectionPolicyRule `
    -Identity "Strict Preset Security Policy" |
    Format-List

Get-ATPProtectionPolicyRule `
    -Identity "Strict Preset Security Policy" |
    Format-List

Revisar Built-in Protection

Get-ATPBuiltInProtectionRule |
    Format-List

Buscar reglas que pueden saltarse el spam filter

Get-TransportRule |
    Select-Object Name,State,Mode,SetSCL

Revisar allow lists de anti-spam

Get-HostedContentFilterPolicy |
    Select-Object Name,
                  AllowedSenders,
                  AllowedSenderDomains,
                  BlockedSenders,
                  BlockedSenderDomains

Revisar SPF/DKIM desde Microsoft 365

Get-DkimSigningConfig |
    Select-Object Domain,Enabled,Status,Selector1CNAME,Selector2CNAME

No recomiendo publicar un script que “configure todo” automáticamente

Los presets y el portal de Microsoft proporcionan una línea base mucho más mantenible.

PowerShell es excelente para:

assessment → inventario → comparación → documentación.

Los cambios deberían realizarse de forma controlada, entendiendo primero qué usuarios están dentro de cada política.

Qué métricas revisar después del despliegue

Una métrica que no debería crecer indefinidamente

Número de allow lists.

Una organización que cada mes añade más excepciones puede estar debilitando lentamente el filtro.

Roadmap de despliegue en 90 días

Días 1–15: entender el entorno

Días 16–30: baseline

Días 31–45: autenticación y phishing

Días 46–60: Safe Links, Attachments y colaboración

Días 61–75: operación

Días 76–90: Plan 2 y mejora continua

Errores frecuentes al configurar Microsoft Defender for Office 365

Checklist de Microsoft Defender for Office 365

Preguntas frecuentes sobre Microsoft Defender for Office 365

Conclusión: Defender for Office 365 funciona mejor como sistema, no como colección de políticas

Microsoft Defender for Office 365 puede reducir significativamente el riesgo asociado al correo electrónico y a determinadas experiencias de colaboración, pero su eficacia depende de cómo se integran sus diferentes capas.

El primer paso no debería ser Safe Links.

Debería ser comprender cómo llega realmente el correo.

Si existe un gateway externo, hay que revisar Enhanced Filtering for Connectors y autenticación antes de crear reglas que omitan filtrado.

Después necesitamos una base consistente.

Microsoft proporciona precisamente para ello los perfiles Standard y Strict. Para la mayoría de organizaciones son preferibles a intentar replicar manualmente docenas de recomendaciones.

Standard puede utilizarse como baseline general y Strict reservarse para usuarios de alto valor cuando encaje con el perfil de riesgo.

Sobre esa base funcionan las diferentes capas.

Anti-phishing ayuda a distinguir spoofing e impersonation. Mailbox intelligence incorpora contexto de relaciones habituales. Safe Links protege URLs, incluyendo la comprobación en el momento del clic. Safe Attachments analiza ficheros desconocidos mediante detonation.

Pero la seguridad no termina en delivery.

Zero-hour Auto Purge permite reaccionar cuando Microsoft descubre después que un mensaje ya entregado era malicioso.

Los propios usuarios proporcionan otra señal.

Configurar correctamente el botón Report de Outlook permite convertir un correo sospechoso en una entrada estructurada para SecOps y, en Plan 2, una denuncia de phishing puede iniciar automáticamente una investigación AIR.

También necesitamos autenticar nuestros propios dominios.

SPF indica qué sistemas pueden enviar, DKIM firma los mensajes y DMARC comprueba la alineación con el remitente visible y publica una política.

Los tres deberían formar parte de una única estrategia.

Y no debemos olvidar los dominios que no utilizamos: un dominio parked sin protección puede seguir siendo atractivo para un atacante.

La operación diaria es igual de importante.

Quarantine policies deben determinar qué puede liberar cada usuario. Tenant Allow/Block List debe utilizarse con cuidado. Los falsos positivos deberían resolverse mediante Submissions y correcciones de configuración antes de recurrir a allow lists permanentes.

Para simulaciones de phishing externas o buzones SecOps existe Advanced Delivery; crear reglas amplias SCL -1 no debería ser la primera opción.

Con Plan 2 podemos ir más lejos.

Threat Explorer ayuda a investigar campañas y artefactos, AIR automatiza determinadas investigaciones y Attack Simulation Training permite evaluar la resistencia frente a técnicas como credential harvesting o QR phishing.

Finalmente, el objetivo no es conseguir que “Defender esté en verde”.

La pregunta realmente útil es:

si mañana un usuario recibe un phishing sofisticado, ¿tenemos suficientes controles para detectarlo, suficientes señales para investigarlo y un procedimiento claro para contener el impacto si alguien interactúa con él?

Cuando la respuesta es sí, Defender for Office 365 deja de ser un conjunto de licencias y empieza a funcionar como una arquitectura real de seguridad de correo.

Documentación oficial recomendada

Microsoft Defender for Office 365

• Microsoft – Microsoft Defender for Office 365
• Microsoft – Defender for Office 365 service description
• Microsoft – Defender for Office 365 features

Configuraciones recomendadas

• Microsoft – Recommended settings for EOP and Defender for Office 365
• Microsoft – Preset security policies
• Microsoft – Policy precedence

Anti-phishing

• Microsoft – Anti-phishing protection
• Microsoft – Anti-phishing policies
• Microsoft – Anti-spoofing protection
• Microsoft – Tune anti-phishing protection

Anti-malware y anti-spam

• Microsoft – Anti-malware policies
• Microsoft – Anti-spam policies
• Microsoft – Spam Confidence Level

Safe Links

• Microsoft – Safe Links
• Microsoft – Configure Safe Links

Safe Attachments

• Microsoft – Safe Attachments
• Microsoft – Configure Safe Attachments
• Microsoft – Safe Attachments for SharePoint, OneDrive and Teams

ZAP

• Microsoft – Zero-hour Auto Purge
• Microsoft – Defender for Office 365 reports

SPF, DKIM, DMARC y autenticación

• Microsoft – Email authentication
• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC
• Microsoft – Troubleshoot email authentication
• Microsoft – DMARC for parked domains

Gateways y flujo de correo

• Microsoft – Enhanced Filtering for Connectors
• Microsoft – Secure by default

Cuarentena, Submissions y Allow/Block

• Microsoft – Quarantine
• Microsoft – Quarantine policies
• Microsoft – Tenant Allow/Block List
• Microsoft – Submit messages and files to Microsoft
• Microsoft – Advanced Delivery

User reporting

• Microsoft – Report suspicious messages in Outlook
• Microsoft – Admin review of user-reported messages

Investigación y respuesta

• Microsoft – Threat Explorer and Real-time detections
• Microsoft – Automated Investigation and Response
• Microsoft – Automatic feedback for user-reported phishing

Attack Simulation Training

• Microsoft – Attack Simulation Training
• Microsoft – Attack Simulation Training FAQ
• Microsoft – Payload automations