Cl0p kiest geen slachtoffers, Cl0p kiest software

Sinds 2020 heeft afpersgroep Cl0p duizenden organisaties beroofd zonder er ooit één uit te kiezen. Wat de groep wél koos, past op één regel: Accellion FTA, GoAnywhere MFT, MOVEit Transfer, de Cleo-producten, Oracle E-Business Suite, en sinds deze zomer PTC Windchill en FlexPLM. Geen bedrijven. Applicaties.

Dat klinkt als een detail uit een aanvalsrapport, maar het is een uitspraak over hoe risico zich in jouw keten gedraagt. Mijn stelling is dat leveranciersdiversificatie je risico niet spreidt zodra die leveranciers dezelfde bedrijfssoftware draaien. De vraag die telt is niet bij wie je inkoopt, maar welke applicatie daarachter draait en hoe vaak dezelfde naam terugkomt in je lijst.

De slachtofferlijst is een softwarelijst

De verse zaak laat het mechanisme in slow motion zien. PTC, maker van de PLM-software waarin fabrikanten hun product- en ontwerpdata beheren, publiceerde op 17 juni herstelstappen voor CVE-2026-12569, een fout in de verwerking van onvertrouwde data waarmee een aanvaller zonder in te loggen op afstand code kan uitvoeren, goed voor een 9,8 op de CVSS-schaal. Een dag later zette PTC de sporen erbij: webshells met namen van zestien hextekens in de loginmap van Windchill, een adres voor aansturing op afstand, een verdachte requestheader. Op 25 juni belandde het lek op de Amerikaanse lijst van actief misbruikte kwetsbaarheden, met een patchdeadline van drie dagen voor federale diensten.

Pas in de laatste week van juli werd de campagne publiek aan Cl0p gekoppeld. De aanvallers koppelen een informatielek in het WSDL-eindpunt van FlexPLM aan een fout in de loginservlet van Windchill, waarna ze ontwerp- en engineeringdata wegsluizen; ReliaQuest tekent daarbij aan dat de dader formeel onbevestigd blijft. Tussen de eerste herstelstappen en die naamgeving zit vijf weken. Vijf weken waarin elke Windchill-server die aan het internet hing dezelfde vraag beantwoordde, en niemand vroeg wie de eigenaar was.

Kijk dan naar de vorige golf van dezelfde groep. Op de afpersingssite van Cl0p stonden in november 2025 negenentwintig namen na de inbraak op Oracle E-Business Suite, waaronder Harvard University, The Washington Post, Logitech, Schneider Electric, luchtvaartmaatschappij Envoy Air en zilvermijnbouwer Pan American Silver. Onderwijs, media, randapparatuur, industriële automatisering, luchtvaart, mijnbouw. Die organisaties delen geen toeleverancier, geen markt en geen klant. Ze deelden een applicatie. Later kwam daar het cosmeticaconcern bij waar aanvallers in augustus 2025 via CVE-2025-61882 in het HR-systeem zaten, iets wat pas in juni 2026 werd bevestigd.

En dat is nog een bescheiden golf. Bij MOVEit, dezelfde groep, twee jaar eerder, telde Emsisoft 2.773 getroffen organisaties en bijna 95,8 miljoen betrokken personen, stand 28 juni 2024. Het NCSC beschrijft deze campagnes droog en precies: ze zijn opportunistisch van aard en richten zich niet op specifieke landen of sectoren, en bij Accellion FTA en MOVEit zaten er Nederlandse organisaties tussen. Er wordt niet gekozen. Er wordt gescand.

Spreiding werkt alleen als dingen los van elkaar kunnen omvallen

Diversificatie is een leenwoord uit de beleggingsleer, en daar staat de aanname er hardop bij: je spreidt over dingen die onafhankelijk van elkaar kunnen tegenvallen. Twintig aandelen dempen het risico van één slecht bedrijf. Ze dempen niets aan het risico van de index waar ze alle twintig aan hangen. Dan koop je twintig keer dezelfde beweging en noem je het een portefeuille.

Je leverancierslijst werkt precies zo. Drie ontwerppartners, twee productiepartners en je eigen engineeringafdeling zijn zes namen. Draaien vier daarvan de marktleider in PLM, dan heb je één positie in vier stukken geknipt. En ze kozen die marktleider niet toevallig: PTC ondersteunt naar eigen zeggen meer dan 30.000 klanten wereldwijd. Iedereen die rationeel inkoopt, komt bij dezelfde paar namen uit. Dat is geen slordigheid van jouw leveranciers, dat is hoe een volwassen softwaremarkt eruitziet.

Het pijnlijkst is de timing. Een continuïteitsplan leunt bijna altijd op uitwijken: valt partij A weg, dan schuift het werk naar B. Dat plan gaat er stilzwijgend van uit dat A en B om verschillende redenen omvallen. Een massa-exploitatie is het tegenovergestelde. A en B liggen in hetzelfde weekend plat, om dezelfde reden, en jouw ontwerpdata staat bij allebei in dezelfde weggesluisde map. De uitwijkroute is dan geen uitwijkroute meer, maar een tweede exemplaar van hetzelfde risico.

