Введение
Специалистам SOC бывает крайне сложно составить правила выявления вредоносной активности от имени учетных записей пользователей (в первую очередь IT- и ИБ- специалистов) в условиях, когда:
сотрудников IT- и ИБ- очень много;
они постоянно изменяют что-то важное;
постоянно работают удаленно, при этом мигрируя из локации в локацию;
постоянно работают в выходные и по ночам.
В таких обстоятельствах отличить действия сотрудника от захватившего его учетную запись хакера, работающего ночью с домашнего компьютера сотрудника, практически нереально без долгого изучения логов и, зачастую, опроса пользователя.
Персональные отчеты о действиях
Одним из способов выявления захвата учетных записей пользователей в инфраструктуре могут быть персональные отчеты о действиях. Например:
действия из под учетной записи ночью;
действия из под учетной записи в выходные дни.
Данные отчеты можно слать утром следующего дня владельцам учетных записей.
В этой статье расскажу о принципах формирования таких отчетов. При этом заведомо не буду приводить технических реализаций, т.к. везде они будут своими.
Интерактивность действий
Разумеется, просто выслать сводку из SIEM по всем событиям пользователю можно, но это будет крайне не информативно и не понятно большинству. В нее попадут и множество сетевых аутентификаций (Logon Type - 3), и запуски ПО (которые происходят сами по себе), и множество URL, которые обновляются через AJAX, и др.
Поэтому я предлагаю включать в отчет только интерактивные действия - т.е. действия, которые с наивысшей долей вероятности пользователь делает непосредственно.
Если брать информационные системы абстрактно, то это могут быть:
успешные аутентификации;
изменения параметров объектов;
доступ на просмотр и изменение отдельных объектов;
поиски.
Нормализация действий для отчета
В зависимости от устройства SIEM, интерактивные действия можно выделять отдельным правилом, создавая корреляционные события, или обогащать дополнительными полями. Некоторые SIEM уже содержат в себе встроенные аналогичные по своей сути поля.
Единственное, что нужно предусмотреть на этапе разработки отчета - одно событие может повлечь за собой несколько интерактивных действий. К примеру, запуск mmc.exe dsa.msc - это и запуск ПО mmc, и также запуск оснастки.
Нам подошла следующая таксономия полей, которая расширила нашу общую таксономию нормализации:
Поле |
Описание |
Варианты значений |
action_int |
Флаг интерактивности действия |
yes - действие интерактивное |
action_type |
action_type |
login - аутентификации |
obj_type |
obj_type |
computer - компьютер/сервер/АРМ/устройство |
obj_name |
obj_name |
Путь к файлу, путь запущенному файлу, измененная группа и т.п. |
isys_name |
Имя информационной системы. Указывается, когда полей выше недостаточно для идентификации действия. К примеру, создание пользователя User1 в AD DOMAIN. В isys_name попадет «AD DOMAIN» |
Примеры интерактивных действий из разных источников
Далее приведу примеры интерактивных действий, которые можно извлечь из типовых источников.
Раздел отчета |
События |
Особенности |
По журналам Windows (Security, Sysmon) | ||
Запуски программ |
EventID 4688, 1 Запуски ПО из под родителя explorer.exe. Именно запуски с таким родителем наиболее вероятно произведены непосредственно пользователем Пример нормализации: |
• Некоторые программы надо будет не показывать в отчете, т.к. они технические (обновления Chrome и т.п.) • Некоторые программы можно расшифровать - например, вместо c:\windows\system32\calc.exe указать «Калькулятор» - это будет понятней пользователям |
Входы на компьютеры (удаленно или физически) |
EventID 4624 с Logon type = 10, 7, 2 Входы по RDP, разблокировки сеансов и физические входы Пример нормализации: |
• С типом входа 2 (Interactive) придется немного повозиться, выявляя физические входы,а не запуски от имени |
Запуск оснасток MMC |
EventID 4688, 1 Рассматриваются запуски mmc.exe. Из командной строки процесса mmc.exe извлекается имя оснастки. Пример нормализации: |
• Наиболее популярные оснастки расшифровываются (dsa.msc = «Управление пользователями») |
Запуск ярлыка RDP |
EventID 4688, 1 Рассматриваются запуски mstsc.exe. Из командной строки (при наличии) извлекается имя ярлыка (файл.rdp) Пример нормализации: |
|
Создание доменных пользователей |
Event ID 4720 Рассматриваются события на контроллерах домена. Пример нормализации: |
|
Входы в системы |
Event ID 4624 с Logon Type 3. Для интегрированных с доменом ИС, события аутентификации обычно сопровождаются событием 4624 с IP источника на контроллере домена. Благодаря этому, можно выявить входы в системы, даже если логи с них не подключены. Пример нормализации: |
• Потребуются точные условия для того чтобы отличить события именно входа в ИС, а не активность сессий залогиненных по RDP администраторов (на крайний случай их можно просто исключить при нормализации) - действуйте по обстоятельствам • Также подойдет для выявления входов в кластеры • Событие 4648 не рекомендую, т.к. нет понимания что введен существующий пользователь/верный пароль |
Изменение файлов на сетевых дисках |
Event ID 4663 с действием изменения Пример нормализации: |
• Требует включения аудита изменений файлов на файловой шаре • Потребуется немного обработать имена файлов, исключить временные от Office для удобства восприятия информации |
А также: | ||
По журналам sshd | ||
Входы на компьютеры (удаленно или физически) |
События входа на SSH под доменным пользователем Пример нормализации: |
|
По журналам VPN | ||
Входы в системы |
Событие успешной аутентификации в VPN Пример нормализации: |
|
По журналам Jira | ||
Просмотр задач Jira |
По запросам GET /browse/XXX-12345, а также иным - изучите AJAX запросы на страницах поиска и просмотра задач Пример нормализации: |
В отчете интересней выводить ссылку на задачу. Еще интересней - выводить название задачи, но это не решить наскоком (нужен доступ к API Jira) |
Поиск в Jira |
Есть несколько разных запросов в журнале, дадут понятие, что искалось. Пример нормализации: |
Текст поискового запроса декодируется из url-encode для человекопонятного восприятия |
Исключение из отчета устаревших событий
Бывает, что в SIEM попадают старые логи, к примеру, заново перечитывается текстовый файл с логами Jira и в систему попадают логи за последний месяц.
Чтобы такие устаревшие события не попали в отчет, SIEM должна:
извлекать время из событий по версии источника и дропала все, что отличается на 2 часа от текущего времени; или
иметь возможность для формирования отчета использовать не время поступления события, а время по версии источника.
Формирование отчета
Отчет состоит из разделов. Каждый раздел имеет:
название;
формулу запроса;
форматтеры (позволяют ключ задачи в Jira преобразовать в ссылку, дать подсказку по значению и т.п.).
В раздел попадают только уникальные значения obj_name по формуле - т.о. мы можем в одном разделе собрать входы на все компьютеры, в другим - входы во все системы и т.д.
Если в каком-то разделе нет данных, то он не включается в отчет.
В шапке отчета выводится временной период активности пользователя (время первого и последнего события).
Пример наполнения разделов отчета по каждому конкретному пользователю:
Раздел |
Формула запроса |
Описание |
Входы на компьютеры (удаленно или физически) |
action_type=login AND obj_type=computer |
Выведет имена компьютеров, на которые входил пользователь |
Входы в системы |
action_type=login AND obj_type=isys |
Выведет список названий ИС, в которые был вход |
Запуски программ |
action_type=start AND obj_type=proc |
Выведет список запущенных программ |
Запуски оснасток MMC |
action_type=start AND obj_type=custom.winmmc.osn |
Выведет список названий оснасток |
Запуски ярлыков RDP |
action_type=start AND obj_type=custom.winrdp.link |
Выведет список ярлыков MMC |
Изменения групп безопасности домена AD DOMAIN |
action_type=write AND obj_type=group AND isys_name=«AD DOMAIN» |
Выведет список измененных групп безопасности в домене «AD DOMAIN» |
Доступ к задачам Jira |
action_type=read AND obj_type=custom.jira.issue |
Выведет список задач Jira открытых пользователем |
Возможные проблемы
Проблема |
Подход к решению |
После перезагрузки после обновления Windows браузер переоткрывает вкладки и порождает события «интерактивного» доступа к тем же заявкам Jira |
Очень редкие ситуации. В расследовании подозрения визуально видно что: ночью браузер был открыт (приходили AJAX-запросы), далее одним махом открылись несколько задач и больше ничего интерактивного не происходило, все задачи открывались ранее днем. Если у конкретного пользователя такое повторяется каждый день, то можно ему исключить раздел |
Пользователи помещают рассылки в спам/игнорируют их |
Проводится регулярная вычитка и максимальное сокращение/упрощение отчета, а также работа с исключениями. Проводится организационная работа: информирование о полезности отчета с примерами взломов, премирование за обнаружение «тестовых» атак, проверка просмотра отчетов пользователями (встраивание пикселя в письмо). Возможно внедрение обязательного подтверждения действий из отчета. |
Злоумышленники блокируют поступление отчета взломанному сотруднику правилами почты |
Настройка уведомлений в корп. мессенджер о факте ночной работы с кратким дайджестом и указанием, мол смотрите отчет на почте |
Заключение
Расскажите, а используете ли вы нечто подобное у себя и насколько успешно?