Хабрахабр

Готовимся к расследованию инцидентов

Можно ли полностью защититься от кибератак? Наверное, можно, если окружить себя всеми существующими средствами защиты и нанять огромную команду экспертов управлять процессами. Однако понятно, что в реальности это невозможно: бюджет на информационную безопасность не бесконечный, и инциденты все же будут происходить. А раз они будут происходить, значит, к ним нужно готовиться!

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

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


Классический цикл реагирования на инциденты по методике SANS

В общих чертах действия аналитиков в ходе расследования выглядят следующим образом:

  1. Формирование версий, объясняющих причины возникновения инцидента (например, «вредоносное ПО установилось на хост, потому что пользователь запустил его из фишингового письма» или «инцидент — ложная тревога, потому что пользователь посетил легитимный сайт, располагающийся на том же хостинге, что и сервер управления вредоносным ПО»).
  2. Приоритизация версий по степени вероятности. Вероятность рассчитывается (а скорее — прикидывается) на основе статистики прошлых инцидентов, критичности инцидента или системы, а также на базе собственного опыта.
  3. Проработка каждой версии, поиск фактов, доказывающих или опровергающих ее.

Разумеется, все-все возможные гипотезы проверять нет смысла — как минимум, из-за того, что время ограничено. Поэтому и здесь мы рассмотрим наиболее вероятные версии и типовые сценарии расследования инцидентов, связанных с вредоносным ПО.

Сценарий 1

Ввиду некритичности системы на проверку отведено совсем немного времени. У вас есть подозрение, что некритичная система была скомпрометирована вредоносным ПО.

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

В рамках проработки этой версии следует выполнить три простых действия:

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


Вывод всех запущенных процессов и служб в Event Log Explorer

В теории это достаточно тривиальный процесс. Однако на практике встречается ряд подводных камней, к которым следует подготовиться.

Если же так получилось, что этот аудит не был включен заранее, можно попробовать получить список исполняемых файлов из других артефактов Windows, например, из реестра Amcache. Во-первых, стандартная настройка аудита Windows не логирует факты запуска процессов (событие 4688), поэтому его надо включить заблаговременно в доменной групповой политике. Извлечь данные из этого файла реестра можно с помощью утилиты AmcaheParser.


Пример извлечения фактов запуска процессов из Amcache.hve

Однако этот метод не очень надежен, поскольку он не дает точной информации о том, когда конкретно и сколько раз запускался процесс.

в ней содержится путь к потенциально вредоносному файлу-скрипту. Во-вторых, свидетельства запуска таких процессов, как cmd.exe, powershell.exe, wscript.exe и других интерпретаторов, принесет мало пользы без информации о командной строке, с которой процессы были запущены, т.к.

При этом довольно популярная Windows 7/2008 не логирует командную строку без установленного обновления KB3004375, поэтому поставьте его заранее.
Запуск интерпретатора скриптов без информации о том, что за скрипт был запущен

Еще одна особенность Windows заключается в том, что аудит командной строки запускаемого процесса производится отдельной настройкой доменной групповой политики: Computer Configuration -> Policies -> Administrative Templates -> System -> Audit Process Creation -> Include command line in process creation events.

В них содержится информация о всех файлах (в основном DLL), загруженных в процесс в первые 10 секунд жизни. Если же так получилось, что вы заранее ничего не настроили или забыли про обновление, можно попытаться узнать расположение скрипта в файлах Prefetch (утилита в помощь). И скрипт, содержащийся в аргументах командной строки интерпретатора, наверняка будет присутствовать там же.


Пример поиска «потерянного» аргумента командной строки в Prefetch

Но и этот метод совсем не надежен — при очередном запуске процесса кеш Prefetch перезатрется.

Подготовка к расследованию:

  • Включите расширенный аудит создания и завершения процессов.
  • Включите логирование аргументов командной строки процессов.
  • Установите обновление KB3004375 на Windows 7/Server 2008.

Сценарий 2

IP-адрес вредоносного сервера получен из подписки threat intelligence средней надёжности. На периметровом маршрутизаторе зафиксировано обращение к серверу управления вредоносным ПО.

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

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

Но все это долго, не масштабируемо и самое главное — не надежно. Существует много способов узнать, какой процесс инициировал соединение: можно запустить netstat и увидеть текущие сокеты или собрать дамп памяти и потом натравить на него volatility, которая может показать в том числе уже завершенные соединения. Намного надежнее получать всю необходимую информацию из security-журнала Windows.

