Раньше такие истории считались редким кейсом для крупных корпораций, но теперь под удар попадают и специальные государственные сборки Windows 10. Исследователи Kaspersky описали сложную цепочку заражения, которую нацелили на правительственные организации в Азии. Целью стал не обычный пользовательский компьютер, а кастомная версия системы, которую ставят только в госструктурах.

Какую проблему решаем

Главная проблема здесь — не один вредоносный файл, а целая многоступенчатая схема, которая прячется внутри легитимных компонентов. Такие атаки сложнее заметить, потому что код запускается через штатные механизмы .NET Framework, а часть файлов выглядит как обычные служебные модули.

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

Что подготовить

Если вы отвечаете за рабочие станции или серверы на Windows, начните с базового набора:

  • список устройств с нестандартными сборками системы;
  • контроль целостности файлов в каталогах обновлений;
  • журналирование запуска .NET-приложений и дочерних процессов;
  • проверку подозрительных CAB-архивов и конфигов рядом с ними;
  • правила EDR/антивируса на запуск из папок обновления Windows.

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

Пошаговые действия

Один. Проверьте каталог обновлений Windows

По описанию атаки вредоносный CAB-архив оказался в папке загрузок обновлений Windows. Администратору стоит отдельно проверить содержимое каталогов SoftwareDistribution и похожих временных хранилищ на неожиданные файлы .config, .dll и .resx.

Два. Ищите странные связки файлов

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

Три. Смотрите на аномалии запуска .NET

Один из ключевых трюков — AppDomainManager injection, то есть подмена механизма загрузки .NET-компонентов при старте приложения. Если вы видите, что обычный процесс внезапно подхватывает стороннюю библиотеку, это уже не нормальная работа. Подробнее о похожей технике мы писали в разборе поддельного обновления Claude Code.

Четыре. Проверьте сетевую активность

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

Пять. Удалите мусор и следы

Вредоносный компонент пытался зачистить временные файлы, логи CLR и следы в кэше Prefetch. Это значит, что после инцидента стоит проверять не только саму угрозу, но и попытки зачистки следов. Если журналов стало заметно меньше без объяснимой причины, это плохой знак.

Как проверить себя

Для быстрой самопроверки задайте три вопроса.

Первый: есть ли у вас нестандартные сборки Windows, которые используются только в отдельном контуре? Второй: контролируете ли вы файлы в каталогах обновлений и временной установки? Третий: умеете ли вы отлавливать .NET-инъекции и необычный запуск dllhost.exe или похожих системных процессов?

Если на любой из этих вопросов ответ «нет», риск пропустить атаку выше. В таких случаях полезно провести аудит доверенных источников обновлений и сверить, не появлялись ли в них новые файлы без понятного происхождения.

Что делать, если не получилось

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

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

Чек-лист

  • Проверить папки обновлений Windows на неожиданные CAB, .config, .dll и .resx.
  • Сверить, какие .NET-приложения запускаются на рабочей станции и откуда.
  • Настроить контроль целостности для файлов в системных каталогах.
  • Отдельно мониторить необычные сетевые запросы от dllhost.exe и похожих процессов.
  • Проверить, нет ли попыток удалить логи CLR и следы в Prefetch.
  • Изолировать машину, если поведение похоже на многоступенчатую загрузку кода.
  • Разобрать инцидент вместе с журналами, а не только по антивирусному срабатыванию.
Поделиться: