En Kinaanknuten hackergrupp har använt AI för att automatisera angrepp mot över 2 250 Microsoft 365-miljöer. Genom stulna behörigheter hos IT-leverantören ConnectWise kunde angriparna försöka ta sig in via applikationer som företagen redan hade godkänt. I flera fall lyckades de skaffa sig obehörig åtkomst. Nu uppmanas berörda företag att kontrollera sina molnkonton och säkerhetsloggar.

Microsoft offentliggjorde den 21 oktober hur hackergruppen Storm-0940 använde AI-ramverket ARTEX för att genomföra storskaliga angrepp mot Microsoft 365.

Attacken skiljer sig från traditionella försök att komma över en anställds lösenord. Angriparna utnyttjade i stället förtroendet mellan företag och deras IT-leverantörer.

I vissa drabbade miljöer lyckades de ge sig själva utökade administratörsbehörigheter och skapa nya möjligheter att komma tillbaka.

Däremot betyder inte de 2 250 angreppsmålen att lika många företag har hackats. Microsoft har inte heller redovisat någon samlad siffra över hur mycket information som eventuellt har stulits.

Så tog sig angriparna in via ConnectWise

ConnectWise levererar bland annat tjänster för säkerhetskopiering och administration av företags molnmiljöer. En av produkterna är Cloud Backup, som tidigare hette SkyKick.

För att kunna säkerhetskopiera e-post, filer och annan företagsinformation behöver sådana tjänster tillgång till kundernas Microsoft 365-miljöer.

Åtkomsten ges genom särskilda applikationsidentiteter. Företagets administratör godkänner vilka rättigheter applikationen ska ha, exempelvis att läsa information eller kommunicera med Microsofts molntjänster.

Storm-0940 kom över autentiseringsuppgifter kopplade till ConnectWise-applikationer och kunde därmed försöka använda dessa betrodda anslutningar för egna syften.

Det innebar att angriparna inte behövde lura varje enskild användare att lämna ifrån sig sitt lösenord.

De kunde i stället försöka identifiera sig som en applikation som redan hade tillstånd att arbeta i företagets Microsoft 365-miljö.

Det är ett exempel på en leverantörskedjeattack, där ett säkerhetsproblem hos en leverantör kan sprida risker till många kunder.

Microsoft betonar att attacken inte byggde på någon konstaterad sårbarhet eller kompromettering i bolagets egna produkter eller system.

AI gjorde attackerna snabbare och mer omfattande

Angriparna använde ARTEX, ett öppet AI-ramverk som kan samordna flera automatiserade agenter.

En AI-agent kan utföra uppgifter med hjälp av tillgängliga verktyg, analysera resultaten och fortsätta med nästa moment utan att en människa behöver styra varje steg.

I den aktuella kampanjen användes tekniken bland annat för att kartlägga molnmiljöer, genomföra autentiseringsförsök och automatisera delar av den efterföljande aktiviteten.

Microsoft har också dokumenterat omfattande lösenordsattacker inom samma kampanj.

Mellan den 10 och 14 oktober registrerades över 151 000 misslyckade lösenordsbaserade inloggningsförsök mot 327 konton hos åtta organisationer. Vid ett tillfälle noterades upp till 2 900 autentiseringsförsök per minut.

De siffrorna gäller lösenordsangreppen och ska inte förväxlas med antalet Microsoft 365-miljöer som attackerades via ConnectWise.

Microsoft har dessutom sett exempel där AI-understödda angrepp ledde till privilegierad molnåtkomst på mindre än tre timmar.

Det betyder inte att AI skapade någon ny avancerad sårbarhet. Den stora förändringen var i stället att redan kända angreppsmetoder kunde genomföras snabbare, i större skala och med mindre löpande mänskligt arbete.

Samma utveckling har synts i andra cyberattacker där AI-agenter använts för att automatisera intrång.

Hur många Microsoft 365-miljöer blev faktiskt hackade?

Det finns en viktig skillnad mellan ett angreppsförsök, en lyckad inloggning och en bekräftad datastöld.

Microsoft har identifierat automatiserade angreppsförsök mot fler än 2 250 Microsoft 365-miljöer.

Det betyder att miljöerna har varit måltavlor, inte att alla har komprometterats.

Säkerhetsföretaget Huntress har samtidigt bekräftat obehöriga applikationsinloggningar hos ett betydande antal kunder. I en uppdatering redovisades misstänkt inloggningsaktivitet i närmare 1 000 miljöer, varav över 300 hade lyckade autentiseringar.

I två närmare undersökta miljöer hittade Huntress dessutom tydliga tecken på att angriparna hade tagit kontroll över ytterligare behörigheter.

