IT – это “жизнь”: Аудит удаления и доступа к файлам и запись событий (отслеживание изменений файлов на файловом сервере)

Что искать в логах сетевых устройств

Изучите входящие и исходящие действия ваших сетевых устройств.

Примеры ниже – это выдержки из логов Cisco ASA, но другие устройства имеют схожую функциональность.

Что искать в логах windows

Идентификаторы событий перечислены ниже для Windows 2008 R2 и 7, Windows 2022 R2 и 8.1, Windows 2022 и 10. (В оригинальной статье используются в основном идентификаторы для Windows 2003 и раньше, которые можно получить, отняв 4096 от значений указанных ниже EventID).

Большинство событий, приведенных ниже, находятся в журнале безопасности (Windows Event Log: Security), но некоторые регистрируются только на контроллере домена.

Введение

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

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

Даже при наличии неограниченных ресурсов всегда будут существовать иные ограничения, не позволяющие довести уровень безопасности до абсолюта. Это и пресловутые уязвимости нулевого или обычного дня (endless patch management), и постоянная гонка вооружений хакеров и безопасников, и динамичность развития ИТ-инфраструктуры, и многое-многое другое.

В этом свете как никогда актуален вопрос приоритезации средств и методов защиты, в том числе в направлении мониторинга. В этой области согласно статистике, приведённой на основе данных матрицы MITRE ATT&CK, про которую мы уже писали в прошлый раз, приоритеты расставляются следующим образом: безоговорочное первое место занимает такой источник событий безопасности, как эндпойнты.

Данный источник лидирует по количеству техник матрицы, которые можно выявить на основе регистрируемых на нем событий. Самой распространенной ОС для эндпоинтов остаётся Microsoft Windows. Сбор именно её логов в большинстве корпоративных инфраструктур даст наилучший результат по соотношению всех видов затрат к охвату устройств сети и покрытию техник злоумышленников.

Но, как в известном анекдоте, есть один нюанс. В последние годы широкое распространение получило мнение, что логи Windows нужно дополнить, если не заменить, событиями Sysmon — дескать они полнее, лучше, приспособленнее в качестве инструмента мониторинга с точки зрения ИБ.

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

Sysmon же разработан специалистами Microsoft, а недавно и поглощен этой корпорацией, что даёт определённый уровень доверия со стороны ИТ. Кроме того, логи пишутся в виде .evtx журнала, что позволяет собирать и обрабатывать их теми же средствами и методами, что и обычные логи Windows.

Сразу оговоримся, что статья получилась большая, хоть мы и старались минимально дублировать и сжимать материал. Читатель, конечно, может сказать, отсылая нас к тому анекдоту про Ленина: “А мог бы и полоснуть…”. Или что “публикацию можно было разделить на две или три части для большей читаемости”.

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

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

В двух словах о том, как это работает

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

Здесь мы смотрим нужную информацию с операцией «Delete». При переименовании файла будет создано два события ID=4663, отражающих операции «Запись Данных» и Delete. То есть, в логи будет попадать много лишней информации, и будет не совсем понятно, когда файлы были переименованы, а когда удалены.

В данном случае лучше ориентироваться на событие с ID, равным 4660, которое создается конкретно при удалении данных. Здесь содержится множество информации, кроме имени файла. Зато тут присутствует код дескриптора

Однако в предшествующем событии с ID=4663, такая информация, как время, а также имя файла указывается, а номер его дескриптора соответствует номеру события с ID, равным 4660.

То есть из обоих событий в цикле выборочно берутся определенные свойства с необходимой нам информацией, после чего параметр $BodyL записываются в текстовый лог-файл. В заданном временном промежутке, который определяется в $PrevEvent, осуществляется поиск события с требуемым порядковым номером. Собственно, по тому же принципу можно искать и добавляемые в хранилище файлы.

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

Вас также может заинтересовать:

Возможено ли вести лог копирования файлов в windows?

Где находится журнал событий windows

Физически Журнал событий представляет собой набор файлов в формате EVTX, хранящихся в системной папке %SystemRoot%/System32/Winevt/Logs.

Хотя эти файлы содержат текстовые данные, открыть их Блокнотом или другим текстовым редактором не получится, поскольку они имеют бинарный формат. Тогда как посмотреть Журнал событий в Windows 7/10, спросите вы? Очень просто, для этого в системе предусмотрена специальная штатная утилита eventvwr.

Действия с реестром

До сих пор, говоря о группе, мы включали в неё только одно событие. Здесь эта тенденция изменится.

Логирование этих событий настраивается так: Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Registry — Success.

SACL для всех (Everyone) пользователей задаётся следующим образом: regedit.exe — ветка реестра — Permissions — Advanced — Auditing — Everyone — Success — Advanced Permissions — Full Control или Set Value, Create Subkey, Create Link, Delete, Write DAC.

Также SACL на файлы можно задать глобально, определив его в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Global Object Access Auditing — Registry. Минусы подхода аналогичны таким же операциям с файлами.

Сразу остановим внимание на ограничениях. Для Sysmon все операции (создание, изменение, удаление) с value или key порождают события (кроме переименования value). Для Windows:

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

Дополнительные продукты

Так же вы можете автоматизировать сбор событий, через такие инструменты как:

Так что вам выбирать будь то просмотр событий или PowerShell для просмотра событий windows, это уже ваше дело. Материал сайта msconfig.ru



Доступ к процессу

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

, как злонамеренный процесс может сделать ваш легитимный чуточку «лучше». Разумеется, не альтруизма ради, а злонамеренных действий для. И рассматриваемые события как раз помогут нам обнаружить многие варианты подобного творчества. Включаются эти логи в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Kernel Object — Success

У Windows тут два преимущества. Во-первых, отображение пользователя, от которого работает процесс-источник вмешательства. Как мы уже отмечали выше, преимущество обычно незначительное. А, во-вторых, HandleID и права доступа.

Если интерес к правам доступа понятен, то HandleID пригодится только для поиска смежных событий. Он необходим для организации взаимодействия пользователя через процессы с объектами ОС — такими же процессами (их потоками), файлами и т.д. Соответственно, дополнительные события могут показать, как, в результате чего и кому был выдан и когда был отозван требуемый handle для доступа.

Касаясь в первый раз темы объектов и handle, а также логирования действий с ними, важно отметить две вещи.

Во-первых, для логирования вышеуказанных дополнительных действий важно включить дополнительные настройки политик аудита, в частности Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Handle Manipulation — Success.

При этом стоит помнить, что объём данных событий может быть очень велик. Handle выдается при поступившем запросе, соответственно, отражает истребованные права. Но почему мы можем не ждать такого же объёма событий непосредственно от аудита доступа к объектам?

Всё потому, что, во-вторых, необходимо включить SACL на объекте, который планируется контролировать. Фактически это перечень, аналогичный перечню прав доступа DACL, который определяет, получит субъект или объект, созданный с его токеном, успех или отказ при попытке доступа к объекту.

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

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

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

К счастью, для объектов типа процесс SACL по умолчанию уже существует для ядра версии 6.3 и выше. Если кто-то может указать способ, как этот SACL получить (рекомендации из этой статьи нам выполнить не удалось), будет интересно услышать/обсудить.

На стороне Sysmon у нас кроме уже рассмотренных GUID-ов и Rule Name-ов есть ещё несколько интересных полей. Во-первых, PID процесса-цели. Он позволит отслеживать последующую активность инфицированного объекта, ведь инстансов из одного исполняемого файла может быть запущено несколько.

Во-вторых, поле CallTrace, которое фиксирует действия источника событий в цели. Посмотришь на такое и поймёшь, что «ловкость рук и никакого мошенничества» — не просто слова. С другой стороны, такой подробный анализ — это уже удел форензики. А кто имеет выделенного форензика, тот скорее всего уже не в начале пути по построению системы мониторинга.

Завершение процесса

В целом, событие, как уже писалось выше, не особо часто используется, но…

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

Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Detailed Tracking – Audit Process Termination – Success

Загрузка драйвера

Данное событие Windows, в отличие от остальных, включено по умолчанию и попадает в журнал System. Информативных полей в данных событиях не много.

И снова сразу к выводам.

Запросы dns

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

За несколько предыдущих лет тема использования DNS не по назначению, например, для получения команд от C&C или хищения информации через этот канал, стала популярной. Скорее всего не сама по себе — рассказы о таком использовании каналов ICMP и DNS мы бы отнесли ещё к нулевым.

В то время знакомые студенты изощрялись в инкапсулировании трафика игрушек с целью добраться по единственным разрешённым каналам до заветных игровых серверов из сети института (привет, Женя tumbochko!). Это позволяло хоть как-то скоротать время на скучных или быстро освоенных ими лабах. И вряд ли это была их идея.

Но не так давно к этому каналу утечки добавилась такая концепция, как DoH, что усложнило обнаружение подозрительного DNS трафика на уровне сети.

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

Итак, ближе к делу. Включаем Event Viewer — Application and Services Logs — Microsoft — Windows — DNS Client Events — Operational — Контекстное меню — Enable Log.

Всё то же, что уже обсуждали. Что касается информации о субъекте, обратим внимание на явное указание образа исполняемого файла, выполнившего запрос в событии Sysmon.

Если говорить об объекте — в логах Windows информации значительно больше. Но есть несколько важных «но». Во-первых, информация распределена по нескольким событиям со всеми вытекающими.

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

Иные бесплатные поставщики базовых событий

В этом разделе, прежде всего, хотелось бы сказать о механизме

(Event Trace for Windows). И встроенные журналы Windows, и Sysmon регистрируют события, используя этот механизм. Фактически на каждое действие в системе мы можем получить событие. Проще всего посмотреть на потенциальный объём таких событий, включив опцию Event Viewer — View — Show Analytics and Debug log.

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

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

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

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

Ещё один из популярных, но не рассмотренных в статье вариантов — osquery. Две основные причины, по которым мы не стали рассматривать здесь это решение — низкая частота обновления продукта (минус как с точки зрения безопасности, так и функциональности) и увеличенное, по сравнению с другими вариантами, использование системных ресурсов (в состав входит полноценная БД).

В последнее время появилось ещё несколько инструментов, которые распространены не так широко, как рассмотренные. К ним можно отнести Velociraptor и SilkETW. Велосипеда они не изобретают и также работают поверх стандарта Windows — ETW. В виду объёма уже приведённого материала было решено выделить данные инструменты в отдельную публикацию (по мере наличия времени и сил, а также ощущения востребованности).

Как использовать содержимое журнала

Хорошо, теперь мы в курсе, где находится журнал событий и как его открыть, осталось узнать, как его можно использовать. Сразу нужно сказать, что в силу своей специфичности содержащиеся в нем сведения мало что могут поведать обычному пользователю. О чем говорит, к примеру, ошибка «Регистрация сервера {BF6C1E47-86EC-4194-9CE5-13C15DCB2001} DCOM не выполнена за отведенное время ожидания»?

Так, описание приведенной выше ошибки имеется на сайте Microsoft и указывает оно на проблемы со SkyDrive, кстати, не представляющие совершенно никакой угрозы. Если вы не пользуетесь этим сервисом, ошибку можно игнорировать или отключить ее источник в «Планировщике заданий». А еще описание ошибки можно отправить разработчику, предварительно сохранив его в файл XML, CSV или TХT.

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

Как открыть в просмотр событий

Зайти в оснастку Просмотр событий можно очень просто, подойдет для любой версии Windows. Нажимаете волшебные кнопки

Win R и вводите eventvwr.msc

