Storm-3168 Azure-attack: Vad hände

Microsoft har avslöjat en kampanj som de spårar som Storm-3168, där angripare komprometterade Azure-tjänsteprincipaler – de identitetsobjekt som applikationer och automatiserade tjänster använder för att autentisera mot Azure – och använde den åtkomsten för att radera lagringskonton. Enligt Microsofts egen redogörelse liknar aktiviteten mindre en smash-and-grab-datastöld och mer en förberedelse för utpressningsprogram eller aktiv störning. Noterbart är att Microsoft inte har bekräftat att utpressning eller dataexfiltrering förekom i denna specifika incident, även om taktiken liknar de tidiga stadierna av en utpressningsattack.

Den distinktionen spelar roll. Att radera lagringskonton kan vara lika skadligt som att kryptera dem, särskilt om det inte finns någon säkerhetskopia, men det är en annan hotmodell än en angripare som tyst kopierar filer innan den försvinner. För organisationer som förlitar sig på Azure är slutsatsen att en angripare inte behövde stjäla data för att orsaka allvarlig skada. Att få kontroll över rätt identitet var tillräckligt.

Varför tjänsteprincipaler är ett huvudmål

Tjänsteprincipaler är lätta att förbise eftersom de inte är mänskliga användarkonton. De är de autentiseringsuppgifter som låter en Azure-tjänst eller applikation kommunicera med en annan, ofta med förhöjda behörigheter och minimal daglig tillsyn. Det gör dem till ett attraktivt mål för angripare: kompromettera en, och du kan ärva bred åtkomst till lagring, databaser eller infrastruktur utan att någonsin röra en persons inloggningsskärm.

Detta är en del av ett bredare mönster som säkerhetsforskare har flaggat för inom Microsofts molnekosystem. Angripare riktar alltmer in sig på de autentiseringsuppgifter och förtroenderelationer som finns bakom kulisserna snarare än att rikta in sig direkt på slutanvändare. Det är en liknande logik som kampanjer som Storm-3032:s röstfiskeoperation som riktar sig mot BYOD-enheter för Microsoft 365-åtkomst, där målet inte är att lura en person att lämna över ett lösenord på plats, utan att hitta den svagaste länken i en identitetskedja och rida den in i en mycket större miljö.

En relaterad varning: Lösensumman som gömdes i en databas

Medan Storm-3168 Azure-incidenten inte (som dokumenterat hittills) har eskalerat till utpressning, visar ett separat fall rapporterat av säkerhetsföretaget Sysdig vart den här typen av åtkomst kan leda om den lämnas obevakad. I den incidenten, sammanfattad av SOCFortress, krypterade en angripare som fick åtkomst till en databasmiljö data, släppte databastabeller och lämnade efter sig ett lösenskrav. Forskare fann att angriparen hade skapat en tabell med namnet README_RANSOM som innehöll en Bitcoin-plånboksadress och en Proton Mail-kontakt för att förhandla om betalning.

Microsofts Storm-3168-aktivitet nådde inte det stadiet, men parallellen är lärorik. Båda fallen började på samma sätt: en angripare fick tag i autentiseringsuppgifter eller åtkomst som borde ha varit strikt kontrollerad, och använde den fotfästet för att hota integriteten hos lagrad data. Oavsett om slutresultatet är radering, kryptering eller en lösensumma, är grundorsaken densamma. Någon kom in i ett konto som inte borde ha varit nåbart.

Vad detta innebär för dig

Om din organisation eller dina personliga projekt förlitar sig på Azure eller liknande molnplattformar, är denna kampanj en påminnelse om att identitetssäkerhet, inte bara perimeterskydd, är där dessa attacker vinns eller förloras. Några praktiska steg gäller oavsett om du hanterar företagsinfrastruktur eller en liten verksamhets molnlagring:

  • Granska tjänsteprincipalers behörigheter regelbundet. Många organisationer beviljar bred åtkomst när de ställer in automation och återvänder aldrig till det. Begränsa behörigheter till endast det som behövs.
  • Aktivera multifaktorautentisering överallt där det stöds, inklusive för administrativa konton och tjänstekonton, inte bara vanliga användarinloggningar.
  • Granska åtkomstloggar för ovanliga autentiseringsmönster, särskilt inloggningar från oväntade platser eller vid udda tider kopplade till tjänstekonton.
  • Säkerhetskopiera lagringskonton oberoende av den primära miljön så att radering eller kryptering inte innebär permanent förlust.
  • Rotera autentiseringsuppgifter och hemligheter enligt ett schema, istället för att låta tjänsteprincipalnycklar vara giltiga på obestämd tid.

Stöld av autentiseringsuppgifter är fortfarande en av de vanligaste vägarna in i molnmiljöer, och stark autentisering kombinerat med noggrann åtkomsthantering gör mer för att stoppa dessa attacker än något enskilt verktyg. Att använda en VPN för att skydda näten som dina administratörer och distanspersonal ansluter från lägger till ett extra lager, men det fungerar bäst tillsammans med, inte istället för, solid identitetshygien.

Slutsatser

Storm-3168 Azure-attacken visar att angripare inte behöver exfiltrera data för att orsaka skada; att radera lagringskonton genom komprometterade tjänsteprincipaler är tillräckligt störande i sig. Tillsammans med lösensummedetaljen i Sysdig-fallet är det en tydlig signal om att molnidentitetshantering förtjänar samma granskning som organisationer ägnar åt brandväggar och slutpunktssäkerhet. Att granska vem och vad som har åtkomst till din molnlagring, strama åt behörigheter och aktivera multifaktorautentisering för varje kontotyp är praktiska steg du kan ta idag för att minska risken att bli nästa fallstudie.