Bland annat hade en applikation tilldelats rollen Global Administrator, en av de högsta administratörsrollerna i Microsofts molnmiljö.

Angriparna hade även lagt till nya autentiseringsuppgifter i andra applikationer.

Det är särskilt allvarligt eftersom en sådan förändring kan göra att obehörig åtkomst finns kvar även om den ursprungliga ConnectWise-anslutningen stängs av.

Finns det bevis för att data stulits?

Microsoft har dokumenterat aktivitet mot Microsoft Graph, den tjänst som används för att komma åt och administrera information i Microsoft 365.

Sådan aktivitet kan omfatta allt från att läsa information om användare och behörigheter till att arbeta med filer och andra resurser, beroende på applikationens rättigheter.

Men en lyckad anslutning är inte i sig ett bevis för att företagsinformation har laddats ned eller stulits.

Huntress fann inte belägg för att e-post eller filer hade ändrats i de två miljöer som granskades särskilt noggrant. Företaget kunde däremot inte utesluta att information hade lästs.

Det finns ännu ingen offentlig, fullständig sammanställning över hur många organisationer som utsatts för konstaterad dataåtkomst eller datastöld.

Vilka företag behöver kontrollera sina konton?

Företag som använder ConnectWise Cloud Backup eller äldre SkyKick-tjänster bör undersöka om deras Microsoft 365-miljö har berörda applikationsanslutningar.

Det gäller också företag som får sin IT administrerad av en extern leverantör.

En organisation behöver alltså inte själv ha tecknat ett direktavtal med ConnectWise för att omfattas av risken. Anslutningen kan ha installerats av en IT-partner eller återförsäljare.

Även tidigare installationer kan vara relevanta om applikationsidentiteter eller behörigheter finns kvar.

Det är därför viktigt att varje berörd Microsoft 365-miljö kontrolleras individuellt.

En central granskning hos IT-leverantören kan inte fullt ut ersätta en kontroll av de behörigheter som finns hos kunden.

Så kontrollerar du om din Microsoft 365-miljö är berörd

Microsofts och ConnectWise tekniska instruktioner ger administratörer en konkret väg för att undersöka miljöerna.

Kontrollerna bör utföras av behörig IT-personal. Vid misstanke om intrång behöver relevanta loggar och andra bevis bevaras innan större förändringar görs.

1. Leta efter de berörda applikationerna

Öppna administrationsportalen för Microsoft Entra och gå till:

Entra ID → Enterprise applications → All applications

Sök efter applikationerna med deras Application ID. Det är säkrare än att enbart söka på namn, eftersom äldre SkyKick-beteckningar kan förekomma.

ConnectWise har identifierat följande sju applikationer:

Applikation	Application ID
Cloud Backup	506e08f9-6e9a-4da4-942b-a099a03644ae
Cloud Management	2399d300-6fca-4e6a-a686-399fefe75b83
MS Teams	24205314-2b89-4e07-a2a4-579e898a5640
Exchange Online	b78f6a77-d4e5-46fb-87e5-d1648bd02519
MS Graph	0de14c77-b9b0-4137-9360-34878a929827
Partner Center	412dcf96-176d-4b3a-a1b0-4981ad66971e
SharePoint Online	b2b55f5b-7758-4719-8d8f-88ae172e6bdb

Dokumentera också det lokala Object ID som hör till respektive applikationsinstans.

ConnectWise uppger att företaget inaktiverade och återkallade behörigheterna för de aktuella applikationsidentiteterna den 17 oktober.

Trots det behöver kundernas egna miljöer granskas för att upptäcka eventuell obehörig aktivitet och kvarvarande åtkomstvägar.

2. Undersök applikationernas inloggningar

Nästa steg är att kontrollera Microsoft Entras inloggningsloggar för applikationer, särskilt så kallade service principal sign-ins.

Där går det att undersöka vilka applikationsidentiteter som använts, vilka resurser de försökt nå och varifrån anslutningarna gjordes.

Granska i första hand perioden från den 13 oktober och framåt. Där äldre loggar finns tillgängliga bör undersökningen utökas till början av oktober.

Microsoft har bland annat kopplat IP-adresserna 144.172.64.128 och 144.172.64.99 till angreppsaktiviteten.

En träff på en sådan adress är relevant att undersöka, men räcker inte ensam för att fastställa ett intrång. Frånvaron av träffar utesluter inte heller att miljön berörts.

3. Kontrollera om nya administratörsbehörigheter skapats

Det räcker inte att kontrollera om ConnectWise-applikationen har loggat in.

Administratören behöver också undersöka vad som hände efter en eventuell lyckad autentisering.

Granska särskilt:

• Nya eller ändrade klienthemligheter och certifikat.
• Ändrade applikationsägare och behörigheter.
• Oväntade tilldelningar av rollen Global Administrator.
• Nya applikationer och godkända åtkomsträttigheter.
• Ändringar av federerade autentiseringsuppgifter.
• Misstänkt aktivitet via Microsoft Graph.

En angripare som lyckats skapa en ny åtkomstväg kan behålla möjligheten att komma tillbaka även efter att den ursprungliga leverantörsanslutningen har spärrats.

4. Granska e-post, filer och annan molndata

En lyckad inloggning bör följas upp med en undersökning av vilka resurser som faktiskt har nåtts.

Microsoft Purview Audit, Entra audit logs och relevanta säkerhetsloggar kan användas för att undersöka aktivitet i Exchange, SharePoint, OneDrive och Teams.

Kontrollera bland annat om nya regler för vidarebefordran av e-post har skapats, om behörigheter ändrats eller om ovanliga filaktiviteter förekommit.

Tillgängligheten varierar mellan olika licenser och inställningar.

Entra Free har normalt sju dagars lagring av inloggningsloggar medan Entra P1 och P2 normalt ger 30 dagar. Längre historik kan finnas om loggarna tidigare har exporterats till andra system.

Det gör det viktigt att säkra materialet snabbt. Loggar som redan har raderats återskapas inte genom att mer omfattande loggning aktiveras i efterhand.

5. Stäng obehörig åtkomst – men bevara bevisen

Om granskningen visar tecken på intrång måste obehöriga autentiseringsuppgifter och behörigheter återkallas.

Samtidigt behöver företaget dokumentera förändringarna så att det går att förstå hur angriparen fick åtkomst och vad som kan ha påverkats.

Att bara byta ett lösenord eller ta bort en ConnectWise-anslutning är inte nödvändigtvis tillräckligt.

Undvik också att omedelbart radera berörda applikationer innan nödvändiga undersökningar genomförts.

ConnectWise har publicerat en teknisk guide för undersökning och sanering med de berörda applikationerna och mer detaljerade instruktioner.

Varför stoppade inte tvåfaktorsautentisering attacken?

En vanlig fråga är hur angriparna kunde ta sig in i företagsmiljöer där flerfaktorsautentisering används.

Förklaringen är att applikationer och användarkonton inte autentiseras på samma sätt.

En vanlig användare kan behöva ange lösenord och därefter godkänna sin inloggning med en app eller annan säkerhetsmetod.

En applikationsidentitet kan däremot använda exempelvis en klienthemlighet eller ett certifikat för att begära åtkomst utan att någon användare samtidigt loggar in.

Det är en nödvändig funktion för många automatiserade IT-tjänster.

Men om en angripare kommer över sådana autentiseringsuppgifter kan samma teknik missbrukas.

Det innebär inte att flerfaktorsautentisering är värdelös eller att angriparna lyckades knäcka skyddet.

Det visar att säkerheten också måste omfatta applikationer, externa leverantörer och de rättigheter som finns mellan olika system.

ConnectWise har påbörjat återställningen

ConnectWise har under incidenthanteringen stängt av berörda molntjänster, däribland Cloud Backup, Cloud Management och SaaS Security.

I en uppdatering den 22 oktober uppger företaget att berörda konton och autentiseringsuppgifter har återställts och att arbetet med att stegvis starta tjänsterna pågår.

Enligt ConnectWise är befintliga säkerhetskopior krypterade, isolerade och bevarade, utan tecken på att de komprometterats.

Bolaget uppmanar samtidigt kunderna att hålla berörda anslutningar avstängda tills de får formella instruktioner om återstart.

Det är ännu inte offentligt fastställt hur angriparna ursprungligen kom över de komprometterade uppgifterna.

Och även om leverantörens centrala system återställs återstår en annan fråga för varje kund: om angriparna hann skapa en separat åtkomstväg inne i företagets egen Microsoft 365-miljö.

Det är därför den lokala granskningen av applikationsbehörigheter, administratörsroller och säkerhetsloggar är så viktig.

Attacken visar hur snabbt en komprometterad leverantörsanslutning kan förvandlas till ett storskaligt säkerhetsproblem när AI används för att automatisera angreppen.

Men den visar också något mer grundläggande: ett företags Microsoft 365-säkerhet avgörs inte bara av hur väl de egna användarkontona skyddas, utan också av vilka externa applikationer som redan har fått förtroendet att arbeta i miljön.