Storm-3168 изтрива ресурси в Azure при 7-минутна унищожителна облачна атака

Storm-3168 използва компрометирани облачни идентичности, за да извърши унищожителна атака срещу Azure среда в рамките на броени минути. Операцията показва как откраднати данни за достъп на приложение могат да дадат на нападателя широк контрол върху хоствани данни, услуги и защити за възстановяване.

Тя също така подчертава нарастващата заплаха от автоматизирани облачни атаки. Дейността се свързва с агентурни зловредни операции за откуп JADEPUFFER, документирани по-рано при друг инцидент.

Изследователите откриха две компрометирани идентичности на услуги (service principals) в един тенант, като едната е картографирала средата, а другата е унищожавала ресурси и събирала ключове за съхранение.

Microsoft проследява автора на заплахата под името Storm-3168. Изследователите не са потвърдили, че изкуствен интелект пряко е управлявал тези Azure операции. Анализаторите на Microsoft са идентифицирали Azure дейността.

Microsoft заяви в доклад, споделен с Cyber Security News (CSN), че кампанията е била насочена към профили в Azure Storage, SQL бази данни, Key Vaults, Function Apps, App Services и механизми за контрол на възстановяването.

Разследването не потвърди наличието на бележка за откуп или успешно откраднати данни, но комбинацията от действия сочи към вероятна цел за изнудване.

Случаят подчертава проблем с облачната сигурност, който започва дълго преди да бъде издадена команда за изтриване. Идентификационният номер на клиента, тайният ключ и ID на тенанта за една от идентичностите на услуги са се появили в некриптиран вид в публичен проблем в GitHub, въпреки че изследователите не можаха да потвърдят дали този конкретен ключ е бил използван. Премахването на таен ключ от публикация не го отменя и не изтрива неговата история.

Storm-3168 изтрива ресурси в Azure

В началото на юни 2026 г. първата компрометирана идентичност е прекарала около 15 часа и 30 минути в извършване на над 300 успешни операции за четене.

Тя е извлякла списък с виртуални машини, абонаменти, групи ресурси и други елементи. Около 90 минути по-късно втората идентичност е проверила виртуални машини и групи в два абонамента само за пет секунди.

Втората идентичност на услуга по-късно е разгледала хранилищата за конфигурация на App Service, вероятно търсейки изложени данни за достъп, и неуспешно е запитала ресурси в Azure OpenSearch.

Седемдесет секунди след последното си действие по инвентаризация, тя се е опитала да извлече ключ от профил за съхранение, който не е съществувал. По-малко от секунда по-късно е започнала унищожителната последователност.

В продължение на приблизително седем минути Storm-3168 е направил над 100 опита да изтрие профили за съхранение, като повечето целеви профили са били успешно премахнати.

Тя също така е изтрила Key Vault, Function App и план за App Service, свързани със същата група ресурси. Заключванията на ресурси и защитата от изтриване на ниво профил са спрели няколко опита, което показва, че независимите защитни мерки могат да ограничат щетите.

Атакуващият се е опитал паралелно да изтрие и няколко Azure SQL бази данни, но всеки опит е се е провалил поради използването на неподдържана версия на API.

Той отделно е насочил действията си към защитните заключвания на Site Recovery и Azure Backup. Предишни доклади за дефекти в ролите на Azure API показват защо строго дефинираните облачни роли все още изискват внимателен преглед на разрешенията.

Откраднатите идентичности повишават рисковете при възстановяване

Около 30 минути след последните унищожителни действия същата идентичност е изпратила над 30 успешни заявки ListKeys за профили в Azure Storage, включително профили, свързани със Site Recovery.

Ключовете за достъп могат да изложат на риск чувствителни данни и да създадат път за последващо събиране на информация. Последователността е била насочена и към профили за съхранение с имена, съдържащи „terraform“ и тематика за резервни копия, което увеличава риска от затруднено възстановяване.

Времето и използването на множество идентичности подсказват за координирана автоматизация. Microsoft наблюдава пет отделни токена за идентичността на услугата, използвана при изтриването и събирането на ключове; четири са поддържали изтриване, докато един е управлявал инвентаризацията на съхранението и извличането на ключове.

Два токена за изтриване са били активни по време на един и същ 70-секунден прозорец, разпределяйки операциите между цели в съхранението и SQL базите данни.

Организациите трябва незабавно да отменят и подновят всички публично изложени данни за достъп, след което да проучат тяхната предишна употреба. Те трябва да държат тайните ключове извън изходния код, тикетите, хранилищата и конфигурационните файлове, като същевременно прилагат принципа на най-малките привилегии за идентичностите на работните товари.

Отделен доклад относно излагането на данни за достъп в Azure Arc показва колко бързо достъпните тайни за внедряване могат да се превърнат в мощни входни точки.

Администраторите трябва да ограничат достъпа до резервните копия и контролите за възстановяване, да следят опитите за промяна или премахване на защитите и редовно да преглеждат разрешенията за идентичност.

Екипите по сигурност трябва също така да следят за неочаквано разкриване на ресурси, голям обем извлечени ключове и необичайна дейност по изтриване. Свързаните доклади за рисковете при достъп до Key Vault илюстрират важността от проследяване на рисковата употреба на идентификационни данни в целия тенант.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC