Один из клиентов IT-компании скачивает «срочное обновление» для привычной программы, запускает файл — и через несколько минут получает шифровальщик вместо рабочего инструмента. Именно на такую доверчивость и рассчитывали злоумышленники, которые пользовались сервисом Microsoft для подписания кода.

Компания заявила, что перекрыла схему, через которую преступники создавали поддельные сертификаты и выдавали вредоносные файлы за легитимное ПО. По данным Microsoft, операторы успели выпустить свыше 1000 сертификатов и задействовали сотни учётных записей и подписок в Azure.

Что произошло и почему это важно

Речь идёт о схеме malware-signing-as-a-service: преступники не просто распространяли вредоносные файлы, а снабжали их цифровой подписью. Для пользователя и для системы безопасности это плохой сигнал — подписанный файл выглядит куда менее подозрительным, чем неизвестный исполняемый файл без репутации.

Microsoft связывает операцию с группой Fox Tempest. По версии компании, злоумышленники использовали Azure Artifact Signing, чтобы выпускать краткоживущие сертификаты и подписывать вредоносные сборки так, будто они вышли от нормального разработчика.

Дальше схема работала просто: файл с именем знакомого приложения — например, Microsoft Teams, AnyDesk, PuTTY или Webex — попадал к жертве, запускал загрузчик и доводил цепочку до шифровальщика или стилера. В числе кампаний, которые компания привязала к этой инфраструктуре, — Oyster, Lumma Stealer, Vidar, Rhysida, Akira, Qilin и BlackByte.

Как работала схема и где ломалась защита

Microsoft утверждает, что преступники пытались пройти проверку личности с помощью украденных данных из США и Канады. Отдельный штрих — короткий срок жизни сертификатов: 72 часа. Это снижало шанс, что защитные системы успеют среагировать и отозвать подписи вовремя.

Для бизнеса здесь важен не только сам инцидент, но и принцип. Если атакующий получает возможность подписью легализовать вредоносный файл, классические маркеры угрозы начинают работать хуже. Именно поэтому инциденты вроде атак через цепочки поставки и компрометацию инфраструктуры особенно болезненны — похожую логику мы уже разбирали в тексте про атаку через npm-цепочку и в материале о том, как GitHub проверяет взлом внутренних репозиториев и утечку кода.

Microsoft говорит, что закрыла доступ к домену signspace[.]cloud, вывела из строя сотни виртуальных машин и отозвала более 1000 сертификатов. Отдельно компания добилась судебных мер в США.

Что делать компаниям и обычным пользователям

У этой истории есть три практических вывода.

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

Второй — уязвимость часто начинается не с кода, а с доверия. Злоумышленники любят маскировать загрузчики под известные приложения, а затем давить на спешку: «обновите», «подтвердите», «срочно установите». Для такой истории лучше работает базовая гигиена: проверка отправителя, запрет на запуск неизвестных .exe и обучение сотрудников, как выглядит фишинг (от англ. phishing — выуживание).

Третий — в публичных сетях и на чужих устройствах стоит помнить о перехвате трафика и лишних следах. Для тех, кто часто работает из кафе, отеля или аэропорта, Frеedome.space может быть одним из практичных слоёв защиты от пассивного наблюдения за перепиской и метаданными.

Кому это должно быть особенно интересно

Обычным пользователям — чтобы не путать «подписано» с «безопасно». Руководителям и администраторам — чтобы пересмотреть политику запуска файлов, контроль учётных записей и правила работы с корпоративной почтой.

Разработчикам и DevOps-командам — чтобы внимательнее смотреть на цепочку сборки, выдачу сертификатов и зависимость от внешних платформ. Инцидент Microsoft показывает: если атакующий добирается до доверенного механизма, он получает не просто доступ к инфраструктуре, а право выглядеть легитимно.

Практический чек-лист

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