ConnectWise-angrepet: AI-agenter angrep 2 250 Microsoft 365-miljøer

ConnectWise-angrepet ga et Kina-tilknyttet hackerteam en betrodd vei inn mot mer enn 2 250 Microsoft 365-miljøer. Deretter brukte angriperne AI-agenter til å prøve stjålne appidentiteter i nesten 3 000 innloggingsforsøk i minuttet. I flere berørte miljøer gikk aktiviteten videre til kartlegging og forsøk på å skaffe varig, privilegert tilgang.

Dette er ikke historien om en chatbot som plutselig lærte seg å hacke. Angriperne hadde fått kontroll over identitetene til flere ConnectWise-applikasjoner som kundene allerede stolte på. AI-verktøyet ARTEX lot dem misbruke den tilliten raskere, bredere og mer systematisk enn et menneske kunne gjort manuelt.

Det er alvorlig nok uten å overdrive. Microsoft dokumenterer at angriperne forsøkte å nå over 2 250 miljøer, men understreker samtidig at en berørt app eller en vellykket innlogging ikke i seg selv beviser at data ble lest eller hentet ut. ConnectWise sier per 23. oktober at selskapet ikke har funnet tegn til at selve backup-arkivene er kompromittert. Hvert kundemiljø må likevel granskes separat.

Hva skjedde i ConnectWise-angrepet?

Angriperne fikk uautorisert tilgang til appidentiteter knyttet til ConnectWise Cloud Backup, tidligere kjent som SkyKick. Disse identitetene ble brukt til å koble ConnectWise-tjenester til kundenes Microsoft 365-miljøer. Når en slik identitet allerede har fått tillatelse, kan den autentisere som en betrodd applikasjon uten at en vanlig bruker logger inn interaktivt.

Microsoft knytter angrepet til Storm-0940, en Kina-tilknyttet aktør som har vært aktiv siden 2021 og driver med datatyveri. Gruppen har tidligere brukt passordspraying, sårbare nettjenester og OAuth-applikasjoner for å komme inn og beholde tilgang i skymiljøer.

ConnectWise oppdaget problemet 14. oktober og publiserte den første meldingen 16. oktober. Selskapet suspenderte Cloud Backup, SaaS Security og Cloud Management, nullstilte kontoer og innloggingsopplysninger i det berørte miljøet og begynte deretter en kontrollert gjenoppretting. Per 23. oktober skulle testing og sikkerhetsvalidering etter planen fullføres i løpet av helgen, før funksjoner gradvis kunne åpnes igjen.

Dette er et forsyningskjedeangrep i praksis. Angriperen trenger ikke bryte seg gjennom ytterveggen hos 2 250 virksomheter én etter én hvis én leverandørforbindelse allerede har adgang. Når den forbindelsen i tillegg kan operere på tvers av mange kunder, blir én stjålet appidentitet en hovednøkkel med altfor mange dører foran seg.

Hvordan brukte angriperne AI-agenter?

Storm-0940 brukte ARTEX til å automatisere kartlegging, passordspraying og misbruk av OAuth-applikasjoner. ARTEX er et open source-rammeverk for penetrasjonstesting der flere LLM-drevne agenter kan arbeide fra innledende kartlegging til datauthenting med lite menneskelig innblanding. Rammeverket kan bruke forskjellige AI-modeller og bygger opp en graf over systemer, tilganger og svakheter underveis.

Etter at angriperne hadde kontroll over ConnectWise-identitetene, lot de agentene prøve tilgang mot mer enn 2 250 kundemiljøer. Microsoft målte over 200 innlogginger på under fire minutter og en topp på over 2 900 forsøk i minuttet. Det er denne farten som endrer forsvarssituasjonen: Et varsel kan være korrekt, men hendelsen kan allerede ha flyttet seg flere steg videre før noen rekker å åpne saken.

I noen miljøer fortsatte aktiviteten gjennom Microsoft Graph. Angriperne kartla katalogen, endret app-legitimasjon og forsøkte å påvirke identiteter, grupper og privilegerte roller. Slike endringer kan gi en ny bakdør som overlever selv om den opprinnelige ConnectWise-forbindelsen blir stengt.

Microsoft beskriver også separate ARTEX-drevne angrep der Storm-0940 fikk privilegert skytilgang på under tre timer. Siden september har gruppen brukt rammeverket mot hundrevis av virksomheter innen blant annet forsvar, energi, finans, myndigheter, industri, programvare og teknologi. ConnectWise-hendelsen er derfor ikke en isolert demonstrasjon. AI-agentene er tatt inn i en eksisterende offensiv arbeidsflyt og brukt operativt.

Hvor mange virksomheter ble faktisk kompromittert?

Mer enn 2 250 Microsoft 365-miljøer ble forsøkt nådd, men det er ikke det samme som at 2 250 virksomheter ble fullt kompromittert. Microsoft fant vellykkede innlogginger og videre aktivitet i flere kundemiljøer, men har ikke offentliggjort et samlet tall for bekreftede datainnbrudd. Flertallet av målene i den bredere Storm-0940-kampanjen ble ikke kompromittert.

Det samme skillet gjelder den store passordsprayingen fra 10. til 14. oktober. Microsoft registrerte mer enn 151 000 mislykkede innlogginger mot 327 kontoer i åtte organisasjoner. Nesten 98 prosent av svarene var kontolåsinger, og Microsoft observerte ingen vellykket autentisering, token-utstedelse, Graph-kall eller katalogendring fra akkurat denne delen av kampanjen.

TechCrunch beskrev saken som spionasje mot tusenvis av selskaper. Det er en skarp overskrift, men primærkildene er mer forsiktige. En vellykket appinnlogging kan gi tilgang til e-post og filer, og Storm-0940 har historikk med slik datauthenting. Likevel sier Microsoft uttrykkelig at verken tilstedeværelsen av appen eller autentisering alene beviser at kundedata ble åpnet eller stjålet.

ConnectWise sier at eksisterende backup-arkiver er krypterte, isolerte og bevart uten tegn til kompromittering. Selskapet har heller ikke funnet tegn til at andre ConnectWise-produkter er berørt. Det frikjenner ikke de enkelte Microsoft 365-miljøene, for eventuell tilgang og uthenting der må undersøkes i deres egne logger.

Hvorfor er leverandørtilliten viktigere enn modellnavnet?

AI-agenten skapte ikke tilliten som ble misbrukt. Den gjorde misbruket raskt nok til at forsvarerne fikk svært liten reaksjonstid. Den avgjørende sikkerhetssvikten var at kompromitterte appidentiteter allerede hadde rettigheter på tvers av mange kundemiljøer.

Det er lett å stirre seg blind på ARTEX fordi «AI-agent hacket tusenvis» er en bedre overskrift enn «for vide OAuth-tillatelser fikk alvorlige følger». Men det siste er lærdommen virksomheter faktisk kan bruke. Agenten kunne byttes ut med et annet rammeverk eller en samling scripts. En betrodd flerbrukerapplikasjon med brede tillatelser ville fortsatt vært en svært attraktiv inngang.

Jeg mener denne hendelsen bør fjerne den siste tvilen om at agentisk AI allerede har praktisk betydning for cyberangrep. Ikke fordi modellen fant opp en ny form for hacking, men fordi den kunne kjøre kjente teknikker kontinuerlig, prøve flere veier samtidig og følge opp et funn i maskinfart. Forskjellen mellom «vi fikk et varsel» og «vi rakk å stoppe angrepet» blir mindre for hver automatiserte handling.

Det samme tillitsproblemet dukker opp når AI-agenter får API-nøkler og tilgang til skytjenester. Jeg har tidligere skrevet om hvordan 1,5 millioner API-nøkler ble stjålet fra AI-agenter på én uke. Nøkkelen eller appidentiteten er ikke bare en teknisk detalj. Den representerer alle handlingene eieren har lov til å utføre.

Hva bør ConnectWise-kunder gjøre nå?

Berørte ConnectWise-forbindelser skal fortsatt være avslått til ConnectWise gir formell beskjed om gjenåpning for den aktuelle tjenesten. Ikke slett enterprise-applikasjonene som første tiltak. Microsoft anbefaler å bevare konfigurasjon og logger før irreversible endringer, slik at hendelsesresponsen ikke ødelegger sporene den trenger.

Gå gjennom alle Microsoft 365-miljøer der de berørte ConnectWise-appene er eller tidligere har vært installert. Søk etter app-ID, ikke bare visningsnavn. Bevar Entra-logger, Purview Audit, SIEM-data og tilgjengelig Microsoft Graph-telemetri, og undersøk både vellykkede og mislykkede service principal-innlogginger fra minst 15. oktober. Der loggene finnes, anbefaler Microsoft å gå tilbake til 1. oktober.

Se spesielt etter nye app-legitimasjoner, eiere og service principals, tildeling av approller, nye samtykker, privilegerte roller og endringer i brukere, grupper, autentiseringsmetoder eller Conditional Access. Kontroller også uvanlig e-post- og filtilgang, nedlastinger, videresendinger og regler i innbokser og e-posttransport.

ConnectWise sin løpende sikkerhetsmelding sier at leverandørens opprydding ikke fjerner eventuell tilgang angriperen allerede har etablert inne hos en kunde. Det er derfor ikke nok å vente på at Cloud Backup kommer tilbake. Hver virksomhet og hver MSP må kontrollere egne og administrerte miljøer.

Hvis dere finner mistenkelig aktivitet, sikre bevis først og la en autorisert hendelsesresponsgruppe fjerne ukjente nøkler, roller, samtykker og identiteter. Roter berørte innloggingsopplysninger og kontroller at oppryddingen faktisk fjernet vedvarende tilgang. Dette er ikke dagen for å rydde pent i portalen og håpe at fraværet av røde varsler betyr at alt er i orden.

Hva bør andre virksomheter lære av saken?

Start med en oversikt over flerbrukerapplikasjoner, OAuth-samtykker og service principals som har tilgang til virksomhetens skymiljø. Spør hvilke av dem som kan lese e-post, filer og katalogdata, og hvilke som kan endre roller eller app-legitimasjon. En integrasjon som ikke lenger brukes, skal ikke beholde en stående adgang bare fordi ingen har ryddet den bort.

Bruk minste privilegium og kortest mulig levetid på nøkler. Overvåk appinnlogginger som egne identiteter, ikke som bakgrunnsstøy under vanlige brukerlogger. Sett varsler på nye legitimasjoner, selvtildeling av roller, uventede Graph-kall og aktivitet fra leverandørapper utenfor kjent infrastruktur.

Forsvarssiden må også planlegge for maskinfart. Et menneske som vurderer 2 900 forsøk i minuttet én alarm om gangen, har tapt før kaffen er ferdig. Automatisert isolering kan være nødvendig ved klare indikatorer, men den må være øvd på og ha presise grenser slik at et angrep ikke blir byttet ut med et selvpåført driftsstans.

Den nøkterne konklusjonen er ubehagelig: Dette angrepet trengte både et verdifullt leverandørfotfeste og AI-drevet tempo. Å late som AI ikke gjorde noen forskjell blir like feil som å skylde alt på AI. Sikre tilliten først, begrens hva hver app kan gjøre, og bygg en respons som faktisk rekker å reagere når angriperen arbeider i maskinfart.

Ofte stilte spørsmål