Кампания PAYLOAD: вымогательство через объект групповой политики Active Directory

Краткое содержание

В апреле 2026 года глобальная команда экстренного реагирования на киберинциденты «Лаборатории Касперского» (GERT) расследовала инцидент безопасности на производственном предприятии на Ближнем Востоке. Злоумышленник получил контроль над средой Active Directory организации с правами, эквивалентными привилегиям администратора домена, и создал вредоносный объект групповой политики (GPO) с именем PAYLOAD, привязав его к корню домена. С помощью одного этого объекта атакующий распространил записку с требованием выкупа, изменил обои рабочего стола и экран блокировки, принудительно настроил отображение баннера при входе в систему и отключил учетную запись локального администратора на всех рабочих станциях, входящих в домен. Хотя атакующий загрузил на Linux-серверы в организации версию шифровальщика PAYLOAD для ESXi, в атаке на Windows-машины не использовался исполняемый файл программы-вымогателя и не шифровались данные. Злоумышленнику удалось эксфильтровать данные с файловых серверов и некоторых других систем. Позднее похищенная информация была опубликована в даркнете.

Этот инцидент демонстрирует комбинацию двух тенденций, определяющих ландшафт вымогательских кампаний в 2026 году:

1. Использование доверенной инфраструктуры Active Directory. Групповая политика представляет собой подписанный доверенный канал распространения с привилегиями SYSTEM, проверка которого не предусмотрена в большинстве решений для обнаружения и реагирования на рабочих местах (EDR). Воздействуя на работу систем через GPO, а не с помощью вредоносного ПО, злоумышленник полностью обошел стек обнаружения, ориентированный на анализ файлов и процессов.
2. Вымогательство без шифрования. Как показывает отраслевая телеметрия, в 2025 году количество инцидентов, связанных исключительно с вымогательством, значительно выросло по сравнению с 2024-м. Кампания PAYLOAD вписывается в эту модель: основными рычагами давления выступают нарушение операционной деятельности и угроза эскалации, а не блокирование доступа к данным посредством шифрования.

Мы удостоверились, что на момент проведения анализа данные в атакованных Windows-системах не были зашифрованы, отсутствовали вредоносные исполняемые файлы на дисках, механизмы закрепления на конечных устройствах и запущенные вредоносные процессы. Вся атака происходила непосредственно внутри Active Directory. С точки зрения защиты напрашивается очевидный вывод: организация, стратегия обнаружения которой опирается на выявление исполняемых файлов вымогательского ПО, заметила бы инцидент лишь после перезагрузки любого из устройств в атакованном домене, когда на рабочем столе появились обои с требованием выкупа.

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

Групповая политика как поверхность атаки

Использование в атаках групповых политик — техника не новая. Политики предоставляют широкие возможности и способны нанести существенный ущерб в масштабах всего домена, если к ним получит доступ злоумышленник. По своей сути объект групповой политики (GPO) представляет собой комбинацию контейнера групповой политики (GPC) в Active Directory и шаблона групповой политики (GPT) в SYSVOL. Область действия групповой политики зависит от того, на каком уровне GPC связан с деревом каталога: на уровне домена, сайта или подразделения (OU). Привязка GPC на уровне корня домена означает, что политике подчиняются все объекты компьютеров и пользователей в соответствующей ветви иерархии. Таким образом, скомпрометированный GPO на уровне корня домена может затронуть всех пользователей и все компьютеры в этом домене, потенциально предоставляя злоумышленнику полный контроль над корпоративной сетью. Злоупотребление GPO особенно опасно еще и тем, что групповые политики обрабатываются в доверенной среде с высокими привилегиями и могут обеспечивать закрепление в системе: обычной очистки конечных устройств недостаточно для их удаления.

Мы уже подробно обсуждали архитектуру GPO и способы ее компрометации в нашей предыдущей публикации. Эта техника также была неоднократно описана в общедоступных аналитических отчетах об угрозах, посвященных вымогательским операциям. Так, специалисты Microsoft наблюдали, как операторы Ryuk распространяли вымогательское ПО с помощью групповых политик, механизмов автозапуска в SYSVOL и инструмента PsExec. Также было зафиксировано, что аффилированные с LockBit злоумышленники модифицировали файлы групповых политик в SYSVOL, включая ScheduledTasks.xml, для запуска и распространения вымогательского ПО. Операторы BlackCat/ALPHV тоже использовали GPO для создания запланированных задач и развертывания вымогательского ПО.

Вымогательская кампания PAYLOAD — это еще один пример злоупотребления GPO. Она примечательна тем, что в ней используются механизмы предпочтений групповой политики (GPP) и параметры политик непосредственно на этапе воздействия, а не в качестве механизма запуска шифровальщика. Давайте подробнее рассмотрим эту атаку.

Хронология атаки

В ходе расследования инцидента в апреле 2026 года мы восстановили хронологию атаки, которую приводим ниже:

Дата	Событие
11 апреля	Первоначальный доступ. Злоумышленник аутентифицировался в FortiGate SSL VPN с помощью скомпрометированных действительных учетных данных домена.
13 апреля	Создание GPO. Был создан и привязан к корню домена вредоносный объект групповой политики (GPO) с именем PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}). В нем настроено отображение сообщений с требованием выкупа, изменение обоев рабочего стола и экрана блокировки, отображение баннера при входе в систему, а также отключение учетной записи администратора.
13 апреля	Размещение файлов в SYSVOL. Файлы payload.jpg и hello.txt записаны по пути \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
13 апреля	Второй GPO. GPO с именем win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) привязан к корню домена. Он отключает брандмауэр Windows для всех сетевых профилей.
13 апреля	Ожидание. GPO закэширован на конечных устройствах, но конфигурация компьютера еще не применена — с момента обновления политики ни одно конечное устройство не перезагружалось.
13 апреля	Эксфильтрация данных. Зафиксирована эксфильтрация данных с файловых серверов и нескольких дополнительных систем.
14 апреля	Активация. Большинство конечных устройств начинает перезагружаться, после чего применяются политики конфигурации компьютеров. На устройствах появляются текстовые файлы и обои с требованием выкупа, а также баннер при входе в систему. Нарушается работа организации.
15 апреля	Реагирование. Привлечена команда GERT. Начат криминалистический анализ данных с пораженных рабочих станций и контроллера домена.
16 апреля	Оценка. Команда GERT зафиксировала отсутствие шифрования данных, файлов вредоносного ПО на дисках и механизмов закрепления на конечных устройствах.

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

Обзор инцидента

Первоначальный доступ

Вектором проникновения стала скомпрометированная действительная учетная запись (техника MITRE ATT&CK T1078), с помощью которой злоумышленник аутентифицировался через используемое организацией решение FortiGate SSL VPN — внешнюю службу удаленного доступа (T1133). По причине недостаточной детализации логирования на устройстве FortiGate мы не смогли установить, каким именно образом учетные данные были скомпрометированы изначально.

В контексте данного инцидента рассматривались три правдоподобные и равновероятные гипотезы:

• атака методом проверки распространенных паролей (password spraying) или подстановки учетных данных (credential stuffing) через портал SSL VPN;
• сбор учетных данных с помощью фишинга;
• приобретение ранее скомпрометированных учетных данных у брокера первоначального доступа.

Оказавшись во внутренней сети, злоумышленник действовал с привилегиями скомпрометированной учетной записи. Поскольку учетная запись позволяла создавать GPO и связывать их с корнем домена, она обладала либо правами администратора домена, либо эквивалентными делегированными полномочиями (например, за счет членства в группе Group Policy Creator Owners в сочетании с правами на связывание объектов на уровне домена).

По логам аутентификации FortiGate SSL VPN и повышения привилегий в гипервизоре ESXi/среде виртуализации, к сожалению, не удалось восстановить цепочку дальнейшего распространения в сети и повышения привилегий с момента первоначального доступа через VPN и до получения прав на запись GPO. Наиболее распространенные на практике пути получения контроля над GPO — DCSync, кражу хэшей привилегированных сервисных учетных записей (Kerberoasting), а также техники pass-the-hash и pass-the-ticket — не удалось ни подтвердить, ни исключить.

Выполнение

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

Объект групповой политики PAYLOAD

Мы провели анализ результирующего набора политик (Resultant Set of Policy, RSOP), что позволило определить все параметры групповых политик, примененные к пораженным рабочим станциям. На основе этого анализа мы восстановили следующие изменения, внесенные политикой PAYLOAD:

Расширение GPO/клиентское расширение (CSE)	Параметр/путь	Настроенное значение/итоговое действие
Файлы (Group Policy Files, предпочтение групповой политики)	Исходный файл SYSVOL\hello.txt → рабочий стол, C:\ и D:\	Сохранен под именем README-payload.txt (только для чтения)
Реестр (Group Policy Registry, компьютер)	HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption	Строка «Welcome to Payload!»
Реестр (Group Policy Registry, компьютер)	HKLM\…\Policies\System\legalnoticetext	(Текст с требованием выкупа)
Политика персонализации	Изображение экрана блокировки	\\DC.THECOMPANY.local\sysvol\…\payload.jpg
Политика рабочего стола (пользователь)	Путь к обоям	\\DC.THECOMPANY.local\sysvol\…\payload.jpg
Параметры безопасности (GptTmpl.inf)	Учетные записи: состояние учетной записи администратора	Отключена

Объект групповой политики PAYLOAD фактически обеспечил выполнение следующих действий:

