Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Получив доступ к системе, злоумышленник первым делом пытается вывести из строя средства аудита, чтобы как можно дольше оставаться незамеченным. В этой статье я покажу, как атакующий может ослепить средства мониторинга Windows путем манипуляций с подсистемой Event Tracing for Windows (ETW). warning
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону.
Признаюсь честно, в прошлом материале, когда я сказал, что у атакующего получилось ослепить Sysmon путем манипуляций с дескриптором безопасности устройства DeviceSysmonDrv
, я немножечко слукавил. На самом деле после проделанных манипуляций Sysmon перестанет формировать лишь часть событий, но не все. Перестают генерироваться события, полученные от драйвера SysmonDrv (это, кстати говоря, основная часть: события запуска и завершения процессов, загрузка DLL в адресное пространство процесса, загрузка драйвера, манипуляций с ключами реестра и другие). Но есть еще один поставщик информации, на основе которого Sysmon формирует свои события, — это ETW. Сегодня мы посмотрим на этот механизм со стороны атакующего и попытаемся поманипулировать его работой, чтобы «до конца ослепить Sysmon».
Event Tracing for Windows (ETW) — механизм операционной системы Windows, предназначенный для регистрации событий, происходящих в системе.
www
Подробнее про тонкости работы ETW ты можешь прочесть на «Хабрахабре»:
В ETW есть несколько основных понятий: провайдеры, сессии, контроллеры и потребители.
Можно сказать, что ETW основан на провайдерах и потребителях. Провайдеры формируют и передают события о состояниях, происходящих внутри процессов или ядра, а потребители используют эти события для собственных целей (например, для анализа производительности). Причем между провайдером и потребителем присутствует промежуточная сущность — сеанс трассировки (сессия).
Дело в том, что один провайдер может генерировать множество предопределенных типов событий, часть из которых нужна одним потребителям, а другая часть — другим. Именно на уровне сессии происходит фильтрация событий. Кроме того, одной группе потребителей могут потребоваться события не от одного, а сразу от группы провайдеров, поэтому сеанс трассировки может собирать события сразу от нескольких провайдеров и отдавать их нескольким потребителям.
Давай посмотрим, как это выглядит в ядре ОС. За общее состояние подсистемы ETW отвечает структура _ETW_SILODRIVERSTATE, адрес которой можно получить из глобальных переменных ядра.
В этой структуре есть два интересных нам поля: EtwpLoggerContext
и EtwpGuidHashTable
.
Остановимся на них подробнее.
Поле EtwpLoggerContext
— указатель на массив структур типа _WMI_LOGGER_CONTEXT, каждая из которых описывает сессию сбора событий. Адреса для этих структур можно получить способом, изображенным ниже.
Обрати внимание, что первые адреса равны 0x00000000 00000001
. Скорее всего, это связано с тем, что два сеанса трассировки предопределены системой и не могут быть изменены, поэтому они имеют такие значения.
Давай посмотрим на определение структуры _WMI_LOGGER_CONTEXT
.
На скрине выведены только наиболее интересные нам детали:
LoggerId
— идентификатор сеанса трассировки. LoggerName
содержит имя сессии в формате _UNICODE_STRING
. InstanceGuid
— идентификатор сессии трассировки в формате GUID. SecurityDescriptor
— указатель на дескриптор безопасности сессии. Consumers
представляет собой список структур _ETW_REALTIME_CONSUMER, каждая из которых содержит указатель на структуру _EPROCESS
. Сама структура _ETW_REALTIME_CONSUMER
описывает отдельный объект — потребитель событий. Поле ProcessObject
— это указатель на структуру _EPROCESS
процесса‑потребителя.
Для примера давай посмотрим на сессию 0xFFFFBA05E862D040
.
Тут мы видим, что у сессии EventLog-Microsoft-Windows-Sysmon-Operational
есть только один потребитель и это процесс с идентификатором 1528. Интересно, что же это за процесс?
Да, это служба журнала событий Windows, которая берет события Sysmon-провайдера и записывает их в файл . evtx. Но об этом чуть позже. А пока давай вернемся к структурам ядра.
Наверное, было бы логично, если бы в _WMI_LOGGER_CONTEXT
был указатель на массив провайдеров, которые пишут события в сессию. Но нет, все устроено немного иначе.
Каждый зарегистрированный в системе провайдер описывается структурой _ETW_GUID_ENTRY.
Причем поставщик событий может предоставлять события не более чем в восемь сеансов трассировки. Эти сведения хранятся в поле EnableInfo
, которое представляет собой массив структур типа _TRACE_ENABLE_INFO. Эта структура содержит информацию о «состоянии провайдера внутри сессии» (включен/выключен — поле IsEnable
), о «принадлежности» к конкретной сессии (поле LoggerId
), а также поля фильтрации событий (MatchAnyKayword
и MatchAllKayword
).
Параметры провайдера, описанные в структуре _TRACE_ENABLE_INFO
, можно настроить одновременно для всех сессий. Для этого в структуре _ETW_GUID_ENTRY
есть отдельное поле ProviderEnableInfo
.
Источник: xakep.ru