El minero se apaga cuando abres el Administrador de tareas

El 8 de octubre Huntress publicó el detalle de una intrusión y dentro había una pieza pequeña que no se parece a las demás: un script de PowerShell que vigila si abres el Administrador de tareas. Cuando lo abres, para el servicio que ejecuta el minero. Cuando lo cierras, lo vuelve a arrancar. Y a las seis de la tarde, hora local de la máquina, cierra el Administrador de tareas él solo. La máquina comprometida era una consola de copias de seguridad. Lo que el atacante modeló no fue el antivirus: fue el horario de la persona que mira.

Qué pasó y en qué fechas

El 4 de octubre de 2026 el NVD publicó dos vulnerabilidades de AhsayCBS, la consola con la que se gestionan políticas de copia, almacenamiento y usuarios en el producto de copias de Ahsay. Es software de proveedor: quien lo tiene montado suele ser un prestador de servicios gestionados o un integrador, y detrás de esa consola están las copias de todos sus clientes. La primera, CVE-2026-105133, está en la función checkSysPwd de com/ahsay/obs/api/ApiStructsAction.java y es un fallo de autenticación. La segunda, CVE-2026-105134, está en el componente /rps/api/json/UpdateReceivers.do y permite inyectar comandos del sistema operativo.

La segunda está en el componente Replication Receiver, y el ataque la usa configurando un receptor malicioso. La ficha puntúa esa inyección de comandos en 10,0 sobre 10 en CVSS 3.1 y la de autenticación en 7,3; en CVSS 4.0 bajan a 9,3 y 5,5, que es la razón de que veas la segunda etiquetada como media en unos sitios y como alta en otros. Es la misma ficha leída con dos versiones de la métrica, no dos opiniones. BleepingComputer añade el dato que de verdad cambia la urgencia: la de autenticación tiene exploit público. Y lo que no discute nadie es el encadenado: primero se salta la autenticación y después se ejecuta código como NT AUTHORITY\SYSTEM.

La primera explotación la vio Huntress el 7 de octubre a las 23:20:15 UTC, tres días después de la publicación en el NVD. El 8 de octubre contaba cinco organizaciones afectadas. La señal de entrada era un proceso de la propia aplicación, cbssvcX64.exe, pariendo procesos hijo que no le tocaba parir. Y hay un detalle de versiones que merece una línea aparte, porque es el más incómodo de todo el caso: la ficha del NVD lista como afectadas las versiones 10.3.0 a 10.3.2, marca la 10.3.4 como no afectada y enlaza las notas de esa versión como la corrección. Huntress dice que la 10.3.4, que es la última y es de agosto, es la que están explotando. La versión que el registro señala como el parche es por la que están entrando. Si tu inventario dice «actualizado», no está contestando a la pregunta.

El script conoce tu horario

El fichero se llama Taskgmr.ps1. Repasa las letras: es taskmgr con dos cambiadas de sitio, el nombre del Administrador de tareas de Windows. Ya ahí hay una decisión de diseño. Hace tres cosas, y el informe de Huntress las describe sin ambigüedad: para el servicio del minero cuando el Administrador de tareas se abre, lo vuelve a arrancar cuando se cierra, y mata el Administrador de tareas a las seis de la tarde o si lleva más de una hora abierto de noche. La hora la toma del reloj local de la máquina, no de UTC.

Los dos primeros comportamientos son ocultación y no sorprenden a nadie. El tercero es el que hace que merezca la pena escribir sobre esto. Apagar el Administrador de tareas a las seis de la tarde es una apuesta sobre nosotros: a esa hora ya no hay nadie delante de la pantalla, y una ventana que lleva una hora abierta a las tres de la madrugada está abierta porque alguien se la dejó, no porque alguien la esté mirando. Es una hipótesis sobre el comportamiento del administrador, está escrita en código, y es acertada. Huntress añade su valoración de que el script parece asistido por IA; eso no se puede verificar desde fuera y tampoco es lo importante. Lo importante es que esta pieza ya no cuesta esfuerzo escribirla.

De ahí sale la tesis, y es incómoda porque describe el procedimiento de casi todo el mundo: entrar a la máquina, abrir el visor de procesos, ver la CPU, decir «esto está bien». Abrir el visor de procesos es una consulta a un canal que el atacante puede cerrar, y en este caso cierra. En un servidor de copias es todavía peor, porque el consumo alto de madrugada es exactamente lo que se espera de él: la ventana nocturna justifica cualquier cifra, y la única manera de distinguir una copia de un minero es saber a qué hora acabó la copia.

Los disfraces están pensados para un lector humano

Mira el resto del kit con esa idea en la cabeza. El minero de Monero, XMRig, se llama edge.exe. El gestor que lo mantiene vivo se llama msedge.exe y es una copia modificada de NSSM, una utilidad legítima que convierte cualquier ejecutable en servicio de Windows. El servicio se llama MicrosoftEdgeUpdateSvc, se ejecuta desde la carpeta Temp con privilegios SYSTEM y rearranca el minero si se cae. Y en el directorio de la aplicación de copias quedó un webshell en JSP. Todo ese trabajo de nomenclatura está hecho para que, leído en una lista de procesos por una persona con prisa, cuadre. Un servicio de actualización de Edge ejecutándose como SYSTEM es lo más normal del mundo.

Lo que no cuadra no se ve a ojo, se ve en el registro. La ruta desde la que se ejecuta un binario que dice llamarse como un navegador. Quién creó ese servicio, a qué hora y con qué cuenta. Quién es el padre del proceso, porque un servicio de Microsoft no nace de la aplicación de copias. Y, sobre todo, el tráfico. Son dos indicadores distintos y conviene no mezclarlos: el minero hablaba con un pool de Monero, xmr.kryptex[.]network en el puerto 8029, mientras que las herramientas se habían descargado antes de un contenedor de almacenamiento de objetos en Alibaba Cloud. Un servidor de copias conversando con un pool de minería en un puerto no estándar es, de toda la lista, lo más difícil de confundir con trabajo legítimo.

Los indicadores publicados son cuatro líneas y se buscan hoy mismo, así que los dejamos aquí en lugar de describirlos:

• xmr.kryptex[.]network:8029 y 51.195.127[.]124:8029 — el pool de minería, con el usuario krxYMRN97D/creativejs.
• imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com — el contenedor de descarga, con los ficheros bajo /javas/Office/win/.
• SHA256 de edge.exe: 4dcb0202fe8b2d4d7b183764e38184cd6ed50132786cc7e7d1f7f4bce1dd6f3d.
• SHA256 de msedge.exe: 05f69ae6b2b89c1c4dcf836bff032232f11bf0109f2b498e2345045d06139034, y de Taskgmr.ps1: 481728a7c9c4c02be07051d9c1958d902ea6397ebb8952ab83944818e3d25d21.

Una lectura nuestra sobre esa segunda línea, y la marcamos como nuestra porque no está en el informe: el depósito desde el que se descargaron las herramientas lleva la palabra «backup» en el nombre. En el registro del proxy de un servidor de copias, un destino con esa palabra dentro no le llama la atención a nadie.

El driver, otra vez, pero por otro motivo

En uno de los equipos el atacante dejó caer WinRing0x64.sys, un controlador de kernel legítimo y firmado que da acceso de bajo nivel al hardware y que arrastra una vulnerabilidad conocida desde 2020. Hace cuatro días desmenuzamos la mecánica de la lista de controladores bloqueados de Windows y no la vamos a repetir aquí: está entera en ese post, incluida la letra pequeña de que aplicar la política no expulsa de memoria lo que ya está cargado y de que la regla de reducción de superficie de ataque impide escribir el controlador, no cargarlo si ya está.

Lo que añade este caso es el motivo. Cargar un controlador vulnerable suele servir para cegar al EDR, y por eso un evento de carga de controlador se interpreta casi siempre como el preludio de que algo se va a quedar ciego. Aquí Huntress lo dice sin rodeos: el controlador le daba al minero acceso de nivel kernel al hardware, con el mayor control y rendimiento posibles. El mismo evento, otra intención y ninguna de las señales que lo acompañan habitualmente. Si tu procedimiento solo mira la carga de controladores cuando el EDR se queja, este no lo habrías visto.

Un minero es la versión amable

