Microsoft Defender for Endpoint: Guía Completa para Entornos Enterprise

Defender for Endpoint en el ecosistema Microsoft

Microsoft Defender for Endpoint (MDE) ocupa una posición única en el mercado EDR. No es solo un producto de seguridad: es una pieza de un ecosistema integrado que abarca endpoint, email, identidad, cloud y datos. Para organizaciones que ya usan Microsoft 365, MDE ofrece una integración nativa que ningún competidor puede replicar.

Esta guía analiza MDE desde la perspectiva técnica de un analista SOC o un responsable de seguridad que necesita entender qué ofrece, cómo operarlo, y dónde están sus limitaciones.

Arquitectura: el agente y la nube Microsoft

El sensor MDE

En Windows 10/11 y Windows Server 2019+, el sensor de MDE está integrado en el sistema operativo. No hay un agente separado que instalar: se activa mediante configuración (GPO, Intune, o script de onboarding). Esto es una ventaja significativa en despliegue, pero también significa que la versión del sensor está vinculada a la versión del sistema operativo.

En sistemas operativos anteriores (Windows Server 2016, 2012 R2), se requiere el Microsoft Monitoring Agent (MMA) o el agente unificado, que sí es un componente instalable separado.

En macOS y Linux, MDE requiere la instalación de un agente específico (mdatp) que proporciona capacidades de detección y respuesta, aunque con menor cobertura que en Windows.

Componentes del sensor en Windows:

• MsSense.exe. El servicio principal del sensor que recopila telemetría y la envía al cloud de Microsoft.
• Anti-malware platform (AM). El motor de protección en tiempo real heredado de Windows Defender Antivirus. Ejecuta análisis de archivos con firmas, heurísticas y machine learning.
• Behavioral monitoring. Monitorización de comportamiento de procesos, archivos, red y registro.
• Cloud-delivered protection. Verificación en la nube de archivos sospechosos con modelos de ML más potentes que los locales.

Cloud backend

La telemetría de MDE se envía al cloud de Microsoft (Azure) y se almacena en el tenant de Microsoft 365 del cliente. Los datos residen en el datacenter regional del tenant (EU, US, UK, etc.), lo que facilita el cumplimiento de requisitos de soberanía de datos para organizaciones europeas.

Retención de telemetría:

• Datos de alertas y incidentes: 180 días
• Telemetría raw (Advanced Hunting): 30 días
• Datos del dispositivo: 180 días tras último heartbeat

La retención de 30 días para telemetría raw es competitiva frente a los 7 a 14 días de otros vendors en sus planes base, pero puede ser insuficiente para investigación de APT con persistencia prolongada.

El portal Microsoft Defender

MDE se opera desde el portal Microsoft Defender (security.microsoft.com), que unifica todos los productos Defender en una sola consola.

Incidentes y alertas

Incidentes. MDE agrupa alertas relacionadas en incidentes automáticamente. Un incidente puede incluir alertas de MDE (endpoint), Defender for Office 365 (email), Defender for Identity (AD/identity), y Defender for Cloud Apps (SaaS). Esta correlación cross-product es la base de Microsoft 365 Defender como solución XDR nativa.

Alertas. Cada alerta muestra:

• Severity (High, Medium, Low, Informational)
• Técnica ATT&CK mapeada
• Alert story: visualización del árbol de procesos con los eventos que generaron la alerta
• Evidence: archivos, procesos, IPs, URLs involucradas
• Automated investigation: estado de la investigación automatizada (si está habilitada)

Device inventory

Inventario completo de dispositivos con MDE, incluyendo:

• Sistema operativo y versión
• Nivel de exposición y valor del dispositivo
• Estado del sensor (activo, inactivo, desconfigurado)
• Tags y grupos de dispositivos
• Vulnerabilidades detectadas (integración con Threat and Vulnerability Management)

Threat and Vulnerability Management (TVM)

TVM es un módulo integrado en MDE que identifica vulnerabilidades de software en los endpoints sin necesidad de escáneres externos:

• Inventario de software instalado con versiones
• CVEs aplicables a cada versión
• Priorización basada en exploits activos (CISA KEV, feeds de inteligencia)
• Recomendaciones de parcheo con impacto estimado en la reducción de riesgo
• Métricas de exposición organizacional

KQL: el lenguaje de hunting de Microsoft

KQL (Kusto Query Language) es el lenguaje de consulta que usa MDE para Advanced Hunting. A diferencia de CQL (propietario de CrowdStrike) o la sintaxis de Deep Visibility de SentinelOne, KQL es un lenguaje ampliamente usado en el ecosistema Microsoft: Azure Data Explorer, Azure Monitor, Microsoft Sentinel, y todos los productos Defender lo usan.