Сделать это можно на основе событий аудита платформы фильтрации и аудита отбрасывания пакетов.
Корреляция события «обращение к вредоносному IP-адресу» в SIEM-системе HPE Arcsight и соответствующий обращению процесс в security-логе Windows

Подготовка к расследованию

Чтобы отработать этот сценарий на пользовательской машине, следует включить запись в журнал security всех сетевых соединений.

По нашему опыту, на обычном пользовательском хосте такого объема хватает примерно на 3 дня записи всех сокетов, а этого срока вполне достаточно для успешного расследования. При этом журнал может начать быстро забиваться, поэтому увеличьте его размер до 2-3 Гб.

На высоконагруженных серверах, вроде контроллеров домена, web-серверов и т.п., так делать не стоит, журнал переполнится намного быстрее.

Сценарий 3

Ваша NG/ML/Anti-APT система детектирования аномалий сообщает, что с 30 хостов происходит разведка с целью получения одних и тех же учетных записей.

При попадании в новую сеть злоумышленники, как правило, пытаются узнать, какие сервисы присутствуют в ней и какие учетные записи используются — это очень помогает в процессе дальнейшего движения по инфраструктуре. В частности, эту информацию можно получить из самой Active Directory с помощью команды net user /domain.

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

  1. Разведка зафиксирована на 30 хостах в отношении одних и тех же объектов AD, потому что команду net запустил один и тот же легитимный пользователь — администратор.
  2. Разведка зафиксирована на 30 хостах в отношении одних и тех же объектов AD, потому что это сделало одно и тоже легитимное ПО.

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

Подготовка к расследованию

Необходимо организовать долговременное хранение, как минимум, следующих данных из журналов общих сервисов сети:

  • Контроллеры домена — входы, выходы учетных записей и выдача билетов Kerberos (категория Account Logon в расширенных настройках аудита).
  • Прокси-серверы — адреса, порты источника и внешнего сервера, а также полный URL.
  • DNS-серверы — успешные и неуспешные DNS-запросы и их источник внутри сети.
  • Периметровые маршрутизаторы — Built и Teardown для всех TCP/UDP-соединений, а также соединений, пытающихся нарушить правила логического доступа: например, попытки отправить DNS-запрос наружу напрямую, минуя корпоративный DNS-сервер.

Сценарий 4

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

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

Часть подобного расследования можно провести, используя только журналы контроллера домена. Реагирование на такой инцидент включает в себя очень большой пласт работ, в том числе анализ всех действий, совершенных из-под этой учетной записи. Или же можно проанализировать события, связанные с изменением критичных объектов AD, чтобы проверить, не изменялся ли состав высокопривилегированных групп (тех же доменных администраторов). Например, можно изучить события, связанные выдачей тикетов Kerberos, чтобы понять, куда ходили из-под этой учетки. Естественно, все это требует заранее настроенного аудита.

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

Результатом подобной атаки может быть добавление пользователя в группу доменных администраторов или более хитрые закрепления через изменение атрибута SID History либо модификацию ACL-объекта AdminSDHolder. Суть ее заключается в том, что злоумышленник сам представляется контролером домена, вносит изменения в AD и затем реплицирует (синхронизирует) эти изменения с легитимными контроллерами, таким образом обходя настроенный на них аудит изменений объектов.

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


Удаление неизвестного контроллера домена из репликации AD

Подготовка к расследованию:

  • Для расследования действий, совершенных скомпрометированной учетной записью, необходимо заранее включить:
    • Аудит входов, выходов учетной записи и выдачу билетов Kerberos (категория Account Logon в расширенных настройках аудита).
    • Аудит изменений учетных записей и групп (категория Account Management).
  • Для расследования версий, связанных с возможными применениями атаки DCShadow:
    • Включить подробный аудит репликации службы каталогов.
    • Организовать долговременное хранение событий 4928/4929, в которых источник событий не является легитимным контроллером домена (признак DCShadow).

Заключение

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

Закончить хотел бы цитатой из недавнего исследования одной компании, работающей в сфере кибербезопасности:

Так, половина (48%) полагает, что бюджет не изменится никак, а 15% думают, что финансирование сократится». «Российские директора по информационной безопасности в большинстве своём склонны давать пессимистичные ответы [на вопросы исследования].

Для меня лично это сигнал к тому, что оставшийся бюджет в новом году лучше потратить не на покупку новомодных СЗИ вроде Machine Learning детекторов, очередной IDS нового поколения и т.д., а на тонкую настройку тех СЗИ, которые уже есть. А лучшее СЗИ — это правильно настроенные логи Windows. IMHO.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть