- CPUID sufrió un ataque a su cadena de suministro al comprometerse una API de descargas, redirigiendo durante horas a instaladores troyanizados de CPU-Z y HWMonitor.
- Los atacantes usaron una DLL maliciosa y técnicas de inyección en memoria para desplegar STX RAT, especializado en robo de credenciales y control remoto sigiloso.
- El perfil de víctimas incluye sobre todo profesionales de IT y administradores, multiplicando el impacto potencial en redes corporativas y sistemas críticos.
- El incidente refuerza la necesidad de fortalecer la seguridad de la distribución de software y de que usuarios y empresas adopten medidas de verificación y monitorización avanzadas.
Durante años, muchos usuarios han considerado que descargar herramientas como CPU-Z o HWMonitor desde la web oficial de CPUID era sinónimo de seguridad absoluta. El reciente ataque a la cadena de suministro en CPUID ha demostrado lo contrario: incluso un sitio plenamente legítimo puede convertirse, durante unas pocas horas, en un punto de distribución de malware de alto nivel orientado a profesionales de TI, administradores de sistemas y entusiastas del hardware.
En este contexto, no hablamos de un virus cutre que salta a la vista, sino de una operación muy bien pensada que abusó de la confianza en la marca y en su infraestructura. Los atacantes no tocaron el código fuente de las herramientas ni sus ejecutables firmados en origen, sino que fueron directamente a la infraestructura de entrega, a una API secundaria y a los mecanismos de distribución y carga dinámica de bibliotecas, aprovechando la propia lógica de Windows y los flujos de descarga del sitio para colar troyanos avanzados como STX RAT sin levantar demasiadas sospechas al principio.
Qué es CPUID y por qué es un objetivo tan jugoso
CPUID es una compañía veterana, fundada a finales de los noventa, que se ha ganado un hueco de referencia en el ecosistema Windows gracias a utilidades como CPU-Z y HWMonitor. CPU-Z recopila datos detallados de procesador, memoria y placa base, mientras que HWMonitor se centra en el control de temperaturas, voltajes y ventiladores, algo casi obligatorio para overclockers, técnicos de campo o administradores que quieren vigilar la salud de servidores y estaciones de trabajo.
Estas herramientas tienen decenas de millones de descargas acumuladas a nivel mundial, y son, en la práctica, estándar de facto en muchos departamentos de IT y en el mundillo del hardware entusiasta. Precisamente ese alcance masivo, combinado con el hecho de que a menudo se ejecutan con privilegios elevados, convierte a CPUID en un objetivo ideal para campañas de compromiso de cadena de suministro: si logras colar un binario infectado en su canal oficial, el radio de impacto se dispara.
Los ataques observados en los últimos incidentes reflejan justo ese enfoque. Los actores maliciosos sabían que los usuarios iban a confiar ciegamente en la web oficial, que muchos administradores descargarían y ejecutarían el software en máquinas críticas, y que un solo técnico infectado puede contaminar dominios enteros, infraestructura corporativa y datos sensibles de miles de usuarios finales.
Más allá de los entornos profesionales, tampoco hay que olvidar a los usuarios domésticos avanzados. Gamers, overclockers, y aficionados que montan PCs recurren constantemente a CPU-Z y HWMonitor para afinar sus configuraciones, ajustar voltajes o comprobar estabilidad térmica. Ese perfil de usuario suele tener también cuentas de juego, carteras online y servicios vinculados al navegador, lo que convierte a un infostealer discreto en una mina de oro para los atacantes.
La ventana de ataque: redirecciones maliciosas y API comprometida
El incidente más relevante se produjo entre el 9 y 10 de abril de 2026, en una ventana de tiempo relativamente corta —en torno a seis horas, ampliada en algunos análisis hasta unas 19 horas de exposición según distintas fuentes—. Durante ese intervalo, el dominio oficial de CPUID empezó a servir enlaces de descarga manipulados que, en lugar de apuntar a los binarios legítimos de CPU-Z o HWMonitor, redirigían de forma silenciosa hacia instaladores controlados por los atacantes.
La clave no estuvo en el repositorio ni en los ejecutables originales firmados, que se mantuvieron intactos. El punto débil fue una funcionalidad secundaria, básicamente una API lateral responsable de gestionar parte de los enlaces de descarga. Al comprometer esa API, los atacantes pudieron inyectar enlaces maliciosos en la página principal de descargas sin necesidad de modificar el código fuente de las herramientas, ni romper la firma digital de los binarios oficiales.
Para el usuario, la secuencia era engañosamente normal: entraba en cpuid.com, hacía clic en la descarga de la versión vigente (por ejemplo, HWMonitor 1.63) y esperaba recibir un ejecutable firmado y legítimo. En su lugar, en esa ventana de ataque, algunos usuarios obtenían ficheros con nombres sospechosos como “HWiNFO_Monitor_Setup.exe” que, además de no corresponderse con el nombre habitual de HWMonitor, contenían el malware.
Mientras tanto, muchos antivirus lanzaron alertas durante la descarga o la instalación, pero una parte de los usuarios decidió ignorarlas asumiendo que eran falsos positivos por tratarse del sitio oficial. Los reportes en foros como Reddit empezaron a aparecer cuando varios usuarios coincidieron en que algo raro estaba pasando con cpuid.com, pero para entonces la campaña ya había tenido tiempo de sembrar un buen conjunto de infecciones.
Disección del ataque: de la DLL maliciosa a la cadena de ejecución
El detalle técnico del ataque muestra un enfoque de cadena de suministro bien estudiado. En uno de los escenarios analizados, el binario de CPU-Z descargado desde el sitio oficial llegaba junto a una DLL maliciosa denominada CRYPTBASE.dll, compilada incluso en un lenguaje moderno como Zig para dificultar su análisis. Esta DLL se alojaba en el mismo directorio que el ejecutable legítimo.
Cuando el usuario ejecutaba CPU-Z, Windows aplicaba su habitual orden de búsqueda de DLLs. El sistema cargaba primero la CRYPTBASE.dll falsa residente en el directorio de la aplicación, antes de llegar a la librería legítima en System32, lo que permitía a los atacantes inyectar su código sin tocar directamente el binario firmado. Este secuestro del orden de carga (DLL search order hijacking) es clásico, pero muy eficaz cuando se combina con un ejecutable de confianza.
Desde esa DLL maliciosa se iniciaba la siguiente fase: una inyección reflectiva de una segunda DLL cifrada directamente en memoria, sin necesidad de escribir nuevos archivos en disco. Esto refuerza la evasión de detecciones basadas en firmas estáticas, ya que muchos antivirus tradicionales dependen del análisis de los binarios almacenados en el sistema de archivos.
La comunicación con la infraestructura de mando y control también estaba cuidadosamente diseñada. El malware utilizaba un protocolo cifrado personalizado sobre DNS-over-HTTPS apuntando, por ejemplo, a 1.1.1.1. Al encapsular el tráfico de C2 dentro de consultas DNS cifradas, la telemetría de muchas redes veía simplemente “tráfico DNS legítimo”, sin advertir que se trataba de un canal encubierto de comando y exfiltración.
En cuanto a la cadena de procesos, se observaron creaciones anómalas de PowerShell que a su vez lanzaban csc.exe y cvtres.exe, herramientas legítimas del compilador .NET y de recursos, que CPU-Z no debería disparar en circunstancias normales. Este patrón, junto con la carga reflectiva y el secuestro de DLLs, permitió a soluciones avanzadas de EDR catalogar rápidamente la actividad como framework de penetración o shellcode.
STX RAT, robo de credenciales y persistencia a largo plazo
La carga útil final de la cadena de ataque se identificó como STX RAT, un troyano de acceso remoto con capacidades muy amplias. Entre sus funciones destacaban un VNC oculto para tomar el control visual del equipo, inyección de teclado y ratón, mecanismos de robo de contraseñas en navegadores y herramientas para acceder a carteras de criptomonedas y al almacén de credenciales de Windows.
Los módulos de infostealer estaban muy afinados. El malware se centraba especialmente en navegadores basados en Chromium (Chrome, Edge, Brave) y también en Firefox, extrayendo contraseñas guardadas, cookies de sesión y datos de autocompletado. De este modo, cualquier cuenta recordada en el navegador —correo, banca online, tiendas, redes sociales— quedaba potencialmente comprometida.
Adicionalmente, algunos análisis mencionan cargas orientadas a extraer información de Windows Vault y a localizar wallets de criptomonedas, con lo que el impacto financiero directo podía ser considerable. No se trataba de un ransomware ruidoso ni de un wiper destructivo, sino de una puerta trasera silenciosa capaz de permanecer en el sistema durante años.
Para garantizar esa permanencia, los atacantes configuraron varios mecanismos redundantes de persistencia. Se han documentado claves Run en el registro de Windows, tareas programadas con tiempos absurdamente largos (por ejemplo, ejecuciones cada 68 minutos con duración prevista de décadas) y proyectos de MSBuild colocados en directorios como AppData\Local, diseñados para sobrevivir a limpiezas parciales y a reinicios del sistema.
Los investigadores que hicieron análisis forense recomiendan, por tanto, revisar no solo la presencia de CRYPTBASE.dll fuera de C:\Windows\System32 o la creación de procesos inusuales por parte de cpuz_x64.exe, sino también bloquear dominios y direcciones IP asociadas a la campaña —como supp0v3com o determinados rangos de infraestructura sospechosa— a nivel de DNS y firewall, y eliminar uno por uno todos los artefactos de persistencia detectados.
Perfil de víctimas y alcance potencial del compromiso
Los datos disponibles apuntan a que, aunque el número de víctimas confirmadas directas ronda algo más de un centenar en algunas fuentes, el impacto potencial es muchísimo mayor debido al tipo de usuario que suele descargar CPU-Z y HWMonitor. No es lo mismo infectar a un usuario doméstico aislado que a un administrador de dominio con acceso a cientos de servidores.
En la práctica, un solo sysadmin comprometido puede convertirse en el caballo de Troya perfecto para acceder a redes corporativas completas, consolas de virtualización, infraestructuras en la nube, repositorios de código y sistemas de producción. Buena parte de los usuarios afectados manejan credenciales de alta sensibilidad y disponen de permisos elevados en entornos críticos.
Además, hay que tener en cuenta el volumen global de descargas de estas herramientas. CPU-Z y HWMonitor acumulan decenas de millones de instalaciones y son lo primero que muchos técnicos descargan cuando se enfrentan a una máquina desconocida. Una ventana de seis horas de descargas maliciosas, distribuida a través de múltiples husos horarios, implica que miles de usuarios podrían haber recibido instaladores troyanizados sin percatarse de nada.
Desde el punto de vista geográfico, los informes señalan un mayor número de casos en Europa y Norteamérica, zonas donde este software está especialmente extendido en entornos profesionales y entusiastas. Sin embargo, el alcance real puede ser muy superior, ya que no todas las infecciones se reportan ni todos los incidentes se detectan a tiempo.
Un matiz especialmente relevante es la reputación de CPUID dentro de la comunidad técnica. Al tratarse de un proveedor ampliamente usado, muchos filtros de seguridad internos permitían sin problema el tráfico hacia su dominio y la ejecución de sus binarios. Esto ayuda a que la cadena de suministro comprometida atraviese capas de control que sí habrían bloqueado binarios desconocidos o procedentes de sitios menos confiables.
Evidencias de infección: cómo saber si estuviste en la diana
Para los usuarios que descargaron CPU-Z o HWMonitor en las fechas críticas, hay varios indicios clave que pueden ayudar a determinar si han estado expuestos. El primer indicador es el propio nombre del archivo descargado: cualquier variación llamativa respecto al patrón habitual (por ejemplo, “HWiNFO_Monitor_Setup.exe” en lugar de los típicos hwmonitor_*.exe) debe considerarse señal de alarma.
Otro elemento a revisar son los registros del antivirus durante los días 9 y 10 de abril. Si hubo alertas etiquetadas como malware, PUA o comportamiento sospechoso y se descartaron como falsos positivos, conviene reanalizar el evento con más calma. Los logs de seguridad pueden contener la pista de un intento de ejecución bloqueado a tiempo o de una amenaza parcialmente neutralizada.
También es recomendable consultar el historial de descargas del navegador. Cualquier ejecutable procedente de cpuid.com con nombres poco coherentes y fechas dentro de la ventana de ataque debe tratarse con especial cautela. Si además se recuerda haber ignorado una advertencia del antivirus durante la instalación, las probabilidades de infección aumentan.
En el terreno más técnico, los analistas sugieren buscar presencia de CRYPTBASE.dll en ubicaciones distintas de System32, procesos donde cpuz_x64.exe genere instancias de powershell.exe, csc.exe o cvtres.exe, y cualquier artefacto inusual en tareas programadas o claves Run del registro. Son huellas típicas de la cadena de ataque observada en este caso.
Por último, si tu organización emplea soluciones de EDR o XDR, merece la pena revisar los eventos históricos etiquetados como inyección de código, secuestro de DLL o frameworks de penetración relacionados con ejecutables de CPUID. Muchos agentes avanzados detectaron y pusieron en cuarentena el comportamiento en segundos, pero eso no exime de hacer una comprobación posterior de posibles movimientos laterales o accesos no autorizados.
Pasos de mitigación si descargaste durante la ventana comprometida
Si descargaste CPU-Z o HWMonitor en torno al 9 y 10 de abril, y no tienes claro si tu instalador era legítimo, conviene actuar con prudencia. La primera medida es desinstalar por completo las versiones sospechosas de estas herramientas desde el Panel de control o la configuración de aplicaciones de Windows, sin dar por hecho que están limpias aunque hayan seguido funcionando con aparente normalidad.
A continuación, hay que ejecutar un análisis antivirus completo, no uno rápido. Puedes utilizar soluciones como Windows Defender, Malwarebytes o Kaspersky, preferiblemente con bases de firmas actualizadas y, si la herramienta lo permite, con análisis offline o desde un entorno de rescate, para aumentar las posibilidades de detección de componentes residentes en memoria o de persistencias ocultas.
Una vez hecho el escaneo, el siguiente paso crítico es el cambio de todas las credenciales que pudieran haber estado almacenadas en el navegador. Esto incluye correos electrónicos (Gmail, Outlook), banca online, servicios en la nube (Dropbox, Google Drive), redes sociales y cualquier otra cuenta importante. Es preferible actualizar las contraseñas desde un dispositivo que tengamos por limpio o desde una sesión en modo seguro.
No está de más revisar el historial de accesos de las cuentas más sensibles, especialmente correos y servicios financieros, buscando inicios de sesión desde ubicaciones o dispositivos extraños. En caso de tener tarjetas de crédito o medios de pago guardados en el navegador, merece la pena contactar con el banco o proveedor de la tarjeta para activar alertas de movimientos sospechosos o incluso solicitar un reemplazo, según el nivel de exposición.
Para los usuarios más avanzados o en entornos corporativos, una opción es arrancar el equipo desde una distribución Linux en modo live y realizar análisis desde ese entorno aislado, evitando que un posible malware en Windows interfiera en el proceso. Ahí se pueden montar las particiones, buscar artefactos concretos y recopilar evidencias sin que el sistema principal esté en ejecución.
¿Está CPUID limpio ahora? Estado actual y riesgos residuales
Tras el incidente, CPUID comunicó públicamente que había identificado y corregido la vulnerabilidad en la API comprometida. La infraestructura de descargas volvió a servir binarios legítimos y firmados digitalmente con sus certificados habituales, y en principio, las descargas realizadas fuera de la ventana de ataque no deberían presentar problemas.
En el momento actual, los informes coinciden en que el sitio oficial opera de nuevo con normalidad y que no hay evidencia de que los ejecutables oficiales estén modificados. No obstante, y como suele suceder tras un ataque de cadena de suministro, la confianza se resiente y muchos usuarios miran con lupa cualquier descarga, incluso cuando el proveedor asegura haber resuelto la brecha.
La realidad es que, aunque el incidente se haya contenido, el riesgo estructural de este tipo de ataques no desaparece. Los adversarios han comprobado que comprometer la cadena de distribución de una herramienta tan popular puede abrirles puertas muy valiosas, por lo que es razonable esperar intentos similares en otros proyectos de software ampliamente difundidos.
Una práctica interesante para quienes sigan utilizando CPU-Z o HWMonitor es verificar el hash SHA-256 de los binarios descargados cuando el proveedor publique sumas de comprobación, comparándolas con las oficiales. Aunque no es una bala de plata, añade una capa de verificación para asegurarse de que el archivo no ha sido modificado en tránsito.
También es recomendable seguir los canales oficiales de CPUID (web, redes sociales, boletines de seguridad) para estar al tanto de cualquier actualización relacionada con seguridad, nuevas versiones firmadas o indicaciones específicas de mitigación que la compañía pueda publicar en el futuro.
Por qué este ataque encaja en el patrón de la cadena de suministro
El caso de CPUID encaja perfectamente en la tendencia creciente de ataques de cadena de suministro que ya vimos en incidentes como SolarWinds, Codecov o campañas dirigidas contra proyectos como FileZilla y otros. La idea central es comprometer un eslabón confiable de la cadena de desarrollo o distribución, de forma que, sin tocar el código fuente central, se pueda llegar a miles de usuarios finales.
En este incidente confluyen varios elementos típicos de este patrón: compromiso de una API secundaria responsable de servir enlaces de descarga, uso de binarios aparentemente legítimos acompañados de DLLs troyanizadas, y aprovechamiento de la firma digital del ejecutable principal para vencer defensas basadas en reputación.
Este tipo de ataque es especialmente peligroso porque subvierte la lógica de “descarga solo desde la web oficial”, que hasta ahora se consideraba una recomendación de seguridad básica. Si incluso el dominio legítimo de un proveedor consolidado puede ser usado como trampolín, el usuario medio se queda sin referencia clara para diferenciar entre una descarga segura y una falsa.
El problema no se limita a CPUID. Múltiples proyectos de software han sufrido incidentes similares, desde editores de texto hasta compresores de archivos o gestores FTP. La lógica del atacante es sencilla: en lugar de ir infectando usuarios uno a uno, se ataca al punto desde el cual todos confían en obtener actualizaciones y nuevas versiones, multiplicando el alcance de cada campaña.
Todo esto refuerza la importancia de que las organizaciones que distribuyen software adopten medidas específicas orientadas a la seguridad de la cadena de suministro: controles estrictos sobre APIs y paneles de administración, autenticación fuerte, segmentación de servicios críticos, revisión continua de logs y auditorías periódicas orientadas a detectar actividades anómalas en infraestructuras de descarga y firma de binarios.
Lecciones para usuarios, empresas y la comunidad de ciberseguridad
Una de las primeras lecciones que deja este caso es que no basta con confiar en HTTPS y en un dominio oficialmente reconocido. Aunque sigues estando mucho mejor descargando desde la web del fabricante que desde sitios de terceros dudosos, la experiencia de CPUID demuestra que el eslabón débil puede estar en la propia infraestructura de distribución.
Para los usuarios particulares, se hace cada vez más vital adoptar cierta “higiene digital básica” al manejar instaladores: comprobar nombres de archivo que cuadren con lo esperado, no ignorar de primeras las alertas del antivirus, verificar hashes cuando el proveedor los ofrece y actualizar el microcódigo de la CPU.
En el entorno corporativo, la respuesta pasa por reforzar arquitecturas tipo zero trust en la gestión de software y actualizaciones. Esto implica aplicar listas blancas estrictas, segregar entornos de pruebas, utilizar máquinas virtuales o sandboxes para validar herramientas antes de llevarlas a producción y desplegar soluciones EDR capaces de detectar patrones de comportamiento sospechosos aunque el binario inicial esté firmado y parezca legítimo.
Otro aspecto clave es el de la monitorización y el análisis forense continuo. Contar con telemetría granular sobre procesos, conexiones de red, cargas dinámicas y cambios en el sistema permite reaccionar con mucha más rapidez ante comportamientos que se salgan de lo habitual, como un CPU-Z lanzando PowerShell o iniciando comunicaciones DNS-ofuscadas hacia IPs anómalas.
Por parte de la industria del software de diagnóstico y monitoreo de hardware, este tipo de incidentes debería servir como punto de inflexión para integrar mejores prácticas de seguridad desde el diseño: empleo extensivo de firmas robustas, publicación sistemática de SBOM (Software Bill of Materials), validación cruzada de integridad en servidores espejo y quizá, a futuro, exploración de tecnologías como blockchain para registrar huellas de binarios de forma inmutable.
En última instancia, lo ocurrido con CPUID es un recordatorio contundente de que la confianza en los procesos automatizados y en las cadenas de distribución no puede darse por garantizada. La combinación de herramientas de análisis estático y dinámico, reglas específicas para monitorizar flujos CI/CD, uso de bibliotecas criptográficas fiables para la firma y una cultura de seguridad activa tanto en proveedores como en usuarios finales es lo único que puede reducir el impacto de ataques similares en los próximos años.
Todo lo anterior muestra que, aunque CPUID haya corregido la vulnerabilidad y la situación actual sea razonablemente segura, el episodio ilustra a la perfección cómo un fallo puntual en una API de descargas puede desencadenar una campaña de malware sofisticada contra uno de los ecosistemas más extendidos en el mundo del hardware y la administración de sistemas, obligándonos a replantear cómo descargamos, verificamos y ejecutamos incluso las herramientas que creíamos más confiables.