Dit is iets anders dan het ketenrisico waar de meeste stukken over gaan. Toen een lek in beheersoftware SimpleHelp een aanvaller zonder inloggegevens een beheerdersaccount liet aanmaken op de server waarmee een dienstverlener de IT van al zijn klanten beheert, liep de schade via één centraal punt: één gekaapte server, alle klanten eraan vast. Dat is concentratie via een knooppunt, en je kunt het tekenen. Hier is er geen knooppunt. Tussen de slachtoffers van een applicatiegolf bestaat geen enkele relatie; niemand is iemands leverancier. Precies daarom komt het in geen enkel ketenschema voor.

Je beoordeelt bedrijven, de aanvaller scant applicaties

De eenheid van je beoordeling klopt niet met de eenheid van de aanval. Een leveranciersbeoordeling is een vragenlijst over een rechtspersoon: certificering, verwerkersovereenkomst, incidentprocedure, verzekering, referenties. Al die antwoorden gaan over een bedrijf. Geen ervan vertelt je of er ergens in die keten een Windchill 12.0.2 aan het open internet hangt waarop de patch van 17 juni nog niet is geland. Dat is geen tekortkoming van de vragenlijst, het is een categoriefout.

Ik zie dat object nu voor de derde keer verschuiven. Bij Accenture was de buit toegang: 35 GB interne data met broncode, RSA- en SSH-sleutels en Azure-tokens stond te koop op een hackersforum, en het aanvalsoppervlak was niet de leverancier maar zijn accounts in jouw omgeving. Daarna schoof het naar wie er handelt: de aanvaller die Hugging Face dagenlang zocht, bleek een testmodel van OpenAI, een bedrijf zonder enige contractrelatie met het slachtoffer. Toegang, en vervolgens handelende agents. Hier is het object de applicatie zelf: dezelfde software bij tientallen partijen die niets met elkaar te maken hebben.

Dat de ingang naar die laag verschoven is, valt inmiddels ook gewoon te meten. In het Data Breach Investigations Report van Verizon over 2026 begint 31 procent van de datalekken bij een softwarekwetsbaarheid, waarmee die route gestolen wachtwoorden voorbijstreeft als meestgebruikte ingang. De voordeur is de code. Je risicoregister kent alleen de naam op de factuur.

En het antwoord veroudert razendsnel. Toen het NCSC in juli opriep tot direct patchen na tien Oracle-lekken met de maximale CVSS-score van 10,0, was dat geen bericht voor je systeembeheerder alleen: het raakte in één klap iedereen in je keten die dezelfde middleware draait. De vraag die je leveranciersgesprek mist is daarom kort. Welke van jullie applicaties die mijn data raken zijn bereikbaar vanaf het internet, en welke naam daarvan komt bij meerdere van mijn leveranciers terug? Dat is geen technische vraag. Het is een concentratievraag, en hij hoort op dezelfde plek als de vraag wie je tweede bank is.

Om eerlijk te zijn: die monocultuur is niet dom

De sterkste tegenwerping is niet dat spreiding wel werkt. Het is dat de concentratie een uitstekende reden heeft.

Begin bij het eerste punt. Diversificatie doet echt werk, alleen ander werk dan je denkt. Ze beschermt tegen wat één leverancier eigen is: een faillissement, een overname die de roadmap sloopt, een prijsverhoging, een eigen inbraak, een team dat vertrekt. Dat zijn reële risico's, en meerdere leveranciers zijn daar een verstandig antwoord op. Ik pleit nergens voor één partij.

Het tweede argument is sterker. Standaardiseren op de marktleider is meestal het veiligste wat een organisatie kan doen. PTC had binnen een dag herstelstappen klaar en publiceerde daarna zelf de webshellpaden, een bestandshash, het aanstuuradres en kant-en-klare detectieregels voor je logging. Een nichepakket met vier klanten publiceert dat nooit; daar hoor je het lek jaren later, of helemaal niet. Exotische software ruilt een bekend risico in voor een onbekend risico, en dat is zelden een goede ruil. Wie na dit stuk zijn leveranciers gaat dwingen tot drie verschillende PLM-pakketten, heeft me verkeerd begrepen.

De draai zit hier. Het probleem is niet dat de concentratie bestaat, het probleem is dat ze onzichtbaar is en daarom nergens wordt meegewogen. Een fondsbeheerder die de index volgt weigert de index niet. Hij weet alleen dat hij hem heeft, en hij richt zijn buffers daarop in. Jij weet het niet. Je hebt zes leveranciers op papier en één applicatie in de praktijk, en je noodplan is geschreven alsof dat zes onafhankelijke uitkomsten zijn.

Twee lijsten die niet over hetzelfde gaan

Je risicoregister bevat namen van bedrijven. De lijst waar een afpersgroep uit werkt bevat namen van software. Zolang die twee lijsten niet over hetzelfde object gaan, is elke geruststelling die je uit de eerste haalt in het gunstigste geval toeval.

Het aangename is dat dit probleem kenbaar is. Een kwetsbare applicatie die vanaf het internet bereikbaar is, is geen abstract dreigingsbeeld maar een regel in een inventarisatie, en zulke regels laten zich tellen. Wie ze telt, ziet meestal binnen een middag hoe vaak dezelfde naam terugkomt achter verschillende leveranciers. Dat is geen prettig plaatje, maar het is wel het echte plaatje, en je kunt er een noodplan op bouwen dat klopt.

Spreiden is pas spreiden als de dingen onafhankelijk kunnen omvallen. Verdeel je alleen de namen en niet de code eronder, dan heb je hetzelfde risico drie keer gekocht. En je betaalt er ook drie keer voor.