Siemens heeft bekendgemaakt dat aanvallers een kwetsbaarheid in Siemens Software Center inzetten binnen een malwarecampagne. Het gaat om CVE-2026-110936, een beveiligingslek dat is gekoppeld aan het laden van DLL-bestanden. Door de manier waarop het programma locaties voor DLL’s doorzoekt, kan een aanvaller een kwaadaardige bibliotheek plaatsen die vervolgens met de privileges van Software Center wordt uitgevoerd.
De melding is extra urgent omdat Siemens eerder wél de kwetsbaarheid publiceerde, maar pas later in detail duidelijk maakte dat er daadwerkelijk misbruik in het wild plaatsvindt. Hieronder zet ik de kernpunten op een rij en geef ik praktische aanknopingspunten om te controleren en te reageren.
Wat doet Siemens Software Center?
Siemens Software Center ondersteunt organisaties bij het downloaden, installeren, activeren en updaten van softwareproducten die klanten hebben aangeschaft. Daarnaast kan het platform ook worden gebruikt om gratis proefversies te starten. Juist omdat het een centrale schakel is in softwarebeheer, is het aantrekkelijk als doelwit: wie daar code kan laten draaien, kan potentieel verder reiken dan alleen één losse applicatie.
De oorzaak: onvoldoende beperking bij DLL-locaties
Volgens Siemens ontstaat het probleem doordat het programma niet goed beperkt waar het zoekt naar DLL-bestanden. Een geauthenticeerde lokale aanvaller kan daardoor een schadelijke DLL in een relevante map plaatsen. Als Software Center vervolgens opstart, kan de applicatie die DLL laden en uitvoeren.
Het gevolg is dat aanvallers hun code kunnen laten draaien met dezelfde rechten als Software Center. Daardoor kan de impact bij een succesvolle aanval aanzienlijk zijn, zeker op systemen waar de getroffen software actief wordt gebruikt.
CVE-2026-110936 en de patchstatus
Siemens publiceerde de kwetsbaarheid op 15 oktober via een advisory. Daarbij kreeg het lek een CVSS v4-score van 8.4. Twee dagen later volgde een update: versie 4.0.9.8 verhelpt het probleem.
Gebruikers die Software Center al hebben geïnstalleerd, ontvangen de fix automatisch bij de volgende keer opstarten van de applicatie. Dat maakt het in de praktijk relatief eenvoudig om te zorgen dat systemen niet langer kwetsbaar zijn.
Waarom het misbruik in het wild nu opvalt
In de advisory werd aanvankelijk niet expliciet gesproken over exploitatie in het echte verkeer. Siemens maakte die stap later duidelijk door op maandag extra informatie te delen en een link naar een nieuw blogbericht toe te voegen met de aanvalsbeschrijving.
Daaruit blijkt dat aanvallers een legitieme kopie van het Siemens-programma gebruikten. Die kopie had een geldige digitale handtekening. Vervolgens voegden ze zelf kwaadaardige DLL-bestanden toe, zodat het programma de door de aanvaller geleverde bestanden vanuit de eigen map kon laden.
Wat was er in eerdere versies mogelijk?
Siemens geeft aan dat met name versie 3.5.8.7 (de nieuwste release op het moment van die bevinding) deze helperbestanden niet valideerde voordat ze werden geladen. Dat betekent: zelfs als de hoofdapplicatie “legitiem” lijkt door een geldige signatuur, kan de set ondersteunende bestanden onder controle staan van de aanvaller.
Dit patroon past bij een bredere klasse aanvallen waarbij de kwaadwillende niet de signatuur van het hoofdprogramma hoeft te forceren, maar de omgeving waarin het programma vervolgens laadt.
Legitiem softwarepakket, maar kwaadaardige componenten
Siemens benadrukt dat het niet ziet dat “Siemens-systemen, -producten of -updatekanalen” zijn geschonden. Ook zegt het bedrijf dat het kwaadwillende pakket niet via de distributiekanalen van Siemens is verspreid.
Dat is belangrijke context voor defenders: het gaat hier niet om een supply-chain incident waarbij updates zijn aangepast, maar om misbruik dat plaatsvindt zodra een aanvaller lokale of procesgerichte voorwaarden kan creëren zodat Software Center de verkeerde DLL’s laadt.
Jagen op gedrag: focus niet alleen op hashes
Omdat de Siemens-bestanden in de aanval legitiem waren, adviseert Siemens om bij detectie niet uitsluitend te leunen op bestands-hashes. In plaats daarvan moeten verdedigers letten op verdacht gedrag en op de mappen die met de malware-aanpak te maken hebben.
Siemens deelt ook indicatoren van compromis (IoC’s) en signalen die kunnen wijzen op infectie. Door die combinatie te gebruiken met EDR-telemetrie en hostcontext, wordt het eenvoudiger om te bepalen wat er precies is gebeurd.
Link met Romulus ClickFix-campagne
Siemens koppelt de aanval aan Romulus, een multi-platform ClickFix-campagne. ClickFix-achtige aanvallen draaien vaak om misleidende prompts, bijvoorbeeld neppe CAPTCHA-achtige controles, die gebruikers instrueren om zelf commando’s te kopiëren en uit te voeren op hun eigen device.
Onderzoek van Forescout liet eerder zien dat het Romulus-platform meerdere malwarepayloads kan leveren. In de bevindingen werd ook een server genoemd die Siemens als distributie-infrastructuur had geïdentificeerd voor het kwaadaardige pakket met Siemens-software.
DLL-side-loading en misbruik van legitieme applicaties
Forescout meldde dat Romulus onder meer LegionLoader afleverde en ook een “trojanized installer” die een legitieme Stardock-toepassing misbruikte voor DLL-side-loading. Huntress beschreef in een latere analyse een vergelijkbaar pakket dat via rogue ChatGPT Custom GPT’s gebruikers richting ClickFix-pagina’s lokte. In die ketens werden ondertekende programma’s van andere leveranciers (eerst Canon, later Stardock) misbruikt om uiteindelijk een RAT neer te zetten.
Hoewel deze rapporten Siemens Software Center niet expliciet noemen, wijzen de gedeelde infrastructuur en het vergelijkbare side-loading principe erop dat Siemens mogelijk is toegevoegd aan hetzelfde “toolkit” of dezelfde aanpak.
Wat kun je nu doen op je omgeving?
Als je Siemens Software Center gebruikt, is het verstandig om snel te toetsen of systemen op de juiste versie draaien en of er verdachte DLL-loading of procesgedrag zichtbaar is.
- Update naar 4.0.9.8 of bevestig dat de fix automatisch is doorgekomen bij de volgende software-start.
- Controleer verdachte mappen waar helper-DLL’s terecht kunnen komen. Richt je op locaties die in advisories of threat intelligence worden genoemd.
- Onderzoek procesgedrag rondom het opstarten van Software Center: wat voor commando’s werden gestart, en welke child-processen verschijnen mogelijk onbedoeld?
- Ga niet alleen op hashes af. Als de hoofdapplicatie legitiem is, helpt hash-checking minder; gedrag en context zijn leidend.
- Gebruik EDR-signalen en koppel ze aan IoC’s. Siemens zegt threat intelligence te delen met autoriteiten en EDR-providers, dus de detectieketen kan gericht worden opgezet.
Wil je breder leren hoe defenders omgaan met kwaadaardige “legitieme” ketens en signatuurmisbruik, dan kan ook dit achtergrondstuk relevant zijn: geërfde agents en Agentforce ketens: governance faalt. Het gaat niet om Software Center, maar wél om het bredere governance- en detectieprobleem rond ketens die misleidend betrouwbaar lijken.
Snelle checklist voor incidentrespons
Onderstaande korte aanpak helpt om niet te verdwalen zodra er signalen zijn:
- Inventariseer welke hosts Software Center draaien en welke versies actief zijn.
- Markeer tijdslijnen: wanneer is Software Center voor het laatst gestart, en welke afwijkingen zie je rond die momenten?
- Zoek naar afwijkende DLL’s in de relevante mappen. Niet alleen “aanwezig”, maar ook: hoe en wanneer zijn ze geplaatst?
- Verifieer netwerk- en commandline-artifacts. ClickFix-aanvallen beginnen vaak met social engineering die daarna een commandline-beweging triggert.
Als je ook te maken hebt met andere softwareketens waar supply-chain of integratiecomponenten een rol spelen, dan is dit vergelijkbare thema mogelijk bruikbaar: Rank Math PRO gehackt via supply chain: aanpak. Ook daar draait het om het onderscheiden van legitieme distributie versus gemanipuleerde componenten.
Conclusie
Siemens Software Center is onderwerp van een kwetsbaarheid (CVE-2026-110936) die is misbruikt in een malwarecampagne. De kern is DLL-side-loading door onvoldoende restricties op DLL-locaties, waarbij aanvallers kunnen profiteren van een legitiem hoofdprogramma met geldige signatuur. De oplossing ligt bij het updaten naar versie 4.0.9.8 en bij detectie die verder kijkt dan alleen bestandshashes.
Door verdachte mappen, gedrag rond het opstarten van Software Center en EDR-telemetrie samen te nemen, kun je sneller bepalen of jouw omgeving geraakt is—en wat je als eerste moet herstellen.
