Ataque a la cadena de suministro en CPUID: qué pasó y qué implica

Informatec Digital » Recursos » Ataque a la cadena de suministro en CPUID: qué pasó y qué implica

En los últimos meses, el nombre de CPUID —la compañía detrás de herramientas tan populares como CPU-Z y HWMonitor— ha saltado a los titulares de ciberseguridad por un ataque a la cadena de suministro que ha dejado a miles de usuarios con muy mal sabor de boca. Lo preocupante no es solo el malware en sí, sino el hecho de que todo se haya producido a través de descargas realizadas desde el propio sitio oficial, aprovechando la enorme confianza que la comunidad técnica tiene en estas utilidades.

Este incidente se suma a otros casos recientes como el compromiso de la app de macOS de OpenAI a través de la biblioteca Axios manipulada, y refuerza una idea incómoda: ya no basta con mirar si una web es «la oficial» o si el ejecutable viene firmado para estar tranquilos. Los atacantes están afinando sus técnicas de cadena de suministro, tocando precisamente el eslabón de distribución del software, allí donde duele más.

Qué ha pasado exactamente con CPUID, CPU-Z y HWMonitor

CPUID es una empresa veterana, fundada a finales de los 90, conocida por ofrecer utilidades gratuitas de diagnóstico y monitorización de hardware para Windows. CPU-Z sirve para ver al detalle el procesador, la memoria y la placa base, mientras que HWMonitor se usa para controlar temperaturas, voltajes y ventiladores. Son herramientas omnipresentes en talleres de reparación, centros de datos, equipos de gaming y entornos de pruebas.

Durante abril de 2026, el sitio web oficial de la compañía fue comprometido en un ataque de cadena de suministro que afectó a las descargas de CPU-Z y HWMonitor. Lo delicado del caso es que los atacantes no tocaron el código fuente ni los binarios firmados que CPUID distribuye de forma legítima, sino una pieza mucho más sutil: una API secundaria encargada de gestionar los enlaces de descarga y ciertos flujos internos.

Entre el 9 y 10 de abril de 2026, durante una ventana aproximada de seis horas según algunas fuentes y de hasta unas 19 horas según otros análisis más profundos, esa API lateral empezó a redirigir las peticiones de descarga legítimas hacia infraestructura controlada por los atacantes. El usuario entraba a cpuid.com, hacía clic en el botón oficial de descarga y, a simple vista, parecía todo normal.

En ese intervalo de tiempo, varios usuarios notaron comportamientos raros: instaladores con nombres poco habituales, como “HWiNFO_Monitor_Setup.exe” en lugar del típico hwmonitor_*.exe, y avisos de antivirus que mucha gente, por desgracia, ignoró pensando que eran falsos positivos. A partir de ahí empezó a destaparse el pastel.

Las estimaciones hablan de un número potencialmente enorme de usuarios expuestos, porque CPU-Z y HWMonitor no son programas de nicho: acumulan decenas de millones de descargas históricas y se usan a diario por técnicos, administradores de sistemas, overclockers y profesionales de IT. Una ventana de ataque de unas pocas horas, distribuida en distintas franjas horarias globales, es suficiente para generar un impacto serio.

Cadenas de suministro: por qué este ataque es tan peligroso

Lo que hace especialmente inquietante el caso de CPUID es que se trata de un ataque quirúrgico a la cadena de distribución del software, no a los binarios originales. Es decir, el problema no estuvo en el repositorio de código ni en los ejecutables firmados, sino en la infraestructura que decide qué archivo se entrega a cada usuario.

Este patrón encaja con una tendencia clara en los últimos años: los ataques a la cadena de suministro de software, en los que el delincuente no intenta comprometer directamente cada equipo final, sino el eslabón común que sirve software a miles o millones de máquinas. Casos como SolarWinds o Codecov ya demostraron lo devastador que puede ser manipular una pieza en el camino de distribución.

Los atacantes aprovechan normalmente fallos de seguridad en APIs, servidores web o flujos de CI/CD para introducir enlaces maliciosos, bibliotecas manipuladas o cargas troyanizadas. En CPUID, se habló de una “característica secundaria” o “API lateral” como punto de entrada, no del repositorio central ni del sistema de firma. Esa API habría permitido cambiar el destino de los enlaces de descarga sin que el usuario viera nada sospechoso en el navegador.

