В апреле 2026 года производственная компания на Ближнем Востоке пережила атаку, которая обошлась без привычных признаков работы шифровальщика. Ни один файл на рабочих станциях не пострадал от шифрования, на дисках не осталось вредоносных программ, а средства защиты не зафиксировали ничего подозрительного. Работа предприятия при этом встала. На экранах компьютеров появились обои с требованием выкупа. Вход в систему сопровождал угрожающий баннер, а встроенную учётную запись администратора отключили на всех машинах домена. Инструментом атаки стал не вирус, а штатный механизм управления доменом - групповые политики.
Описание
Групповые политики - служебный инструмент администраторов Windows-домена. Через них на все компьютеры организации централизованно рассылают настройки: оформление рабочего стола, правила безопасности, параметры входа. Механизм работает с высшими правами и считается доверенным, поэтому большинство средств защиты его почти не проверяет. Политика, привязанная к корню домена, действует на каждый компьютер и каждую учётную запись ниже уровнем. Один объект способен изменить конфигурацию всей сети. Именно это и привлекло атакующих.
Кампания, которую разбирала команда экстренного реагирования Kaspersky GERT, держится на подмене доверенного канала. Получив права уровня администратора домена, злоумышленник создал собственную политику и привязал её к корню домена. Один такой объект автоматически разослал требование выкупа и подменил обои с экраном блокировки. Баннер при входе и отключение локальной учётной записи администратора добавились оттуда же - на всех подчинённых компьютерах сразу. Ни один вредоносный файл на машины при этом не попал.
Второй объект политики отключил встроенный брандмауэр Windows сразу по всем профилям. Это ослабило защиту рабочих станций и сохранило атакующим свободный сетевой доступ к ним на случай продолжения операции. Обе политики применялись штатными средствами домена. Искать в них код, за который цепляется антивирус, бессмысленно: вредоносная логика заключена в самих настройках.
Хронология объясняет, почему атаку заметили не сразу. Одиннадцатого апреля злоумышленник вошёл в корпоративную сеть через VPN-шлюз, используя действующий, но похищенный доменный пароль. Как именно пароль оказался у него, установить не удалось: журналов VPN-шлюза не хватило. Среди вероятных версий - подбор пароля через веб-портал, фишинг и покупка готовых учётных данных у посредников. Тринадцатого апреля появились обе политики. Тогда же началась утечка данных с файловых серверов и нескольких других систем. Компьютеры получили новые настройки, однако применили их только при следующей перезагрузке. Сутки спустя машины начали перезагружаться по обычному графику, и политика сработала разом по всей организации. Пятнадцатого апреля к разбору инцидента подключилась внешняя команда реагирования. Шестнадцатого апреля она подтвердила, что шифрования не было.
Похищенные данные позже выложили в теневом сегменте сети. Требование выкупа опиралось не на шифрование, а на остановку работы и угрозу публикации. За последние годы доля инцидентов, где данные не шифруют, а лишь угрожают их обнародовать, заметно выросла. Злоумышленникам достаточно нарушить работу предприятия и пообещать новую эскалацию.
Сложность в том, что большинство средств защиты ищет файлы и процессы. Искать здесь было нечего. На машинах не осталось ни закрепления, ни запущенных вредоносных процессов, ни зашифрованных документов. Закрепление жило в самой службе каталогов. При этом политика подписана, входит в список разрешённых и распространяется с системными правами. Чистка рабочей станции ничего не даёт: следующее обновление политик вернёт всё на место.
Единственный найденный образец программы-вымогателя предназначался для Linux-серверов с гипервизором ESXi - средой для запуска виртуальных машин. Атакующие всё чаще берутся за этот уровень: контроль над ним открывает доступ сразу к множеству критичных сервисов. Следов ослабления настроек виртуализации в этом инциденте не обнаружили, хотя к такому повороту стоит готовиться.
Порядок действий при таком инциденте необычен. Удалять что-либо с рабочих станций бессмысленно. Сначала убирают саму политику на контроллере домена. Затем чистят служебный сетевой каталог от посторонних файлов и меняют все привилегированные учётные данные. Только после этого на машинах принудительно обновляют политики и возвращают отключённые настройки. Отдельно проверяют права. Создание и привязку политик разводят между разными ролями и отдают специальной группе с полным аудитом. Доменные администраторы не работают за обычными рабочими местами.
Помогают и общие меры. Многофакторная аутентификация на всех точках удалённого доступа закрывает самый вероятный путь входа. Автоматическая смена паролей локальных администраторов лишает злоумышленника одного из рычагов. Аудит изменений службы каталогов и контроль целостности служебного каталога позволяют заметить подмену политики в момент создания. Это точнее, чем разбираться с последствиями после перезагрузки парка машин. Полезно разместить в домене контрольную политику-приманку: её срабатывание подскажет, что у атакующего появились права на запись. Подробный журнал входов на VPN-шлюзе тоже пригодится: без него восстановить картину проникновения почти невозможно.
Атака PAYLOAD обошлась без единого вредоносного файла на рабочих станциях и всё же остановила предприятие. Контроль уровня администратора домена сам по себе равносилен серьёзному компромиссу, и отсутствие зашифрованных документов ничего здесь не смягчает. Стратегии обнаружения, построенные только на файлах и процессах, такую угрозу не видят.
Индикаторы компрометации