1. Размещение файла SYSVOL\hello.txt на рабочем столе и в корневых каталогах C:\ и D:\ под именем README-payload.txt с атрибутом «только для чтения» посредством клиентского расширения (CSE) Group Policy Files.
2. Изменение раздела реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\: параметру legalnoticecaption присвоено значение «Welcome to Payload!» («Вас приветствует Payload!»), а параметру legalnoticetext — текст с требованием выкупа. Изменения выполнены посредством CSE Group Policy Registry.
3. Установка изображения payload.jpg, расположенного в каталоге SYSVOL целевого контроллера домена, в качестве фона экрана блокировки посредством изменения политики персонализации, а также в качестве обоев рабочего стола путем модификации пользовательской политики рабочего стола.
4. Отзыв административных прав у учетной записи администратора, фактически приведший к блокированию учетной записи, посредством изменения настроек CSE Security Settings в файле GptTmpl.inf.

Параметры, измененные объектом групповой политики PAYLOAD

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

Объект групповой политики win Firewall Off

Второй GPO, привязанный к корню домена и получивший имя win Firewall Off, отключил брандмауэр Windows для профилей Domain, Private и Public на всех конечных устройствах (T1562.004). Этот объект, развернутый независимо от PAYLOAD, ослабил защиту хостов и обеспечил злоумышленнику беспрепятственный сетевой доступ к конечным устройствам для выполнения последующих действий.

Однодневная задержка перед активацией

Наиболее значимой с точки зрения криминалистического анализа деталью является однодневный интервал между созданием GPO (13 апреля) и проявлением видимых последствий (14 апреля). Анализ временных меток главной файловой таблицы (MFT) и раздела реестра Group Policy History подтвердил, что политика была записана в SYSVOL и кэширована конечными устройствами 13 апреля. Однако измененная конфигурация компьютера — настройки обоев и экрана блокировки, параметры безопасности и отключение брандмауэра — применяется после его перезагрузки или при обновлении групповой политики. В течение дня ни одно конечное устройство не перезагружалось. Все это время атака оставалась в состоянии ожидания в кэше GPO и стала заметна только после перезагрузки компьютеров в рамках плановых регламентных процедур.

Следует отметить, что привязка активации атаки к перезагрузке компьютеров характерна для атак с использованием GPO и предполагает два потенциальных последствия, которые необходимо учитывать специалистам по безопасности. Во-первых, задержка предоставляет злоумышленнику временное окно для скрытой эксфильтрации данных, закрепления в системе или подготовки дополнительных этапов атаки между созданием вредоносных политик и активацией. Во-вторых, временная связь между причиной (событием создания GPO, зафиксированным в логе каталога) и следствием (последующим массовым нарушением работы систем, заметным для пользователей) становится менее очевидной. Это усложняет восстановление хронологии инцидента, особенно если в организации не настроено логирование событий служб каталогов.

Результаты криминалистического анализа

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

1. Отсутствие шифрования файлов
   Полный анализ MFT на затронутых рабочих станциях не выявил файлов с расширением .payload, характерным для шифровальщика PAYLOAD, а также признаков массового переименования файлов или паттернов операций ввода-вывода, характерных для процессов шифрования. Целью вымогателей было нарушение операционной деятельности и получение выкупа за счет визуального воздействия и блокирования доступа к системам.
2. Отсутствие механизмов закрепления на конечных устройствах
   Мы не нашли никаких следов в стандартных местах закрепления в системе:
   • Задачи планировщика — вредоносные задачи отсутствуют.
   • Разделы реестра Run/RunOnce — чисто.
   • Папки автозагрузки (пользовательские и системные) — без изменений.
   • Службы — вредоносные службы не устанавливались.
   • Подписки на события WMI — отсутствуют.
   • Загрузочный сектор/MBR — изменений не выявлено.

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

3. Отсутствие активных вредоносных процессов
   Анализ процессов и оперативной памяти работающих систем не выявил внедрения потоков, подмены процессов (process hollowing) или аномальных исходящих сетевых соединений.
4. Анализ хронологии реестра
   В разделах реестра Group Policy History, Shadow и State на рабочей станции 13 апреля зафиксировано применение политики PAYLOAD:
   HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1
   HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0
   HKLM\…\Group Policy\State\Machine\GPO-List\7
   HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1
   HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5
   Наличие записи «Loopback-GPO-List» указывает на обработку объекта GPO в режиме loopback, благодаря чему пользовательская конфигурация (в частности, обои рабочего стола) применялась независимо от учетной записи, использованной для входа в систему.
5. Артефакты в SYSVOL
   Два файла были размещены в сетевом ресурсе SYSVOL контроллера домена, а затем переданы на конечные устройства как предпочтение групповой политики через клиентское расширение Group Policy Files:
   • payload.jpg — изображение с требованием выкупа, которое использовалось в качестве обоев рабочего стола и фона экрана блокировки;
   • hello.txt — файл с требованием выкупа, который копировался на рабочие столы и в корневые каталоги дисков под именем README-payload.txt.