Откроется у вас окно просмотр событий windows в котором вам нужно развернуть пункт Журналы Windows. Пробежимся по каждому из журналов.

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

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

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

Самый важный журнал Это система. Сюда записывается все самое нужное и важное. Например у вас был синий экран bsod, и данные сообщения что тут заносятся помогут вам определить его причину.

Так же есть логи windows для более специфических служб, например DHCP или DNS. Просмотр событий сечет все :).

Как открыть журнал

Запустить утилиту можно из классической Панели управления, перейдя по цепочке Администрирование – Просмотр событий или выполнив в окошке Run (Win R) команду eventvwr.msc.

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

Наибольший интерес представляет раздел «Журналы Windows», именно с ним чаще всего приходится работать, выясняя причины неполадок в работе системы и программ. Журнал системных событий включает три основных и две дополнительных категории. Основные это «Система», «Приложения» и «Безопасность», дополнительные – «Установка» и «Перенаправленные события».

Категория «Система» содержит события, сгенерированные системными компонентами – драйверами и модулями Windows.

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

Третья категория событий «Безопасность» содержит сведения, связанные с безопасностью системы. К ним относятся входы пользователей в аккаунты, управление учётными записями, изменение разрешений и прав доступа к файлам и папкам, запуск и остановка процессов и так далее.

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

Чтобы просмотреть конкретную запись, кликните по ней дважды – сведения откроются в окошке «Свойства событий».

Конфигурация wmi

Переходим к предпоследней группе событий. Это события WMI. Злоумышленник может создать фильтр (filter), получающий какие-либо события об изменении состояний системы, в нашем примере — изменение состояния сервиса. И выполнять на основании получаемых от этого фильтра событий определённые действия, создав потребителя (consumer).

. Как раз в описанном порядке и фиксируются события 19-21 Sysmon.

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

Детальнее разберёмся, глядя на таблицу.

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

Критично ли это? Case by case. Если мы начинаем разматывать последовательность инцидента и видим, что нетиповой и предположительно злонамеренный фильтр или потребитель были созданы два года назад, то мы сразу понимаем, что злоумышленники сидят у нас как дома уже два с лишним года. И следы атаки надо искать минимум на эту глубину. Часто ли такое бывает? Это основной вопрос.

Зато если изменения вносятся в фильтр или потребителя существующей связки, мы увидим полную картину целиком в одном событии. В то время, как Sysmon отразит только те изменения (тот объект), которые были произведены.

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.

Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам

Включим «Аудит файловой системы» на успех и отказ.

После этого на необходимые нам папки необходимо настроить аудит.

Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».

Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.

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

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

Общая схема действия

1. Определите, какие источники журналов и автоматизированные инструменты можно использовать для анализа
2. Скопируйте записи журнала в одно место, где вы сможете все их просмотреть и обработать
3. Создайте правила определения того, что события являются необходимыми вам, чтобы в автоматическом режиме уменьшать «зашумленность» логов
4. Определите, можно ли полагаться на метки времени журналов; рассмотрите различия часовых поясов
5. Обратите внимание на последние изменения, сбои, ошибки, изменения состояния, доступ и другие события, необычные для вашей IT-среды
6. Изучите историю событий, чтобы восстановить действия до и после инцидента
7. Сопоставьте действия в разных журналах, чтобы получить полную картину
8. Сформируйте гипотезу о том, что произошло; изучите журналы, чтобы подтвердить или опровергнуть её

Очистка, удаление и отключение журнала

На жестком диске файлы журнала занимают сравнительно немного места, тем не менее, у пользователя может возникнуть необходимость их очистить. Сделать это можно разными способами: с помощью оснастки eventvwr, командной строки и PowerShell.

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

for /F «tokens=*» %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl «%1»

Вместо командной строки для быстрой и полной очистки журнала также можно воспользоваться консолью PowerShell. Откройте ее с повышенными правами и выполните в ней такую команду:

wevtutil el | Foreach-Object {wevtutil cl «$_»}

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

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

Командой services.msc откройте оснастку «Службы», справа найдите «Журнал событий Windows», кликните по нему дважды, в открывшемся окошке свойств тип запуска выберите «Отключено», а затем нажмите кнопку «Остановить».

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

Полезные ссылки

Примеры событий Windows по каждому EventID:

Справочник событий журнала безопасности Windows:

Список инструментов анализа журналов:

Другие «шпаргалки», связанные с реагированием на инциденты безопасности в блоге одного из авторов оригинальной статьи:

Посмотреть логи windows powershell

Было бы странно если бы PowerShell не умел этого делать, для отображения log файлов открываем PowerShell и вводим вот такую команду

Get-EventLog -Logname ‘System’

В итоге вы получите список логов журнала Система

Тоже самое можно делать и для других журналов например Приложения

Get-EventLog -Logname ‘Application’

небольшой список абревиатур

Например, для того чтобы в командной оболочке вывести события только со столбцами «Уровень», «Дата записи события», «Источник», «Код события», «Категория» и «Сообщение события» для журнала «Система», выполним команду:

Get-EventLog –LogName ‘System’ | Format-Table EntryType, TimeWritten, Source, EventID, Category, Message

Если нужно вывести более подробно, то заменим Format-Table на Format-List

Get-EventLog –LogName ‘System’ | Format-List EntryType, TimeWritten, Source, EventID, Category, Message

Как видите формат уже более читабельный.

Так же можно пофильтровать журналы например показать последние 20 сообщений

Get-EventLog –Logname ‘System’ –Newest 20

Или выдать список сообщение позднее  1 ноября 2022

Get-EventLog –LogName ‘System’ –After ‘1 ноября 2022’

Рекомендации

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

После того как определите период времени. Поместите данный скрипт в планировщик задач и укажите, что выполнять данный скрипт необходимо каждые 5,10,60 минут (в зависимости какой период вы указали в скрипте). У меня указано каждый 60 минут. $time = (get-date) — (new-timespan -min 60).

Сетевые соединения

Запись этих событий в Windows: Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Object Access – Audit Filtering Platform Connection

Почему решили остановиться именно на событиях Windows Filtering Platform (WFP), а не Windows Firewall? Ответ прост. Исходя из нашей практики, на хостах так или иначе уже стоят эндпойнты в виде антивирусов. Они хоть и не предназначены для мониторинга базовых событий системы (по причине чего не подходят для наших целей), но тем не менее, в современных реалиях всегда имеют в своем составе хостовый межсетевой экран.

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

Из таблицы видно, что если мы попытаемся опереться на виндовые события, то УЗ пользователя и FQDN взаимодействующих хостов придётся восстанавливать обогащением событий. Хотя, если задуматься, для нас важнее знать какой процесс установил соединение, а не какой пользователь.

А с FQDN всё ещё проще — все современные системы в качестве базового или дополнительного функционала включают компонент CMDB. А если и нет — точно стоит запастись сторонним решением. Знание своей инфраструктуры — основа ИБ в целом. Так что информация доступна либо через обогащение, либо через карточку актива, что позволит использовать её и в корреляции. Главное — по возможности, не забыть подключить логи DHCP, чтобы информация была актуальной.

Все другие уникальные поля не так существенны, например:

Скрипт записи лога об удаленных файлах

$timе = (get-datе) – (nеw-timеspan -min 60)

#$Evеnts – здесь содержится порядковый номер и время записи ивента, который имеет ID= 4660. Также зададим параметр сортировки по порядковым номерам.

Когда файл удаляется, создается две записи: первая с ID=4660, и вторая с ID, равным 4663.

$Еvеnts = Gеt-WinEvеnt -FilterHаshtable

@{LоgNаmе=”Sеcurity”;ID=4660;StаrtTimе=$timе} | Sеlесt

