Siemens patches DLL sideloading flaw in Software Center used in ClickFix attacks

The vulnerability could allow an attacker to place a specially-crafted DLL in a directory the application searches, resulting in execution of malicious code with the same privileges as the affected service. That turns a trusted desktop application into a loader for code the attacker controls.

In a separate alert, Siemens said attackers have abused a genuine copy of Siemens Software Center with a valid signature and placed their own crafted DLL ("archive.dll") next to it to trigger the execution of malicious code. The binary itself is legitimate and correctly signed, so signature checks on the executable do not reveal the problem.

According to Huntress, some of these campaigns have leveraged malicious ChatGPT Custom GPTs to direct victims to a fake URL responsible for serving a ClickFix lure, which when copied and executed by the victim, runs PowerShell code to drop an MSI installer that abuses DLL sideloading to ultimately deploy a remote access trojan.

If this software is in your estate, start with version coverage, then look for the delivery chain that leads to it.

1. 01

   Confirm the installed version everywhere

   Query your software inventory or endpoint agent for every host carrying Siemens Software Center and record the exact version string. Anything below 4.0.9.8 needs the update. Pay attention to engineering laptops and jump hosts that sit outside the standard patch rings.

2. 02

   Hunt for stray DLLs beside the executable

   List the application directory and any folder a copied executable was run from, including user profile paths, Downloads and temporary directories. A DLL named archive.dll sitting next to a signed binary, or any unsigned DLL with a recent write time, is a bad result worth isolating.

3. 03

   Look for copies of the signed binary outside the install path

   Search file inventories for the executable name across all drives rather than only the expected program directory. A correctly signed binary in a user writable folder is the pattern to flag. Record the parent process that wrote it.

4. 04

   Review PowerShell execution from clipboard driven launches

   In your EDR or Windows event logs, check script block logging and process creation where explorer.exe or the Run dialog spawns powershell.exe with encoded or long inline commands. Follow any child msiexec.exe process and the package it installed.

5. 05

   Check outbound traffic from the application process

   Query proxy and DNS logs for connections made by the Software Center process name to domains you do not recognise. Unexpected beaconing on a regular interval is the signal to chase. Capture the destination before you reimage.

6. 06

   Tighten write permissions on application directories

   Run icacls against the install path and confirm standard users cannot write there. Where application allowlisting is available, add rules that block unsigned DLL loads from user writable locations and test them in audit mode first.