Imagina esta secuencia:
Un usuario abre un archivo recibido por correo. Minutos después, WINWORD.EXE inicia PowerShell. PowerShell ejecuta otro proceso, realiza una conexión hacia Internet y aparece actividad con credenciales.
¿Qué debería detectar la empresa?
¿El antivirus?
¿El EDR?
¿El XDR?
La respuesta puede ser: los tres.
El error habitual radica en pensar que representan tres generaciones sucesivas de la misma herramienta. No lo son.
Un antivirus moderno puede bloquear malware antes o durante su ejecución. Un EDR permite observar y reconstruir actividad dentro del endpoint. Un XDR intenta conectar esa actividad con señales procedentes de otros dominios como identidad, correo electrónico o aplicaciones.
Para un analista SOC la diferencia no es una sutileza terminológica. Determina qué evidencia tiene disponible cuando aparece una alerta.
Respuesta rápida: antivirus, EDR y XDR no responden la misma pregunta #
Podemos sintetizar la distinción inicial reduciendo cada tecnología a su objetivo esencial:
| Tecnología | Pregunta fundamental que responde | Enfoque operativo primario |
|---|---|---|
| Antivirus Moderno | ¿Puedo impedir que esta amenaza se ejecute o continúe ejecutándose? | Prevención perimetral de endpoint, interrupción y bloqueo de archivos o procesos hostiles. |
| EDR (Endpoint Detection and Response) | ¿Qué está ocurriendo en este endpoint y qué puedo hacer al respecto? | Visibilidad continua, reconstrucción de cadenas de ejecución, investigación forense y respuesta activa sobre el host. |
| XDR (Extended Detection and Response) | ¿Esta actividad del endpoint forma parte de un ataque que también afecta a usuarios, identidades, correo, aplicaciones u otros activos? | Correlación entre dominios desconectados, unificación de alertas en incidentes multivector y respuesta orquestada. |
Ese resumen sirve para orientarse en la consola, pero exige matices técnicos indispensables.
El primero es especialmente importante:
Un antivirus moderno no funciona únicamente buscando firmas estáticas.
Soluciones como Microsoft Defender Antivirus incorporan motores heurísticos, análisis de comportamiento dinámico, modelos locales de aprendizaje automático e inspección asistida por servicios en la nube en tiempo real. Por ello, presentar el antivirus como una obsoleta lista de hashes de malware pertenece a una simplificación superada en la seguridad corporativa moderna.
Qué es realmente un antivirus moderno #
La función histórica del antivirus fue identificar y bloquear software malicioso antes de que causara daño al sistema.
Esa función preventiva continúa siendo irremplazable, pero los motores actuales operan mediante múltiples capas analíticas concurrentes:
- Firmas y reputación de archivos: Búsqueda inmediata de coincidencias de hash y certificados criptográficos reconocidos.
- Análisis heurístico: Inspección de patrones de código y secuencias de instrucciones típicamente asociadas a exploits.
- Monitorización de comportamiento en tiempo de ejecución: Detección de comportamientos anómalos inmediatos (como un proceso que intenta inyectar memoria en el espacio de otro).
- Modelos de aprendizaje automático (Machine Learning): Clasificadores entrenados en millones de muestras que evalúan atributos estáticos y dinámicos del ejecutable.
- Inteligencia procedente de la nube: Envío de metadatos o muestras sospechosas a sandboxes en la nube para detonación y análisis en milisegundos.
- Bloqueo preventivo de procesos o scripts: Interrupción inmediata de la cadena antes de que se consume la acción.
Por tanto:
La diferencia técnica empieza a comprenderse mejor cuando cambiamos la pregunta operativa.
Supongamos que un documento malicioso desencadena la siguiente cadena:
El antivirus podría bloquear rundll32.exe si detecta que la biblioteca cargada coincide con una firma o exhibe un comportamiento malicioso evidente.
Pero un analista del SOC necesita responder interrogantes que el antivirus no fue diseñado para registrar ni estructurar:
- ¿Quién abrió el documento de Word y bajo qué sesión interactiva?
- ¿Qué comando exacto y qué parámetros recibió
powershell.exeen su línea de ejecución? - ¿Qué proceso creó a PowerShell y qué archivo abrió antes?
- ¿Qué archivos temporales se crearon o modificaron en el disco?
- ¿Qué conexiones de red intentó abrir antes del bloqueo?
- ¿Qué ocurrió en ese mismo endpoint cinco minutos antes de la alerta?
- ¿Apareció exactamente la misma actividad o el mismo documento en otros equipos de la empresa?
- ¿Podemos aislar el dispositivo de la red corporativa de inmediato para contener una propagación lateral?
Ahí es donde abandonamos la prevención aislada y entramos plenamente en el terreno del EDR.
De hecho, agencias de ciberseguridad como CISA (en su guía StopRansomware) contemplan antivirus y EDR como controles defensivos que deben coexistir necesariamente: recomiendan mantener la protección antivirus/antimalware en todos los sistemas y desplegar capacidades EDR para garantizar visibilidad profunda, auditoría de procesos y control de respuesta sobre los endpoints.
Por ello, no plantees la disyuntiva errónea:
“¿Antivirus o EDR?”
Plantea la pregunta profesional del Blue Team:
“¿Qué capacidades de prevención, visibilidad, investigación y respuesta necesito sobre mis endpoints?”
Qué es un EDR (Endpoint Detection and Response) #
EDR responde a las siglas Endpoint Detection and Response.
La palabra clave no es únicamente Detection. Es igualmente decisiva la segunda mitad: Response.
Un EDR es un agente y una plataforma que recopila y analiza telemetría continua de los endpoints con tres propósitos operativos claros:
- Detectar actividad sospechosa que los motores preventivos tradicionales no bloquearon (o técnicas de evasión Living off the Land).
- Proporcionar evidencia histórica contextual para investigar qué ocurrió antes, durante y después del incidente.
- Ejecutar acciones inmediatas de respuesta y contención remota sobre los dispositivos comprometidos.
Dependiendo del producto y de la plataforma analítica, esa telemetría recopilada en tiempo real suele abarcar:
- Creación y finalización de procesos: Registro de PIDs, PPIDs y el árbol genealógico completo de ejecución.
- Líneas de comandos íntegras (Command Line): Parámetros exactos pasados a binarios como
cmd.exe,powershell.exe,wmic.exeomshta.exe. - Operaciones de archivos: Creación, modificación, renombramiento y eliminación de archivos en rutas críticas (ej.
C:\Windows\Temp,AppData). - Modificaciones en el registro de Windows: Claves de persistencia (Run, RunOnce), configuraciones de servicios y políticas de seguridad.
- Conexiones de red originadas por procesos: Asociación exacta de qué binario estableció una conexión TCP/UDP, hacia qué IP/puerto y mediante qué resolución DNS.
- Inicios de sesión y contexto de usuario: Qué cuenta de usuario, con qué privilegios (SID, token) y en qué tipo de sesión se disparó la actividad.
- Carga de módulos y controladores (DLLs/Drivers): Detección de inyecciones de código y cargas anómalas de librerías dinámicas.
En plataformas como Microsoft Defender for Endpoint, Microsoft define su componente EDR como la capacidad para ofrecer detecciones avanzadas post-brecha, investigar el alcance global de un ataque y realizar acciones quirúrgicas de remediación sobre los activos impactados.
Aquí se formaliza la diferencia cardinal para un analista SOC:
El antivirus intenta proteger el equipo impidiendo que el software hostil se ejecute.
El EDR, además, convierte toda la actividad del sistema operativo en evidencia forense investigable.
Esa evidencia estructurada permite construir lo que utilizaremos constantemente en operaciones Blue Team: una línea temporal (timeline).
Imagina esta reconstrucción obtenida desde la consola EDR:
Ahora tenemos una historia. Pero conviene recordar una regla de oro profesional:
Todavía no lo sabemos.
Telemetría no significa culpabilidad.
PowerShell no es malware. rundll32.exe tampoco lo es. Una conexión externa saliente hacia un puerto 443 tampoco demuestra por sí sola la existencia de un compromiso hostil. El analista tiene que interpretar la combinación del proceso padre, la línea de argumentos, el usuario involucrado y los artefactos secundarios.
Esta forma de razonamiento analítico conecta de manera directa con nuestra guía sobre MITRE ATT&CK para analistas SOC: las técnicas modelan comportamientos adversarios, pero no sustituyen el juicio técnico de la investigación.
Un EDR tampoco registra absolutamente todo #
Un error muy extendido entre analistas noveles y administradores es tratar el agente EDR como si fuera una grabadora de audio infalible que almacena cada microsegundo del sistema operativo. No lo es.
La propia documentación técnica de Microsoft advierte con claridad que Defender for Endpoint no está diseñado como una solución de auditoría exhaustiva que deba registrar cada operación individual realizada en un endpoint. El sensor del kernel y los controladores en modo usuario implementan mecanismos deliberados de limitación de tasa (throttling) y deduplicación para impedir que bucles de eventos masivos o aplicaciones legítimas saturen el rendimiento de la CPU, la memoria o el ancho de banda hacia la nube.
Esto nos deja una máxima de investigación forense que todo profesional de seguridad debe interiorizar:
La ausencia de un evento no demuestra que la actividad no ocurrió.
No lo veo no significa que no ocurrió.
Cuando revisas una consola y no encuentras una traza esperada, las causas técnicas pueden ser múltiples:
- El evento puntual fue descartado por los filtros de optimización del sensor local para proteger el rendimiento del host.
- Hubo una caída temporal de conectividad de red y el búfer de cola local del agente se desbordó antes de sincronizar con el backend.
- La actividad ocurrió fuera de la ventana de retención contratada para la telemetría histórica (por ejemplo, pasados los 30 o 90 días estándar).
- El tipo de evento específico pertenecía a un canal de auditoría opcional o un proveedor de telemetría que no estaba habilitado en la política central.
- El malware utilizó técnicas avanzadas de evasión para cegar el sensor antes de ejecutar su carga útil (como la descarga del driver mediante vulnerabilidades Bring Your Own Vulnerable Driver o el parcheo de ganchos en modo usuario de AMSI/ETW).
Por eso, un analista nunca debe emitir un veredicto de cierre de alerta basándose exclusivamente en no haber encontrado un registro en su primera consulta superficial.
Qué puede hacer un analista desde un EDR #
Las capacidades operativas exactas varían en función de la arquitectura del producto y el nivel de suscripción, pero una solución EDR profesional proporciona al analista defensivo un conjunto de acciones tácticas incomparables frente al análisis pasivo de logs centralizados:
| Capacidad EDR | Mecánica técnica | Valor operativo para el SOC |
|---|---|---|
| Inspección del árbol de procesos | Reconstrucción gráfica y tabular de la jerarquía padre, proceso actual y procesos hijos (PID/PPID). | Descubrir de inmediato qué aplicación legítima fue abusada para lanzar herramientas de administración o scripts ofuscados. |
| Análisis temporal adyacente | Consulta de telemetría de disco, red y registro generada en una ventana de minutos antes y después de la alerta. | Contextualizar la detonación: qué documento se guardó previamente, qué clave de registro se tocó y qué dominio se resolvió. |
| Búsqueda horizontal de alcance (Scoping) | Consultas masivas sobre la base de telemetría de todos los endpoints de la organización (ej. KQL en Defender o EQL en Elastic). | Determinar en segundos si un hash, un archivo temporal o una IP de destino ha tenido presencia en otros 500 equipos. |
| Aislamiento de red del endpoint | Corte inmediato del tráfico de red a nivel de driver en el endpoint, manteniendo exclusivamente el túnel seguro hacia la consola EDR. | Contener de raíz una posible propagación lateral o exfiltración activa sin apagar la máquina, preservando la memoria volátil. |
| Terminación de procesos y cuarentena | Interrupción forzada del árbol de ejecución en memoria y aislamiento criptográfico del binario en un repositorio seguro del agente. | Frenar en seco la persistencia del adversario antes de que establezca canales de mando y control (C2). |
| Respuesta interactiva remota (Live Response) | Apertura de una consola segura de comandos directa contra el endpoint para recolectar volcados de memoria, ejecutar scripts forenses o inspeccionar sockets. | Recolectar evidencias de bajo nivel sin necesidad de desplazarse físicamente hasta el puesto de trabajo del usuario. |
Tanto Microsoft (con las capacidades de Live Response y Automated Investigation and Response en Defender for Endpoint) como Elastic (con las acciones de aislamiento, terminación de procesos y comandos remotos en Elastic Defend) demuestran que estas funciones representan el estándar operativo de la industria.
Y aquí aparece el cambio radical de paradigma respecto a consultar registros de eventos convencionales en un visor pasivo:
Un log tradicional te dice: “Ocurrió el evento X.”
Un EDR te permite investigar: “¿Qué produjo X? ¿Qué ocurrió inmediatamente después? ¿En qué otros 50 equipos de la red está sucediendo lo mismo? ¿Y debo pulsar el botón de aislamiento de red ahora mismo para proteger el negocio?”
La herramienta aporta telemetría. El analista aporta interpretación.
Qué es XDR (Extended Detection and Response) #
XDR responde a las siglas Extended Detection and Response.
La palabra cardinal ahora es Extended (extendido).
El problema estructural que intenta resolver es evidente en cualquier centro de operaciones de seguridad corporativo:
Un ciberataque real nunca respeta la fragmentación de nuestras herramientas de seguridad.
Una intrusión contemporánea suele comenzar a través de una superficie multifacética:
Sin embargo, dentro de muchas empresas, el equipo de seguridad gestiona este incidente a través de silos tecnológicos inconexos:
- Una consola dedicada exclusivamente a la pasarela de seguridad del correo electrónico (Email Gateway / Antiphishing).
- Una consola independiente para el directorio de identidades y la autenticación multifactor (Active Directory, Entra ID, Okta).
- Una consola específica para la monitorización de los endpoints (la plataforma EDR).
- Una consola separada para la seguridad de aplicaciones SaaS y almacenamiento en la nube (CASB / Cloud Security).
- Y una plataforma SIEM donde se envían registros masivos mediante reenvío de logs.
El resultado es la mayor debilidad táctica del defensor:
El atacante ve una única cadena fluida de intrusión.
El analista defensivo ve cinco pantallas desconectadas generando alertas fragmentadas.
XDR surge para derribar esos silos. Plataformas como Microsoft Defender XDR unifican y correlacionan señales nativas provenientes de endpoints, identidades de usuario, tráfico de correo electrónico y aplicaciones cloud para agrupar alertas dispersas en incidentes holísticos coordinados.
El propósito de XDR no radica en ser un almacén gigantesco de almacenamiento masivo. Consiste en aportar contexto automático entre dominios.
Un ejemplo permite verlo mejor #
Analicemos cómo cambia drásticamente la perspectiva del SOC ante una campaña de phishing dirigida:
1. En el vector de correo
A las 09:45, la pasarela de correo registra la llegada de un mensaje con el asunto «Actualización de nómina urgente» que contiene un enlace hacia una URL recién registrada.
2. En el vector de identidad
A las 09:51, la cuenta del usuario jorge.sanchez registra un inicio de sesión anómalo desde una dirección IP residencial desconocida, completando satisfactoriamente un desafío MFA mediante un ataque de fatiga de notificaciones.
3. En el vector de endpoint
A las 09:55, el navegador web en el portátil corporativo de Jorge descarga un documento con macros. Dos minutos después, el agente EDR registra en local:
4. En la actividad posterior
A las 10:02, ese mismo equipo establece una conexión por SMB contra el servidor de archivos interno de Finanzas utilizando credenciales cacheadas en memoria.
La diferencia entre operar con alertas aisladas y operar con XDR
En un entorno fragmentado sin correlación entre dominios, la cola del SOC recibiría cuatro alertas desconectadas asignadas potencialmente a cuatro analistas distintos o dispersas en diferentes consolas:
- Alerta 1 (Consola de correo): Suspicious link delivered in email.
- Alerta 2 (Consola de identidad): Atypical travel or impossible travel detected for user jorge.sanchez.
- Alerta 3 (Consola EDR): Suspicious PowerShell execution from Office process.
- Alerta 4 (Consola de red): Anomalous SMB connection to file server.
El analista del endpoint que investiga la Alerta 3 no sabe que 10 minutos antes hubo un phishing ni que la identidad del usuario fue vulnerada. El analista de correo que ve la Alerta 1 no sabe si el usuario hizo clic o si se ejecutó código en la máquina.
Una plataforma XDR toma esas cuatro señales y las fusiona automáticamente en un único incidente unificado:
Eso reduce drásticamente la tarea más costosa y propensa a errores humanos en las operaciones diarias del SOC:
Reconstruir manualmente la historia de una intrusión cruzando registros inconexos entre múltiples consolas.
EDR vs XDR vs antivirus: tabla comparativa #
La siguiente matriz sintetiza las diferencias operativas, técnicas y de alcance entre las tres soluciones:
| Dimensión analítica | Antivirus Moderno | EDR | XDR |
|---|---|---|---|
| Alcance principal | Endpoint local (workstation y servidor). | Endpoint local y telemetría de host. | Múltiples dominios integrados (endpoint, identidad, email, apps, cloud). |
| Prioridad operativa | Prevención perimetral y bloqueo de malware antes de ejecutarse. | Detección de comportamientos anómalos, investigación forense y respuesta en host. | Correlación multivector, investigación transversal e incidentes unificados. |
| Bloqueo de malware conocido | Sí, es su función primaria mediante firmas, ML y sandboxing en nube. | Sí, generalmente integrando o colaborando con el motor antivirus. | Sí, integrando la señal defensiva en la correlación global. |
| Telemetría continua de procesos | Variable y limitada a inspección de memoria en tiempo de ejecución. | Fundamental y exhaustiva: registra ejecuciones, argumentos, PIDs y módulos. | Consume la telemetría del EDR para enriquecer el grafo del incidente. |
| Árbol genealógico de procesos | No orientado a reconstrucción visual ni investigación forense. | Sí, capacidad central e indispensable de la consola analítica. | Sí, contextualizado dentro de la secuencia global de eventos entre dominios. |
| Investigación histórica | Limitada a los registros locales de detecciones y cuarentenas pasadas. | Sí, permite realizar consultas retroactivas sobre días o semanas de datos. | Sí, combinando eventos históricos de endpoint con logs de identidad y correo. |
| Contexto de identidades | No es su ámbito de actuación; solo registra el usuario local ejecutor. | Aporta contexto de la cuenta de usuario que lanzó los comandos. | Ámbito central: analiza atributos de identidad, tokens, anomalías de logon y grupos AD. |
| Visibilidad de correo | Escaneo de adjuntos en disco al descargarse; sin visión de la pasarela. | Detecta si un proceso de correo (Outlook) engendró un binario secundario. | Ámbito central: analiza remitentes, cabeceras, clics en URLs y buzones de la organización. |
| Capacidad de respuesta | Bloqueo automático de ejecución, desinfección o cuarentena del archivo. | Aislamiento de red del equipo, terminación de procesos, borrado de archivos, Live Response. | Respuesta coordinada: aislar el host, revocar credenciales, invalidar tokens y purgar correos. |
| Función principal en el SOC | Capa preventiva básica que filtra el malware genérico y no sofisticado. | Herramienta central de investigación técnica y triage en endpoints. | Plataforma de gestión de incidentes avanzados y correlación multivectorial. |
No utilices esta tabla comparativa para llegar a la conclusión simplista de que XDR es automáticamente «mejor» que un EDR.
XDR tiene un alcance conceptual más amplio. Pero eso no implica que una solución comercial etiquetada como XDR ofrezca mejor telemetría de kernel, mejores analíticas de procesos o mejores capacidades de contención que un EDR de primera línea.
Entonces, ¿un XDR sustituye al EDR? #
Habitualmente, esta pregunta está mal formulada desde su base.
Un XDR no sustituye al EDR porque un XDR se alimenta de señales. Y una de las fuentes de datos más valiosas y determinantes en cualquier investigación defensiva es, precisamente, la telemetría granular del endpoint provista por el sensor EDR.
En el ecosistema de Microsoft Defender, por ejemplo, Microsoft Defender for Endpoint actúa como el sensor y motor EDR. Posteriormente, sus eventos y detecciones viajan hacia Microsoft Defender XDR, donde se entrecruzan con Microsoft Defender for Identity, Defender for Office 365 y Defender for Cloud Apps.
Por consiguiente, la relación técnica real debe modelarse así:
El modelo mental que debes desterrar es concebir una línea recta de obsolescencia:
Antivirus ──► EDR ──► XDR ❌ (Modelo incorrecto)
Al implementar la tecnología siguiente no desaparece la anterior. De hecho, en la mayoría de los fabricantes de vanguardia, el motor antivirus de nueva generación, el sensor de comportamiento EDR y los conectores XDR se despliegan en un único agente unificado instalado en el endpoint.
¿Qué utiliza realmente un SOC? #
Si visitas un centro de operaciones de seguridad de una corporación madura, la respuesta a la pregunta del título no será un producto exclusivo. En la práctica, el SOC opera con una estrategia de defensa en profundidad donde coexisten múltiples capas:
Si la empresa cuenta con una arquitectura XDR, esta consolida los incidentes multivector del fabricante. Pero ese ecosistema continúa coexistiendo armónicamente con la plataforma SIEM.
De hecho, las directivas y especificaciones técnicas emitidas por CISA para los organismos federales exigen que las soluciones EDR obligatorias cuenten con conectores nativos para reenviar sus alertas, detecciones y metadatos forenses hacia el SIEM centralizado de la organización.
En el SOC no pensamos en herramientas como islas independientes. Pensamos en un ciclo técnico integrado:
Fuentes ──► Telemetría ──► Detecciones ──► Correlación ──► Investigación ──► Respuesta
SIEM y XDR tampoco son exactamente lo mismo #
Es común encontrar debates comerciales que presentan a XDR como el asesino del SIEM o al SIEM como una reliquia superada. Ninguna de las dos afirmaciones resiste un análisis técnico riguroso.
Un SIEM (Security Information and Event Management) es un sistema centralizado de recopilación masiva de telemetría y cumplimiento normativo. Su función histórica y actual es ingerir datos de absolutamente cualquier fuente que genere texto o JSON:
- Logs de servidores Linux y bases de datos Oracle.
- Tablas de auditoría de routers Cisco y switches perimetrales.
- Tráfico de proxies corporativos, balanceadores F5 y firewalls Fortinet o Palo Alto.
- Registros de eventos de Active Directory y VPN corporativa.
- Logs de aplicaciones empresariales propias y APIs personalizadas.
Por su parte, un XDR suele estar optimizado para construir analíticas de alta fidelidad, telemetría profunda y acciones de respuesta automatizadas dentro del conjunto cerrado de productos y dominios de seguridad que la plataforma o su ecosistema soportan (típicamente endpoint, identidad, correo y nube).
XDR no significa «SIEM nuevo».
SIEM no significa «XDR antiguo».
Ambas tecnologías resuelven problemas complementarios. El XDR aporta detección especializada y respuesta entre sus dominios integrados; el SIEM proporciona retención a largo plazo, correlación de infraestructura no gestionada por agentes y centralización de auditoría para toda la compañía. Para profundizar en la arquitectura y funciones del SIEM, consulta nuestra guía sobre qué es un SIEM y cómo lo utiliza un SOC.
Caso práctico: una alerta de PowerShell #
Analicemos un escenario de investigación real para comprobar cómo interactúan estas capas sin precipitarnos a conclusiones erróneas.
El analista del SOC abre la consola y se encuentra la siguiente alerta de severidad media generada por el motor EDR:
Host: WS-CONTAB-09 (Área de Finanzas)
Usuario: carmen.ruiz
Al desplegar el árbol de procesos en el EDR, observa la siguiente estructura:
¿Qué hace un analista riguroso ante este hallazgo? Lo primero que NO hace es redactar de inmediato: «Equipo infectado por malware crítico».
Todavía no lo sabemos. PowerShell no es malware.
Un analista profesional formula de inmediato ocho preguntas técnicas que investiga utilizando las capacidades del EDR:
- Proceso padre: ¿Por qué Microsoft Word (
WINWORD.EXE) inició PowerShell? ¿Existe alguna macro legítima de contabilidad que la empresa utilice de forma homologada? - Línea de comandos: ¿Qué oculta el parámetro
-enc? El analista decodifica la cadena en Base64 para analizar el script real ejecutado en memoria. - Contexto de usuario: ¿La cuenta
carmen.ruiztiene permisos administrativos locales en el equipo? - Archivo asociado: ¿Cuál fue el documento específico que abrió Word? El EDR revela que el archivo se llamaba
factura_abril_rectificada.docmguardado en la carpeta de descargas del usuario. - Conexiones de red: ¿Estableció
powershell.exealguna conexión hacia Internet? El EDR muestra una sesión TCP saliente hacia194.26.29.112:8443inmediatamente después de iniciarse. - Procesos hijos: ¿Engendró PowerShell otros procesos antes de finalizar? En la telemetría aparece la creación de
whoami.exeycmd.exe. - Artefactos de persistencia: ¿Se modificó alguna clave de registro en
CurrentVersion\Runo se creó una tarea programada medianteschtasks.exe? - Alcance en otros endpoints: ¿Existe el archivo
factura_abril_rectificada.docmo la conexión a la IP externa en alguna otra máquina de la organización?
Añadiendo la capa XDR a la investigación
Ahora imaginemos que el SOC cuenta con una plataforma XDR integrada.
Al abrir el incidente correlacionado, la consola no solo muestra la ejecución del proceso en el endpoint; aporta automáticamente piezas procedentes de otros dominios:
- Dominio de Correo: Muestra que 25 minutos antes, el buzón de Carmen recibió un correo electrónico externo con remitente falseado simulando ser un proveedor habitual de la empresa, adjuntando el archivo
factura_abril_rectificada.docm. Además, el XDR alerta de que otros cuatro empleados de contabilidad recibieron exactamente el mismo correo. - Dominio de Identidad: Revela que tras la ejecución de PowerShell, no se registraron inicios de sesión sospechosos para la cuenta de Carmen en otros sistemas corporativos.
La alerta de PowerShell en el endpoint no cambió en lo más mínimo.
Lo que cambió radicalmente fue el contexto disponible para interpretarla y tomar decisiones de respuesta.
Con esa visibilidad enriquecida, el analista no solo aísla el equipo WS-CONTAB-09 desde el EDR: a través del XDR solicita la purga inmediata de los otros cuatro correos en los buzones de los compañeros antes de que alguno de ellos abra el archivo adjunto.
Un SOC no debería investigar sólo el nombre de la alerta #
Un error clásico que cometen los analistas junior al enfrentarse a una consola EDR o XDR es obsesionarse con el nombre comercial de la detección:
El analista novato abre un buscador en Internet y escribe el nombre de la regla para intentar entender qué ha ocurrido. Aunque consultar la documentación del fabricante es útil para conocer la lógica del detector, la investigación forense real debe basarse siempre en la evidencia técnica observable:
- ¿Qué proceso exacto (con ruta absoluta y hash) intentó acceder a la memoria de
lsass.exe? - ¿Bajo qué cuenta de usuario y con qué privilegios de token se ejecutaba ese proceso?
- ¿En qué estación de trabajo o servidor ocurrió y qué rol desempeña ese activo en la red corporativa?
- ¿Qué eventos se registraron en la línea temporal dos minutos antes y dos minutos después?
- ¿Qué otros activos o sesiones de red aparecen involucrados?
- ¿Existe algún software legítimo (como un agente de backup, un antivirus de terceros o una herramienta de inventario) que justifique esa lectura?
El nombre de una alerta no es una sentencia judicial. Es simplemente una hipótesis generada por un algoritmo analítico.
Una alerta no es una conclusión.
Aprender a contrastar esa hipótesis con evidencia objetiva es la base sobre la que se asienta el siguiente proceso fundamental del analista en las trincheras defensivas: el triage de alertas SOC.
Cómo utilizar un EDR durante una investigación SOC #
Cuando un analista recibe una alerta en la consola del EDR, debe seguir un método técnico estructurado y reproducible para evitar perderse entre miles de eventos o emitir conclusiones prematuras. Podemos sintetizar el flujo operativo en siete pasos clave:
1 Leer la detección sin asumir que es un compromiso confirmado
Identifica de forma metódica los parámetros observables de partida: nombre del host afectado, cuenta de usuario, hora exacta (en UTC para evitar discrepancias de zona horaria), nivel de severidad asignado por el motor, binarios involucrados, indicadores (hashes, IPs, dominios) y la técnica de MITRE ATT&CK asociada si la regla la contempla.
2 Reconstruir el árbol de procesos completo
Nunca estudies un proceso aislado del resto del sistema. Inspecciona la jerarquía genealógica en ambas direcciones:
Verifica las líneas de comandos completas (CommandLine). La mayoría de los atacantes que utilizan herramientas del sistema (LOLBins) dejan su intención reflejada en los argumentos pasados al binario (por ejemplo, parámetros para ocultar la ventana, deshabilitar logs o ejecutar código codificado).
3 Construir el contexto temporal adyacente
Pregunta siempre: ¿qué ocurrió inmediatamente antes y después del evento alertado? Establece una ventana de análisis de al menos 15 minutos previos y posteriores en el host:
- ¿Se descargó algún archivo desde el navegador o la aplicación de correo antes de la ejecución?
- ¿Se crearon binarios ejecutables o scripts en directorios temporales (
Temp,ProgramData)? - ¿Aparece actividad anómala en el visor de eventos de autenticación?
4 Revisar la actividad y correlación de red
Una ejecución sospechosa adquiere una dimensión radicalmente distinta si el EDR refleja que el proceso inició una conexión de red hacia infraestructura externa no catalogada o hacia un segmento interno de servidores críticos. Revisa la IP de destino, el puerto, la reputación del dominio resuelto y el volumen de bytes transmitidos.
5 Determinar el alcance horizontal (Scoping de flota)
Lanza una consulta en la base de datos de telemetría del EDR para verificar si otros equipos de la organización presentan la misma huella:
- ¿El hash del archivo sospechoso aparece registrado en otros puestos de trabajo?
- ¿La misma línea de comandos fue ejecutada en otros servidores del dominio?
- ¿Otros hosts se han conectado a la misma dirección IP en las últimas 24 horas?
6 Decidir y ejecutar acciones de contención
Si la evidencia técnica confirma una actividad maliciosa activa o una amenaza de propagación inminente, aplica las capacidades de respuesta del EDR con criterio táctico:
- Aislar el host en red: Corta la comunicación lateral de inmediato.
- Finalizar el proceso: Interrumpe la ejecución del árbol hostil.
- Poner en cuarentena los archivos: Extrae el binario hacia un contenedor seguro.
- Abrir Live Response: Recolecta artefactos volátiles si el equipo de respuesta a incidentes requiere análisis forense en profundidad.
7 Documentar rigurosamente la justificación del veredicto
Cerrar un ticket escribiendo simplemente «Falso positivo» o «Resuelto» es inaceptable en un SOC profesional. Redacta qué evidencias específicas sustentaron tu conclusión: qué orden de cambio justificaba el script, por qué el hash coincide con el software homologado o qué acciones de contención se aplicaron antes de transferir el caso.
Mini laboratorio: aprender EDR sin ejecutar malware #
No necesitas descargar ni detonar muestras de malware destructivo para comprender a fondo la telemetría del endpoint y aprender a pensar como un analista SOC.
En una máquina virtual de laboratorio aislada con Windows 10/11 o Windows Server, puedes generar una cadena de procesos benigna pero rica en artefactos ejecutando una única línea de PowerShell con permisos estándar:
Start-Process cmd.exe -ArgumentList '/c whoami && nslookup example.com'Al ejecutar este comando, el sistema operativo genera una estructura jerárquica observable:
El objetivo pedagógico de este ejercicio no es detectar un ciberataque, sino responder a las preguntas que formularías ante una alerta real:
- ¿Puedo localizar el evento de creación de
powershell.exey extraer su PID? - ¿Aparece la línea de comandos completa de
cmd.execon los argumentos/c whoami && nslookup example.com? - ¿Puedo identificar con precisión que el proceso padre de
cmd.exefue PowerShell y no el explorador de archivos (explorer.exe)? - ¿Se registraron las ejecuciones efímeras de
whoami.exeynslookup.exeantes de que sus procesos finalizaran? - ¿Puedo rastrear el evento de red correspondiente a la consulta DNS generada por
nslookup.exe? - ¿Qué cuenta de usuario figura como propietario de cada uno de los procesos en la cadena?
- ¿Qué marca de tiempo (timestamp) en milisegundos separa la ejecución de cada componente?
Practicar sin un EDR comercial mediante Sysmon y Windows Event Logs
Si no tienes acceso a una licencia comercial de Microsoft Defender for Endpoint o CrowdStrike en tu laboratorio personal, puedes reconstruir exactamente este mismo nivel de visibilidad combinando dos tecnologías gratuitas estándar:
- Los Windows Event Logs de auditoría de creación de procesos (Event ID 4688 con la directiva de auditoría de líneas de comandos habilitada).
- La herramienta Sysmon (System Monitor) de Microsoft Sysinternals, que registra con fidelidad el Event ID 1 (Creación de procesos con hashes MD5/SHA256 y CommandLine), Event ID 3 (Conexiones de red con PID) y Event ID 22 (Consultas DNS).
Esto demuestra la continuidad formativa del Blue Team en nuestro itinerario formativo:
Logs ──► Windows Event Logs ──► Sysmon ──► SIEM ──► MITRE ATT&CK ──► EDR
La tecnología de visualización puede variar entre una consola web sofisticada y el Visor de Eventos de Windows, pero el principio analítico es idéntico: aprender a seguir la evidencia técnica paso a paso.
Qué aporta XDR durante ese mismo laboratorio #
Ahora imaginemos que ese mismo comando de prueba se ejecuta dentro de un entorno corporativo empresarial monitorizado por una arquitectura XDR completa.
Mientras que el sensor EDR se limita a proyectar la secuencia dentro de la máquina local:
La plataforma XDR aporta capas de contexto que conectan la actividad técnica del host con la identidad y los servicios de la empresa:
Esto transforma la naturaleza de la investigación forense:
El EDR te hace preguntar: «¿Qué procesos, archivos y conexiones ocurrieron dentro del equipo WS-042?»
El XDR te permite preguntar: «¿Quién es este usuario, qué correos ha recibido, qué otras sesiones tiene abiertas en la nube y qué otros activos corporativos ha tocado en la última hora?»
Este cambio de perspectiva es fundamental para el analista defensivo: el EDR suele comenzar su investigación en el endpoint; el XDR intenta reconstruir la historia del incidente entre todos los dominios de la organización.
Antivirus, EDR y XDR frente al mismo ataque #
Para comprobar cómo cooperan estas capas defensivas en la realidad operativa, analicemos un mismo ataque simulado en tres escenarios según los controles activos:
Escenario A: El antivirus bloquea la amenaza en prevención
Un usuario descarga un troyano empaquetado conocido. Al depositarse en el disco, el motor antivirus en tiempo real escanea el archivo, detecta una firma heurística o una consulta de reputación en la nube y bloquea el ejecutable de forma instantánea, enviándolo a cuarentena antes de que llegue a ejecutarse.
Resultado: El ataque no prospera. El SOC recibe una notificación de bloqueo preventivo y puede revisar si otros usuarios descargaron el mismo archivo.
Escenario B: El archivo elude la prevención inicial y actúa el EDR
El atacante utiliza un binario compilado a medida o un script ofuscado que no coincide con ninguna firma previa ni dispara heurísticas estáticas. El archivo se ejecuta sin oposición del antivirus.
Sin embargo, a los pocos segundos, el proceso intenta inyectar código en explorer.exe y lanzar PowerShell para modificar el registro. El sensor EDR detecta este comportamiento anómalo post-ejecución, genera una alerta detallada en la consola del SOC con el árbol de procesos completo y permite al analista aislar el host de la red en un clic para cortar la propagación.
Resultado: La prevención falló, pero la visibilidad y respuesta del EDR permitieron contener y erradicar la intrusión antes de que se produjera movimiento lateral o robo de datos.
Escenario C: El ataque es multivectorial y actúa el XDR
El ataque comenzó con una campaña de phishing de credenciales contra varios empleados. Uno de ellos introdujo su contraseña en un portal señuelo y el atacante utilizó esas credenciales para autenticarse por VPN y acceder a un servidor interno donde ejecutó herramientas de descubrimiento de red.
El XDR vincula el correo original de phishing, el evento de autenticación anómala en el servicio de identidad y los comandos de descubrimiento registrados por el EDR en el servidor, agrupando todo en un único incidente coordinado.
Resultado: El equipo de respuesta a incidentes visualiza el vector de entrada real, revoca los tokens de la cuenta comprometida, aísla el servidor afectado y purga los correos de phishing del resto de los buzones en una sola operación defensiva.
Como demuestran estos tres escenarios, estas herramientas no compiten entre sí:
Se complementan y refuerzan mutuamente dentro de una estrategia de defensa en profundidad.
Cuándo un EDR puede crear una falsa sensación de seguridad #
Comprar una suscripción cara de una plataforma EDR e instalar el agente no equivale de forma automática a tener una visibilidad perfecta sobre la infraestructura. En el SOC, confiar a ciegas en la tecnología sin auditar su estado real crea una falsa y peligrosa sensación de inmunidad.
Antes de dar por cerrado un incidente o asumir que una red está limpia, el equipo defensivo debe verificar ocho dimensiones críticas:
- Cobertura real de agentes: ¿Qué porcentaje de las estaciones de trabajo y servidores corporativos tienen el agente instalado y activo? Si tienes un 95% de cobertura, el 5% no monitorizado se convertirá en el santuario preferido de los atacantes para instalar sus herramientas de movimiento lateral.
- Salud y conectividad del sensor: ¿Los agentes se están comunicando regularmente con la consola central o existen cientos de endpoints con estados Unhealthy, versiones desactualizadas o caídas de conexión?
- Sistemas legacy y no soportados: ¿Qué ocurre con los servidores antiguos (Windows Server 2008, distribuciones Linux obsoletas) o dispositivos IoT/OT donde el agente EDR moderno no puede instalarse?
- Ventana de retención de telemetría: ¿Cuántos días de datos históricos conserva tu suscripción? Si un adversario utiliza técnicas de dwell time prolongado y la telemetría solo se retiene 14 o 30 días, sus trazas de acceso inicial habrán desaparecido para siempre cuando comiences a investigar.
- Telemetría habilitada por política: ¿La configuración del agente tiene activada la captura de conexiones de red de procesos, eventos de registro y eventos DNS, o se deshabilitaron para ahorrar ancho de banda o costes de almacenamiento?
- Configuración del modo de respuesta: ¿El agente está operando en modo preventivo activo (Block / Protect) o en modo de solo auditoría (Audit / Detection only)?
- Permisos y autoridad operativa del analista: ¿El analista del SOC L1 o L2 tiene permisos delegados en la consola para pulsar el botón de aislamiento de red o necesita un proceso burocrático de aprobación de dos horas para contener una máquina?
- Integración con el SIEM y flujos de ticketing: ¿Las alertas del EDR llegan en tiempo real a la cola de trabajo del SOC con la severidad adecuada o se acumulan inadvertidas en una consola secundaria que nadie revisa?
Recuerda siempre este axioma de operaciones defensivas:
Una consola EDR que muestra «0 incidentes detectados» no significa necesariamente «0 incidentes existentes».
Frecuentemente significa: «0 amenazas detectadas dentro del límite de nuestra visibilidad y configuración actual».
Cinco errores frecuentes en operaciones SOC #
Al analizar cómo interactúan los equipos de seguridad con sus plataformas defensivas, es común identificar cinco fallos de concepto recurrentes:
Error 1: «El antivirus ya no sirve para nada»
Falso. La prevención perimetral de malware continúa siendo la primera línea de contención obligatoria en cualquier red. Desactivar el antivirus porque se dispone de un EDR obligaría a los analistas a investigar y responder manualmente miles de intentos de infección por malware genérico o commodity que un motor antivirus básico neutraliza de forma automática en microsegundos sin generar ruido operativo.
Error 2: «EDR es simplemente un antivirus más potente»
Demasiado simplificado. La diferencia que transforma el trabajo diario del SOC no es solo cuántos virus puede parar, sino la capacidad para detectar comportamientos sofisticados, reconstruir líneas temporales forenses, delimitar el alcance global y ejecutar contención remota sobre los activos.
Error 3: «XDR sustituye todas nuestras herramientas defensivas»
No asumas promesas comerciales sin auditoría técnica. Pregunta siempre qué fuentes ingiere nativamente, qué telemetría conserva, qué latencia introduce y qué ocurre con los cortafuegos o servidores de otros fabricantes no integrados en el ecosistema. Las plataformas XDR no eliminan la necesidad de un SIEM para la auditoría universal ni la necesidad de analistas capacitados.
Error 4: «Si el EDR no muestra nada, no ocurrió nada»
Tampoco. Como advierte Microsoft sobre Defender for Endpoint, los sensores aplican técnicas de rate limiting para no degradar el endpoint y pueden existir brechas de visibilidad o evasiones de kernel. Ausencia de evidencia no equivale a evidencia de ausencia.
Error 5: Investigar alertas centrándose exclusivamente en IoCs estáticos
Buscar hashes, direcciones IP y nombres de dominio en VirusTotal sigue siendo una tarea complementaria útil, pero los adversarios modifican sus indicadores atómicos en cada compilación en cuestión de segundos. El valor indiscutible de un EDR radica en modelar y detectar comportamientos técnicos (TTPs):
El hash cambia; la lógica adversarial de la cadena de ejecución permanece observable.
¿Qué debería aprender primero alguien que quiere trabajar en SOC? #
Uno de los errores más frustrantes para los estudiantes que aspiran a entrar en el sector es intentar memorizar los botones, paneles y menús de veinte consolas comerciales distintas de EDR o XDR.
Las interfaces gráficas de los fabricantes cambian constantemente de diseño, pero los fundamentos técnicos de los sistemas operativos no cambian. Tu prioridad formativa debe centrarse en aprender a interpretar la evidencia del endpoint:
- Árboles de procesos: Relación entre procesos padre, procesos hijos y llamadas al kernel de Windows y Linux.
- Cuentas y contextos de usuario: Permisos, SIDs, elevación UAC y tipos de logon interactivo vs red.
- Líneas de comandos: Identificación de ofuscaciones, parámetros de LOLBins y scripts de administración.
- Operaciones de disco y registro: Modificaciones de persistencia y rutas estándar de descarga.
- Conexiones y sockets de red: Correlación entre el PID del proceso y el socket de red TCP/UDP.
- Timelines forenses: Construcción de secuencias cronológicas coherentes cruzando eventos.
Si comprendes qué significa la evidencia técnica, aprender a manejar la interfaz de Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne o Elastic Defend te llevará unos pocos días. Si solo aprendes a hacer clic en una consola específica sin comprender los datos que muestra, cualquier cambio de herramienta en tu empresa te obligará a empezar prácticamente de cero.
Para conocer la secuencia ordenada de estudio y las competencias clave del sector, revisa nuestro Blue Team roadmap y la guía especializada sobre las habilidades que necesita un analista SOC.
¿Quieres seguir una ruta completa de Blue Team?
Si quieres pasar de interpretar logs y telemetría a investigar alertas, trabajar con SIEM, EDR y respuesta a incidentes, continúa con la Ruta Blue Team & SOC de Achirou, organizada para avanzar paso a paso desde los fundamentos técnicos hasta las operaciones defensivas reales.
Explorar la Ruta Blue Team & SOC de AchirouPreguntas frecuentes técnicas #
¿Cuál es la diferencia entre EDR y antivirus?
¿EDR sustituye al antivirus?
¿Qué diferencia existe entre EDR y XDR?
¿Un SOC necesita obligatoriamente un EDR?
¿XDR reemplaza al SIEM corporativo?
¿El EDR registra absolutamente todo lo que ocurre en un ordenador?
¿Qué EDR debería aprender a utilizar un analista SOC junior?
Conclusión y siguientes pasos #
Antivirus, EDR y XDR no deben entenderse como tres versiones sucesivas ni como productos que se anulan mutuamente en una carrera comercial:
- El antivirus aporta la capa preventiva indispensable para bloquear amenazas conocidas y malware genérico antes de que toquen el sistema.
- El EDR convierte la actividad interna del endpoint en telemetría forense estructurada para detectar comportamientos evasivos, investigar su origen y contener hosts comprometidos.
- El XDR rompe los silos entre herramientas y correlaciona las evidencias del host con identidad, correo electrónico y aplicaciones en la nube para reconstruir la historia completa del ataque.
Sin embargo, ninguna de estas plataformas puede sustituir el criterio técnico de un profesional capacitado. Una consola puede alertar de que PowerShell se ha ejecutado; puede mostrar el árbol genealógico desde Microsoft Word; e incluso puede correlacionar el evento con la llegada de un correo electrónico previo.
Pero el analista del SOC continuará necesitando responder a las preguntas determinantes:
¿Por qué ocurrió esta ejecución? ¿Se trata de un procedimiento administrativo legítimo o de una intrusión hostil? ¿Qué evidencia técnica respalda esa afirmación? ¿Y cuál es el alcance real en la red de la empresa?
Ese proceso analítico riguroso se estructura de forma reproducible en el siguiente artículo de nuestro cluster defensivo: aprende cómo pasar de la señal técnica al veredicto profesional en nuestra guía sobre triage de alertas SOC: cómo investigar una alerta paso a paso.
Volver al índice de contenidos