TimeCrеаted,@{n=”Nоtе”;е={([хml]$_.ToXml()).Event.System.EvеntRecоrdID}} |sоrt Nоtе

$BоdyL = “”

$TimеSpаn = new-TimеSpan -sec 1

fоrеаch($еvеnt in $еvents){

$PrеvEvеnt = $Evеnt.Зaпись

$PrеvEvеnt = $PrеvEvеnt – 1

$TimeEvеnt = $Event.TimеCrеаtеd

$TimеEventEnd = $TimeEvent $TimеSpan

$TimеEventStart = $TimеEvent- (new-timеspan -sеc 1)

Скрипт поиска событий за определенный временной промежуток

Задаем поисковый параметр за промежуток, равный, к примеру, 1 часу:

$timе = (gеt-dаte) – (nеw-timеspan -min 60)

$BоdуL = “”

Переменная «$BodyL» требуется для записи события в лог файл.

$Bоdу = Gеt-WinEvеnt -FiltеrHashtable

@{LоgName=”Sеcurity”;ID=4663;StаrtTimе=$Timе

Создание процесса

Начать, как это ни парадоксально, решили с начала. А далее были так же не оригинальны и шли по порядку — по возрастанию EID Sysmon.

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

• Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Detailed Tracking – Audit Process Creation – Success включает логирование самого события;

Создание файла

Включается данная категория в Windows следующим образом: Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit File System — Success

Как можно видеть из таблицы, все плюсы и минусы данной группы аналогичны уже описанным выше. В том числе плюсы и минусы SACL (для файлов и папок для всех (Everyone) пользователей включается Properties — Security — Advanced — Auditing — Add — Everyone — Success — Write (для файлов) или Modify (для директории)).

Также SACL на файлы можно задать глобально, определив его в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Global Object Access Auditing — File System.

Хотелось бы отметить начинающиеся здесь странности логирования. Для этой группы не фиксируется событие Windows при создании файла через Powershell, например, New-Item C:ForTesttest.t. При этом то же действие отображается в логах Sysmon на отлично.

Уникальные событий sysmon

К уникальным событиям Sysmon мы отнесли следующие:

• EID 4, 16. Хотя и можно отследить через журналы Windows, но они говорят нам только о событиях самого Sysmon. Соответственно, при его отсутствии смысла не имеют.
• EID 2 — в качестве аналога можно было бы считать EID 4663. Но даже с учётом предоставляемых в нём списков прав доступа, событие не является таким гранулярным, как EID2, и не обогащается до такого состояния иными событиями Windows.
• EID 7-9, 17 — не найдены аналоги. Можно попробовать получить их через ETW. О том, что это такое, поговорим в одном из следующих разделов.
• EID 15 — не найдены аналоги, отсутствуют аналоги в ETW. Это мы уже можем утверждать с уверенностью, так как используется дополнительный функционал — хэш.
• EID 18 — сетевое взаимодействие по именованным каналам (named pipes) можно отлавливать с помощью мониторинга сетевых соединений. Но, во-первых, это частный случай. А во-вторых, так как это иной уровень абстракции, то и информация о таком взаимодействии будет иная. Локальные пайпы должны фиксироваться тем же ETW.

Фильтрация событий

Существует три возможности фильтрации событий на стороне источников.

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

Второй доступен и для событий Windows, и для событий Sysmon: использование Xpath с учётом ограничений, налагаемых великим Microsoft. Так как метод доступен для обоих источников, описание вынесем за рамки данной статьи.

И третий — конфиг Sysmon. Тут есть множество вариантов:

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

Также Sysmon пока только находится на пути к сложной фильтрации с помощью комбинирования условий из различных полей. Можно создать только одну группу правил для каждого EID, объединённых отношениями И, и только одну с отношениями ИЛИ. Соответственно, условия вида (A and B) or (C and D) уже не напишешь.

Формат сравнения

Зачем и что сравнивали, вроде бы понятно. А как это делалось и почему именно так?

Сравнение решили произвести в виде таблицы для каждой из групп событий, отражающих определённую активность в системе. Например, события с ID (Event ID, EID) 12, 13 и 14 в Sysmon, отражающие активность с реестром, даже не фильтруются по отдельности, хотя и говорят про разные атомарные действия. По подобной логике произведена и остальная группировка.

В такие группы включали только аналогичные события. Например, аналог события Sysmon EID 6 — событие Windows EID 6. При этом о загрузке драйверов есть ещё как минимум события 219 и 7036 Windows. Но они возникают в случае неуспеха. Т.е. не несут ту же смысловую нагрузку и, при необходимости, могут дополнять события Sysmon или Windows, в зависимости от того, что мы решили собирать.

Общий вывод

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

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

Во-вторых, система логирования событий Windows тоже постоянно дополняется, и за время написания этой статьи появились такие Windows EID, как 4798 и 4799. Возможно также, что дополняется и набор полей. Таким образом, данное сравнение хоть и является наиболее полным, исходя из той информации, которой мы обладаем, но не высечено в камне.

А в-третьих, Sysmon пока является внешним инструментом, что влечёт за собой ряд рисков. Например, у нас были случаи, когда логирование отдельных EID прекращалось без объявления причины. При этом запись остальных событий шла как обычно. Более именитые коллеги утверждают, что проблема была связана с утечками памяти в версии 10.41. Но релиз 10.

Выражаю благодарность Тимуру zinint за помощь в подготовке публикации.

UPD1: Оказывается действительно сложно вести нормальный change log или добавлять новые фичи в основное описание, поэтому, как мы обнаружили (спасибо, дядь Дим shudv), грузовик с ништяками перевернулся нанашей улице уже 9 месяцев назад… Краткое содержание: в Sysmon можно сделать (A and B) or (C and D), только тсс…

Вывод

Для фиксации данной группы событий Sysmon подходит куда лучше:

• Уникальные GUID позволяют отслеживать только старт сессий и процессов, в то время как в большой инфраструктуре не мала вероятность, что, даже отфильтровав события конкретного хоста, вы можете обнаружить не уникальный ID процессов и вынуждены будете искать события их окончания (завершение процесса или сеанса пользователя). Забегая вперёд, скажу, что именно по этой причине вообще рассматривалась группа событий завершения процессов. Обычно необходимость в этих событиях не так и очевидна. Подход с использованием ID создает дополнительную работу для аналитика или нагрузку на используемый инструмент анализа, например, SIEM, который будет строить списки сессий и процессов в фоне. Наличие GUID, соответственно — большой плюс.
• Хэш процесса — на название образа запускаемого процесса или дополнительные текстовые сведения о нём мы бы сильно не ориентировались — кто знает, кем прикинулся зловред и не получилось ли у авторов подписать его сертификатом, который ещё не отозван. Жирный минус здесь — в Sysmon недоступна фильтрация по хэшу, её придётся организовывать на стороне SIEM (при необходимости). А если какой-то процесс запускается часто — это надо зафиксировать, создав дополнительную нагрузку на диск хоста и сеть. Самым неприятным местом будет, если ваш SIEM считает лицензионную квоту до фильтрации. Раньше так было, например, в IBM QRadar. Может, где-то есть и до сих пор. Но это замечание, скорее, не в рамках сравнения — в Windows не то, что фильтра такого нет, сам хэш не снимается.
• Про удобство Rule Name подробно уже сказали выше.
• Применимость остальных уникальных полей, что в событиях Windows, что в событиях Sysmon, играет роль, как говорится на англицком, case by case. Поэтому и принимать решение о выборе того или иного лога, или вообще их совмещения, тоже нужно case by case.

Похожее:

Политики аудита изменений в Active Directory Schtasks exe что это Аудит успехов это Что можно почерпнуть из журнала действий Windows 7. что для этого нужно