El EDR aísla el equipo solo; la regla que lo devuelve a la red se escribe antes

El 3 de septiembre a las 20:19 UTC, alguien de Microsoft añadió una frase a la documentación de Defender for Endpoint. El 4 de septiembre a las 19:06 UTC ya no estaba. Vivió menos de un día y decía: «This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule».

Lo cuenta el repositorio público donde Microsoft escribe esa documentación: un commit la mete el día 3, y el siguiente que toca el fichero —titulado «Resolve syncing conflicts from repo_sync_working_branch to public»— la deja fuera. No sabemos si la quitaron a propósito o se perdió en una sincronización, y no vamos a fingir que lo sabemos. Lo que sí podemos comprobar es que los dos hechos que esa frase unía siguen hoy publicados, cada uno en un sitio distinto, y que juntarlos ahora te toca a ti.

Una aclaración de vocabulario antes de seguir, porque el producto se llama de una manera y todo el mundo lo llama de otra. La función se llama attack disruption (interrupción automática de ataques) y hace varias cosas distintas. Las dos que nos ocupan aquí son contener y aislar, que no son sinónimos y de cuya diferencia depende el resto del artículo.

Dónde vive la barrera cuando «contienes» un equipo

Aislar actúa sobre el equipo: le corta la red desde dentro, dejándole conectividad con los servicios de seguridad necesarios. Contener hace lo contrario de lo que su nombre sugiere. La documentación describe la acción para un equipo no gestionado que está o puede estar comprometido, y dice: «When you contain a device, all Defender for Endpoint onboarded devices block incoming and outgoing communication with that device». La política se aplica en las demás máquinas.

De ahí salen tres cosas prácticas, dos de ellas escritas y una nuestra. Las escritas: puede tardar hasta cinco minutos en que los detalles de un equipo recién contenido lleguen al resto del parque dado de alta, y Microsoft recomienda no pasar de cien equipos contenidos a la vez porque puede haber problemas de rendimiento en los que aplican el bloqueo. La nuestra, y la marcamos como deducción: si la barrera vive en las otras máquinas, lo que no esté dado de alta —el hipervisor, la cabina, el NAS, el switch, la impresora, el Linux que nadie recuerda— sigue hablando con el equipo contenido igual que ayer.

Esa deducción es la que convierte una decisión de seguridad en una tarea de inventario, y el inventario tiene una trampa que ya nos ha mordido: un agente puede figurar en verde en la consola llevando semanas sin enviar telemetría. Un equipo que consta como dado de alta y no lo está no bloquea nada, y encima cuenta en tu porcentaje de cobertura.

Lo que se aísla solo son puestos de usuario

La objeción que nos ponen en las reuniones suele ser «no quiero que una IA me desconecte el servidor de ficheros». Esa concretamente no ocurre. Lo dicen dos páginas distintas con la misma frase: «Automatic device isolation works only on end-user workstations that are onboarded and managed by Microsoft Defender for Endpoint». Puestos de usuario, dados de alta y gestionados. Y las dos páginas marcan además el aislamiento automático como vista previa, lo cual importa para planificar: nosotros una función en vista previa la pilotamos en un grupo pequeño y la documentamos como reversible.

A los servidores críticos les pasa la otra cosa. La sección de contención de activos críticos dice que «Device containment supports critical asset types like domain controllers, DNS servers, and DHCP servers» y que ahí la contención «blocks only specific ports and communication directions», con el objetivo declarado de que el activo siga funcionando. Al controlador de dominio no se le corta la red: se le corta una parte muy concreta de ella.

Los dos hechos que la frase borrada unía

El primero lleva tiempo publicado y sigue ahí hoy, en la lista de puntos a tener en cuenta del aislamiento. Lo citamos entero, porque la segunda mitad matiza a la primera y omitirla sería hacer trampa: «In environments that use web proxies (including Proxy Auto Configuration (PAC), WPAD, or static/direct proxy configurations), devices might not be able to recover from network isolation. Use selective isolation in such cases. When using selective isolation, exclusion settings aren't required to avoid this scenario».

