Я запустил whoami из 1С, а SIEM промолчала. Как ловить выполнение кода через внешние обработки / Хабр

Открываю внешнюю обработку в 1С. Нажимаю кнопку. В окне появляется ws01\wc01.

Это whoami, выполненный из обычной обработки .epf. Уязвимости тут нет, так устроена платформа. Меня интересовало другое: увидит ли это SOC. База на стенде файловая и работает на рабочей станции; что меняется на сервере 1С, расскажу ниже.

Иду в журнал регистрации 1С. Пусто: ни открытия обработки, ни запуска команды. Только пара транзакций Begin/Commit.

Иду в SIEM. Тоже пусто: правил под это нет ни у меня, ни, скорее всего, у вас.

Внешняя обработка в 1С выполнила whoami

Для атакующего 1С — золотая жила. В одной системе лежат деньги, зарплаты, контрагенты и персональные данные, а у администратора базы есть штатный способ выполнить любой код на машине, где она работает. 1С стоит в большинстве российских компаний, но в SOC, которые я видел на проектах, журнал 1С не собирали: SIEM получает логи домена, почты и файрволов, а 1С остаётся слепым пятном.

И дело не только в данных. Штатными средствами 1С можно запустить процесс (WScript.Shell), сходить по HTTP (HTTPСоединение) и отправить почту (ИнтернетПочтаПрофиль). А с доступом к Конфигуратору код в общем модуле после F7 выполняется у каждого, кто откроет базу: закладка сразу на всю организацию, без установки чего-либо лишнего.

На пентестах я не раз заходил в инфраструктуру через 1С. Встречал и веб-публикации 1С, открытые в интернет, и тогда всё решает пароль.

Как атакуют 1С, на Хабре написано хорошо, причём про разные векторы, от консоли кластера до внешних обработок (раз, два, три).

Со стороны защиты тоже есть материалы. Kaspersky разобрал, где искать следы компрометации 1С при расследовании, а в разборе на codeby есть чек-лист для SIEM и Sigma-правило на дочерние процессы rphost.exe.

В коммерческих SIEM 1С тоже не забыта: в KUMA есть коннектор для журнала регистрации (через выгрузку в XML), для MaxPatrol SIEM Positive Technologies представляла пакет экспертизы 1С.

Но открытого набора, который забирает журнал регистрации в SIEM, ловит запуск процессов из 1С и проверен на атаках, я не нашёл, а состав закрытых пакетов неизвестен. Поэтому собрал стенд, атаковал свою 1С и написал правила под каждую атаку.

В статье:

что 1С пишет в журнал регистрации, а что нет;
где лежит журнал регистрации и как забрать его в SIEM;
правила: подбор пароля, вход после подбора, создание и удаление пользователя, изменение конфигурации, выполнение команд из внешних обработок;
почему через веб-клиент детект сначала промолчал;
что по-прежнему не ловится.

Сборщик и правила выложил на GitHub: можно брать и дорабатывать под себя.

Как это используют в атаках

Внешние обработки — штатный механизм 1С: файл .epf с кодом, который пользователь открывает через «Файл → Открыть». Код выполняется с правами процесса 1С. Начиная с 8.3.9 платформа при открытии показывает предупреждение защиты от опасных действий, но его достаточно подтвердить, а в свойствах пользователя защиту можно отключить. У администратора базы права на внешние обработки есть всегда.

В реальных атаках этим пользуются:

в кейсе Solar пентестеры подобрали доменные пароли, с ними вошли в 1С, через штатную загрузку внешней обработки залили веб-шелл и вышли во внутреннюю сеть;
в разборе на codeby цепочка такая: веб-публикация 1С → .epf → rphost.exe → повышение прав → GPO → шифровальщик.

В обоих случаях 1С — точка входа, а код выполняется штатной функцией платформы.

Почему это ещё и повышение привилегий

Код обработки работает с правами процесса 1С. Клиентский код выполняется от имени пользователя, который открыл обработку (в файловой базе через толстый клиент — и серверный тоже). Серверный код клиент-серверной базы или веб-публикации выполняется от имени сервера 1С или пула IIS. И вот здесь права обычно выше, чем нужно:

сервер 1С (ragent, rphost) часто запускают под LocalSystem или под служебной учёткой, которую добавили в локальные администраторы, «чтобы всё работало». Тогда серверный код обработки сразу получает SYSTEM или администратора на сервере 1С, а это обычно сервер, где лежат все базы компании.
даже под отдельной учёткой у службы есть привилегия SeImpersonatePrivilege, как и у пула IIS. Это классический путь до SYSTEM через атаки семейства Potato (T1134.001). На стенде whoami /priv из обработки через веб-клиент выполнился от имени пула DefaultAppPool, и SeImpersonatePrivilege у него включена.
права в 1С и права в Windows никак не связаны. Бухгалтер с ролью администратора базы или пользователь, которому разрешили внешние обработки, на сервере не имеет ничего. Но через обработку он выполняет код с правами учётки сервера 1С.

Разницу видно на одной и той же обработке. Через толстый клиент whoami /priv показывает пять привилегий обычного пользователя. Через веб-клиент та же команда показывает уже десять, среди них SeImpersonatePrivilege и SeAssignPrimaryTokenPrivilege: код выполнился от имени пула IIS.

Толстый клиент: код выполняется от имени пользователя, 5 привилегий

Веб-клиент: та же обработка, код выполняется от имени пула IIS, 10 привилегий, SeImpersonatePrivilege включена

Поэтому в цепочке из разбора codeby между rphost.exe и GPO стоит повышение прав: 1С дала выполнение кода на сервере, а дальше до домена недалеко.

Стенд

Машина	Что там
WS01	Windows 11 (build 26300, 1С показывает её как Windows 10), 1С:Предприятие 8.3.16 (учебная), файловая база, веб-публикация в IIS, агент Wazuh
siem	Ubuntu 22.04, Wazuh 4.12 (менеджер + индексатор)

Ограничение стенда сразу: база файловая, учебная платформа 8.3.16, без БСП. Всё, что ниже сказано о поведении журнала, проверено на этой конфигурации. Платформа не самая свежая, и на 8.3.2x и с типовой конфигурацией часть деталей может отличаться — об этом в конце. Если у вас актуальная платформа, проверьте и напишите в комментариях: дополню.

Модель угроз

Что может сделать атакующий с 1С и чем это видно:

Атака	MITRE ATT&CK	Где след	Правило
Подбор пароля к базе	T1110.001	журнал регистрации	`1c_bruteforce.yml`
Вход после подбора	T1110, T1078	журнал регистрации	`1c_login_after_bruteforce.yml`
Создание пользователя базы	T1136	журнал регистрации	`1c_user_created.yml`
Удаление пользователя базы	T1531	журнал регистрации	`1c_user_deleted.yml`
Изменение конфигурации (закладка)	T1505	журнал регистрации	`1c_config_update.yml`
Выполнение команд из внешней обработки	T1059	только события Windows	`1c_shell_spawn.yml` и ещё два
Повышение прав через учётку сервера 1С	T1134.001	события Windows	первый шаг — `1c_shell_spawn.yml`

Журнал регистрации и как его забрать

У 1С два журнала. Технологический — отладочный: включается отдельно (logcfg.xml), огромный и для постоянного сбора не годится. Журнал регистрации пишется всегда: входы, ошибки входа, изменения пользователей и конфигурации. Его и берём.

Обычного лога, который агент SIEM мог бы читать построчно, 1С не даёт. Журнал хранится в своём формате: события ссылаются на справочник по номерам, а одна запись растянута на несколько строк со вложенными скобками. Поэтому между 1С и агентом нужен скрипт, который переводит журнал в JSON.

Журнал лежит в каталоге 1Cv8Log:

База	Где
Файловая	`<каталог базы>\1Cv8Log` (каталог виден в списке баз окна запуска)
Клиент-серверная	`<srvinfo>\reg_1541\<GUID базы>\1Cv8Log`, обычно `C:\Program Files\1cv8\srvinfo\...`

Что в нём:

1Cv8.lgf — справочник: пользователи, компьютеры, приложения, типы событий, у каждого свой номер. Дописывается по ходу: пользователь попадает в справочник при первом событии с ним;
*.lgp — сами события. Имя файла — дата и время его начала (20261026000000.lgp), новый файл заводится по периоду из настроек журнала. Вместо имён в записях стоят номера из .lgf;
1Cv8.lgd — другой формат, всё в одном файле SQLite. Включается отдельно, мой сборщик его пока не читает.

Запись справочника выглядит как {4,"_$Session$_.AuthenticationError",10}: тип (4 — событие), значение и номер, на который ссылаются записи .lgp.

Правила пишутся по ASCII-идентификаторам событий: _$Session$_.Authentication, _$Session$_.AuthenticationError, _$User$_.New, _$InfoBase$_.ConfigUpdate. В интерфейсе 1С их не видно, там «Сеанс. Ошибка аутентификации».

Сборщик onec_shipper.py работает службой Windows: читает новые записи .lgp, подставляет имена из .lgf и дописывает события в C:\ProgramData\1c-eventlog\events.json, по одному JSON на строку. Позицию чтения он хранит в checkpoint.json и после перезапуска продолжает с того же места. Файл забирает агент SIEM, который у вас уже стоит, в режиме JSON; промежуточные серверы не нужны. Ставится сборщик одним скриптом install.ps1, инструкция — в README репозитория.

Событие на выходе:

{"integration":"1c","ib":"demo","ts":"2026-11-05T17:05:35","ev":{"id":"_$Session$_.AuthenticationError","level":"information","data":"WS01\\WC01"},"user":{"name":""},"computer":"WS01","app":"1CV8","session":2,"comment":""}

Почему поле ev, а не event: имя event может быть уже занято в схеме вашей SIEM. В Wazuh, например, data.event в шаблоне индекса — строка, и событие с объектом в этом поле не проиндексируется. Учтите при переименовании полей.

Правила по журналу регистрации

Все правила есть в двух вариантах: Sigma, которая конвертируется под большинство SIEM, и нативные правила Wazuh, на котором работает стенд. В тексте — логика, сами правила — под спойлерами и в репозитории.

Подбор пароля

Логика в три шага:

ошибка входа — событие _$Session$_.AuthenticationError, само по себе низкий уровень;
подбор — пять ошибок за 60 секунд в одной базе;
вход после подбора — успешный _$Session$_.Authentication в ту же базу в течение двух минут после подбора, уровень critical.

И сразу неприятная находка. На моём стенде каждый обычный вход в 1С пишет AuthenticationError. Платформа сначала пробует аутентификацию ОС, получает отказ, пишет ошибку и только потом пускает по паролю. Запись выглядит так же, как запись при неверном пароле.

Пользователь в ней пустой, в данных — только учётка Windows, под которой запущен клиент (WS01\WC01). Поэтому сгруппировать ошибки по пользователю 1С нельзя — только по базе. Учётку Windows сборщик передаёт в ev.data, но через веб-клиент там у всех один и тот же NT AUTHORITY\IUSR, так что и она не спасает.

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

Выходит, одна ошибка входа ничего не значит. А утром, когда пять человек за минуту входят в одну базу, корреляция сработает, а за ней и «вход после подбора». Порог надо подбирать под свою базу: на маленькой бухгалтерии пять за минуту — редкость, на базе с сотней пользователей — нет.

Подбор пароля и вход после подбора. Пятая ошибка показана как «подбор пароля»: в Wazuh одно событие даёт один алерт, по самому конкретному правилу

Правила подбора пароля для Wazuh

