ConnectWise zet stappen om schade te beperken na een cyberaanval waarbij een gecompromitteerde login werd misbruikt. Het bedrijf onderzoekt ongeautoriseerde toegang tot applicatie-identiteiten binnen zijn Cloud Backup-omgeving en heeft vervolgens meerdere cloudservices tijdelijk stilgezet. Voor MSP’s en klanten betekent dit dat back-ups en beheertaken tijdelijk kunnen vastlopen.
In dit artikel zetten we op een rij wat er bekend is over de aanval, welke onderdelen zijn stopgezet, en waar je als organisatie extra op moet letten in je Microsoft 365-omgeving.
Wat er gebeurde: misbruik van applicatie-identiteit
ConnectWise geeft aan dat het ongeautoriseerde toegang heeft gevonden tot applicatie-identiteiten in de ConnectWise Cloud Backup-omgeving. Als beschermingsmaatregel werd de Cloud Backup-service (eerder bekend als SkyKick) uitgeschakeld voor application access.
Daarna besloot ConnectWise ook SaaS Security en Cloud Management te stoppen. Het bedrijf benadrukt dat de backups versleuteld blijven en beschermd, en dat er (voor zover bekend) geen aanwijzingen zijn dat de backupdata zelf is aangeraakt. Tegelijkertijd kan de containmaatregel wel impact hebben op geplande backups, archieftoegang en restores.
Welke services zijn stilgezet en wat is de impact?
ConnectWise kondigde aan dat het meerdere services heeft uitgeschakeld om de situatie te beheersen en mitigaties door te voeren. Volgens de beschikbare informatie geldt dat de maatregelen doorwerken in meerdere dagelijkse processen.
- Cloud Backup: de service is uitgeschakeld; geplande backups kunnen worden onderbroken en restores/archiefacties kunnen vertraging oplopen.
- SaaS Security: monitoring en alerting kunnen (tijdelijk) beperkt of uitgeschakeld zijn.
- Cloud Management: ook onderdelen rond user- en licentiebeheer worden geraakt door de containmaatregel.
ConnectWise heeft geen hersteltijdlijn gedeeld. Wel heeft het informatie verschaft over de gebruikte IP-adressen en publiceerde het guidance voor het naleven van checks in Microsoft 365-omgevingen van MSP’s.
De rol van de gecompromitteerde login
Volgens een analyse door Huntress werd een gecompromitteerde Cloud Backup-credential gebruikt om Microsoft 365 tenants te benaderen op 15 oktober. Daarbij merkte Huntress op dat de identiteit in Microsoft’s eigen sign-in logs terugkomt in elke betrokken tenant.
Het gaat specifiek om een credential type dat een client assertion betreft. Dat betekent dat het credential in de eigen tenant van de vendor leeft en niet door acties van klanten in hun omgeving is gegenereerd. Met andere woorden: de signalering wijst niet op een “klant-initiatief” maar op misbruik van een vendor-credential.
Toegang op grote schaal en misleidende “succes”-signalen
Huntress stelt dat de aanval zich in het begin kenbaar maakte via activiteiten vanuit hetzelfde IP-adres. Op 17 oktober was er volgens de onderzoeker sign-in activiteit gezien in bijna 1.000 Entra tenants, met meer dan 300 succesvolle sign-ins.
Belangrijk detail: een succesvolle sign-in betekent niet automatisch dat ook daadwerkelijke toegang tot de relevante ConnectWise service mogelijk was. In tenants waar de bijbehorende ConnectWise service principal niet aanwezig was, konden aanvallers niet “landen” binnen het benodigde access-model.
Dit verklaart waarom de impact per tenant kan verschillen, zelfs wanneer de externe sign-in logs op het eerste gezicht overeenkomen.
Wat er in tenants is waargenomen
In één van de customer tenants observeerde Huntress dat een ConnectWise Cloud Management app voor Microsoft Teams zichzelf toevoegde aan de Global Administrator-rol op 15 oktober. Vervolgens werd een Python-script uitgevoerd dat nieuwe client secrets toevoegde aan een MSP-managementapp en aan een eigen toepassing van Huntress.
Die wijzigingen vonden ongeveer tweeënhalf uur plaats vóór de eerste sign-ins vanuit het IP-adres van de aanvaller. Daarbij kwam de toegang niet rechtstreeks uit hetzelfde netwerkpad als het IP, maar via het interne Microsoft cloudnetwerk. Huntress zegt dat het deze twee fases niet één-op-één aan dezelfde actor of operator heeft gekoppeld.
Daarnaast noemt Huntress dat de actor zich bewoog tussen tenants in volgorde van GUID’s, met seconden ertussen. Dat patroon past bij het gebruik van een script dat een doellijst afloopt.
Naast Microsoft 365: mogelijke misbruik van Graph tokens
Volgens Huntress werd de gecompromitteerde app-credentie gebruikt om Microsoft Graph tokens te verkrijgen in klanttenants vanuit een specifiek IP-adres. De activiteit vond plaats tussen 06:13 en 08:34 UTC op 15 oktober.
ConnectWise geeft aan dat het de aanval heeft gestopt en dat de benodigde applicaties zijn uitgeschakeld. Toch benadrukt de situatie één kernpunt: stoppen van de aanval is niet hetzelfde als uitsluiten dat er al veranderingen in configuraties zijn aangebracht of dat er persistence is opgebouwd.
Waarom herstel lastig kan zijn (en wat dat betekent voor jou)
Een van de risico’s in dit soort incidenten is dat organisaties verkeerd inschatten hoe herstel werkt. Volgens een security strategy VP van CoreView hebben veel IT-leiders het misverstand dat Microsoft automatisch hun configuration terugzet of “meeneemt” in backups. Juist daardoor kan herstel na een tenantwijziging complex worden.
Concreet betekent dit: ook als data versleuteld is en backups in de kern nog aanwezig zijn, kan een aanvaller wel rollen, app-registraties of secrets hebben aangepast. Dat vraagt om gerichte tenantcontroles.
Praktische checklist: waar je Microsoft 365 op controleert
ConnectWise heeft richtlijnen gepubliceerd voor het beoordelen van Microsoft 365-omgevingen. Als leidraad voor je eigen response kun je denken aan de volgende stappen.
- Bekijk sign-in activiteiten in Microsoft Entra ID: let op tijdvakken rondom 15–16 oktober en op sign-ins die passen bij vendor-applicaties.
- Controleer app-rollen en permissies: is een ConnectWise gerelateerde app of een vergelijkbare service principal toegevoegd aan hoge rollen zoals Global Administrator?
- Scan voor nieuwe secrets en credential updates: detecteer of er nieuwe client secrets zijn toegevoegd aan MSP- of vendor-gerelateerde toepassingen.
- Valideer of de betreffende ConnectWise service principals nog nodig zijn en of ze overeenkomen met de beoogde inrichting.
- Controleer persistence: zoek naar ongebruikelijke configuratie-aanpassingen die na het begin van de aanval mogelijk zijn doorgevoerd.
Werk daarbij bij voorkeur met een vast proces: documenteer bevindingen per tenant, prioriteer high-privilege wijzigingen en stem af met je MSP- of security team.
Vergelijkbare incidenten: leer van eerdere signalen
Dit incident past in een bredere trend waarbij aanvallers niet “gewoon” inloggen, maar misbruik maken van credentials en applicatie-identiteiten binnen cloudomgevingen. Als je wilt vergelijken met andere aanvallen waarbij account- of identiteitstoegang centraal staat, lees ook:
- gecompromitteerde login bij ETS — een voorbeeld van hoe gestolen of misbruikte toegang kan escaleren.
- Contextuele cybersecurity: van losse alerts naar actie — helpt bij het omzetten van logsignalen naar concrete vervolgstappen.
Conclusie
ConnectWise heeft cloudservices tijdelijk stilgezet na misbruik van een gecompromitteerde login die leidde tot ongeautoriseerde toegang tot Microsoft 365 tenants via vendor-applicatie-identiteiten. Hoewel het bedrijf aangeeft dat backups versleuteld en beschermd blijven, kan de containmaatregel invloed hebben op backups, monitoring en cloudmanagement.
Voor organisaties is de volgende stap cruciaal: verifieer in je tenant of er configuratiewijzigingen zijn doorgevoerd of persistence is ontstaan. Alleen zo sluit je uit dat stoppen van de aanval ook daadwerkelijk herstel mogelijk maakt.
Bron: https://www.securityweek.com/connectwise-suspends-cloud-services-in-response-to-cyberattack/
3 reacties