Leído así, para el aislamiento manual el problema está resuelto: eliges tú el modo, eliges selectivo, y ni siquiera hacen falta reglas de exclusión. El segundo hecho está en otra sección, la del aislamiento automático, y es una nota: «When an isolation exclusion rule is defined, automatic attack disruption uses selective isolation by default and isolates the device according to the configured isolation exclusion rules».

Hay dos cosas más sobre esas reglas que conviene saber antes de tocar el interruptor. Una, que las reglas de exclusión de aislamiento se definen en Settings > Endpoints > Advanced features > Isolation Exclusion Rules, y que al habilitar la función las exclusiones incorporadas para Microsoft Teams, Outlook y Skype dejan de aplicarse y la lista arranca vacía en todas las plataformas (Skype, aclara la propia documentación, está en desuso y ya no entra en ninguna exclusión por defecto). Si quieres que Teams y Outlook sigan funcionando durante un aislamiento, los escribes tú.

Y dos, la limitación que decide el momento en que este trabajo sirve de algo: «Changes to exclusion rules only impact new isolation requests. Devices that were already isolated remain with the exclusions that were defined when they were applied». Con el equipo ya aislado, aplicar una regla nueva exige soltarlo y volverlo a aislar. Con el incidente en marcha, la palanca no se mueve.

Un límite honesto de todo lo anterior: la documentación dice que «Exclusions, such as e-mail, messaging application, and other applications for both macOS and Linux isolation aren't supported», y el aislamiento selectivo está disponible en Windows, Azure Stack HCI y macOS. O sea que «escribe la regla antes» resuelve la parte Windows del parque y deja fuera a Linux. Si tienes puestos Linux dados de alta, ese trozo del plan hay que resolverlo por otro lado.

El camino de vuelta, punto por punto

La acción de ida se dispara sola y en segundos. Lo de volver está repartido entre varias secciones de la documentación y, puesto en fila, se lee distinto:

• Soltar el equipo es manual, desde el portal, con Release from isolation. Para usar la función de aislamiento la documentación pide al menos el rol Active remediation actions y acceso al equipo según la configuración de grupos de dispositivos.
• Si nadie lo suelta, hay reloj, pero no el mismo en los dos casos. El aislamiento manual se levanta a los siete días. Para el disparado por attack disruption la documentación dice solo «after a defined time window», sin dar la cifra. La contención de un usuario por attack disruption sí la da: cinco días.
• Si el equipo deja de responder aislado, existe un script de liberación forzada con tres condiciones: se descarga desde la página de ese equipo, caduca a los tres días y solo funciona en Windows con versiones y KB concretos. Lo ejecutan administradores o quien tenga permisos de gestión de configuración de seguridad, que no son exactamente los mismos permisos que soltar desde el portal.
• En Linux el riesgo va en la dirección contraria: un equipo aislado sale del aislamiento en cuanto un administrador modifica o añade una regla de iptables. El comando con el que un compañero intenta ayudar tumba la contención sin que nadie lo decida.
• Un equipo aislado detrás de una VPN de túnel completo no alcanza el servicio en la nube de Defender. La recomendación escrita es túnel dividido para el tráfico de Defender for Endpoint y de la protección en la nube del antivirus.

Dos efectos colaterales que no salen en la demo

El primero es para quien virtualiza en Windows: «Isolating a server running on Microsoft Hyper-V blocks network traffic to all child virtual machines of the server». Aislar un anfitrión Hyper-V deja sin red a todas sus máquinas virtuales. Esto es aislamiento manual, y aun así describe con precisión el error que se comete a las tres de la mañana: un nombre en una lista no dice qué hay dentro. Está en la misma familia que la redundancia que no sobrevive al procedimiento.

El segundo es para quien vigila el directorio. Contener un usuario se aplica en el extremo y no deshabilita la cuenta en el proveedor de identidad: bloquea tráfico entrante en protocolos de ataque —inicios de sesión de red, RPC, SMB, RDP—, corta sesiones remotas en curso y cierra las conexiones RDP existentes. La nota marcada como importante viene después: «Once a Contain user action is enforced on a domain controller, it starts a GPO update on the Default Domain Controller policy», y ese cambio arranca una sincronización entre los controladores de dominio. Deshacer la acción revierte la GPO y arranca otra. Quien monitorice cambios de GPO va a recibir alertas de la respuesta automática en el mismo sistema con el que pensaba investigarla.

Tres palancas para excluir, y la que casi nadie toca

Aquí es donde más gente se equivoca de herramienta, nosotros incluidos la primera vez. La página de exclusiones ofrece exclusiones de cuentas de usuario, de rangos de IP y de grupos de dispositivos, y abre con un aviso de tipo CAUTION: «Excluding assets from automated responses isn't recommended». Pero el selector de grupos de dispositivos no tiene dos posiciones, tiene cinco: Full, tres variantes de Semi que siguen investigando automáticamente y solo piden aprobación para remediar, y No automated response. El aviso de que excluir un grupo «also impacts automated investigation and response actions» muerde de verdad en el último escalón.

Y hay una tercera palanca, en vista previa, que casi nadie toca porque vive en otra pestaña del portal: policy applications and exclusions. Creas una etiqueta de dispositivo —con reglas dinámicas por tipo de equipo, sistema operativo u otras propiedades—, creas una regla para esa etiqueta y desactivas solo los controles que quieras. La documentación tiene una sección dedicada a excluir únicamente la acción Isolate device para una etiqueta: el resto de attack disruption sigue funcionando, y cuando el sistema identifica como comprometido a un equipo excluido, la acción aparece con estado Skipped en el Action center. El objetivo declarado es «Keep most disruption controls active while selectively disabling specific protections».

Nuestra recomendación, que va como opinión y con la fuente en contra a la vista: Microsoft sugiere «using automatic attack disruption exclusions to reduce the likelihood of isolating devices that can't tolerate interruption», y al mismo tiempo desaconseja excluir en general. Las dos frases conviven porque hablan de granularidades distintas. Nosotros preferimos la etiqueta y la exclusión por acción antes que bajar el nivel de automatización de un grupo entero: el primer camino se paga una vez, al configurarlo, y el segundo se paga en visibilidad todos los días del año. Y apagarlo todo se pide por soporte: hay que abrir un caso en el portal de Defender con el asunto Attack disruption opt-out y explicar por qué.

Siete preguntas antes de encenderlo

Esto es lo que repasamos nosotros. Ordena lo que la documentación de Microsoft tiene repartido, para poder contestarlo en una reunión de media hora:

1. ¿Qué nivel de automatización tiene cada grupo de dispositivos, hoy, mirándolo? Está en Settings > Microsoft Defender XDR > Automated responses > Devices, pestaña de grupos. Nadie recuerda de memoria lo que dejó puesto hace dos años.
2. ¿El parque usa PAC, WPAD o proxy estático? Si es que sí, la regla de exclusión de aislamiento deja de ser opcional para los puestos Windows.
3. ¿Cuántos puestos Linux hay dados de alta? Para esos, las exclusiones de aislamiento no están soportadas y el plan tiene que ser otro.
4. ¿La VPN es de túnel completo? Entonces la decisión es anterior: túnel dividido para el tráfico de Defender, o asumir que el equipo aislado no habla con la nube.
5. Si activamos las exclusiones de aislamiento, ¿quién reescribe las reglas de Teams y Outlook, y cuándo? La lista arranca vacía.
6. ¿Qué porcentaje del parque está realmente dado de alta, y qué hay en la lista de lo que no? Ahí es donde la contención tiene agujeros, y esa lista casi nunca está escrita.
7. ¿Quién puede soltar un equipo fuera de horario, y sabe monitorización que una contención de usuario en un controlador de dominio genera un cambio de GPO y su sincronización?

Las siete son preguntas de operación, y por eso se caen entre las sillas: quien compra la licencia no las conoce y quien responde de madrugada no estaba en la reunión de compra. Es la misma grieta que describimos hablando del plan de continuidad que nadie ha ensayado: el documento existe, la cadena de decisiones no.

Lo que sí dice el 99%

Microsoft publica una cifra sobre attack disruption y la publica clara: «For containment actions, Defender maintains a confidence level of 99% or higher based on real production data». Es precisión del detector, medida como relación señal-ruido, y viene con el detalle de que los detectores se validan primero en modo auditoría y se despliegan de forma gradual. Nos parece un número honesto y no tenemos motivo para discutirlo.

Lo que ese 99% no dice es cuántas veces al año se va a disparar en tu parque. Esa tasa no la publica nadie, y tampoco se deduce de la precisión del detector: son dos cosas que se miden distinto. Así que la discusión sobre si te fías del modelo, tenga la respuesta que tenga, deja intacta la pregunta que de verdad cuesta dinero el día del incidente: cómo vuelve la máquina, quién la devuelve y con qué regla escrita.

Nos gusta attack disruption y no vamos a fingir lo contrario para tener un artículo más picante. En un ransomware, los minutos que tarda una persona en enterarse, entender y actuar son los mismos minutos que separan un equipo comprometido de una carpeta cifrada. La función hace bien su trabajo. El campo de quién tiene el rol un sábado a las tres lo rellenas tú.

Si prefieres empezar por lo básico, la puerta de entrada es la de siempre: saber qué hay en tu red y qué está realmente protegido. De eso va nuestra práctica de ciberseguridad, y ninguna respuesta automática compensa no tenerlo.

Nota de fuentes

Hay que separar dos grupos de citas. Primero, la frase del titular, que hoy NO está publicada: el texto «This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule» se añadió al fichero defender-endpoint/respond-machine-alerts.md del repositorio público MicrosoftDocs/defender-docs en el commit f2685dde («Update respond-machine-alerts.md», 3 de septiembre de 2026, 20:19 UTC) y no aparece en el commit siguiente que toca ese fichero, 2f51dff1 («Resolve syncing conflicts from repo_sync_working_branch to public», 4 de septiembre de 2026, 19:06 UTC); tampoco está en la versión publicada hoy, que hemos descargado y comprobado. Si el motivo fue un descuido de sincronización o una decisión, no lo sabemos, y lo decimos así. Segundo, todo lo demás, que sí está publicado hoy y lo hemos consultado el 15 de septiembre de 2026 en ese mismo repositorio: el 99% y el modo auditoría, el aviso CAUTION sobre excluir activos, los cinco niveles de automatización, la advertencia sobre la investigación automatizada, las policy applications and exclusions en vista previa y el procedimiento de baja con el asunto Attack disruption opt-out están en Automatic attack disruption in Microsoft Defender y en Exclude assets from automated response in attack disruption; la nota de los puestos de usuario, la contención de activos críticos, el comportamiento de Contain device, los cinco minutos, los cien equipos, los siete días del aislamiento manual, los cinco días de contención de usuario, el script de tres días, el comportamiento de iptables en Linux, la VPN de túnel completo, el efecto sobre las máquinas virtuales de un anfitrión Hyper-V, la nota de la GPO, la no compatibilidad de exclusiones en macOS y Linux, la nota del aislamiento selectivo por defecto y la exclusión de la acción Isolate device por etiqueta están en Take response actions on a device in Microsoft Defender for Endpoint; los dos modos de aislamiento, la ruta de las reglas, el vaciado de las exclusiones de Teams, Outlook y Skype y la limitación de que los cambios solo afectan a nuevas peticiones están en Network isolation exclusions in Microsoft Defender for Endpoint; y la marca de vista previa del aislamiento automático aparece tanto en Take response actions on a device in Microsoft Defender for Endpoint como en Configure automatic attack disruption in Microsoft Defender XDR. Lo que en este artículo es deducción nuestra va marcado como tal: que lo no dado de alta sigue hablando con un equipo contenido, y la preferencia por la exclusión por etiqueta frente a bajar el nivel de un grupo. No hemos encontrado ninguna cifra publicada sobre con qué frecuencia se dispara attack disruption en un parque, y por eso no damos ninguna.