Tablas principales de Advanced Hunting

Tabla	Datos
DeviceProcessEvents	Creación y terminación de procesos
DeviceFileEvents	Operaciones de archivo (crear, modificar, eliminar, renombrar)
DeviceNetworkEvents	Conexiones de red TCP/UDP
DeviceRegistryEvents	Operaciones de registro de Windows
DeviceLogonEvents	Eventos de login (local, remoto, red, desbloqueo)
DeviceImageLoadEvents	Carga de DLLs y módulos
DeviceEvents	Eventos misceláneos (scripts, WMI, servicios)
AlertEvidence	Evidencia asociada a alertas de MDE
EmailEvents	Eventos de email (requiere Defender for Office 365)
IdentityLogonEvents	Eventos de autenticación AD (requiere Defender for Identity)

Queries de hunting con KQL

Buscar ejecución de PowerShell con encoding Base64:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "powershell.exe"
| where ProcessCommandLine has_any ("-enc", "-encodedcommand", "-e ")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, 
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Detectar descarga con certutil (T1105):

DeviceProcessEvents
| where FileName == "certutil.exe"
| where ProcessCommandLine has_any ("urlcache", "split", "verifyctl")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Buscar persistencia en Run keys del registro:

DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey has @"\CurrentVersion\Run"
| where ActionType == "RegistryValueSet"
| project Timestamp, DeviceName, InitiatingProcessFileName,
          RegistryKey, RegistryValueName, RegistryValueData

Detectar possible credential dumping de LSASS:

DeviceProcessEvents
| where FileName == "lsass.exe"
| join kind=inner (
    DeviceProcessEvents
    | where InitiatingProcessFileName !in ("csrss.exe", "services.exe", 
                                            "wininit.exe", "svchost.exe")
) on DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, 
          InitiatingProcessCommandLine

Buscar conexiones a IPs de un rango geográfico sospechoso:

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where RemotePort in (4444, 5555, 8080, 8443, 9090)
| project Timestamp, DeviceName, InitiatingProcessFileName,
          RemoteIP, RemotePort, RemoteUrl
| summarize ConnectionCount = count() by RemoteIP, DeviceName
| where ConnectionCount > 10

Ventaja de KQL

KQL tiene una ventaja estratégica: es portable dentro del ecosistema Microsoft. Las mismas queries funcionan en MDE, Microsoft Sentinel, Azure Monitor, y Log Analytics. Un analista que aprende KQL puede usar sus skills en múltiples productos. Además, la comunidad de KQL es significativamente más grande que la de lenguajes propietarios como CQL, lo que significa más ejemplos, recursos y queries compartidas.

ASR Rules: Attack Surface Reduction

Las reglas ASR (Attack Surface Reduction) son controles preventivos que bloquean comportamientos específicos asociados a técnicas de ataque, sin necesidad de identificar malware específico.

Reglas ASR principales

Regla	Qué bloquea
Block executable content from email and webmail	Ejecutables y scripts descargados de email
Block Office apps from creating executable content	Word, Excel, PowerPoint escribiendo .exe, .dll
Block Office apps from creating child processes	Office lanzando cmd, powershell, wscript
Block JavaScript/VBScript from launching downloaded content	Scripts descargados ejecutando payloads
Block execution of potentially obfuscated scripts	PowerShell con ofuscación detectada
Block credential stealing from LSASS	Acceso a memoria de LSASS (mimikatz)
Block process creations from PSExec and WMI commands	Ejecución remota via PSExec o WMI
Block untrusted/unsigned processes from USB	Ejecutables no firmados desde USB
Block abuse of exploited vulnerable signed drivers	Drivers firmados con vulnerabilidades conocidas

Modos de ASR

Cada regla ASR puede configurarse en tres modos:

• Not configured. La regla está desactivada.
• Audit. La regla registra eventos cuando se activaría, pero no bloquea. Esencial para evaluar el impacto antes del bloqueo.
• Block. La regla bloquea activamente el comportamiento.
• Warn. El usuario recibe un aviso y puede elegir continuar (no disponible para todas las reglas).

Recomendación práctica: Activar todas las reglas en modo Audit durante dos a cuatro semanas. Analizar los eventos generados para identificar falsos positivos (aplicaciones legítimas que activarían la regla). Crear exclusiones para los falsos positivos. Activar en modo Block con las exclusiones configuradas.

ASR y la kill chain del malware

Las reglas ASR bloquean múltiples puntos de la cadena de infección típica:

1. Email con adjunto malicioso → ASR bloquea ejecución de contenido ejecutable desde email
2. Documento Office con macro → ASR bloquea Office creando procesos hijo o ejecutables
3. Script de descarga → ASR bloquea scripts descargados ejecutando payloads
4. Credential dumping → ASR bloquea acceso a LSASS
5. Movimiento lateral → ASR bloquea ejecución via PSExec/WMI

La combinación de varias reglas ASR activas proporciona una defensa en profundidad significativa contra las técnicas de ataque más comunes.

Automated Investigation and Response (AIR)

Cuando MDE genera una alerta, puede iniciar automáticamente una investigación que analiza el contexto, identifica artefactos maliciosos, y ejecuta acciones de remediación.

Cómo funciona AIR

1. Trigger. Una alerta dispara la investigación automatizada.
2. Análisis. AIR examina el proceso detectado, sus archivos asociados, conexiones de red, cambios en registro, y actividad del usuario. Expande la investigación a archivos y procesos relacionados.
3. Veredictos. Cada artefacto analizado recibe un veredicto: Malicious, Suspicious, Clean, No threats found.
4. Acciones. Para artefactos maliciosos, AIR propone o ejecuta acciones: quarantine file, stop and quarantine process, block URL, isolate machine.

Niveles de automatización

MDE permite configurar el nivel de automatización de AIR:

Nivel	Comportamiento
No automated response	AIR analiza pero no ejecuta acciones. Solo propone.
Semi (require approval for any remediation)	AIR propone acciones. Un analista debe aprobar cada una.
Semi (require approval for core folders)	Acciones automáticas excepto en carpetas del sistema (C:\Windows, C:\Program Files).
Full	AIR ejecuta todas las acciones automáticamente.

La recomendación para organizaciones que empiezan con MDE es usar "Semi" y migrar gradualmente a "Full" tras validar que las acciones automáticas son correctas en su entorno.

Integración con Microsoft Sentinel

Microsoft Sentinel es el SIEM/SOAR cloud-native de Microsoft. La integración con MDE es nativa y profunda:

Conector de datos. Un conector preconfigurado ingesta todas las alertas, incidentes y telemetría raw de MDE en Sentinel. No requiere configuración de syslog ni parsers.

Correlación extendida. Sentinel puede correlar alertas de MDE con logs de firewalls (Palo Alto, Fortinet), VPN, proxies, AWS/Azure/GCP, y cualquier otra fuente. Esto proporciona la correlación multi-vendor que MDE solo no ofrece.

Playbooks SOAR. Logic Apps de Azure permiten automatizar respuestas: cuando MDE detecta ransomware, Sentinel puede automáticamente aislar el endpoint, deshabilitar la cuenta del usuario en Azure AD, enviar notificación a Slack/Teams, y crear un ticket en ServiceNow.

KQL unificado. Las mismas queries KQL funcionan en MDE y en Sentinel. Las queries de hunting se pueden promover a reglas de detección analítica en Sentinel, que monitorizan continuamente y generan alertas.

Hunting notebooks. Sentinel ofrece Jupyter notebooks integrados para investigación avanzada. Los notebooks pueden consultar tanto datos de MDE como de cualquier otra fuente conectada a Sentinel.

MDE sin Sentinel

MDE funciona perfectamente sin Sentinel. La decisión de añadir Sentinel depende de:

• Múltiples fuentes de datos. Si necesitas correlar MDE con firewalls, VPN, IAM no-Microsoft, cloud multi-provider, Sentinel aporta valor real.
• Retención extendida. Sentinel puede retener logs durante años (con coste de almacenamiento). La retención nativa de MDE (30 días de hunting) puede ser insuficiente.
• Automatización avanzada. Si necesitas playbooks complejos con múltiples pasos y decisiones condicionales, los Logic Apps de Sentinel son más potentes que las acciones de respuesta nativas de MDE.
• Coste. Sentinel cobra por volumen de datos ingestados (GB/día). Para organizaciones con miles de endpoints, el coste de ingestar toda la telemetría de MDE en Sentinel puede ser significativo.

Licenciamiento: lo que necesitas saber

El licenciamiento de MDE es un tema complejo que afecta directamente a las capacidades disponibles.

MDE Plan 1 vs Plan 2

Capacidad	Plan 1	Plan 2
Next-gen protection (antivirus)	Si	Si
Attack Surface Reduction rules	Si	Si
Device control (USB)	Si	Si
Endpoint firewall	Si	Si
Network protection	Si	Si
Web content filtering	Si	Si
EDR capabilities	No	Si
Advanced Hunting (KQL)	No	Si
Automated Investigation	No	Si
Threat and Vulnerability Mgmt	No	Si
Endpoint Attack Notifications	No	Si
Defender Experts for Hunting	No	Add-on
Microsoft Copilot for Security	No	Add-on