Методология обнаружения

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

• Аудит изменений службы каталогов
  Включите параметр Advanced Audit Policy → DS Access → Audit Directory Service Changes (Расширенная политика аудита → Доступ к службе каталогов → Аудит изменения службы каталогов) на всех контроллерах домена и настройте оповещения для следующих событий:

  ID события	Описание	На что обратить внимание
  5137	Создан объект службы каталогов	Учетная запись, создающая новые объекты groupPolicyContainer, должна принадлежать уполномоченному администратору GPO.
  5136	Изменен объект службы каталогов	Изменения атрибута gPLink в корне домена или критически важных подразделениях, а также изменения атрибутов gPCMachineExtensionNames, gPCUserExtensionNames, gPCFileSysPath и versionNumber любых GPO.
  5141	Удален объект службы каталогов	События удаления GPO могут указывать на попытки скрытия следов и помочь в нейтрализации угрозы.

  Модификация атрибута gPLink в корне домена с использованием нестандартной учетной записи является одним из наиболее явных индикаторов атак этого класса.

• Мониторинг целостности файлов SYSVOL
  Отслеживайте появление аномальных файлов в каталоге \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\, особенно изображений, текстовых файлов, скриптов, файлов ScheduledTasks.xml, а также изменений в файлах registry.pol и GptTmpl.inf, не связанных с легитимной репликацией.
• Телеметрия применения политик на конечных устройствах
  На конечных устройствах применение GPO фиксируется в логе Group Policy Operational (Microsoft-Windows-GroupPolicy/Operational) и отражается в указанных выше разделах реестра History и Shadow. Внезапное изменение набора применяемых политик на уровне всего домена является серьезным признаком произошедшей атаки.
• Отсутствие событий с ID 5136
  Если содержимое GPO в SYSVOL было изменено без соответствующего события с ID 5136, это может указывать на прямое редактирование шаблонов GPO в SYSVOL, например с помощью инструментов с открытым исходным кодом PowerView или SharpGPOAbuse, в обход стандартного механизма внесения изменений через консоль управления групповыми политиками (GPMC). Отметим, что отсутствие ожидаемых событий аудита может быть как признаком подозрительной активности, так и следствием некорректной настройки аудита.

Затруднение криминалистического анализа и восстановления систем

Подтвержденные возможности семейства PAYLOAD

Описанная в этом отчете атака на Windows-машины была реализована с использованием вредоносных объектов групповых политик. На момент проведения криминалистической экспертизы не было выявлено файлов программы-вымогателя, признаков наличия вредоносного ПО на конечных устройствах, зашифрованных файлов или активных вредоносных процессов. Тем не менее, шифровальщик PAYLOAD для Windows существует, и на основании других источников, включая общедоступные отчеты об анализе образцов PAYLOAD, можно получить представление о дополнительных вредоносных возможностях этой угрозы, помимо описанных выше. Эти сведения могут помочь командам защиты расширить логику обнаружения и усовершенствовать политики безопасности.

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

Очистка журналов событий Windows

Общедоступные отчеты о реверс-инжиниринге Windows-варианта PAYLOAD указывают на наличие опциональной функции очистки журналов событий (T1685.005, ранее T1070.001). Программа-вымогатель динамически разрешает функции API журналов событий Windows, перебирает доступные каналы логов и очищает каждый из них в отдельности.
Артефакты реализации:

• загрузка wevtapi.dll во время выполнения;
• EvtOpenChannelEnum;
• EvtNextChannelPath;
• EvtClearLog;
• перебор журналов «Безопасность» (Security), «Система» (System), «Приложение» (Application) и PowerShell, а также операционных каналов;
• параметр командной строки для активации очистки логов.

Очистка журналов событий сокращает объем доступной информации о выполнении процессов, аутентификации, активности PowerShell, управлении службами и системных изменениях. Однако она не обязательно означает удаление событий, которые ранее были переданы в SIEM, Сборщик событий Windows (WEC), бэкенд EDR или защищенный архив логов.

Криминалистические индикаторы

• Событие безопасности Windows с ID 1102
• События остановки или сбоя службы регистрации событий
• Внезапное уменьшение идентификаторов записей событий
• Перезапуск нескольких каналов событий с малых номеров записей
• Расхождения между телеметрией на конечных устройствах и централизованно пересланной телеметрией
• Выполнение утилит или вызовов API, связанных с управлением логами
• Прямой доступ к файлам EVTX (файлам журналов событий Windows) в папке журналов событий Windows

Следует отметить, что эти индикаторы нельзя интерпретировать изолированно. Например, событие с ID 1102 следует сопоставлять с рядом подкрепляющих признаков, таких как:

