ConnectWise heeft na een security-incident ConnectWise reset credentials doorgevoerd. De aanleiding: ongeautoriseerde toegang tot applicatie-identiteiten die gekoppeld zijn aan Cloud Backup. Inmiddels zijn mitigaties ingezet en wordt de effectiviteit van de maatregelen gevalideerd.
Belangrijk detail: ConnectWise meldt dat er in de omgevingen die het monitort geen succesvolle dreigingsactiviteit is waargenomen. Tegelijkertijd benadrukt het bedrijf dat partners en klanten per tenant moeten beoordelen of er impact is geweest.
Wat is er gebeurd bij ConnectWise?
Het incident leidde tot ongeautoriseerde toegang tot applicatie-identiteiten die gebruikt worden binnen Cloud Backup. Daardoor heeft ConnectWise administratieve beschermingen aangescherpt en accounts en applicatiecredentials gereset, inclusief het vervangen van secrets.
De uitrol van mitigaties begon op 17 oktober om 05:00 UTC, ongeveer drie dagen nadat het incident voor het eerst werd geïdentificeerd. Daarna heeft ConnectWise een reeks containment- en herstelacties uitgevoerd.
Stappen die ConnectWise nam om het risico in te dammen
ConnectWise beschrijft de volgende maatregelen als onderdeel van de incidentrespons:
- Beïnvloede applicatieverbindingen uitschakelen en Cloud Backup opschorten.
- SaaS Security en Cloud Management ook tijdelijk schorsen uit voorzorg, omdat deze integreren met Cloud Backup.
- Onafhankelijke derde specialisten inschakelen voor incident response en remediation.
- Administratieve toegangsbescherming versterken.
- Technische richtlijnen publiceren zodat partners potentiële ongeautoriseerde activiteit in hun eigen en beheerde klantomgevingen kunnen onderzoeken.
Daarnaast ligt de focus op verificatie. ConnectWise geeft aan containment te valideren en herhaalt dat het in de door hen gemonitorde omgevingen geen succesvolle threat-activiteit heeft gezien.
Welke diensten zijn wel of niet geraakt?
ConnectWise stelt dat er geen aanwijzingen zijn voor impact op andere ConnectWise producten en services dan:
- Cloud Backup (waar het incident om draait), en
- de voorzorgssuspensies van SaaS Security en Cloud Management.
Toch zegt het bedrijf expliciet dat dit niet automatisch bewijst of individuele Microsoft 365 tenants zijn getroffen. Daarom blijft de beoordeling per tenant essentieel. Dit is ook de reden dat ConnectWise partners oproept om eigen onderzoeken te doen.
Waarom per tenant controleren nog steeds nodig is
ConnectWise waarschuwt dat het afronden van containmentsmaatregelen niet garandeert dat een tenant vrij is van ongeautoriseerde toegang. Het bedrijf adviseert daarbij om bepaalde stappen eerst te doorlopen:
- Bewijs veiligstellen vóórdat er wijzigingen worden doorgevoerd.
- Bevindingen valideren en de mogelijke operationele impact inschatten.
- Geen getroffen applicaties opnieuw verbinden totdat ConnectWise formele instructies voor herstel geeft.
Het onderwerp raakt hier nadrukkelijk aan forensische discipline: als je te snel terugschakelt, kun je sporen of logcontext verliezen en wordt triage lastiger.
Waargenomen IP’s en het type inloggedrag
Een beveiligingsbedrijf (Huntress) deelde IP-adressen die zichtbaar waren in verband met de activiteit. Volgens de update zijn password spray en mislukte loginpogingen gekoppeld aan sommige adressen waarschijnlijk niet direct gerelateerd aan de applicatie-sign-ins.
Genoemde voorbeelden:
- 144.172.64.128 — applicatie-sign-ins met een vendor credential (dit wordt gezien als een primaire vector).
- 144.172.64.99 — mislukte gebruikers password spray, geconcentreerd in de periode 10–14 oktober 2026.
- 144.172.64.60 — enkele mislukte gebruikersinlogpogingen (18 oktober 2026).
- 144.172.94.243 — brede mislukte login spray die doorloopt tegen veel organisaties.
Volgens Huntress werden bij een review van applicatie-sign-ins over meer dan 10.000 tenants alleen 144.172.64.128 en Microsoft-interne ranges gevonden als de adressen die echte applicatie-sign-in activiteit produceerden.
Geen applicatie-sign-ins vanuit andere adressen
Verder stelt Huntress dat het geen applicatie-sign-in activiteit zag vanuit andere opgesomde adressen. Die adressen bevonden zich wel in hetzelfde providerbereik als het eerder genoemde IP, maar daaruit kwamen vooral password spray en mislukte pogingen naar voren.
Hoe kan persistence zijn toegepast in een getroffen tenant?
Huntress beschrijft ook post-compromise acties in een tweede tenant. Daarbij zou de applicatie zich Global Administrator hebben gegeven en vervolgens een nieuw secret hebben toegevoegd aan een beperkte set andere applicaties. Dit lijkt gericht op het behouden van toegang (persistence).
Wat betreft het doelwit van die bevoegdheden: de onderzoekers geven aan dat het mogelijk was gebruikt voor directory-lezen via Microsoft Graph. Er zijn volgens de beschikbare informatie echter geen signalen dat de aanvallers het misbruikten voor het manipuleren van mailboxen of bestanden, of voor het wijzigen van gebruikers of policies.
Opvallend is de manier waarop de keuze voor applicaties werd gemaakt. Huntress merkt op dat de selectie van welke applicaties “in de aanval” belandden bij twee tenants in de onderzochte steekproef niet hetzelfde was. De enige constante factor leek structureel: credentials werden in applicaties geplaatst die als geregistreerd stonden binnen de getroffen tenant, zonder directe relatie met wat die apps functioneel konden doen.
Praktische aandachtspunten voor partners en beheerders
Voor wie beheert of beheerde omgevingen heeft, komt de kern neer op twee parallelle doelen: technisch herstel en verificatie. Omdat ConnectWise aangeeft dat je getroffen applicaties niet moet herverbinden zonder formele instructies, is de volgorde van acties cruciaal.
1) Onderzoek applicatie-sign-ins en afwijkend gedrag
Focus op logs rond applicatie-authenticatie. Let daarbij specifiek op sign-ins vanuit de genoemde IP’s en op patronen die lijken op token/secret misbruik. Als je meerdere tenants beheert, vergelijk dan ook binnen dezelfde periode en identificeer welke tenants afwijken.
2) Controleer op Global Administrator-toekenning en secret-wijzigingen
Omdat Huntress een modus beschrijft waarin applicaties zichzelf Global Administrator-rollen toekennen en nieuwe secrets toevoegen, is het verstandig om te verifiëren of er binnen de tenant soortgelijke wijzigingen hebben plaatsgevonden na het incidentmoment.
3) Volg de ConnectWise-richtlijnen voor herstel
ConnectWise benadrukt herstelstappen niet “op eigen gevoel” te doen. Bewaar eerst relevante evidence, valideer je bevindingen en wachtn op de formele restauratie-instructies voordat applicaties worden heractiveerd.
Als je bredere context zoekt over het omgaan met incidenten rondom cloudtoegang en account-misbruik, kan ook dit artikel helpen: Gecompromitteerde ConnectWise toegang: wat nu te doen?
Conclusie: snelle reset, maar geen “one size fits all”
Met de uitrol van mitigaties en het ConnectWise reset credentials-traject heeft ConnectWise het directe risico rond Cloud Backup ingeperkt. Cloud Backup werd geschorst en applicatieverbindingen werden uitgezet, met aanvullende voorzorgssuspensies voor SaaS Security en Cloud Management.
Toch blijft de boodschap helder: de afwezigheid van waargenomen succesvolle dreigingsactiviteit in de gemonitorde omgevingen betekent niet automatisch dat elke partner- of klanttenant veilig is. Daarom is tenant-specifieke controle essentieel, inclusief het bewaren van bewijs en het volgen van de herstelrichtlijnen.
Blijf de updates rond het herstelproces volgen en werk met een gestructureerde aanpak: onderzoek eerst, herstel daarna. Dat is de beste manier om zeker te weten dat de ongeautoriseerde toegang daadwerkelijk is geëlimineerd.
Bron: https://thehackernews.com/2026/10/connectwise-resets-credentials-as-cloud.html
