Storm-3168 використала дві скомпрометовані ідентичності застосунків Azure для знищення хмарних ресурсів. У розслідуванні Microsoft від 25 вересня йдеться про червневу атаку: години розвідки змінилися сімома хвилинами руйнування. Облікові записи сховищ видалялися; спроби видалення SQL-баз провалилися через непідтримувану версію API. Частина захисних механізмів сховищ спрацювала. [1]
Після видалення зловмисник отримував ключі
Одна ідентичність виконувала розвідку; друга — також руйнування та збирання облікових даних.
Приблизно через 30 хвилин після руйнування друга ідентичність успішно запитала ключі сховищ понад 30 разів, зокрема для сховищ відновлення. Ключі видало й уціліле сховище поруч із видаленими ресурсами застосунку. Це підтверджує доступ до ключів, але не викрадення даних. [1]
Успадкована через групу роль Storage Account Contributor дозволяла руйнування сховищ. Пряма Contributor — видалення ресурсів застосунку й отримання ключів уцілілого сховища; SQL DB Contributor — невдалі спроби видалення баз. Операції відповідали наявним ролям. [1]
Дозвіл належав застосунку
Service principal — це ідентичність застосунку в середовищі Microsoft Entra конкретної організації. Вона дає програмі змогу автентифікуватися й користуватися ресурсами від власного імені. Такий доступ потрібен сценаріям розгортання та інтеграціям, тому їхні дозволи заслуговують не меншої уваги, ніж привілейований обліковий запис працівника. [2]
Звідси й ризик: законні облікові дані автоматизації можуть дозволити зловмисну операцію. Під час розслідування важливо з’ясувати, яка ідентичність застосунку діяла, які дозволи мала та які ресурси вони охоплювали, а не лише перевірити входи працівників.
Microsoft також знайшла секрет в історії редагувань GitHub issue, але не встановила шлях проникнення. Вимоги викупу й успішного викрадення даних не підтверджено. [1]
Збережений ресурс ще не означає безпеки даних
Невдалі SQL-запити показують важливу різницю: операція могла не виконатися, але все одно свідчити про намір знищення. Якщо вважати кожну помилку нешкідливою, можна не відрізнити звичайну описку адміністратора від атаки, успішної на інших ресурсах.
Доступність сервісу також потребує контексту. В окремому випадку запобіжного вимкнення Kiteworks виробник попросив призупинити роботу, не повідомляючи про підтверджений злам. Це інший стан доказів, ніж задокументовані тут руйнівні операції.
Блокування Azure CannotDelete забороняє видаляти обліковий запис сховища, залишаючи можливість змінювати конфігурацію. Воно не захищає вкладені контейнери й об’єкти від видалення або перезапису. ReadOnly також блокує операцію List Keys, проте раніше отримані ключі можуть залишатися придатними. Отже, існування сховища саме по собі не доводить цілісності його вмісту. [3]
Видалити публікацію — не означає відкликати доступ
GitHub радить реагувати на витік через відкликання облікових даних. Прибрати секрет із репозиторію недостатньо: він не стає недійсним. Визначте власника та залежні застосунки, замініть або відкличте секрет у постачальника й перевірте сліди використання. Якщо негайне відкликання зупинить робочий сервіс, узгодьте перехід на заміну. [4]
Далі перевірте роль і межі доступу ідентичності. Рекомендації Azure передбачають лише потрібні операції та якомога вужче коло ресурсів. Надмірні дозволи на всю підписку збільшують наслідки витоку одного секрету. [5]
В іншому розслідуванні, про віддалений доступ Storm-2570, ми розглядали контроль, який переживає зміну інструментів атаки. Тут висновок конкретний: зберігайте невдалі запити як докази, відкликайте скомпрометовані секрети та перевіряйте захист даних окремо від збереження самого ресурсу.
Джерела
- Microsoft Security Research. Розслідування Storm-3168. 25 вересня 2026 року.
- Microsoft Learn. Ідентичності програмних навантажень. Переглянуто 27 вересня 2026 року.
- Microsoft Learn. Блокування облікового запису сховища. Переглянуто 27 вересня 2026 року.
- GitHub Docs. Реагування на витік секрету. Переглянуто 27 вересня 2026 року.
- Microsoft Learn. Рекомендації щодо ролей Azure RBAC. Переглянуто 27 вересня 2026 року.