• событие с ID 4688 (журнал событий Windows) или ID 1 (Sysmon), свидетельствующее о создании процесса;
• событие с ID 4624, соответствующее административному входу в систему;
• деревья процессов в EDR;
• операционные логи PowerShell;
• записи системы пересылки событий Windows (WEF);
• активность в системах управления привилегированным доступом (PAM).

В то же время отсутствие события ID 1102 не доказывает, что очистка логов не производилась. Прямое удаление или усечение файлов, нарушение работы служб или неполная настройка аудита могут оставлять иные следы.

Завершение процессов и служб безопасности

Анализ Windows-версии PAYLOAD выявил наличие в ней логики, направленной на противодействие работе процессов и служб безопасности (T1685 и T1489). С ее помощью зловред пытается остановить защитные продукты, программное обеспечение для резервного копирования, службы баз данных и приложения, которые могут блокировать файлы, предназначенные для шифрования.

Завершение процессов и остановка служб преследуют несколько целей:

1. Снижение видимости активности для средств обнаружения и реагирования на рабочих местах (EDR).
2. Освобождение файловых дескрипторов для последующего изменения данных.
3. Прерывание работы служб резервного копирования и восстановления.
4. Снятие защиты с файлов, занятых работающими базами данных и корпоративными приложениями.
5. Минимизация препятствий для выполнения операций шифрования.

Криминалистические индикаторы

• Остановка служб агентов безопасности
• Событие с ID 7036, фиксирующее изменение состояния служб
• Событие с ID 7040, фиксирующее изменение типа запуска служб
• Событие с ID 4688 (журнал событий Windows) или ID 1 (Sysmon), связанное с запуском утилит управления службами
• Событие с ID 5 в Sysmon, фиксирующее завершение процессов
• Ухудшение работоспособности EDR, затрагивающее множество конечных устройств
• Многократные попытки завершения процессов, связанных с безопасностью или резервным копированием
• Запуск специализированных утилит для принудительного завершения процессов

Удаление VSS и нарушение работы резервного копирования и восстановления

Общедоступные отчеты об анализе образцов PAYLOAD указывают на удаление теневых копий томов Windows (VSS) перед началом шифрования (T1490). Зловред удаляет локальные точки восстановления, снижая шансы жертвы восстановить файлы без использования внешних резервных копий.
Противодействие восстановлению не ограничивается удалением VSS и может включать ряд других вредоносных техник, в том числе:

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

Образец PAYLOAD для Windows, который, как установили исследователи, шифровал файлы, также, по подтвержденным данным, удалял VSS перед началом шифрования. Более широкая компрометация платформ резервного копирования в рамках расследуемого инцидента не была установлена.

Криминалистические индикаторы

• Запуск утилит управления теневыми копиями
• Попытки удаления каталогов с резервными копиями
• Изменение конфигурации средств восстановления
• Остановка или завершение работы служб резервного копирования
• Массовое удаление снапшотов
• Входы администраторов резервного копирования вне плановых окон обслуживания
• Изменение политик хранения или неизменяемости резервных копий
• Сбои заданий резервного копирования непосредственно перед началом вредоносной активности

Релевантные техники программ-вымогателей

Выше мы разобрали техники, специфичные для вымогательской кампании PAYLOAD и соответствующего шифровальщика. При этом существуют и другие техники, применяемые программами-вымогателями, такие как BYOVD (внедрение легитимного уязвимого драйвера) и ослабление политик ESXi. Они актуальны для данного типа угроз, однако без подтверждающей телеметрии с данными о загрузке драйверов, процессах, оперативной памяти, ESXi, vCenter или платформах резервного копирования мы не можем говорить об их использовании в данном инциденте. Ниже мы описываем эти техники, поскольку они могут иметь значение для других криминалистических расследований, связанных с атаками программ-вымогателей.

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

Нарушение работы ETW с патчингом кода в памяти

Трассировка событий Windows (Event Tracing for Windows, ETW) — поддерживаемая ядром архитектура трассировки, используемая компонентами Windows, диагностическими утилитами, средствами защиты и системами мониторинга конечных устройств.

Хотя мы не зафиксировали применение этой техники в ходе расследования, некоторые семейства программ-вымогателей могут динамически изменять функции, связанные с ETW, внутри собственного процесса (T1685, ранее T1562.001). В рамках этого подхода зловред изменяет уровень защиты памяти страниц кода, перезаписывает начало нужных функций ETW таким образом, чтобы они возвращали управление без генерации событий, после чего восстанавливает исходную защиту памяти и обновляет кэш инструкций.

В числе целевых функций упоминаются EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer и EtwRegister.

Модификация применяется к локальной для процесса области памяти, куда была загружена библиотека ntdll.dll. Она не отключает ETW глобально во всей системе Windows, однако может снизить объем телеметрии, генерируемой модифицированным процессом.