Algo similar ocurrió recientemente con OpenAI, cuando un flujo de trabajo de GitHub Actions que firmaba la app de macOS descargó una versión maliciosa de la biblioteca Axios el 31 de marzo. En ese caso, OpenAI tuvo que revocar el certificado de la aplicación para macOS como medida preventiva, pese a asegurar que no se habían comprometido datos de usuarios ni sistemas internos. Es otro ejemplo de cómo un único eslabón débil en el proceso automatizado puede contaminar toda la cadena.

Desde el punto de vista técnico, estas intrusiones suelen explotar fallos como credenciales débiles, APIs sin autenticación robusta, servidores desactualizados o falta de monitorización en sistemas críticos. Y lo más grave: a menudo pasan desapercibidas durante horas o días, hasta que la comunidad o las herramientas de seguridad empiezan a detectar comportamientos anómalos en masa.

Cómo se distribuyó el malware en el caso de CPUID

En el incidente de CPUID se han observado, según los distintos análisis públicos, dos variantes de cadena de ataque muy relacionadas. En los casos más documentados, los atacantes sirvieron un binario legítimo de CPU-Z acompañado de una DLL maliciosa en el mismo directorio de instalación.

Esa DLL, identificada como CRYPTBASE.dll (el mismo nombre que una librería legítima de Windows), estaba compilada en Zig y se aprovechaba del orden de búsqueda de DLL de Windows: al estar en el mismo directorio que el ejecutable legítimo de CPU-Z, el sistema cargaba primero la versión maliciosa en lugar de la original de C:\Windows\System32. Esto es un clásico caso de secuestro de carga de DLL (DLL hijacking).

Una vez cargada la DLL falsa, se iniciaba una cadena de ataque bastante avanzada. La carga maliciosa ejecutaba una segunda DLL cifrada directamente en memoria, mediante técnicas de inyección reflectiva, lo que permitía evitar escrituras en disco y dejaba muy pocos rastros para análisis posteriores. Este comportamiento fue lo que llevó a algunos agentes de seguridad avanzada a marcar inmediatamente la actividad como “penetration framework or shellcode detected”.

A partir de ahí, la comunicación con el servidor de mando y control (C2) se realizaba a través de DNS-over-HTTPS hacia 1.1.1.1, un truco diseñado para esquivar muchos sistemas de monitorización DNS tradicionales. Además, la cadena incluía la creación de procesos como PowerShell lanzando csc.exe y cvtres.exe, algo totalmente fuera de lo normal para una herramienta como CPU-Z.

Para garantizar que la infección sobreviviera a reinicios y a intentos de limpieza parciales, el malware desplegaba hasta tres mecanismos redundantes de persistencia: una clave Run en el registro de Windows, una tarea programada con una periodicidad de 68 minutos y duración de hasta 20 años, y archivos de proyecto de MSBuild escondidos en AppData\Local. Este planteamiento dificulta enormemente la erradicación si no se sabe exactamente qué buscar.

La carga final era identificada como STX RAT, un troyano de acceso remoto con capacidades de VNC oculto, inyección de teclado y ratón, robo de credenciales desde múltiples navegadores (Chrome, Firefox, Edge, Brave), extracción de datos de Windows Vault y acceso a monederos de criptomonedas. No se trataba de un simple adware, sino de una puerta trasera con un abanico amplio de posibilidades de espionaje y control.

Qué buscaba el malware: credenciales, control remoto y más

Todo el diseño del ataque deja bastante claro que el objetivo principal era el robo silencioso de información sensible y el acceso remoto persistente, no el daño inmediato al usuario (como haría un ransomware, por ejemplo). Esa diferencia es clave, porque hace que el ataque sea más difícil de detectar y potencialmente más rentable para los atacantes.

Entre las capacidades asociadas a STX RAT y a las cargas vistas durante el incidente destacan varias funciones típicas de infostealers y RAT avanzados: extracción de contraseñas y cookies almacenadas en navegadores, acceso a sesiones activas (correo, banca online, tiendas digitales), recopilación de información del sistema y posible escalada de privilegios en entornos donde el usuario tuviera permisos elevados.

En algunos relatos se menciona también el despliegue de payloads adicionales en .NET y el uso de PowerShell en memoria para bajar más módulos desde servidores remotos, práctica habitual en campañas que buscan modularidad: se instala un primer implante relativamente ligero y, una vez que el atacante confirma que la máquina le interesa, descarga componentes extra para exfiltrar datos concretos o moverse lateralmente por la red.

La elección de CPU-Z y HWMonitor como vectores no es casual. El perfil típico de quien instala estas herramientas está muy sesgado hacia profesionales de IT, administradores de sistemas y gente con accesos privilegiados en redes corporativas. Comprometer a un único sysadmin con derechos de dominio puede tener un radio de impacto radicalmente mayor que infectar a un usuario doméstico sin privilegios.

Por eso, aunque el número de víctimas confirmadas directas pueda parecer relativamente bajo (del orden de un centenar largo de casos bien documentados, según algunos proveedores de EDR), el potencial de daño en entornos empresariales y de infraestructura crítica era elevado. Basta con que uno de esos técnicos tenga credenciales de servidores, paneles de cloud o dispositivos de red para abrir una puerta muy peligrosa.

Cómo saber si podrías haberte visto afectado

Si descargaste CPU-Z o HWMonitor desde el sitio oficial de CPUID alrededor del 9-10 de abril de 2026, conviene que hagas una revisión mínima de tus descargas y sistemas, aunque solo sea por descartarlo. No hace falta caer en la paranoia, pero sí comprobar algunos puntos clave.

Lo primero es revisar el nombre del archivo que descargaste. Si tu instalador de HWMonitor llevaba un nombre extraño, como “HWiNFO_Monitor_Setup.exe” o cualquier otra variante que no encaje con el patrón habitual hwmonitor_*.exe, eso es una bandera roja importante. Muchos usuarios comentaron precisamente esas incongruencias de nombres en foros y redes.

En segundo lugar, deberías mirar los logs de tu antivirus correspondientes a esas fechas. Si Windows Defender, Malwarebytes, Kaspersky u otra solución de seguridad lanzó una alerta durante la descarga o la instalación y tú la ignoraste, ahora es el momento de recuperar ese historial y ver qué detectó exactamente. Avisos con términos como “suspicious”, “malware” o “PUA” merecen un análisis más detenido.

También merece la pena revisar el historial de descargas del navegador para localizar cualquier ejecutable procedente de cpuid.com durante esa ventana de tiempo. Si encuentras algo sospechoso, guarda copia del archivo para análisis (por ejemplo, subiéndolo después a VirusTotal) y evita ejecutarlo de nuevo bajo cualquier concepto.

Si eres más técnico y tienes dudas razonables de que tu sistema pudo estar comprometido, una opción es arrancar desde una imagen limpia de Linux en un USB y analizar el disco de Windows desde fuera. No es algo que la mayoría de usuarios necesite, pero para entornos críticos puede ayudar a localizar ficheros como CRYPTBASE.dll fuera de System32, tareas programadas raras o artefactos en AppData.

Pasos recomendados si descargaste en la ventana comprometida

Si al revisar fechas y nombres de archivos ves que descargaste CPU-Z o HWMonitor justamente entre el 9 y 10 de abril de 2026, lo prudente es asumir que existe al menos una posibilidad razonable de exposición y actuar en consecuencia, aunque luego el análisis termine mostrando que no hubo infección real.

El primer paso es desinstalar las versiones afectadas desde el Panel de control o Configuración de Windows. No tiene sentido mantener programas en los que no confías mientras investigas. Una vez desinstalados, conviene limpiar también restos de carpetas en Program Files y AppData, siempre con cuidado de no borrar nada que no tengas claro.

Después, ejecuta un escaneo antivirus completo (no rápido) del sistema. Las soluciones modernas de seguridad, especialmente las que cuentan con detección de comportamiento, son capaces de cazar rastros de este tipo de malware incluso si parte de la carga vivió solo en memoria. Si puedes, utiliza una combinación de Windows Defender actualizado y una herramienta adicional como Malwarebytes para tener una segunda opinión.

En paralelo, deberías asumir que cualquier credencial almacenada en el navegador durante ese periodo puede estar comprometida. Eso significa que es recomendable cambiar contraseñas de correo, banca online, servicios en la nube y cualquier plataforma crítica cuyo acceso haya pasado por Chrome, Firefox, Edge o Brave. Hazlo después de haber escaneado y limpiado el sistema, no antes.

También conviene revisar el historial de accesos sospechosos a tus cuentas principales (por ejemplo, en Gmail, Amazon, Dropbox o el panel de tu banco) para ver si ha habido logins desde ubicaciones o dispositivos extraños. Y, si guardabas tarjetas en el navegador, tiene sentido avisar al banco para que esté atento a posibles movimientos raros o, en casos extremos, solicitar el cambio de tarjeta.

Respuesta de CPUID y situación actual de sus descargas

Tras destaparse el incidente, CPUID publicó comunicados explicando que el ataque había afectado a una funcionalidad secundaria de su infraestructura —esa famosa API lateral— y que los binarios firmados y los repositorios de código no habían sido alterados. Afirmaron haber identificado y parcheado la vulnerabilidad en el API comprometido y restaurado la normalidad en la plataforma de descargas.

Según la información disponible, los ejecutables actuales de CPU-Z y HWMonitor vuelven a estar firmados correctamente y servidos desde la infraestructura limpia. A día de hoy, descargar estas herramientas desde la web oficial, una vez corregido el problema, se considera seguro, siempre que se mantengan las precauciones habituales de cualquier software obtenido de Internet.

Aun así, el incidente deja una cierta desconfianza razonable. Muchas organizaciones se están planteando si tiene sentido seguir desplegando utilidades de terceros como CPUID en servidores de producción o entornos extremadamente sensibles. En algunos casos, se opta por alternativas open source bien auditadas (como lm-sensors en Linux u OpenHardwareMonitor) o por herramientas nativas de los proveedores de cloud y hardware.

Por su parte, CPUID tendrá que trabajar para reconstruir la confianza de la comunidad, no solo limpiando el incidente puntual, sino demostrando que han reforzado su seguridad interna: auditorías periódicas, controles de acceso más duros, monitorización de anomalías en descargas y publicación de hashes verificables de cada versión, entre otras medidas.

A nivel más general, este tipo de ataques está empujando a que la industria adopte prácticas como los SBOM (Software Bill of Materials), que obligan a documentar todos los componentes que lleva un software, y modelos de arquitectura de confianza cero (zero trust), donde ni siquiera se asume que el código interno es de fiar si no pasa controles continuos.

Lecciones clave para usuarios y para la industria

El incidente de CPUID es un recordatorio incómodo de que confiar ciegamente en el sitio oficial ya no es suficiente. Los atacantes han entendido que el eslabón débil a menudo no está en el usuario que hace clic, sino en la infraestructura de distribución que todos damos por segura.

Para los usuarios finales, hay varias ideas que conviene grabarse a fuego. La primera: no ignores los avisos del antivirus solo porque el archivo venga de una web conocida. Las detecciones modernas se basan en comportamiento y reputación global; si salta una alerta cuando descargas algo de cpuid.com en una fecha concreta, puede ser precisamente la señal de que algo raro está ocurriendo en el backend del proveedor.

La segunda: fíjate en los detalles obvios como el nombre del ejecutable. Un instalador llamado HWiNFO_Monitor_Setup.exe cuando tú esperabas HWMonitor debería levantar sospechas al instante. Son dos segundos de atención que pueden evitar una infección bastante seria.

Para las empresas de software, este tipo de incidentes refuerza la necesidad de endurecer los procesos de CI/CD, los accesos a servidores de descarga y las APIs auxiliares. Herramientas de escaneo de dependencias como Semgrep u otros sistemas SCA, reglas Sigma aplicadas a los logs de CI/CD y análisis estático/dinámico antes de firmar binarios ya no son “nice to have”: son básicos.

Por último, la comunidad de ciberseguridad está empujando hacia soluciones más sofisticadas: uso de bibliotecas criptográficas robustas para garantizar integridad y autenticidad en el proceso de firma, EDR con detección en memoria capaz de cortar cadenas de ataque como las vistas en CPU-Z, y una cultura donde cualquier anomalía en descargas masivas se investiga de inmediato, en lugar de despacharla como un bug puntual.

Todo lo ocurrido con el ataque a la cadena de suministro en CPUID deja claro que el vector de comprometer la distribución, y no el código fuente directamente, ha llegado para quedarse. Usuarios y organizaciones tienen que subir el listón de su higiene digital: verificar hashes cuando sea posible, prestar atención a nombres de archivos y certificados, no desconectar el radar cuando ven el logo de una marca que les suena de toda la vida y, sobre todo, reaccionar rápido ante cualquier sospecha para que un incidente puntual no se convierta en un problema de largo recorrido.