Hay que decirlo con esa crudeza. En la lista de cosas que le pueden pasar a la máquina que gestiona las políticas de copia, el almacenamiento y los usuarios de una cartera entera de clientes, que te roben electricidad para minar Monero es el mejor resultado posible. Lo que entró fue ejecución de código como SYSTEM; el minero es solo lo que el atacante decidió hacer con eso, y esa decisión se cambia mañana sin tocar la cadena. Este argumento ya lo defendimos en agosto con otro producto y otro mecanismo —entraron por el puerto 5900 y salieron con root, y el minero era igual de secundario—, así que aquí lo damos por hecho y vamos a la consecuencia concreta.

Es el mismo asunto que tratamos el 7 de octubre a propósito de otro producto: la consola de copias es infraestructura privilegiada, y el modelo de permisos que tiene dentro vale lo que valga la puerta por la que se llega a ella. Si alguien ejecuta como SYSTEM en ese servidor, la pregunta siguiente es si tus copias se pueden borrar desde ahí. La respuesta debería ser que no, y si es que sí, la inmutabilidad y la separación de credenciales dejan de ser un apartado del presupuesto y pasan a ser lo único que te queda.

Y la honestidad en la otra dirección: cinco organizaciones el 8 de octubre no es una epidemia. No hemos encontrado una cifra pública fiable de cuántas instancias de esta consola están publicadas en internet, así que no la ponemos. Lo único que se puede afirmar sobre la exposición es lo obvio: para que esto pase, la interfaz de gestión tiene que ser accesible desde donde está el atacante.

La prueba del observador

Esto no se compra. Es una pregunta sobre el pasado, y se contesta hoy en diez minutos. Elige un servidor que te importe y una hora concreta de la semana pasada: un martes a las nueve de la noche, por ejemplo. Y ahora responde a estas cuatro cosas sin conectarte a esa máquina, solo con lo que ya está guardado en otro sitio:

• ¿Se creó algún servicio nuevo en ese equipo durante esa semana? Cuál, a qué hora exacta y con qué cuenta.
• ¿Se cargó algún controlador de kernel que no estuviera cargándose el mes anterior?
• ¿Qué procesos abrieron conexiones hacia internet esa noche, y hacia qué destinos?
• ¿Quién inició sesión, desde qué dirección y a qué hora terminó la ventana de copias?

Si para contestar tienes que conectarte ahora y mirar, tu detección es interactiva. Tiene exactamente el punto ciego del Administrador de tareas —existe mientras tú estás delante— y encima tiene horario de oficina. Si las cuatro se contestan desde el registro, sin tocar la máquina, el truco de las seis de la tarde no te afecta: tu canal no se cierra porque no haya nadie despierto.

Queda la segunda mitad del ejercicio, que ya defendimos hace once días y no vamos a reconstruir aquí: guardar el dato no sirve si nadie lo consulta nunca.

Lo que hacemos nosotros, sin humo

Nuestro EDR/MDR gestionado existe por esto: creación de un servicio, carga de un controlador, un binario con nombre de programa conocido ejecutándose desde una ruta que no es la suya, una conexión de salida que no pega con el papel de esa máquina. Son eventos que se registran y que alguien mira en turno, no cosas que se descubren abriendo una ventana. Encima ponemos Zabbix para los síntomas, y el que vale aquí es sencillo de describir: el consumo que no vuelve a bajar cuando la ventana de copias ya ha terminado. Zabbix no nos dice «tienes un minero». Nos dice «esto no es el patrón de siempre», y con eso basta para ir a comprobarlo.

Ahora la parte que no queda bien en un folleto: un EDR no es un oráculo. Hace once días escribimos sobre una técnica de inyección publicada que cuatro EDR no veían, y lo que dijimos entonces vale igual hoy: la defensa consiste en tener más de un canal y en que ninguno dependa de que haya alguien mirando. Por eso el turno de 24x7 pesa aquí: el canal no se apaga a las seis.

Y la medida más eficaz de todo este caso no se compra: que la consola de copias no esté publicada en internet. Es exactamente lo que recomienda Huntress mientras no haya versión corregida —restringir el acceso a la interfaz de gestión a direcciones de confianza o a través de VPN—, y no requiere presupuesto, solo decidir que el plano de gestión de un sistema no es una página web.

No hay parche, y eso no cierra la conversación

La frase de Huntress es literal: hasta que haya un parche disponible, restringir el acceso y buscar indicios de compromiso. Una política de parcheo que solo sabe conjugar el verbo «parchear» no tiene nada que decir en una semana como esta; lo escribimos hace ocho días y este caso es el ejemplo de manual. Mientras no haya versión, lo que hay es esto: la interfaz solo accesible desde donde tenga que serlo, una búsqueda activa de los indicadores conocidos —el servicio con nombre de actualizador de Edge, binarios de navegador fuera de la ruta del navegador, el script con nombre casi igual al del Administrador de tareas, el controlador de hardware— y, si aparece algo, reinstalar el servidor desde cero a partir de una copia de confianza. Esa es la recomendación literal de Huntress, y tiene doble filo en este contexto: la copia de confianza la guarda la máquina comprometida. En un servidor en el que ha corrido código como SYSTEM, limpiar lo que has encontrado solo demuestra que has encontrado algo; ellos lo justifican diciendo que los atacantes han sido capaces de esconder puertas traseras secundarias.

Lo de siempre: el fallo es inevitable, la avería es una decisión de diseño. Este caso añade una variante que no habíamos escrito aún, y es la que nos llevamos. La ceguera también es una decisión de diseño. El minero no se escondía de tu antivirus: se escondía de ti. Y si la única forma que tienes de saber qué pasa en una máquina es entrar a mirarla, ya sabes a qué hora deja de funcionar tu seguridad.

Fuentes: entrada del blog de Huntress «Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer», consultada el 10 de octubre de 2026. De ahí salen las dos referencias de código (la función checkSysPwd en com/ahsay/obs/api/ApiStructsAction.java y el componente Replication Receiver en /rps/api/json/UpdateReceivers.do), la primera explotación observada el 7 de octubre a las 23:20:15 UTC, las cinco organizaciones afectadas a 8 de octubre, los procesos hijo de cbssvcX64.exe, los tres comportamientos de Taskgmr.ps1 —parar MicrosoftEdgeUpdateSvc al abrirse el Administrador de tareas, rearrancarlo al cerrarse, y matar el Administrador de tareas a las 18:00 o si lleva más de una hora abierto de madrugada, con la hora tomada del reloj local—, la valoración de que el script parece asistido por IA, los nombres y hashes de los ficheros, el servicio MicrosoftEdgeUpdateSvc ejecutándose desde Temp con privilegios SYSTEM, el webshell JSP, el pool de minería y el contenedor de descarga de la lista de indicadores, la afirmación sobre el acceso de nivel kernel que el controlador daba al minero, y las dos recomendaciones literales: restringir el acceso a la interfaz de gestión hasta que haya parche, y «a full host re-image from a trusted backup» si aparece algún indicador. Las puntuaciones CVSS (10,0 y 7,3 en 3.1; 9,3 y 5,5 en 4.0), las versiones afectadas 10.3.0 a 10.3.2 y el hecho de que la ficha marque la 10.3.4 como no afectada y enlace sus notas de versión como corrección son del registro del NVD, consultado el 10 de octubre de 2026. De BleepingComputer, «Unpatched AhsayCBS flaws exploited to deploy webshells, mine crypto», tomamos un único dato: que CVE-2026-105133 tiene exploit público. SecurityWeek, «Unpatched AhsayCBS Vulnerabilities Exploited in the Wild», para la descripción del producto y su uso habitual en proveedores de servicios gestionados e integradores. La referencia a CVE-2020-14979 (CVSS 7,8) es aportación nuestra y no de la cobertura del caso: se emitió en 2020 contra WinRing0.sys/WinRing0x64.sys 1.2.0 tal como se distribuía con EVGA Precision X1, no contra «WinRing0» en abstracto. La mecánica de la lista de bloqueo de controladores de Windows está citada en detalle en nuestro post del 6 de octubre a partir de la documentación de Microsoft. Nada de lo que decimos de nuestra operación —EDR/MDR gestionado, turno 24x7, Zabbix para monitorización, copias con Proxmox Backup Server y Veeam— incluye datos de clientes, y no hemos puesto cifras de incidentes propios porque no son públicas. La lectura sobre el nombre del depósito de descarga y la del horario del script son nuestras, y están marcadas como tales en el texto. Fotografía de portada: «A view of the server room at The National Archives», The National Archives (UK), CC BY 3.0.