Криминалистические индикаторы

• Доступные для записи или недавно измененные исполняемые страницы памяти внутри ntdll.dll
• Изменения в защите памяти, затрагивающие адреса функций ETW
• Отличие кода в памяти от соответствующего оригинального файла DLL на диске
• Оповещения EDR о вмешательстве в память процессов
• Неожиданные вызовы API управления защитой памяти, после которых перестает поступать телеметрия
• Активность процесса, зафиксированная в сетевой телеметрии или файловой системе, но отсутствующая в ожидаемых источниках на базе ETW
• Несогласованность данных телеметрии между EDR, Sysmon, журналами событий Windows и средствами сетевого мониторинга

Стоит отметить, что пробелы в телеметрии нельзя считать убедительным доказательством патчинга ETW в памяти. Эти пропуски могут быть вызваны обновлением агентов, сбоями в сети, выключением конечных устройств, ошибками сбора данных в SIEM, перегрузкой коллекторов, а также изменениями в фильтрации или лицензировании.

Наиболее надежные доказательства патчинга ETW внутри процесса можно получить из дампа памяти.

Злоупотребление уязвимыми подписанными драйверами

Концепция Bring Your Own Vulnerable Driver (BYOVD) заключается во внедрении своего или злонамеренном использовании существующего легитимно подписанного, но уязвимого драйвера ядра (T1068 и T1685). Злоумышленник эксплуатирует уязвимые функции драйвера для получения привилегий уровня ядра, изменения защищенной памяти, завершения процессов средств защиты, удаления обратных вызовов (callbacks) защитных механизмов или обхода механизмов безопасности операционной системы.

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

Криминалистические индикаторы

• Аномальные файлы .sys, записанные в пользовательские или временные каталоги
• Появление новых служб, связанных с драйверами ядра
• Событие с ID 6 в Sysmon
• Хэш-суммы драйверов, присутствующие в списках заблокированных уязвимых драйверов Microsoft или сообщества специалистов по безопасности.
• Недействительные, отозванные, просроченные или нетипичные цифровые подписи драйверов
• Принудительное завершение работы EDR сразу после загрузки драйвера
• Появление новых привилегированных процессов сразу после загрузки драйвера
• Оповещения системы целостности кода или Защитника Windows
• События создания служб, ссылающиеся на файлы драйверов

Ослабление политик безопасности ESXi

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

Общедоступные исследования обычно описывают следующие действия операторов (T1685, T1490 и T1489):

• включение SSH на хостах ESXi;
• смена паролей пользователя root;
• отключение параметра execInstalledOnly;
• изменение исключений режима блокирования (lockdown mode);
• остановка виртуальных машин;
• удаление снапшотов и резервных копий;
• изменение правил сетевого экрана на хостах;
• копирование модифицированных исполняемых файлов вымогателей в гипервизоры.

Мы видели на Linux-серверах организации вариант PAYLOAD для ESXi, так что это поведение имеет практическое значение в контексте инцидента. Тем не менее изученные артефакты не подтверждают, что операторы PAYLOAD использовали какие-либо из перечисленных методов ослабления политик в рамках расследуемого инцидента.

Криминалистические индикаторы

• Несанкционированное включение SSH на хостах ESXi
• Изменение параметра execInstalledOnly
• Изменение настроек принудительного использования Secure Boot
• Изменение конфигурации режима блокирования (lockdown mode)
• Смена пароля пользователя root
• Появление новых или нетипичных учетных записей с правами администратора
• Массовое выключение виртуальных машин
• Массовое удаление снапшотов
• Появление новых исполняемых файлов в хранилищах данных (datastore) или временных каталогах
• Запуск задач vCenter с использованием нетипичных учетных записей или систем
• Отсутствие или отключение удаленной передачи логов по протоколу syslog

Устранение последствий

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

Этап 1. Действия на контроллерах домена (выполняются в первую очередь)

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

На контроллерах домена необходимо незамедлительно выполнить следующие действия:

1. Удалить объект групповой политики PAYLOAD. Для этого нужно удалить GPO с идентификатором {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} через консоль GPMC.
2. Удалить или отменить применение объекта групповой политики win Firewall Off. Для этого нужно удалить GPO с идентификатором {22099AD2-E062-4F56-B574-5099BBA4E7A6}.
3. Очистить SYSVOL. Нужно удалить jpg и hello.txt из \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
4. Сменить учетные данные. Для этого нужно: сбросить пароль скомпрометированной учетной записи; провести аудит всех привилегированных учетных записей и членства в группах на предмет несанкционированных изменений; при подтвержденной компрометации учетной записи администратора домена — выполнить двукратный сброс пароля учетной записи krbtgt.
5. Принудительно обновить групповые политики. После удаления вредоносных объектов нужно выполнить команду gpupdate /force на конечных устройствах, затем повторно включить учетную запись локального администратора и сетевой экран с помощью заведомо чистой групповой политики.

