Índice de contenidos
Claves de la noticia
- Siemens confirma ataques que aprovechan CVE-2026-110936 para cargar DLL maliciosas junto a una copia auténtica de Software Center.
- La versión 4.0.9.8 corrige el fallo; el fabricante publica rutas, archivos e indicadores para buscar infecciones.
- Una firma válida del ejecutable no descarta el ataque, que también puede aparecer en ordenadores donde nadie instaló voluntariamente software de Siemens.
Siemens ha confirmado este 19 de octubre la explotación activa de una vulnerabilidad de Siemens Software Center, su gestor de descarga, instalación y activación de programas. Los atacantes distribuyeron una copia legítima y firmada de la aplicación junto a archivos maliciosos. La novedad es la confirmación de ataques y sus señales de detección: el fallo ya tenía un aviso de seguridad desde el día 15.
El ejecutable conserva su firma; las DLL introducen el código
Según la explicación de Siemens ProductCERT, el programa utilizado como vehículo no fue modificado. La versión 3.5.8.7 cargaba archivos auxiliares desde su propia carpeta sin comprobarlos. Los atacantes aprovecharon ese comportamiento colocando sus DLL al lado del ejecutable: al arrancar, el programa auténtico cargaba código ajeno.
Esta técnica, conocida como DLL side-loading, cambia lo que conviene comprobar. Verificar únicamente que SiemensSoftwareCenter.exe es auténtico puede dar un resultado correcto y dejar pasar la infección. La firma acredita ese archivo, pero no convierte en fiables todos los componentes que encuentre a su alrededor. El objeto de la revisión debe ser el conjunto de archivos, su ubicación y la forma de ejecución.
El fabricante vincula los hechos con la campaña Romulus, que emplea señuelos ClickFix. Su recomendación para usuarios es no copiar órdenes de una página web en Ejecutar, Win+R o PowerShell para superar una supuesta verificación. Una comprobación legítima de que el visitante no es un robot no necesita ese procedimiento. Siemens no publica en este aviso un número de víctimas, una lista de países afectados ni una fecha de inicio de la campaña.
Tres fechas que separan el fallo de la alerta por ataques
El historial del boletín SSA-580366 permite distinguir tres hitos. Esta comparación importa para los equipos que ya tramitaron la alerta inicial: conocer la vulnerabilidad no equivale a haber incorporado los indicadores de la campaña publicados después.
| Fecha | Versión del aviso | Cambio registrado |
|---|---|---|
| 15 de octubre | V1.0 | Publicación de la vulnerabilidad. |
| 17 de octubre | V1.1 | Incorporación de la corrección para Software Center. |
| 19 de octubre | V1.2 | Enlace a la confirmación de explotación activa y detección. |
La tabla refleja las revisiones del documento, no las fechas de cada ataque ni el momento exacto en que todos los equipos recibieron el parche. El aviso considera afectadas todas las versiones anteriores a 4.0.9.8 y pide actualizar a esa versión o una posterior. Indica además que las instalaciones existentes se actualizan automáticamente en su siguiente inicio.
De esa cronología sale una consecuencia práctica: una revisión cerrada el día 15 necesita incorporar ahora una búsqueda retrospectiva de compromiso. Actualizar resuelve la carga vulnerable en la aplicación actualizada; no demuestra por sí solo que un ordenador previamente atacado haya quedado limpio. Son dos comprobaciones distintas, con evidencias diferentes.
También hay que buscar en equipos sin instalación prevista
Siemens destaca como señal sospechosa que Software Center aparezca en las aplicaciones de inicio o en el Programador de tareas de un PC donde nunca se instaló. La distribución del paquete se produjo fuera de los canales oficiales. Por eso, limitar la búsqueda al inventario de clientes legítimos del programa puede dejar fuera los equipos donde lo introdujeron los atacantes.
Entre las señales publicadas figuran una carpeta llamada SM Software Provisioning Service dentro de AppDataLocalPrograms, archivos activate.bak o statinfosta.DB junto al ejecutable y una carpeta FTSuite con ftc.uml dentro de AppDataLocal. Para los defensores, el fabricante recomienda buscar SiemensSoftwareCenter.exe ejecutándose desde AppDataLocalPrograms y arrancado por msiexec. Estas señales sirven para investigar; el nombre de un archivo aislado no sustituye el análisis de su contexto.
El comunicado ofrece tres indicadores de infraestructura: la IP 96.62.218[.]59 y el dominio wizardexpensive[.]com estaban activos cuando se publicó; la IP 2.27.248[.]127, utilizada para distribuir el paquete AllMyBasic.msi, estaba inactiva. Aquí aparecen desactivados para evitar accesos accidentales. Que el servidor de distribución ya no entregue archivos no elimina una infección anterior ni vuelve inútiles sus registros históricos.
La combinación de estas dos observaciones amplía el alcance de la respuesta: hay que revisar tanto conexiones pasadas a infraestructura ya inactiva como ejecuciones actuales del programa en rutas inesperadas. Buscar solo dominios activos o solo instalaciones declaradas cubre una parte del problema.
Actualizar, investigar y contener requieren decisiones distintas
Para una empresa española que utilice el gestor, la comprobación inmediata es contrastar la versión instalada con el umbral 4.0.9.8 del aviso. Como ocurre al revisar qué componente de curl está expuesto, el nombre comercial sin versión y contexto de ejecución resulta insuficiente para cerrar el inventario.
Si aparecen indicios de compromiso, Siemens recomienda aislar el PC y seguir el procedimiento de respuesta a incidentes. Su secuencia incluye detener el proceso antes de retirar las entradas de inicio y las tareas, además de restablecer contraseñas. La revisión de credenciales tiene un propósito diferente al parcheado, una distinción también relevante en el antecedente de ConnectWise y sus medidas sobre accesos.
El fabricante afirma que, según su conocimiento, no fueron comprometidos sus sistemas, productos ni canales de actualización. Esa precisión impide describir el caso como una actualización oficial infectada. La conclusión operativa es más concreta: un binario legítimo puede actuar como vehículo de código malicioso cuando carga componentes desde una ubicación no controlada. La autenticidad del ejecutable y la seguridad de su ejecución necesitan verificaciones separadas.
Imagen generada con IA: recreación conceptual de un puesto de ingeniería aislado de la red; no es una fotografía del incidente.
