A signed file can still carry malware: Siemens Software Center attacks

A valid digital signature does not make an entire folder, installer bundle or launch process safe. The campaign abusing Siemens Software Center demonstrates the distinction: the attackers did not need to alter the vendor-signed executable. They placed malicious DLLs beside it, allowing the program to load their code at startup.

On October 19, Siemens reported active exploitation of CVE-2026-110936 in a campaign referred to as Romulus. The attack combines ClickFix social engineering with DLL side-loading. Siemens says it is not aware of any compromise of its systems, products or official update channel.

That distinction matters. The attackers distributed a genuine, signed copy of Siemens Software Center 3.5.8.7 together with malicious DLL files outside official channels. The signed binary itself was not modified. The malicious code sat in the accompanying libraries, while social engineering persuaded the victim to run the bundle.

Breachroad’s conclusion: a signature helps establish the provenance of one file. It does not authenticate every file in the same directory or a command copied from a website. Security controls need to account for download source, neighbouring files and execution context.

How the attack begins

ClickFix commonly pretends to solve a simple problem: an “I am not a robot” check, a video error, an update or access to a document. The page tells the user to open the Run dialog or PowerShell, paste a command and execute it.

This does not require the attacker to crack a password. The criminal persuades a person to run the command that downloads or launches the next stage. A legitimate executable can then act as a credible-looking carrier for a malicious DLL.

A normal CAPTCHA does not ask you to:

• press Win+R;
• paste a command into PowerShell, Terminal or Command Prompt;
• disable protection or dismiss a system warning;
• download a “verification tool” from an unrelated domain.

If a webpage asks for those steps, close the tab. In an organisation, report the event even if you did not run the command. The security team may be able to block the domain and warn other employees.

Who is affected

The vulnerability affects Siemens Software Center. In advisory SSA-580366, Siemens identifies version 4.0.9.8 as the fixed release. Existing installations should update when next started, but administrators should not assume this happened on every endpoint. Verify the actual version.

Two groups need particular attention:

1. endpoints where the organisation knowingly uses Siemens Software Center—the version and installation source must be confirmed;
2. endpoints where the software has no business reason to exist—its presence may be an attack artifact rather than an approved deployment.

An older version alone does not prove infection. Conversely, the absence of Siemens software from the approved application inventory does not close the question, because the bundle may have run from a user directory without a normal installation workflow.

Signals worth checking

Siemens published concrete hunting indicators. They include an unexpected Siemens Software Center entry in Startup Apps or Task Scheduler and an SM Software Provisioning Service directory under the user’s local application data. The vendor also highlights activate.bak and statinfosta.DB files next to the executable, plus an FTSuite directory containing ftc.uml.

The vendor’s network indicators include 96.62.218[.]59 and wizardexpensive[.]com. Its notice also lists the now-inactive distribution address 2.27.248[.]127 and SHA-256 hashes including:

• AllMyBasic.msi: f4d7c5321bb0d1bda439304a753bcf9b467b98ca53c7e9493b9c2c3451092e4a;
• archive.dll: 3fdcc7d7d049a89711fb31fb236940a1c5a09d899143ffd20c3c41fb1f2cf491.

An indicator is a starting point, not a complete description of the actor. The absence of one hash or domain does not rule out an incident, while a match needs context such as time, process ancestry and file path.

What an affected user should do

If you pasted and ran a command from a webpage:

1. disconnect the computer from the corporate network without powering it off, if that matches your organisation’s procedure;
2. contact the help desk or security team from another device;
3. provide the website address, approximate time and steps you completed;
4. do not delete files or history yourself—they may be needed to determine scope;
5. from a known-clean device, prepare to change passwords and revoke the sessions identified by responders.

A home user should disconnect the device from the internet and seek help from a trusted support provider or security vendor. If the computer was used for banking, email or a password manager, treat those accounts as potentially exposed and contact the relevant provider through a known, independently obtained channel.

An action plan for organisations

• update legitimate deployments to 4.0.9.8 or a later vendor-approved version;
• search EDR, DNS, proxy and firewall telemetry for the published indicators;
• hunt for the executable running from unusual user directories and for unsigned DLLs beside it;
• isolate hosts with confirmed artifacts and preserve evidence needed for investigation;
• review identities and sessions used on the endpoint instead of stopping at file removal;
• reinforce one simple lesson: a website should never dictate commands to paste into a system shell.

Allowlisting alone is not enough. If a policy trusts every signed executable regardless of path, adjacent libraries or parent process, a trusted component can be abused outside its normal context.

Source facts and our recommendations

Active exploitation, the software version used in the campaign, published indicators and the absence of a known compromise of Siemens infrastructure come from the vendor’s notice. The fixed version comes from SSA-580366. Neither source says that every older installation is infected.

Prioritising unusual execution paths, reviewing identities used on the endpoint and turning ClickFix instructions into a training scenario are Breachroad recommendations. We described a related pattern in our analysis of ClickFix malware staged through the browser cache. Organisations can rehearse recognition and reporting through cybersecurity training and phishing simulations, then validate application controls and EDR visibility with an IT security audit.