Этап 2. Усиление защиты Active Directory и GPO

• Внедрите многоуровневую модель администрирования Active Directory. Ограничьте учетные записи администраторов домена уровнем Tier 0, запретив им интерактивный вход на рабочие станции и серверы в домене.
• Разделите права на создание GPO и их привязку. Предоставляйте оба типа прав только выделенной роли администратора, для которой включен аудит.
• Включите аудит изменений GPO (события с ID 5136, 5137 и 5141) и настройте их передачу в SIEM.
• Организуйте мониторинг SYSVOL с использованием средств контроля целостности файлов.

Этап 3. Усиление защиты учетных данных и контроля доступа

• Внедрите устойчивую к фишингу многофакторную аутентификацию на всех точках входа через VPN и системы удаленного доступа.
• Разверните Windows LAPS для генерации уникальных паролей локальных администраторов с их регулярной ротацией.
• Включите Credential Guard для защиты секретов, хранящихся в памяти процесса LSASS.
• Внедрите рабочие станции с привилегированным доступом (PAW) для выполнения всех задач администрирования.
• Реализуйте повышение привилегий по запросу через систему управления привилегированным доступом (PIM) для администраторов домена.

Этап 4. Обнаружение и мониторинг

• Добавьте правило SIEM: создание GPO или изменение атрибута gPLink в корне домена нестандартной учетной записью.
• Добавьте правило SIEM: события создания файлов в SYSVOL из источников, не связанных с репликацией.
• Внедрите расширенное централизованное логирование FortiGate SSL VPN (события аутентификации, сведения о сессиях, геолокация исходных IP-адресов, выявление невозможных перемещений) и детальный мониторинг периметра.
• Создайте GPO-индикатор (canary), применение которого в любой части сети будет сигнализировать о получении злоумышленником прав на запись GPO.

Заключение

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

Среди особенностей этой атаки наиболее стратегически значимым является отсутствие шифрования файлов, что соответствует доминирующему тренду 2026 года. Со средней степенью уверенности наша команда GERT оценивает, что отсутствие шифрования может свидетельствовать об одном из двух сценариев: 1) злоумышленники осознанно отказались от необратимого уничтожения данных, сохранив при этом возможность последующего шифрования; либо 2) атака была прервана до ее полного завершения.

Отсутствие зашифрованных файлов не следует ошибочно трактовать как признак незначительной компрометации — наиболее критичным последствием является получение злоумышленником контроля на уровне администратора домена. Этот инцидент демонстрирует, что злоумышленник с привилегиями администратора домена и глубоким пониманием механизмов групповых политик способен нанести ущерб в масштабах всего домена, сопоставимый с последствиями атаки программы-вымогателя, не разместив при этом ни одного вредоносного файла на конечных устройствах.

Стратегии обнаружения, основанные исключительно на файловых или процессных индикаторах, бесполезны против данного класса атак. Эффективная защита GPO требует аудита изменений в службе каталогов, мониторинга целостности SYSVOL и строгого управления привилегированным доступом.

Детектирование решениями «Лаборатории Касперского»

Решения «Лаборатории Касперского» эффективно выявляют описанную вредоносную активность на разных этапах атаки. Ниже приведены возможные сценарии обнаружения.

Для защиты компаний, использующих нашу SIEM-систему Kaspersky Unified Monitoring and Analysis Platform (KUMA), мы подготовили пакет правил корреляции, которые помогают обнаружить подобную вредоносную активность. Правила уже доступны клиентам для скачивания в репозитории KUMA; название пакета: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG.

Пакет Group policy hijacked: PAYLOAD ransomware содержит правила, детектирующие подозрительное создание или изменение файлов в общей папке SYSVOL на контроллере домена, изменение критичных атрибутов и настроек групповых политик домена. Некоторые правила могут потребовать корректировки в случае срабатывания на легитимную активность, например на синхронизацию между контроллерами домена и настройку новой групповой политики.

Для корректной работы правил обнаружения необходимо убедиться, что события с Windows-систем поступают в полном объеме, включая события со следующими идентификаторами: Sysmon — 11, Security — 4663, 5136, 4657.

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

• Обнаружение очистки журнала событий Windows для сокрытия следов атаки — R050_03_Очистка журнала событий Windows
• Выявление подозрительного доступа к процессу LSASS, который может свидетельствовать о попытках дампа учетных данных — R262_Подозрительный доступ к процессу LSASS
• Детектирование запуска службы Volume Shadow Copy, используемой в том числе для создания теневых копий перед их удалением — R231_20_Запуск службы Volume Shadow Copy
• Выявление удаления теневых копий — R321_Удаление теневой копии
• Обнаружение отключения антивирусной защиты Windows Defender — R076_01_Windows Defender Antivirus отключен
• Выявление попыток отключения или изменения системного межсетевого экрана — R240_03_Отключение межсетевого экрана через реестр
• Обнаружение установки службы из папки, не являющейся системной, что может указывать на закрепление вредоносного ПО — R281_01_Установка сервиса не из системной директории

