ClickFix Meets DLL Sideloading: How Attackers Weaponized a Trusted Siemens App (CVE-2026-110936)

A single trusted, signed application became the delivery vehicle for a remote access trojan. Attackers paired a ClickFixsocial-engineering lure with a DLL sideloading flaw in Siemens Software Center (CVE-2026-110936, CVSS 8.4) to run their own code under the cover of legitimate Siemens software. Siemens has patched the flaw and confirmed active exploitation. The incident is worth studying because it combines the two techniques defining a large share of today’s intrusions: tricking a human into starting the chain, and abusing a trusted binary to finish it.

This post explains how the attack works, why “signed and trusted” is no longer a guarantee of safety, and what both engineering teams and defenders should do.

Key facts

Vulnerability: CVE-2026-110936 (CVSS v4 8.4), DLL sideloading in Siemens Software Center
Fixed in: version 4.0.9.8 (start the app to apply the update)
Status: actively exploited in ClickFix campaigns
Chain: ClickFix lure → PowerShell → MSI installer → DLL sideloading via a signed Siemens binary → remote access trojan
Attributed to: a ClickFix delivery platform tracked as “Romulus”
Action: update to 4.0.9.8+, block the published IOCs, and hunt for the specific execution pattern

Two Techniques, One Attack

Most readers will know one of these techniques but not how dangerous they are together.

ClickFix is a social-engineering pattern that has exploded in popularity. Instead of attaching malware, the attacker shows the victim a convincing message, a fake “verify you are human” page, a bogus error, a phony software fix, and instructs them to copy a command and run it themselves (often in the Windows Run dialog or a terminal). Because the victim pastes and runs it, the malicious command bypasses many email and download defenses. The user is the delivery mechanism.

DLL sideloading abuses how Windows applications find the code libraries (DLLs) they depend on. If a trusted, signed program loads a DLL from its own folder without verifying it, an attacker who can drop a malicious DLL with the expected name next to that program gets their code executed with the trusted program’s identity and privileges. Security tools that trust the signed application often wave the malicious DLL through.

In this campaign, the two combine into a clean chain. That combination, human-initiated execution plus a trusted carrier, is exactly why it slips past defenses built for traditional malware.

How the Attack Unfolds

Based on the public reporting, the chain runs roughly like this:

The lure (ClickFix). The victim lands on an attacker-controlled page, in some campaigns reached through malicious ChatGPT Custom GPTs pointing to a fake URL, that presents a ClickFix prompt and tells them to copy and run a command.
PowerShell. Running the pasted command executes PowerShell that fetches and drops an MSI installer.
MSI installer. msiexec.exe launches the malicious MSI (reported as AllMyBasic.msi), which places a genuine, validly signed copy of Siemens Software Center alongside a crafted malicious DLL (archive.dll).
DLL sideloading. When SiemensSoftwareCenter.exe starts, it loads the attacker’s DLL from its own folder, executing the malicious code under the trust of the signed Siemens binary.
Remote access trojan. The final payload is a RAT, giving the attacker hands-on control of the machine.

The attackers specifically chose Siemens Software Center as the carrier because it was signed and trusted, and because the vulnerable version loaded helper files from its own folder without checking them. The reporting attributes the activity to a ClickFix delivery platform known as Romulus, which has been used to deliver loaders and other malware through DLL sideloading.

Why "Signed and Trusted" Is Not Enough

The uncomfortable lesson here is that a valid code signature tells you who built the program, not what the program will load at runtime. DLL sideloading exploits exactly that gap. A signed application with an uncontrolled DLL search path becomes a living-off-the-land carrier: the attacker brings no obviously malicious executable, only a DLL that a legitimate, trusted program obligingly runs.

This is why endpoint defenses that rely on reputation and signatures struggle with these attacks, and why detection has to focus on behavior and relationships between processes rather than on any single file. It is the same principle behind our analysis of data and model supply-chain trust: trusting a component by its name or signature, without verifying what it actually does, is where defenders get caught.

The Developer Angle: This Is a Preventable Bug Class

DLL sideloading is not just an operational problem to detect; it is a secure-development problem to prevent. Applications that load libraries from uncontrolled search paths are shipping a vulnerability. The defensive patterns are well established:

Load DLLs from fully qualified, protected paths, not from the application’s own writable folder or the current working directory.
Verify the integrity and signature of loaded libraries before executing them, rather than trusting any DLL that happens to have the right name.
Use the platform’s safe library-loading controls to restrict the search order.
Treat “what does my application load at runtime, and from where?” as a review question during secure code review.

For software vendors, a trusted, widely deployed, signed application is an attractive carrier precisely because customers run it everywhere. That makes hardening against sideloading a supply-chain responsibility, not just an internal one.

Detection and Response

Siemens and the researchers published concrete guidance. Beyond patching:

Update Siemens Software Center to version 4.0.9.8 or later, and start the application so the update applies.
Block the published indicators of compromise (the attacker IPs and the wizardexpensive[.]com domain used for hosting and command-and-control, and the MSI distribution host).
Hunt for the execution pattern. A strong, carrier-independent detection is: SiemensSoftwareCenter.exe running from an unusual location such as AppData\Local\Programs and started by msiexec.exe. More generally, watch for trusted applications launched from user-writable directories, and for msiexec.exe spawning signed binaries that then load DLLs from the same folder.
Tune detections for the chain, not the sample. The malicious DLL name, MSI name and payload will change; the behavior, a signed app sideloading a DLL from a writable folder after an msiexec launch, is far more durable.

Validating that these detections actually fire is exactly what a purple team exercise is for.

The ClickFix Problem Is a People Problem

No patch fixes the first step. ClickFix works because a real person is persuaded to run a command. That makes security awareness training a frontline control here, not a compliance checkbox. The specific message your people need is simple and memorable: no legitimate website, error, or “fix” ever asks you to copy a command and paste it into the Run box or a terminal. The moment a page gives that instruction, it is an attack.

Pair that human control with technical ones, restricting who can run PowerShell and msiexec in unusual contexts, monitoring for the execution patterns above, and keeping trusted applications patched, and the whole chain breaks at several points.

Conclusion

CVE-2026-110936 is a small flaw with a large lesson. The attackers did not need an exotic exploit; they needed a human willing to paste a command and a trusted application careless about what it loads. Defending against this class of attack means accepting that a valid signature is not a verdict of safety, that detection must follow behavior rather than file names, and that your people are part of the control surface. Patch the flaw, block the indicators, hunt the pattern, and teach your team the one rule that stops ClickFix cold.

Worried about social-engineering and living-off-the-land attacks in your environment? Our Social Engineering & Phishing Awareness Training prepares your people for lures like ClickFix, our Secure Source Code Review catches bug classes like DLL sideloading before release, and our Red Team & Attack Simulation tests whether your defenses catch the full chain. Talk to our team.

Sources

The Hacker News — ClickFix Attackers Exploit Siemens Software Center Flaw to Deploy Remote Access Trojan(20 October 2026)
CVE-2026-110936 — CVE record
Siemens ProductCERT advisory SSA-580366 and active-exploitation alert (productcert.siemens.com)