<rule id="100101" level="5">
  <if_sid>100100</if_sid>
  <field name="ev.id" type="pcre2">^_\$Session\$_\.AuthenticationError$</field>
  <description>1С: неудачный вход</description>
  <mitre><id>T1110</id></mitre>
</rule>

<rule id="100102" level="10" frequency="5" timeframe="60">
  <if_matched_sid>100101</if_matched_sid>
  <same_field>ib</same_field>
  <description>1С: подбор пароля - 5 неудачных входов за 60 с</description>
  <mitre><id>T1110.001</id></mitre>
</rule>

Правила немного сокращены, полные — в репозитории.

Пользователь и конфигурация

Три простых правила, по ID события:

_$User$_.New — создан пользователь базы (T1136). Так атакующий заводит учётку, чтобы закрепиться;
_$User$_.Delete — удалён пользователь (T1531). Так отбирают доступ у сотрудников или заметают следы;
_$InfoBase$_.ConfigUpdate — изменена конфигурация (T1505). Так ставят закладку прямо в код базы.

Имя пользователя в записи журнала есть, но не в «представлении данных», а внутри самих данных. Сборщик достаёт его оттуда, и в алерте видно, кого создали или удалили.

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

Ложные срабатывания — плановая работа администратора 1С, поэтому их стоит сверять с заявками.

Как это выглядит в SIEM

Создание и удаление пользователя видны с именем, изменение конфигурации — только как факт

Внешние обработки: журнал молчит

Теперь главное. Я открыл свою обработку в «Предприятии» и в «Конфигураторе» и стал смотреть, что появилось в журнале регистрации.

Ничего. Ни нового типа события в .lgf, ни записи в .lgp. Открытие внешней обработки на моём стенде журнал регистрации не фиксирует вообще. Видны только транзакции. Что пишет в этом случае типовая конфигурация с БСП, я не проверял.

Одна зацепка всё же есть: если в коде обработки ошибка, в журнал попадает _$PerformError$_ с именем обработки в комментарии ({ВнешняяОбработка.РегистрацияВнешнейОбработки.Форма...}). На такие ошибки советуют смотреть и Kaspersky, и codeby. Но рассчитывать на ошибку в коде атакующего — не стратегия.

Значит, ловить надо то, что обработка делает. Чаще всего она запускает процесс.

Три способа запустить команду из 1С

Обработка-консоль, которую я использовал, умеет три способа: Новый COMОбъект("WScript.Shell"), Новый COMОбъект("Shell.Application") и встроенная ЗапуститьПриложение(). Я запустил whoami всеми тремя и посмотрел на события создания процессов Windows (Security 4688):

17:33:59  1cv8t.exe -> cmd.exe   cmd.exe /C "whoami"
17:34:04  cmd.exe   -> whoami.exe
17:34:10  1cv8t.exe -> cmd.exe   "C:\Windows\System32\cmd.exe" /C "whoami > ...\Temp\res.txt"
17:34:22  1cv8t.exe -> cmd.exe   cmd.exe /c "whoami > ...\Temp\res.txt"

Для операционной системы все три способа выглядят одинаково: COM-объекты создаются внутри процесса 1С, поэтому родитель cmd.exe — тот процесс 1С, где выполнялся код. В файловом режиме клиента это сам клиент. В клиент-серверной базе код &НаКлиенте запустит процесс на машине пользователя, а &НаСервере — в rphost на сервере 1С. Различаются только командные строки, а их пишет автор обработки, и полагаться на них нельзя.

Отсюда логика детекта: процесс 1С запустил командный интерпретатор или системную утилиту. Клиенту бухгалтерии незачем запускать cmd, powershell или certutil. Та же идея есть в Sigma-правиле на codeby, но только для rphost; здесь она расширена на клиентов 1С и веб-публикацию и дополнена связкой с дочерними процессами.

Для этого нужен аудит создания процессов с командной строкой (Security 4688). Если стоит Sysmon, то же видно в Event ID 1, сразу с ParentCommandLine и хэшами.

Как включить аудит процессов с командной строкой

auditpol /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

GUID вместо названия подкатегории — потому что на русской Windows названия другие и команда с английским названием не сработает. Sigma-правила написаны в терминах Sysmon; для 4688 нужен pipeline, который переводит поля NewProcessName/ParentProcessName в Image/ParentImage.

Правило 1: 1С запустила оболочку

Это главное правило статьи, поэтому покажу его целиком в Sigma (метаданные опущены):

logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\1cv8.exe'     # толстый клиент
            - '\1cv8c.exe'    # тонкий клиент
            - '\1cv8t.exe'    # учебные версии
            - '\1cv8ct.exe'
            - '\rphost.exe'   # рабочий процесс сервера 1С
            - '\w3wp.exe'     # веб-публикация в IIS, про неё ниже
    selection_child:
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\mshta.exe'
            - '\certutil.exe'
            - '\whoami.exe'
            # ... всего 15 интерпретаторов и утилит, список в репозитории
    condition: all of selection_*
level: high

Толстый клиент: 1cv8t.exe запустил cmd.exe (правило 1), внутри выполнен whoami (правило 3)

Ложные срабатывания — обработки и регламентные задания, которые штатно вызывают внешние программы: архиватор для выгрузки, скрипт печати. Их командные строки добавляются в исключения.

Правило 2: команда с выводом в файл

Посмотрите ещё раз на второй и третий запуск cmd: whoami > %TEMP%\res.txt. Так «консоль» в обработке возвращает результат: выполняет команду, пишет вывод во временный файл и читает его обратно в форму 1С. Случайно открытый cmd так себя не ведёт, это интерактивная работа атакующего.

Правило простое: сработало правило 1, и в командной строке есть >. Исключение — >nul и 2>&1: это не вывод в файл, а подавление вывода, и на стенде без исключения правило срабатывало на безобидном chcp 1251 >nul.

Но в Wazuh командная строка приходит такой:

cmd.exe /c "whoami &gt; C:\Users\WC01\AppData\Local\Temp\res.txt"

Символ > превратился в XML-сущность >, и правило с одним > молча не сработает. Поэтому ищем оба варианта. Как хранит командную строку ваша SIEM, проверьте на живом событии.

Правило 3: что выполнили внутри оболочки

whoami.exe в цепочке выше пришёл как обычное событие создания процесса: его родитель — cmd.exe, и 1С он никак не касается. Если обработка открыла консоль и дальше атакующий работает в ней, правило 1 сработает один раз, а все команды после — пройдут мимо.

Связать внука с дедушкой по PID умеет не каждая SIEM: в Wazuh, например, правило не сравнивает поле одного события с полем другого. Зато у всех процессов цепочки общий сеанс входа — SubjectLogonId, а группировать по полю умеет любая корреляция.

Логика такая: если в течение 10 минут после правила 1 в том же сеансе входа cmd или powershell что-то запустили — это продолжение атаки. conhost.exe исключаем: он появляется у каждого консольного процесса.

Где будут ложные срабатывания:

пользователь в том же сеансе сам открыл командную строку — на клиенте это возможно;
rphost или пул IIS работают под LocalSystem. У всех процессов SYSTEM один и тот же SubjectLogonId — 0x3E7, и после одного срабатывания правила 1 корреляция десять минут будет реагировать на любую консоль, запущенную любой службой. Лечится отдельной служебной учёткой для сервера 1С и пула приложений — это и без детекта правильная настройка.

Правила 1–3 для Wazuh

<rule id="100107" level="12">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4688$</field>
  <field name="win.eventdata.parentProcessName" type="pcre2">(?i)\\(1cv8[a-z]*|rphost|w3wp)\.exe$</field>
  <field name="win.eventdata.newProcessName" type="pcre2">(?i)\\(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|wmic|schtasks|whoami|net1?)\.exe$</field>
  <description>1С: $(win.eventdata.parentProcessName) запустил $(win.eventdata.newProcessName) - выполнение кода из обработки</description>
  <mitre><id>T1059</id></mitre>
</rule>

<rule id="100108" level="14">
  <if_sid>100107</if_sid>
  <field name="win.eventdata.commandLine" type="pcre2">(?i)(\x3e|\x26gt;)(?!\s*(nul\b|\x26))</field>
  <description>1С: команда из обработки с выводом в файл - $(win.eventdata.commandLine)</description>
  <mitre><id>T1059.003</id></mitre>
</rule>

<rule id="100109" level="12" timeframe="600">
  <if_matched_sid>100107</if_matched_sid>
  <if_sid>67027</if_sid>
  <same_field>win.eventdata.subjectLogonId</same_field>
  <field name="win.eventdata.parentProcessName" type="pcre2">(?i)\\(cmd|powershell|pwsh)\.exe$</field>
  <field name="win.eventdata.newProcessName" type="pcre2" negate="yes">(?i)\\conhost\.exe$</field>
  <description>1С: в оболочке, запущенной из 1С, выполнен $(win.eventdata.commandLine)</description>
  <mitre><id>T1059</id></mitre>
</rule>

> и > записаны через \x, чтобы не воевать с экранированием в XML самого правила. (?!\s*(nul\b|\x26)) пропускает >nul и 2>&1.

Поворот: веб-клиент

Правила работают, алерты летят. Последняя проверка — та же обработка, но через веб-клиент: база опубликована в IIS, захожу браузером, открываю .epf, запускаю whoami.

Алертов нет.

17:43:06  w3wp.exe -> cmd.exe     cmd.exe /C "whoami"     user: DefaultAppPool
17:43:06  cmd.exe  -> whoami.exe

У меня файловая база, а с файловой базой модуль веб-расширения 1С выполняет серверный код прямо в пуле приложений IIS, в w3wp.exe. Родитель cmd.exe — не 1cv8 и не rphost, а w3wp, и в первой версии правила его не было.

С клиент-серверной базой серверный код выполняется в rphost.exe — так и в разборе на codeby. Этот вариант правило 1 покрывает, но на стенде я его не проверял. А файловые базы с веб-публикацией — не экзотика для небольших компаний. Детект, проверенный только на толстом клиенте, такой сценарий пропустил бы.

После добавления w3wp в список родителей сработали правила 1 и 3: запуск оболочки и whoami внутри неё.

Веб-клиент: родитель — w3wp.exe. После добавления его в правило сработали правила 1 и 3

w3wp.exe обслуживает не только 1С. Если на том же IIS есть другие приложения, которые штатно запускают cmd, их пулы надо исключить. Хотя веб-приложение, запускающее cmd, — повод присмотреться и без 1С.

Ещё деталь: в первом прогоне через веб-клиент команды с выводом в файл не выполнились — у пула DefaultAppPool не было прав на запись в каталог. В повторном обработка писала во временный каталог базы (1Cv8Temp), и вывод вернулся в форму. Так что на права каталога рассчитывать не стоит.

Sigma и корреляции

Все правила проходят sigma check. Обычные правила и подбор пароля (корреляция event_count) конвертируются в Splunk, Elastic ES|QL и EQL. Исключение >nul в правиле вывода в файл написано регуляркой PCRE: Splunk её понимает, а для Elastic фильтр придётся переписать.

С цепочками сложнее. «Вход после подбора» и «команда в оболочке из 1С» — это корреляции temporal_ordered. Бэкенды Splunk и ES|QL их не поддерживают вовсе. EQL формально конвертирует, но на выходе получается невалидный запрос с пустым by. Поэтому эти два правила лежат в отдельной папке sigma-correlation/ как описание логики, а на стенде реализованы нативными правилами Wazuh. В своей SIEM их придётся собрать её средствами корреляции.

Грабли

Это особенности Wazuh, но похожие ловушки есть в любой SIEM — проверяйте правила на живых событиях:

Кириллица в правилах не матчится. Правило по «Сеанс. Ошибка аутентификации» не сработает. Используйте ASCII-ID из .lgf.
Свой декодер не нужен. При log_format=json агент отдаёт событие во встроенный декодер json, и кастомный декодер с prematch просто не вызывается. Фильтруйте по полю: decoded_as json + integration=1c.
wazuh-logtest не проверяет события Windows. Декодер windows_eventchannel внутренний, и тестовое событие уходит в json. Правила по 4688 проверяются только живым событием с агента.
> приходит как > — см. правило 2.
Поле event занято — см. раздел про сборщик.

Что не ловится

Прямой запуск без оболочки. Если обработка запустит ipconfig.exe, reg.exe или свой payload.exe напрямую, без cmd, правило «1С запустила оболочку» этого не увидит: оно смотрит на список известных интерпретаторов и утилит. Правило «любой дочерний процесс 1С» на клиентах даст много шума — пользователи штатно открывают из 1С Excel, PDF и браузер.
WMI. Win32_Process.Create запускает процесс от имени WmiPrvSE.exe, а не 1С.
Действия без процессов. Скачивание файла через MSXML2.XMLHTTP, запись через ADODB.Stream, внешние компоненты (DLL) — в событиях 4688 их нет. Нужен Sysmon (сеть, файлы, загрузка библиотек) или EDR.
Повышение прав после запуска. Potato-атаки и прочее, что атакующий сделает дальше, отдельными правилами здесь не покрыты — это задача общих правил SIEM и EDR. Здесь ловится первый шаг: оболочка из 1С.
Встроенные команды cmd. dir, type, echo не создают процессов. Их видно только в командной строке, если они переданы через /c.
Публикация через Apache. Родителем будет httpd.exe, его в правилах нет — добавьте, если у вас Apache.
Очистка журнала регистрации. Если атакующий с правами администратора сократит или удалит журнал, события до этого момента пропадут на хосте. Сборщик к этому времени их уже запишет, а агент отправит, но отдельного правила на сокращение журнала пока нет.
Формат журнала .lgd (SQLite) сборщик пока не читает.
Стенд: файловая база, учебная 8.3.16, без БСП. Ветка с rphost на клиент-серверной базе в лабе не проверялась.

Про EDR: поведенческие правила хорошего EDR часто ловят cmd от нетипичного родителя. Статья для тех, у кого EDR нет или на сервере 1С его отключили ради производительности, а такое бывает часто.

Проверить у себя

Если события создания процессов уже собираются (Sysmon EID 1 или 4688), можно сразу проверить историю: запускали ли процессы 1С и IIS оболочки и системные утилиты. Запрос под свою SIEM: sigma convert -t <backend> sigma/1c_shell_spawn.yml.

Пример для Splunk и Sysmon

Список дочерних процессов сокращён:

index=* source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
ParentImage IN ("*\\1cv8.exe", "*\\1cv8c.exe", "*\\1cv8t.exe", "*\\1cv8ct.exe", "*\\rphost.exe", "*\\w3wp.exe")
Image IN ("*\\cmd.exe", "*\\powershell.exe", "*\\pwsh.exe", "*\\mshta.exe", "*\\certutil.exe", "*\\whoami.exe")
| table User,ParentImage,Image,CommandLine

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

Итого

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

Что сделать у себя:

Включить аудит процессов с командной строкой на серверах 1С и IIS.
Запустить сервер 1С и пул IIS под отдельными учётками без прав администратора.
Забрать журнал регистрации в SIEM и поставить правила.
Ограничить право открывать внешние обработки и не отключать защиту от опасных действий.

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

Сборщик и правила (Sigma и Wazuh): https://github.com/r00tAlchemist/1c-threat-detection

Если вы видели атаки через 1С в своих инцидентах или знаете, что платформа пишет в журнал в других версиях и с БСП, — расскажите в комментариях. Дополню правила.

Я запустил whoami из 1С, а SIEM промолчала. Как ловить выполнение кода через внешние обработки