Корректная работа правил из этого списка требует настройки аудита событий Security с идентификаторами 4663, 5136, 4657, 7036, 1102.
Помимо SIEM-системы, при должных настройках аудита процесс создания, модификации и удаления GPO сопровождается большим количеством характерных артефактов на контроллере домена, благодаря которым Kaspersky Endpoint Detection and Response Expert своевременно оповещает пользователя об аномалиях в инфраструктуре.

Создание нового GPO покрывается правилом gpo_creation, которое срабатывает на соответствующее событие в инфраструктуре. Изменения существующих политик детектируются следующими правилами:

• Правило setting_the_gpcmachineextensionname_attribute обнаруживает изменения атрибута gPCMachineExtensionNames;
• Setting_the_gpcfilesyspath_attribute в свою очередь обнаруживает использование атрибута объекта групповой политики gPCFileSysPath, который указывает путь к содержимому GPO в SYSVOL;
• Более широкое правило setting_the_grouppolicycontainer_class обнаруживает изменение класса groupPolicyContainer.

Удаление GPO сопровождается правилом gpo_deletion.

В следующем обновлении мажорной версии Kaspersky EDR Expert появится новый тип событий — GPO, который позволит отслеживать изменения в объектах групповой политики. Для специалиста по информационной безопасности события GPO станут дополнительным источником контекста при расследовании активности в Active Directory и помогут обнаруживать изменения, которые могут повлиять на конфигурацию, права доступа и защищенность конечных устройств до доставки потенциально вредоносной политики.

Сопоставление с базой знаний MITRE ATT&CK

Тактика	Техника	Наблюдаемое поведение
Initial Access	T1078 — Valid Accounts	Для аутентификации в VPN использовались скомпрометированные доменные учетные данные.
Initial Access	T1133 — External Remote Services	В качестве точки входа в инфраструктуру использовалось решение FortiGate SSL VPN.
Privilege Escalation	T1078.002 — Domain Accounts	Учетная запись обладала правами на создание и привязку GPO на уровне домена.
Privilege Escalation/Defense Impairment	T1484.001 — Group Policy Modification	Вредоносный объект групповой политики PAYLOAD был создан и привязан к корню домена. Он повторно применялся при каждом обновлении политик и перезагрузке. Злоумышленники использовали доверенный канал, чтобы обойти EDR.
Defense Impairment	T1686 — Disable or Modify System Firewall	Объект групповой политики win Firewall Off отключил брандмауэр Windows во всех профилях.
Impact	T1491.001 — Internal Defacement	Обои рабочего стола и экран блокировки были заменены изображением с требованием выкупа.
Impact	T1531 — Account Access Removal	Учетная запись локального администратора была отключена через параметры безопасности GPO.
Collection	T1005 — Data from Local System	Была зафиксирована эксфильтрация данных с файловых серверов.
Command and Control	T1071 — Application Layer Protocol	Не удалось подтвердить наличие активного командного сервера; вредоносное воздействие производилось исключительно посредством GPO.

Индикаторы компрометации

Объекты групповой политики
Объект групповой политики PAYLOAD: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}
Объект групповой политики win Firewall Off: {22099AD2-E062-4F56-B574-5099BBA4E7A6}

Имена файлов и хэши MD5
payload.jpg: изображение для обоев рабочего стола и экрана блокировки с требованием выкупа (SYSVOL)
hello.txt: исходный файл с требованием выкупа (SYSVOL)
README-payload.txt: файл с требованием выкупа, размещенный на рабочих столах и в корнях дисков
killer.exe (0108656A3E1ADE6CA4F21B084F5E1208): инструмент принудительного завершения процессов
kill.exe (BEA5E267F24D7DA59F6821BFFDBFF293): инструмент принудительного завершения процессов

IP-адреса
37.19.210[.]12
146.70.117[.]239
149.102.229[.]154
104.164.55[.]46
104.28.162[.]228
104.28.163[.]162
64.190.76[.]14
192.42.116[.]50
192.42.116[.]12
192.42.116[.]56
192.42.116[.]97
192.42.116[.]52

Разделы реестра
HKLM\...\Policies\System\legalnoticecaption = "Welcome to Payload!"

Путь SYSVOL
\\DC.THECOMPANY.local\sysvol\THECOMPANY.local\payload.jpg

Идентификаторы событий
5137: создание объекта GPO на контроллере домена — проверить учетную запись создателя
5136: изменение атрибута GPO — отслеживать gPLink в корне домена