El aviso llegó 47 días tarde y tus registros duran 30

Hoy vence el plazo que CISA dio a las agencias federales para tapar el fallo de BeyondTrust Remote Support. Si tienes ese producto, ya sabrás que hay que parchear. Lo que casi nadie está mirando es la otra fecha del caso: el primer uso conocido del fallo fue el 29 de agosto, y el aviso salió el 15 de octubre. Cuarenta y siete días. La pregunta que viene después del parche es si tú puedes mirar tan atrás.

Lo que pasó, con las fechas puestas

CVE-2026-102764 es un fallo de validación de origen en un componente interno de mensajería de BeyondTrust Remote Support (el producto que antes se llamaba Bomgar): ese componente no comprobaba bien de dónde venía un mensaje, y eso permite a un atacante sin autenticar hacer operaciones de fichero en el aparato. Puntuación 9,3 sobre 10 en CVSS 4.0, y afecta a la versión 26.2.3 y todas las anteriores; el parche, BT26-05-RS, se instala sobre las ramas 24.3.1 a 26.2.3, así que quien esté por debajo tiene que actualizar antes de poder parchear.

La cronología pública, en orden: el 29 de agosto de 2026 se observa la primera explotación —una instancia alojada por el propio fabricante y un aparato autoalojado de un cliente—; BeyondTrust detecta el incidente de su instancia alojada el 28 de septiembre, en una búsqueda proactiva, y reproduce la vía de entrada ese mismo día; tiene un parche hecho el 30 de septiembre, lo prueba y cierra otras vías antes de publicar BT26-05-RS el 8 de octubre, y el 9 ya lo ha aplicado a todas sus instancias en la nube; el 15 de octubre publica el aviso y el CVE; el 16 CISA lo añade al catálogo de vulnerabilidades explotadas conocidas con fecha límite hoy, 19 de octubre, para las agencias federales estadounidenses. Google Threat Intelligence y Mandiant atribuyen la explotación a un grupo de espionaje al que llaman ARMORY CASTLE (antes UNC5221), y describen lo que vino después de entrar: escalada a root, un web shell para mantenerse dentro, recolección de credenciales, cambios en los controles de acceso y salto a otros sistemas. Merece la pena leer bien ese reparto antes de usarlo en una reunión: de los 47 días que van de la primera explotación al aviso, durante treinta el fabricante no sabía que el fallo existía. El retraso no estaba guardado en un cajón; sencillamente nadie lo había visto.

Nada de eso es insólito. Un producto de soporte remoto es, por diseño, una pieza con privilegios sobre los equipos de medio mundo —ya escribimos sobre esa superficie concreta en la herramienta de soporte remoto es una puerta con privilegios—, y que el catálogo de CISA llegue después de semanas de uso real tampoco es nuevo: el catálogo es un acuse de recibo, no una alarma, y lo argumentamos entero en el catálogo KEV es un acuse de recibo, no una alarma. Lo interesante aquí es otra cosa.

La pregunta del día 48

El día que sale un aviso así, el trabajo se parte en dos. La primera mitad es conocida y acotada: inventariar, parchear, rotar credenciales, revisar accesos. Es la mitad que todo el mundo sabe hacer y la que aparece en los titulares. La segunda mitad es una sola frase, y llega siempre desde dirección o desde un cliente: «¿y nosotros, estuvimos dentro?».

Esa pregunta no la contesta el parche. La contesta el registro, y el registro tiene fecha de caducidad decidida hace meses, normalmente por defecto y casi nunca por alguien. Si la ventana que puedes consultar empieza el 19 de septiembre, el 29 de agosto no existe: no es que no veas nada sospechoso, es que no ves nada en absoluto. Y responder «no consta actividad» cuando lo que pasa es «no tengo datos de esas fechas» es, con perdón, mentir en un informe.

Hasta cuándo puedes mirar, de fábrica

Estos son los valores por defecto de las plataformas que más usan nuestros clientes, tal como los publica Microsoft. No son opiniones ni estimaciones: están en su documentación.

Fíjate en el reparto: lo que más gente consulta cuando hay un susto —quién entró, desde dónde, con qué aplicación— es justo lo que menos dura. Treinta días cubren el mes anterior y nada más. En este caso concreto, el primer uso conocido del fallo quedó a diecisiete días por fuera de esa ventana el día en que se publicó el aviso: contada hacia atrás desde el 15 de octubre, la ventana empezaba el 15 de septiembre.

La frase que lo cierra: la retención no es retroactiva

Aquí está la parte que de verdad duele, y la dice la documentación de Microsoft sin rodeos: los cambios de retención no son retroactivos. Si hoy subes de Free a P1, solo recuperas lo que todavía esté dentro de los siete días; lo que ya expiró no se puede recuperar salvo que se hubiera archivado antes. Con las políticas largas de Purview, Microsoft lo dice explícitamente de la de diez años —no retiene nada generado antes de crearla— y en general avisa de que un cambio de política no afecta a lo ya registrado. Y en la API de streaming de Defender la nota es igual de clara: la retención empieza el primer día que la activas.

Es decir: la capacidad de investigar un incidente que todavía no conoces se compra antes de conocerlo. Es el mismo tipo de decisión que una copia de seguridad, y tiene la misma propiedad desagradable: el día que la necesitas ya no puedes tomarla.

Y el registro del propio aparato es el que menos vale

Queda un detalle incómodo. En este caso el atacante llegó a root en el aparato y tocó los controles de acceso. Los registros que viven dentro de esa misma máquina —y en un appliance suelen vivir ahí, rotando cada pocos días por falta de disco— son, a partir de ese momento, la evidencia menos fiable que tienes: quien manda en la máquina manda en lo que la máquina escribe. Por eso el consejo aburrido de siempre: los registros de un equipo expuesto salen de la caja, hacia un sitio con otras credenciales y otro dueño. Un syslog remoto, un recolector en tu red, el SIEM que ya tengas. Cuesta una tarde y no cambia nada en el día a día, hasta la mañana en que toca mirar atrás.

Las cinco comprobaciones del día 48

Esto es lo que hacemos nosotros cuando entra un aviso de este tipo, y se puede hacer hoy sin comprar nada:

Cuándo NO comprar más retención

Conflicto de interés por delante: vendemos EDR/MDR gestionado y servicios de cumplimiento y continuidad, así que cuando decimos «guarda más registros» estamos hablando de algo que facturamos. Precisamente por eso conviene decir dónde paramos.

Diez años de registros que nadie consulta no son seguridad, son un almacén con factura mensual. Si hay que elegir —y en una pyme casi siempre hay que elegir—, el orden que defendemos es: primero que los registros salgan de la máquina que los genera; después que alguien los mire con criterio y sepa qué es raro en tu casa; y solo entonces, alargar la ventana. Treinta días bien enviados fuera y vigilados valen más que un año guardado en un sitio del que nadie recuerda la contraseña. Nuestra regla interna con la monitorización es esa: una alerta que no obliga a hacer nada se borra, porque la fatiga de alertas es la forma más eficaz que conocemos de no ver lo que importa.

El eje de siempre, aplicado aquí: el fallo es inevitable, la avería es una decisión de diseño. Que un fabricante tenga un día malo y que un grupo con recursos lo aproveche durante cuarenta y siete días antes de que el fabricante lo publicara no está en tu mano. Lo que sí está en tu mano es si, el día que te enteras, puedes contestar con datos o solo con un encogimiento de hombros. Esa diferencia se compra meses antes, o no se compra.

Fuentes y método: los datos del fallo (CVE-2026-102764, CVSS 4.0 de 9,3, validación de origen indebida, versiones 26.2.3 y anteriores, parche BT26-05-RS) y la cronología de explotación desde el 29 de agosto de 2026 salen del aviso BT26-05 de BeyondTrust y del análisis de Google Threat Intelligence Group y Mandiant, recogidos por la prensa especializada — beyondtrust.com y thehackernews.com. La inclusión en el catálogo KEV el 16 de octubre y la fecha límite del 19 para agencias federales, de CISA — cisa.gov. La atribución a ARMORY CASTLE es de Google/Mandiant, no nuestra, y la recogemos como lo que es: la lectura de quien investigó el caso. Los plazos de retención son de la documentación de Microsoft: Entra ID (7 días en Free, 30 en P1 y P2; riesgos 7/30/90) y la advertencia de que la retención no es retroactiva — learn.microsoft.com; Purview Audit (180 días en Standard, un año en Premium para Entra, Exchange, OneDrive y SharePoint) — learn.microsoft.com; y los 30 días de datos crudos de la búsqueda avanzada de Defender XDR, ampliables con Sentinel o con la API de streaming de datos crudos — learn.microsoft.com. Esos valores son los de la fecha de publicación de este post y cambian con el tiempo y con la licencia: compruébalos en tu tenant antes de usarlos en una reunión. No hemos analizado ningún aparato afectado ni tenemos telemetría propia de esta campaña; todo lo que contamos del incidente es de fuentes públicas. Lo que decimos de nuestra forma de trabajar —NetBox como fuente de verdad del inventario, la regla de borrar alertas que no obligan a nada— es nuestro y no lleva número: no publicamos métricas internas que nadie pueda comprobar.