Als een leveranciershack jouw hack wordt
Een gestolen credential bij een cloudbackupleverancier gaf aanvallers een route naar binnen bij duizenden bedrijven die zelf niets fout hadden gedaan. Wat er gebeurde, waarom het telt voor elk mkb dat op cloudsoftware draait, en wat je zelf kunt beheersen.
De meeste securityadviezen veronderstellen dat de aanvaller via jouw systemen komt: een verouderde plugin, een zwak wachtwoord, een ontbrekende header. Deze week liet een ander pad zien, en het is het pad waarop kleine bedrijven het meest kwetsbaar zijn. Aanvallers braken niet in bij hun slachtoffers. Ze liepen naar binnen via een deur die de meeste slachtoffers niet eens kenden: een applicatierecht dat ooit aan een softwareleverancier was verleend.
Wat er bij ConnectWise gebeurde
ConnectWise is een groot IT-beheerbedrijf. Een van zijn producten, Cloud Backup (voorheen bekend als SkyKick), wordt door IT-dienstverleners gebruikt om de Microsoft 365-data van hun klanten te back-uppen: mailboxen, bestanden, Teams en directorydata. Om dat werk te kunnen doen houdt de applicatie in elke organisatie waar hij is geïnstalleerd zeer brede rechten.
Een uiterst gevoelige applicatiecredential kwam in vijandige handen. Daarmee konden aanvallers zich authenticeren als de applicatie zelf. Geen wachtwoord, geen multi-factor-prompt, geen phishing-e-mail: een machine-to-machine-aanmelding die er voor het platform uitzag als de legitieme backupdienst die zijn werk deed.
Microsoft schrijft de campagne toe aan Storm-0940, een aan China gelieerde threat actor. Wat daarna gebeurde laat zien waar aanvalsgereedschap naartoe gaat: de groep gebruikte een open-source agentic-AI-framework (ARTEX) om aanmeldpogingen te doen bij meer dan 2.250 Microsoft 365-tenants, met een piek van rond de 2.900 pogingen per minuut. In sommige gevallen, meldt Microsoft, hadden de aanvallers minder dan drie uur binnen drie uur na de eerste aanval op een slachtoffer al bevoorrechte cloudtoegang. Securitybedrijf Huntress bevestigde ongeautoriseerde aanmeldingen in 173 tenants. ConnectWise nam de backupdienst op 17 oktober offline en het onderzoek loopt nog.
De reikwijdte van de toegang is het deel waar elk bedrijf even bij stil moet staan: de gecompromitteerde applicatie kon e-mail, bestanden en directorydata lezen. In sommige tenants gingen de aanvallers verder: ze veranderden applicatiecredentials en roltoewijzingen om een achterdeur te achterlaten die het opruimen van het oorspronkelijke incident kan overleven.
Waarom één leveranciersleutel duizenden deuren opent
Bedrijven besteden jaren aan het verharden van menselijke logins: wachtwoordbeheerders, multi-factor authenticatie, conditional access. Maar third-party applicaties authenticeren zich als applicatie. Ze werken met applicatierechten, niet met wachtwoorden, en ze passeren geen MFA-scherm. Een toestemming die ooit, misschien jaren geleden, werd verleend, blijft werken tot iemand haar actief intrekt.
Dat is de structurele les van dit incident. Je securityhouding is niet alleen de som van je eigen controles. Ze omvat elk stuk software dat ooit toegang tot je omgeving kreeg, en de beveiliging van het bedrijf achter elk daarvan. Geen van de getroffen organisaties koos ervoor aangevallen te worden, en de meeste hadden de interne credential-afhandeling van de leverancier niet kunnen inspecteren, zelfs als ze dat gewild hadden.
Hetzelfde patroon, in elke branche
Dit is geen geïsoleerd verhaal. Dagen na de ConnectWise-onthulling meldde het Koreaanse softwarebedrijf Duzon Bizon, waarvan de boekhoud- en belastingproducten door zo'n 110.000 kleine en middelgrote bedrijven worden gebruikt, een eigen datalek: aanvallers kwamen binnen via het VPN-account van één medewerker, en de gegevens op risico omvatten salarisadministratie, verkoop- en belastinggegevens van de kleine bedrijven die van de software afhankelijk zijn.
De gemene deler is concentratie. Kleine bedrijven draaien op een handjevol leveranciers: boekhoudsoftware, backups, hosting, een IT-leverancier. Hack één leverancier en je bereikt duizenden mkb-bedrijven tegelijk, die allemaal software vertrouwen die ze niet kunnen auditen. Voor een aanvaller is dat hefboomwerking die geen enkel individueel klein bedrijf ooit kan bieden.
Wat je werkelijk kunt beheersen
Je kunt de infrastructuur van je leverancier niet patchen. Vier dingen staan binnen je bereik, en ze sluiten direct aan op wat er deze week gebeurde:
- Weet welke apps toegang hebben. Leg een inventaris aan van third-party applicaties die aan je Microsoft 365- of Google Workspace-omgeving zijn verbonden, inclusief de rechten die ze hebben. Verwijder wat je niet meer gebruikt: een integratie die je een jaar geleden liet vallen, kan vandaag nog volledige rechten hebben.
- Verleen minimale privileges en behandel leveranciersintegraties als privileged accounts. Minimale rechten, periodieke toegangsreviews en een geteste manier om toegang snel in te trekken. Als een leverancier je mailboxen moet kunnen lezen, verdient die verbinding dezelfde aandacht als een adminaccount.
- Stel je kritieke leveranciers de harde vragen vóórdat je ze nodig hebt. Hoe beschermen ze de credentials die met jouw omgeving verbinden? Verplichten ze zich om je na een datalek in te lichten, en hoe snel? Wat is hun incidenthistorie? Deze vragen worden normaal in inkoop, en NIS2 maakt ketenbeveiliging een expliciet onderdeel van de risicobeheerplicht voor getroffen organisaties.
- Bewaak je leveranciers van buitenaf. Je kunt niet in de cloud van een leverancier kijken, maar je kunt hun publieke houding volgen. Een verlopen TLS-certificaat, een plotselinge DNS-wijziging of een blocklist-vermelding bij een kritieke leverancier zijn vroege signalen dat er aan hun kant iets mis is, en dat zijn precies de signalen die een externe monitor voor je kan opvangen.
Hoe Noroshi helpt
Met supplier-monitoring van Noroshi registreer je de domeinen van de leveranciers waar je bedrijf van afhankelijk is, en elk daarvan wordt continu gecontroleerd: securityheaders, TLS-certificaat, DNS-houding en abuse-blocklists, met alerts zodra er iets verandert. Het geeft een early-warning-beeld van de bedrijven achter je bedrijfsvoering, en gedocumenteerd bewijs voor ketenreviews, inclusief de NIS2-hoek.
We zijn duidelijk over de grenzen: geen enkele externe monitor had deze specifieke credential-diefstal kunnen voorkomen, en dat doen we ook niet voorkomen. Wat supplier-monitoring je geeft, is zicht op de risico's die je wel van buitenaf kunt zien, en een onderhouden, bewijsklaar beeld van wie je kritieke leveranciers werkelijk zijn. Die inventaris is de eerste vraag die elke auditor, verzekeraar en incidentresponder zal stellen.
Zet supplier-monitoring voor je bedrijf aan →
Vragen en antwoorden
Hoe weet ik of mijn organisatie getroffen is door het ConnectWise-incident?
Alleen als je organisatie ConnectWise Cloud Backup gebruikt (voorheen SkyKick), meestal geïnstalleerd door je IT-leverancier. Vraag het je MSP of controleer het Microsoft Entra-beheercentrum op de getroffen enterprise-applicaties. Microsoft adviseerde getroffen organisaties die verbindingen uitgeschakeld te houden tot er herstelinstructies zijn, en de aanmeldactiviteit te herzien van half oktober terug tot het begin van de maand, voor zover de logs dat toelaten.
Beschermt multi-factor authenticatie tegen dit soort aanvallen?
In dit geval niet. De aanvallers phishten geen wachtwoord en omzeilden geen MFA-prompt: ze meldden zich aan als de leveranciersapplicatie zelf, met een gestolen applicatiecredential. MFA beschermt menselijke logins. Rechten van third-party apps zijn een apart aanvalsoppervlak dat zijn eigen review nodig heeft.
Hoe zie ik welke third-party apps toegang hebben tot onze Microsoft 365 of Google Workspace?
In Microsoft 365 kan een beheerder enterprise-applicaties opvragen in het Entra-beheercentrum, inclusief de rechten die elke app heeft. In Google Workspace toont de beheerconsole toegang van third-party apps onder de securityinstellingen. Beide verdienen periodieke review: verwijder wat je niet meer gebruikt en verklein brede rechten waar dat kan.
Geschreven door David Hildering, de engineer achter Noroshi. Meer over Noroshi.