Storm‑2949: как обычный сброс пароля привёл к масштабному взлому Microsoft 365 и Azure

Современные кибератаки всё чаще нацелены не на вредоносное ПО, а на учётные записи пользователей. Кампания Storm‑2949 стала ярким примером этой тенденции: злоумышленники использовали социальную инженерию, механизм восстановления доступа и легитимные инструменты Microsoft, чтобы превратить компрометацию одной учётной записи в масштабный взлом облачной инфраструктуры Microsoft 365 и Azure.

Инцидент также подчёркивает более широкий тренд в отрасли: методы аутентификации, которые можно перехватить или выманить у пользователя (например SMS‑коды), всё чаще рассматриваются как слабое звено безопасности. Именно поэтому Microsoft постепенно переводит пользователей на устойчивые к фишингу методы входа, такие как passkeys.

С чего началась атака Storm‑2949

По данным Microsoft Threat Intelligence, Storm‑2949 — это «методичная, сложная и многоэтапная» кампания, главной целью которой было похищение максимально возможного объёма данных из ценных облачных ресурсов организаций.

Вместо классических вредоносных программ атакующие делали ставку на компрометацию цифровой идентичности пользователя. Получив доступ к учётной записи — часто с расширенными правами — они использовали стандартные административные возможности Microsoft 365 и Azure, чтобы расширить контроль над инфраструктурой компании.

Такой подход позволял атакующим выглядеть как обычные администраторы и избегать многих систем защиты, рассчитанных на обнаружение вредоносного ПО.

Как была использована функция Self‑Service Password Reset

Ключевым элементом атаки стал механизм Self‑Service Password Reset (SSPR) в Microsoft Entra — система, позволяющая пользователям самостоятельно сбрасывать пароль без обращения в IT‑службу.

Storm‑2949 злоупотребляла этой функцией с помощью социальной инженерии.

Сценарий выглядел примерно так:

• злоумышленники представлялись сотрудниками IT‑поддержки или службы безопасности;
• они связывались с выбранными сотрудниками компании;
• жертву просили подтвердить «проверочный запрос» или «служебную процедуру безопасности».

На самом деле эти уведомления были MFA‑подтверждениями, инициированными во время процедуры сброса пароля.

Когда пользователь подтверждал запрос, атакующий мог продолжить процедуру SSPR.

После этого происходило следующее:

• пароль учётной записи сбрасывался;
• существующие методы аутентификации пользователя удалялись;
• злоумышленник регистрировал своё устройство, например Microsoft Authenticator.

В результате настоящий владелец аккаунта терял доступ, а атакующий получал устойчивый доступ с поддержкой MFA.

Как атака распространилась на всю облачную инфраструктуру

После захвата учётной записи Storm‑2949 начинала перемещаться по облачной среде организации.

Часто целью становились привилегированные пользователи — IT‑администраторы или руководители, обладающие широкими правами доступа.

Это открывало путь к множеству сервисов, включая:

• данные Microsoft 365 — файлы в SharePoint и OneDrive
• производственные среды в Azure
• облачные хранилища и базы данных
• секреты и ключи, хранящиеся в Azure Key Vault

Кампания показала важный принцип облачной безопасности: идентичность является фактической «панелью управления» инфраструктурой. Если атакующий получает контроль над привилегированной учётной записью, он может получить доступ к множеству сервисов без взлома программного обеспечения.

Почему Microsoft отказывается от SMS‑аутентификации

На фоне подобных атак Microsoft объявила о постепенном отказе от SMS‑кодов для входа и восстановления личных аккаунтов Microsoft.

По мнению компании, SMS‑аутентификация стала одним из основных источников мошенничества.

К основным проблемам относятся:

• атаки типа SIM‑swap, когда номер пользователя переносится на чужую SIM‑карту
• перехват сообщений в телеком‑сетях
• социальная инженерия, при которой пользователи сами сообщают код злоумышленникам

SMS‑коды считаются легко фишируемыми: их можно выманить или перехватить удалённо. Поэтому Microsoft делает ставку на более безопасные методы — passkeys, приложения‑аутентификаторы и подтверждённые резервные email‑адреса.

Какие меры безопасности рекомендует Microsoft

Инцидент Storm‑2949 показывает, что атаки на идентификацию пользователей способны обходить многие традиционные средства защиты. Microsoft рекомендует организациям усилить безопасность в нескольких ключевых областях.

Устойчивые к фишингу методы MFA

Организациям рекомендуется использовать методы аутентификации, которые нельзя легко подтвердить по ошибке или выманить у пользователя — например passkeys или аппаратные ключи безопасности.

Принцип минимальных привилегий

Контроль доступа на основе ролей (RBAC) должен гарантировать, что у сотрудников есть только те права, которые необходимы для работы. Это снижает масштаб ущерба при компрометации одной учётной записи.

Повышенное внимание к процедурам сброса пароля

Механизмы восстановления доступа, включая SSPR, могут стать точкой входа для атак. Их необходимо тщательно контролировать и мониторить, особенно для привилегированных пользователей.

Мониторинг активности в системе идентификации и облаке

Журналы безопасности должны фиксировать:

• события аутентификации и изменения методов входа
• операции сброса паролей
• доступ к данным Microsoft 365
• административные операции и действия управления в Azure

Такая видимость помогает обнаружить подозрительную активность на ранней стадии атаки.

Главный урок: новая поверхность атак — это идентичность

Storm‑2949 показывает, насколько изменилась современная кибербезопасность. Всё чаще злоумышленники не ищут уязвимости в программном коде и не распространяют вредоносные программы. Вместо этого они атакуют системы аутентификации, механизмы восстановления доступа и пользователей.

В облачной инфраструктуре компрометация всего одной привилегированной учётной записи может стать входной точкой к данным и сервисам всей организации. Поэтому защита идентичности, строгий контроль прав доступа и мониторинг облачных операций становятся критически важными для любой компании, работающей в облаке.