ASTEL-SOC: секреты эффективного мониторинга инцидентов ИБ

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

При принятии решения, собирать ли определенные события с того или иного источника, ключевыми всегда являются такие факторы, как входящие параметры самой SIEM-системы, так и ограничения по количеству обрабатываемых ею событий в секунду (EPS — events per second), но данная статья не о наложении ограничений, а наоборот, о расширении границ мониторинга.

Компания ASTEL использует дополнительные возможности для более эффективного выявления, реагирования и расследования инцидентов ИБ. Далее, рассмотрим наиболее часто встречаемые источники событий и тонкости настроек их журналов для представления полноценной картины при расследовании различных инцидентов.

Windows Event Log

Начнем со стандартного журнала Windows Event Log, так как это самый популярный способ мониторинга для сущностей, развернутых на базе операционной системы Windows.

В журнале Windows Event Log, помимо отслеживания событий входа/выхода из системы, запуска процессов, управления учетными записями, доступа к объектам и других событий, которые по большей части относятся к журналу безопасности (тут необходимо помнить о правильно настроенных политиках расширенного аудита), хотелось бы выделить несколько важных и нужных для мониторинга журналов.

Журнал Sysmon

Sysmon — это официальный инструмент из пакета Microsoft Windows Sysinternals, который существенно расширяет и дополняет возможности мониторинга Windows (также есть Sysmon и для Linux). В зависимости от конфигурации, которую можно редактировать, Sysmon дает возможность отслеживать создание процессов, файлов, ключей реестра, осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов (named pipes). В его событиях отображаются родительские процессы, командная строка процесса, значения хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием цифровой подписи. Именно поэтому рекомендуется использовать Sysmon в качестве источника дополнительной информации совместно со стандартными журналами Windows.

         — Настройка Sysmon

Установка Sysmon производится командой: «sysmon -accepteula -i sysmonconfig.xml», где sysmonconfig.xml — файл конфигурации, который можно настроить под себя.

Журнал PowerShell

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

         — Настройка журнала PowerShell

Чтобы видеть логи данного журнала, необходимо произвести следующие настройки политик: Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Windows PowerShell / Включить регистрацию блоков сценариев PowerShell (Administrative Templates / Windows Components / Windows PowerShell / Turn on PowerShell Script Block Logging).

После выполнения настроек, в событиях Журнала приложений и служб — Microsoft — Windows — PowerShell/Operational можно будет увидеть от имени какой учетной записи, из какой директории и какой именно скрипт выполнялся (рисунок 1):

Рисунок 1. Событие запуска скрипта PowerShell

Аудит командной строки

Хочется отметить, что в стандартных событиях создания процессов EventID 4688 (Process created) можно дополнительно настроить аудит командной строки. Это дает возможность просматривать команды, которые послужили триггером создания процессов, а также за счет этого можно отслеживать скрытые запуски вредоносных программ и скриптов.

Для этого необходимо включить следующую политику: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов / Включать командную строку в события создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation/Include command line in process creation events).

После этого в событиях с EventID 4688 появится строка процесса (рисунок 2):

Рисунок 2. Событие создания процессов с включенным аудитом CMD

Службы, задачи и реестр

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

— реестр (изменение, добавление или удаление веток реестра);
— службы (добавление новых служб или же редактирование существующих);
— запланированные задачи (создание новых задач или же редактирование существующих).

Редактирование реестра может быть нацелено как на закрепление в системе, так и на нарушение работоспособности системы в целом.

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

Здесь необходимо выделить важные события, которые могут быть полезны для детектирования данных этапов атаки: Event ID 4663 (при настройке политики доступа к объектам, в данном случае конкретно к реестру) (An attempt was made to access an object), Event ID 4657 (при настройке SACL на определенную ветку реестра) (A registry value was modified), Sysmon Event ID 12 и 13 (Registry Event Object create or delete и Registry Event Value Set), Event ID 4697 (A service was installed in the system), Event ID 4698 (A scheduled task was created), Event ID 4699 (A scheduled task was deleted), Event ID 4702 (A scheduled task was updated), Event ID 7045 (A new service was installed in the system).

Нельзя не отметить, что задачи и службы можно создавать напрямую через реестр. В таком случае, событий их создания в журнале не будет, и отследить это можно только по событиям редактирования веток реестра: «HKLM\SYSTEM\CurrentControlSet\Services\DriverName» и «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache».

Мониторинг Linux

Если говорить о мониторинге событий в Linux, то здесь необходимо упомянуть Auditd (Linux Audit Daemon) — инструмент, предназначенный для мониторинга событий операционной системы и записи их в журналы. Во время работы наблюдает за системными вызовами и может записывать различные события, связанные с чтением, записью, выполнением, изменением прав и так далее. Логирование нужных событий регулируется файлом конфигурации, который можно редактировать.

         — Настройка auditd

Правила для логирования можно добавлять несколькими способами:

— записать правила в файл по пути /etc/audit/rules.d/test.rules и перезапустить сервис;
— записать в файл по произвольному пути и указать его: auditctl -R filepath;
— добавить правило утилитой auditctl.

Анализ трафика

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

Remote Procedure Call или «удаленный вызов процедур» представляет собой технологию межпроцессного взаимодействия IPC. Она позволяет программам вызывать функции и процедуры удаленно.

RPC используется во множестве процессов в операционных системах Windows. Например, посредством данной технологии можно удаленно изменять реестр, создавать новые задачи и сервисы. На вызовах RPC построена значимая часть работы Active Directory: функции аутентификации в домене, репликация данных и так далее.

Эта технология используется в Windows практически во всех процессах и по понятным причинам она является предметом особого интереса для атакующих.

Например, реализация атаки «Zerologon» (рисунок 3), суть которой заключается в уязвимости протокола Microsoft Netlogon Remote Protocol (MS-NRPC), эксплуатация которой позволяет сбросить пароль от компьютерной учетной записи контроллера домена и впоследствии произвести атаку DCSync, во время которой злоумышленник, притворяясь контроллером домена, производит репликацию с другим контроллером домена, используя протокол MS-DRSR (протокол RPC для репликации и управления данными в Active Directory), и при этом компрометирует пароли всех пользователей в домене, в том числе и пароль от учетной записи krbtgt, заполучив который можно выполнять атаку «Golden Ticket».

Рисунок 3 — Пример трафика при попытке эксплуатации уязвимости Zerologon

По трафику можно однозначно определить ip-адреса участников взаимодействия, а распознать ту или иную атаку можно по используемым протоколам и объектам, которые они используют.

В данной статье были освещены дополнительные журналы и их настройки в контексте операционной системы Windows, также было уделено внимание наиболее интересным сущностям, которые «любят» использовать злоумышленники при закреплении в системе и которые необходимо отслеживать. Была затронута операционная система Linux и возможности ее мониторинга, а также, в качестве еще одного отдельного и самостоятельного источника событий был рассмотрен сетевой трафик, который в некоторых случаях несет большую информативность, нежели стандартные события ОС.

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

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

Обеспечивайте качественный мониторинг своей инфраструктуры и тогда, скорей всего, вы сможете вовремя среагировать и не допустить серьезных последствий!