Siemens Software Center DLL Sideloading Abuse in ClickFix Malware Campaigns — Detection and Remediation Guide | Security Arsenal

Threat actors have been observed weaponizing a legitimate, digitally signed copy of Siemens Software Center — the vendor's official software management and update utility — by pairing it with malicious DLLs that the trusted binary loads at runtime. This classic DLL sideloading technique is being delivered through ClickFix social-engineering lures: fake browser pages, CAPTCHA prompts, or error dialogs that instruct victims to copy and paste an attacker-supplied command into the Windows Run dialog or a terminal, effectively convincing the user to infect themselves.

This combination is dangerous for two reasons. First, the payload executes under the umbrella of a trusted, signed Siemens process, which blinds application-control policies, weakens EDR conviction logic that trusts signed parentage, and gives defenders a plausible-looking process tree. Second, ClickFix removes the need for any traditional exploit — no memory corruption, no macro, no malicious attachment. The user is the execution vector, and the vulnerability is the unsafe DLL search/loading behavior of a legitimate vendor binary.

Any organization running Siemens industrial or engineering software — which means a huge share of manufacturing, energy, and OT-adjacent environments — should treat this as an active threat requiring immediate hunting and hardening.

Technical Analysis

Affected Component and Attack Chain

The campaign combines two techniques that defenders must understand independently:

1. DLL Sideloading via Siemens Software Center (MITRE ATT&CK T1574.002)

The attackers ship a genuine, vendor-signed Siemens Software Center executable alongside one or more malicious DLLs in the same directory. When the signed binary launches, the Windows loader resolves a required library from the application's own directory before checking system paths — and loads the attacker's DLL into the trusted process's address space. The malicious code then executes with the full trust and reputation of the signed Siemens process. No exploit of a memory-corruption bug is required; the weakness is the binary's library resolution behavior combined with the attacker's ability to place a weaponized DLL next to it. No CVE identifier has been publicly assigned to this loading behavior in the reporting to date — defenders should track Siemens ProductCERT advisories for any future identifier or fixed release.

2. ClickFix Delivery (T1204 — User Execution)

ClickFix lures present victims with a fake fix, CAPTCHA verification, or error remediation dialog that instructs them to: press Win+R, paste a command that was silently copied to their clipboard by JavaScript on the malicious page, and press Enter. The pasted command typically invokes powershell.exe, mshta.exe, or curl/certutil to pull down the staged payload — in this campaign, the Siemens Software Center package bundled with malicious DLLs, often dropped into a user-writable directory such as %TEMP%, %APPDATA%, or %LOCALAPPDATA%.

The full chain looks like this:

Victim lands on a compromised or malicious page (malvertising, SEO poisoning, or phishing link).
ClickFix lure silently copies a staged command to the clipboard.
Victim pastes and runs it via Run dialog → powershell.exe or mshta.exe downloads and extracts the payload archive.
The archive contains the signed Siemens Software Center binary + malicious DLL in the same folder.
The signed binary is executed; the loader resolves the malicious DLL from the application directory.
Malicious code runs in-process under the signed binary's reputation, then typically establishes C2 or stages follow-on payloads.

Exploitation Status

This is confirmed active exploitation in the wild — real campaigns, real infections — not a theoretical weakness or proof-of-concept. ClickFix as a delivery mechanism has surged since 2024 and remains one of the most effective initial-access techniques observed through 2025 and into 2026 precisely because it bypasses attachment scanning, macro controls, and most exploit prevention. The abuse of a widely deployed Siemens binary makes this especially relevant to industrial and engineering environments where Siemens software is legitimately present, increasing the noise floor defenders must filter.

Why This Evades Traditional Controls

Application whitelisting that trusts signed binaries will allow the Siemens executable by default.
EDR process-reputation logic deprioritizes alerts on signed vendor processes.
Email and web filtering never see a malicious attachment — the payload is fetched interactively by the user.
Exploit prevention has nothing to hook; there is no exploit.

Detection & Response

The highest-fidelity detection surfaces for this campaign are: (1) the ClickFix execution pattern — explorer.exe spawning script interpreters with download cradles; (2) Siemens Software Center binaries executing from non-standard, user-writable paths; and (3) image-load events where a signed process loads an unsigned DLL from its own directory.

YAML

---
title: ClickFix-Style User-Executed Download Cradle via Run Dialog
id: 3f8c1a94-6b2d-4e71-9a05-7c4d2e8f1b63
status: experimental
description: Detects script interpreters spawned by explorer.exe (consistent with Win+R Run dialog execution) invoking download cradles or encoded commands, a hallmark of ClickFix social-engineering lures.
references:
  - https://www.securityweek.com/siemens-software-center-vulnerability-exploited-in-clickfix-malware-attacks/
  - https://attack.mitre.org/techniques/T1204/
  - https://attack.mitre.org/techniques/T1059/001/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.execution
  - attack.t1204
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\explorer.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\mshta.exe'
      - '\cmd.exe'
  selection_cl:
    CommandLine|contains:
      - 'iex '
      - 'Invoke-Expression'
      - 'Invoke-WebRequest'
      - 'iwr '
      - 'curl.exe'
      - 'certutil'
      - '-enc'
      - '-e '
      - 'DownloadString'
      - 'Start-BitsTransfer'
  condition: selection_parent and selection_child and selection_cl
falsepositives:
  - Administrators running quick one-liners from the Run dialog
  - IT provisioning scripts executed interactively
level: high
---
title: Siemens Software Center Executing from Non-Standard Path
id: 8e2b7d41-5c3a-4f96-b128-9d6e3a7c4f25
status: experimental
description: Detects Siemens Software Center binaries launched from user-writable or temporary directories instead of the legitimate Siemens installation path, consistent with DLL sideloading staging observed in active campaigns.
references:
  - https://www.securityweek.com/siemens-software-center-vulnerability-exploited-in-clickfix-malware-attacks/
  - https://attack.mitre.org/techniques/T1574/002/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.defense_evasion
  - attack.persistence
  - attack.t1574.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_name:
    Image|contains: 'Siemens'
  selection_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\AppData\Local\'
      - '\Users\Public\'
      - '\Downloads\'
      - '\ProgramData\'
  filter_legit:
    Image|startswith:
      - 'C:\Program Files\Siemens\'
      - 'C:\Program Files (x86)\Siemens\'
  condition: selection_name and selection_path and not filter_legit
falsepositives:
  - Portable Siemens tooling in engineering environments (tune to your estate's approved install paths)
level: high
---
title: Unsigned DLL Loaded by Signed Siemens Process from Application Directory
id: c41d9e27-8f3b-4a65-9d72-1b8e4f6a3c90
status: experimental
description: Detects a signed Siemens process loading an unsigned DLL from a non-system directory, indicative of DLL sideloading via directory planting.
references:
  - https://www.securityweek.com/siemens-software-center-vulnerability-exploited-in-clickfix-malware-attacks/
  - https://attack.mitre.org/techniques/T1574/002/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.defense_evasion
  - attack.t1574.002
logsource:
  category: image_load
  product: windows
detection:
  selection_image:
    Image|contains: 'Siemens'
  selection_signed:
    Signed: 'true'
  selection_dll_unsigned:
    SignatureStatus: 'unsigned'
  selection_dll_path:
    ImageLoaded|contains:
      - '\AppData\'
      - '\Users\Public\'
      - '\Downloads\'
      - '\Temp\'
  filter_system:
    ImageLoaded|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Program Files\Siemens\'
  condition: selection_image and selection_signed and selection_dll_unsigned and selection_dll_path and not filter_system
falsepositives:
  - Legitimate third-party plugins; validate signer and hash before suppressing
level: critical

The following KQL hunts the ClickFix execution chain and Siemens sideload staging in Microsoft Sentinel / Defender XDR. Run the first query broadly over the last 7–14 days, then pivot on affected hosts with the second:

KQL — Microsoft Sentinel / Defender

// Hunt 1: ClickFix-style execution — explorer spawning script interpreters with download cradles
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "explorer.exe"
| where FileName in~ ("powershell.exe", "pwsh.exe", "mshta.exe", "cmd.exe", "curl.exe", "certutil.exe")
| where ProcessCommandLine has_any ("iex", "Invoke-Expression", "Invoke-WebRequest", "iwr ", "DownloadString", "Start-BitsTransfer", "-enc", "mshta http", "certutil -urlcache", "curl http")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, SHA256, ReportId
| sort by TimeGenerated desc
;

// Hunt 2: Siemens Software Center binaries running outside the standard install path
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FolderPath has "Siemens"
| where FolderPath has_any ("\\AppData\\", "\\Users\\Public\\", "\\Downloads\\", "\\Temp\\", "\\ProgramData\\")
| where not(FolderPath startswith @"C:\Program Files\Siemens" or FolderPath startswith @"C:\Program Files (x86)\Siemens")
| project TimeGenerated, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, SHA256, InitiatingProcessFileName
;

// Hunt 3: Unsigned DLL loads into signed Siemens processes (requires MDE advanced hunting image load data via DeviceEvents or ASR/EDR telemetry)
DeviceImageLoadEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFolderPath has "Siemens" or FileName has "Siemens"
| where FolderPath has_any ("\\AppData\\", "\\Users\\Public\\", "\\Downloads\\", "\\Temp\\")
| where FolderPath endswith ".dll"
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, FileName, FolderPath, SHA256
| sort by TimeGenerated desc

For endpoint forensics with Velociraptor, this artifact sweeps for staged Siemens binaries in user-writable locations and cross-references suspicious process execution — useful for scoping blast radius after a single detection:

VQL — Velociraptor

-- Hunt for Siemens Software Center staged in user-writable paths (sideload staging)
-- and cross-reference with suspicious script interpreter execution
LET staged_binaries = SELECT FullPath, Size, Mtime
FROM glob(globs=[
  'C:/Users/*/AppData/**/*Siemens*.exe',
  'C:/Users/*/Downloads/**/*Siemens*.exe',
  'C:/Users/Public/**/*Siemens*.exe',
  'C:/ProgramData/**/*Siemens*.exe'
])

LET suspicious_procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Exe =~ 'Siemens' AND Exe =~ 'AppData|Public|Downloads|Temp')
   OR (Name =~ 'powershell|mshta|cmd|curl|certutil' AND CommandLine =~ 'iex|Invoke-WebRequest|DownloadString|certutil -urlcache|mshta http')

SELECT 'staged_binary' AS Finding, FullPath AS Detail, Size AS Size, Mtime AS Timestamp
FROM staged_binaries
UNION ALL
SELECT 'suspicious_process' AS Finding, Exe AS Detail, Pid AS Size, CreateTime AS Timestamp
FROM suspicious_procs

Use this PowerShell script to audit endpoints for staged Siemens binaries outside approved install paths and to inventory the legitimate installations you should baseline:

PowerShell

# Siemens Software Center sideload audit - run elevated via your RMM/EDR live response
$approvedPaths = @('C:\Program Files\Siemens', 'C:\Program Files (x86)\Siemens')
$searchRoots = @("$env:SystemDrive\Users", "$env:ProgramData")
$findings = @()

# 1. Find Siemens-named executables outside approved install locations
foreach ($root in $searchRoots) {
    Get-ChildItem -Path $root -Recurse -Filter "*Siemens*.exe" -ErrorAction SilentlyContinue |
        Where-Object { $p = $_.FullName; -not ($approvedPaths | Where-Object { $p.StartsWith($_) }) } |
        ForEach-Object {
            $sig = Get-AuthenticodeSignature -FilePath $_.FullName
            $findings += [PSCustomObject]@{
                Path      = $_.FullName
                Size      = $_.Length
                Modified  = $_.LastWriteTime
                SigStatus = $sig.Status
                Signer    = $sig.SignerCertificate.Subject
                SHA256    = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
            }
        }
}

# 2. Flag unsigned DLLs sitting next to any discovered executable (sideload indicator)
foreach ($f in $findings) {
    Get-ChildItem -Path (Split-Path $f.Path) -Filter "*.dll" -ErrorAction SilentlyContinue |
        ForEach-Object {
            $dllSig = Get-AuthenticodeSignature -FilePath $_.FullName
            if ($dllSig.Status -ne 'Valid') {
                Write-Warning "UNSIGNED DLL beside staged binary: $($_.FullName)"
            }
        }
}

# 3. Export results for central collection
$findings | Export-Csv -Path "$env:TEMP\siemens_sideload_audit.csv" -NoTypeInformation
if ($findings.Count -gt 0) { Write-Output "SUSPICIOUS STAGED BINARIES FOUND - review CSV and isolate host" } else { Write-Output "Clean: no Siemens binaries outside approved paths" }

Remediation

Because this campaign chains social engineering with legitimate-binary abuse, there is no single patch to deploy — remediation is layered. Prioritize in this order:

Hunt first. Run the KQL and VQL above across the last 30 days. Any host with a staged Siemens binary plus an unsigned adjacent DLL should be isolated and treated as compromised — collect memory, triage the DLL, and pivot on its network connections before reimaging.
Track vendor guidance. Monitor Siemens ProductCERT (https://cert-portal.siemens.com/productcert/) and CISA ICS advisories for any security advisory or updated Software Center release addressing unsafe library loading. If Siemens issues a hardened build that uses secure DLL loading (e.g., LOAD_LIBRARY_SEARCH_SYSTEM32 / fully qualified load paths or a signed manifest), deploy it through your standard software management process and retire older copies — including stale copies left in download caches and shares, which attackers can simply re-abuse.
Constrain ClickFix at the human and OS layer. ClickFix's entire model depends on users pasting commands into Run/terminal. Deploy awareness content showing the exact fake-CAPTCHA/fix-it lure pattern — it is distinctive and trainable. Where policy allows, disable the Run dialog for standard users via GPO (User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu), and enforce PowerShell Constrained Language Mode plus script block logging.
Harden DLL loading. Enable the Windows SafeDllSearchMode (on by default, verify it hasn't been disabled) and audit third-party software for binaries that load DLLs insecurely. Consider WDAC or AppLocker rules that (a) allow Siemens Software Center only from its canonical Program Files path with publisher signature, and (b) block child processes of Siemens update tooling unless explicitly required in your environment.
Constrain script interpreters. Apply ASR rules to block Office/script abuse patterns, restrict mshta.exe and certutil.exe outbound usage (both are common ClickFix staging tools), and alert on certutil -urlcache and mshta http command lines environment-wide — these are low-noise, high-signal in most estates.
Network egress filtering. Block or proxy direct outbound HTTP/S from workstations to uncategorized domains. ClickFix staging typically pulls payloads from freshly registered or compromised infrastructure; DNS filtering and TLS-inspecting proxies materially degrade this delivery model.
OT/ICS caution. In environments where Siemens software bridges IT and OT, do not run aggressive scripts or EDR response actions directly on engineering workstations without change control. Hunt read-only first, then coordinate isolation with operations.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Siemens Software Center DLL Sideloading Abuse in ClickFix Malware Campaigns — Detection and Remediation Guide