Plan 1 está incluido en Microsoft 365 E3. Proporciona protección preventiva (antivirus moderno + ASR), pero no incluye capacidades EDR. Sin Advanced Hunting, sin investigación de incidentes, sin respuesta remota. Es un antivirus avanzado, no un EDR.

Plan 2 está incluido en Microsoft 365 E5 o se puede licenciar como add-on sobre E3. Es el plan que proporciona capacidades EDR reales.

Licencia standalone

MDE Plan 2 se puede licenciar de forma independiente (sin Microsoft 365) para servidores y estaciones de trabajo. El coste por endpoint es significativamente menor que CrowdStrike o SentinelOne, especialmente para organizaciones que ya tienen licencias Microsoft 365 E5.

Fortalezas y debilidades

Fortalezas técnicas

Integración nativa con el ecosistema Microsoft. La correlación entre MDE (endpoint), Defender for Office 365 (email), Defender for Identity (AD), y Defender for Cloud Apps (SaaS) proporciona una visión XDR que requiere configuración mínima. Para organizaciones Microsoft-centric, esta integración es difícil de replicar con productos de terceros.

KQL y Advanced Hunting. KQL es un lenguaje potente y portable. La comunidad de queries compartidas es enorme. Las tablas de hunting cubren procesos, archivos, red, registro, login, módulos y más.

ASR Rules. Controles preventivos gratuitos (incluidos en Plan 1) que bloquean técnicas de ataque comunes. Ningún otro vendor ofrece un equivalente comparable integrado en el agente.

Coste. Para organizaciones con Microsoft 365 E5, MDE Plan 2 está "incluido" en la licencia. El coste marginal respecto a desplegar un EDR de terceros es significativo.

Soberanía de datos. La telemetría se almacena en el tenant de Microsoft 365, con datacenter regional seleccionable (EU para organizaciones europeas). Esto facilita el cumplimiento de RGPD y requisitos de soberanía.

Debilidades y consideraciones

Dependencia del ecosistema Microsoft. MDE brilla en entornos Microsoft. En entornos heterogéneos (Linux heavy, macOS, multi-cloud no-Azure), las capacidades son menores que en Windows. Los analistas acostumbrados a la profundidad de CrowdStrike o SentinelOne en Linux pueden encontrar MDE insuficiente.

Complejidad de licenciamiento. El esquema de licencias (E3 vs E5 vs standalone vs add-ons) es confuso. Muchas organizaciones creen tener EDR porque tienen "Defender" en su licencia E3, cuando en realidad solo tienen antivirus avanzado (Plan 1).

Curva de aprendizaje de KQL. Aunque KQL es potente, tiene una curva de aprendizaje. Analistas acostumbrados a interfaces gráficas de hunting pueden encontrar la transición a queries textuales desafiante.

Rendimiento de la consola. El portal Microsoft Defender puede ser lento bajo carga, especialmente en tenants grandes con miles de endpoints. La experiencia de usuario no es tan fluida como la de consolas dedicadas como Falcon o Singularity.

Sensor vinculado al OS. En Windows, el sensor está integrado en el sistema operativo. Esto significa que la versión del sensor depende de las actualizaciones de Windows. Un endpoint con Windows desactualizado tiene un sensor desactualizado.

Caso de uso: investigar un incidente BEC

Un escenario que demuestra la integración XDR de Microsoft:

Fase 1: Email. Defender for Office 365 detecta un email de phishing que pasó los filtros. El email contiene un enlace a una página de login falsa de Microsoft 365.

Fase 2: Identity. Un usuario hace click y proporciona sus credenciales. Defender for Identity detecta un login anómalo en Azure AD desde una IP en un país donde la organización no tiene operaciones.

Fase 3: Email. El atacante usa las credenciales robadas para enviar emails de phishing interno desde la cuenta comprometida. Defender for Office 365 detecta el patrón de envío anómalo.

Fase 4: Endpoint. Un destinatario interno abre un adjunto del email fraudulento. MDE detecta la cadena: Outlook abriendo Word, Word lanzando PowerShell. El proceso es bloqueado por ASR rules.

Correlación XDR. Microsoft 365 Defender agrupa todo en un único incidente: el email original, el login comprometido, los emails internos, y el intento de ejecución en el endpoint. El analista ve la cadena completa sin necesidad de saltar entre consolas.

Respuesta. Desde el incidente, el analista puede: purgar todos los emails maliciosos de todos los buzones, revocar las sesiones del usuario comprometido en Azure AD, forzar cambio de contraseña, aislar el endpoint afectado, y bloquear la URL de phishing en toda la organización. Todo desde la misma consola.