Siemens meldt dat criminelen een Siemens Software Center kwetsbaarheid actief inzetten in een malwarecampagne. Het gaat om een probleem in software die voor klanten zorgt voor downloaden, installeren, activeren en updaten van aangeschafte (en ook proef)software. Op basis van de beschrijving is het scenario niet puur theoretisch: Siemens voegde na eerdere bekendmaking een update toe waarin in-the-wild misbruik werd aangegeven.
De kern van het risico is dat het programma onvoldoende begrenst waar het naar DLL-bestanden zoekt. Daardoor kan een aanvaller op een lokaal systeem een kwaadaardige DLL plaatsen in een map die door Software Center wordt doorzocht, met als gevolg dat die code wordt uitgevoerd met dezelfde privileges als de applicatie.
Wat doet Siemens Software Center en waar zit het lek?
Siemens Software Center is in de praktijk een schakel tussen de klant en de softwareproducten van Siemens. Het beheert onder meer het downloaden, installeren en updaten van producten die klanten hebben gekocht, en kan daarnaast worden gebruikt om een gratis proefperiode te starten.
De kwetsbaarheid krijgt de identificatie CVE-2026-110936. Volgens Siemens ontstaat het probleem doordat Software Center niet goed restricties toepast op locaties waar het naar DLL’s zoekt. In zo’n situatie kan een geauthentiseerde lokale aanvaller (dus: iemand met toegang tot het systeem) een kwaadaardige DLL neerzetten in een relevante map.
Als Software Center vervolgens wordt gestart, kan het de helperbestanden laden die door de aanvaller zijn aangeleverd. Daardoor draait de aanvalscode in de context van het legitieme programma.
Hoe ziet de aanval eruit: legitiem programma + kwaadaardige DLL
Siemens beschrijft dat de aanvallers niet simpelweg “een aangepast installatietool” verspreiden. In plaats daarvan koppelden ze een legitieme kopie van Siemens Software Center (met een geldige digitale handtekening) aan eigen, schadelijke DLL-bestanden.
Het cruciale punt is dat het programma bij opstart de DLL’s uit een map binnen zijn eigen installatielocatie laadt. Als daar kwaadaardige varianten staan die door de aanvaller zijn geplaatst, kan de code worden uitgevoerd.
Siemens merkt daarbij op dat een oudere versie die op dat moment actueel was (versie 3.5.8.7) de helperbestanden niet valideerde voordat ze werden geladen. Dat wijst erop dat de beveiliging in die eerdere implementatie tekortschiet.
Wanneer is het opgelost en hoe werkt de update?
Siemens publiceerde de technische informatie over de kwetsbaarheid op 15 oktober via een advisory. In die advisory kreeg de kwetsbaarheid een CVSS v4-score van 8.4. Twee dagen later volgde een update: de oplossing zat in versie 4.0.9.8.
Voor systemen waarop de applicatie al is geïnstalleerd, geldt volgens Siemens dat de fix automatisch wordt toegepast zodra de gebruiker Software Center opnieuw start. Met andere woorden: je hoeft niet per se een handmatige vervanging uit te voeren, maar je moet wél zorgen dat de applicatie daadwerkelijk opnieuw draait.
Het praktische advies is dan ook om direct te verifiëren dat je omgeving de beoogde versie gebruikt, of dat de updatecyclus is afgerond bij de eerstvolgende start.
Waarom Siemens waarschuwt voor “gedrag” in plaats van alleen hashes
Een belangrijke nuance in Siemens’ communicatie is dat de aanvallers een legitiem bestand gebruikten dat geldig ondertekend is. Daardoor is het op basis van bestands-hashes lastig om de aanval eenduidig te detecteren, omdat de kerncomponent (het programma) niet is gemanipuleerd op een manier die je eenvoudig met IOC-hashes kunt blokkeren.
Siemens adviseert verdedigers daarom om zich te richten op verdacht gedrag en op de mappen die door de malware worden misbruikt, in plaats van alleen te vertrouwen op file hashes.
Siemens deelt bovendien indicatoren van compromis (IoC’s) en signalen die kunnen wijzen op infectie. Omdat de aanval draait rond het laden van kwaadaardige helper-DLL’s, is het vooral relevant om te kijken naar abnormale laadpatronen, onverwachte wijzigingen in specifieke mappen en afwijkende procesactiviteiten rond het opstarten van Software Center.
Koppeling met ClickFix: Romulus in de achtergrond
Siemens koppelt de aanval aan Romulus, een campagne die valt onder ClickFix-achtige technieken. Bij dit type aanval gebruiken criminelen vaak misleidende prompts, bijvoorbeeld nep-checks zoals valse CAPTCHA-achtige meldingen, die gebruikers ertoe aanzetten om zelf commando’s te kopiëren en uit te voeren op hun toestel.
Eerder onderzoek wees op een ClickFix-leveringsplatform dat verschillende payloads kan serveren. Daarbij werd het framework ook actief aangetroffen op meerdere servers, waaronder een server die Siemens identificeert als distributiepunt voor het pakket dat Software Center misbruikt.
In dat bredere onderzoek werd ook melding gemaakt van de levering van malwarevarianten, waaronder een LegionLoader-achtige component en een “trojanized installer” die profiteert van DLL side-loading met een legitieme Stardock-applicatie. Niet elk detail hoeft exact samen te vallen met deze Siemens-specifieke route, maar de overeenkomst in techniek (side-loading en het misbruik van legitieme componenten) maakt het aannemelijk dat er overlap is in tooling.
Overigens is niet duidelijk wie Romulus beheert. Onderzoekers noemen meerdere mogelijke scenario’s, zoals een intern tool, verkoop als service, een affiliate-model of kopieën van software door verschillende actoren.
Wat betekent dit voor organisaties? Een praktische aanpak
Als je Siemens Software Center in je omgeving gebruikt, is het doel nu helder: voorkom dat kwaadaardige DLL’s in relevante mappen terechtkomen én zorg dat systemen de patch hebben. Omdat het om een scenario gaat met geauthenticeerde lokale toegang, helpt ook een bredere kijk op hardening en gebruikersrechten.
1) Patch en verifieer de versie
De oplossing ligt in Software Center 4.0.9.8. Controleer of de update daadwerkelijk is doorgevoerd zodra de toepassing opnieuw is gestart. Neem daarna eventuele herhaalstarts mee als gebruikers of processen Software Center regelmatig gebruiken.
2) Controleer verdachte mapactiviteiten
Omdat het misbruik draait om het plaatsen en laden van DLL’s, is het checken van de mappen die Software Center doorzoekt een logische stap. Let op onverwachte wijzigingen, nieuwe of gewijzigde DLL’s in specifieke submappen en afwijkende toegangspatronen.
3) Let op gedrag rond opstart en procesketens
Siemens raadt gedragsgestuurde detectie aan. Dat betekent: kijk naar ongewone procesactiviteiten zodra Software Center start, naar procesrelaties die niet passen bij normale bedrijfssoftware, en naar eventuele child-processes of module-load events die een extra aanwijzing vormen.
4) Gebruik EDR-telemetrie, niet alleen bestandsindicatoren
Omdat het legitieme programma mogelijk intact blijft, is alleen “hash-based” blokkeren niet voldoende. Combineer IoC’s met context: processtart, module laden, maplocaties en tijdlijn. Dat verkleint de kans dat je de aanval mist omdat de hoofd-binaire file niet is aangepast.
Vergelijkbare incidenten en detectielessen
Deze casus sluit aan bij bredere patronen waarbij legitieme software of ondertekende componenten worden misbruikt voor misleiding en uitvoering via side-loading. Als je je organisatiebrede aanpak wilt versterken, kan het helpen om ook te kijken naar andere beveiligingscases waarbij gedrag en privilege-context centraal stonden.
Bijvoorbeeld: bij gecompromitteerde login bij ETS lag de nadruk op herstel en het beperken van schade na ongeautoriseerde toegang. Hoewel het aanvalstype anders is, passen de “snelle beperking + herstel van vertrouwen”-lessen goed bij de mindset die je ook bij deze Siemens-casus nodig hebt.
Daarnaast tonen meldingen zoals Plex2Shell aan dat na bekendmaking de kans op misbruik kan toenemen. Ook daar geldt: zorg dat je patch- en detectiestrategie direct meebeweegt zodra er signalen komen dat aanvallen al in het wild plaatsvinden.
Conclusie
De Siemens Software Center kwetsbaarheid (CVE-2026-110936) wordt volgens Siemens actief misbruikt via ClickFix-gerelateerde malwarecampagnes. De aanval gebruikt een legitiem, ondertekend Siemens-programma en combineert dat met kwaadaardige DLL’s die het programma vervolgens laadt, wat kan leiden tot code-uitvoering met dezelfde rechten als Software Center.
De oplossing zit in versie 4.0.9.8. Tegelijk benadrukt Siemens dat detectie niet alleen op hashes moet steunen, maar vooral op verdachte mappen en afwijkend gedrag rond het laden en uitvoeren van bestanden. Wie vandaag patcht, mapactiviteiten monitort en EDR-context gebruikt, verkleint de kans op succesvolle compromittatie aanzienlijk.
2 reacties