Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Sysmon

Перевод Руководство по анализу Sysmon-угроз, часть 1

30.06.2020 16:15:52 | Автор: admin


Эта статья является первой частью серии по анализу Sysmon-угроз. Все остальные части серии:

Часть 1. Знакомство с анализом логов Sysmon (мы тут)
Часть 2. Использование данных из Sysmon событий для выявления угроз
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов

Если вы занимаетесь информационной безопасностью, наверняка вам часто приходится разбираться в происходящих атаках. Если у вас уже намётанный глаз, вы можете поискать нестандартную активность в сырых необработанных логах скажем, PowerShell-скрипт с запущенной командой DownloadString или VBS-скрипт, притворяющийся Word-файлом, просто пролистывая последнюю активность в журнале событий Windows. Но это реально большая головная боль. К счастью, Microsoft создал Sysmon, делающий анализ атак куда более простым.

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

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


Часть 1: Знакомство с анализом логов Sysmon


Что поможет разобраться в сложностях журнала событий? В конечном итоге SIEM. Она производит нормализацию событий и упрощает их последующий анализ. Но нам не обязательно заходить так далеко, по крайне мере первое время. В начале для понимания принципов SIEM достаточно будет попробовать замечательную бесплатную утилиту Sysmon. И с ней на удивление легко работать. Так держать, Microsoft!

Какие есть возможности у Sysmon?


Если кратко полезная и читабельная информация о процессах (см. картинки ниже). Вы обнаружите кучу полезных деталей, которых нет в журнале событий Windows, но самое главное следующие поля:
  • ID процесса (в десятичной форме, а не hex!)
  • ID родительского процесса
  • Командную строку процесса
  • Командную строку родительского процесса
  • Хэш образа файла
  • Имена образов файла

Sysmon устанавливается одновременно и как драйвер устройства, и как служба подробнее здесь. Её ключевым преимуществом является возможность анализа логов из нескольких источников, корреляция информации и вывод результирующих значений в одну папку журнала событий, находящуюся по пути Microsoft -> Windows -> Sysmon -> Operational. В моих собственных расследованиях логов Windows, от которых волосы встают дыбом, мне постоянно приходилось переключаться между, скажем, папкой с логами PowerShell, и папкой Безопасность, пролистывая журналы событий в героический попытке как-то сопоставить значения между ними. Это ни разу не легкая задача, и как я потом понял, лучше было сразу запастись аспирином.

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

В журнале Windows видна какая-то информация о процессе, но она малополезна. Плюс идентификаторы процессов в шестнадцатеричной форме???


В журнале Windows видна какая-то информация о процессе, но она малополезна. Плюс идентификаторы процессов в шестнадцатеричной форме???

У профессионального ИТ-специалиста с пониманием основ хакинга должна вызвать подозрение командная строка. Использование cmd.exe для последующего запуска другой команды с перенаправлением вывода в файл со странным названием это явно похоже на действия софта по контролю и управлению command-and-control (C2): таким способом создаётся псевдо-шелл с помощью служб WMI.
Теперь давайте взглянем на эквивалент записи из Sysmon, обратив внимание на то, сколько дополнительной информации она нам даёт:

Возможности Sysmon на одном скриншоте: детальная информация о процессе в читабельной форме


Возможности Sysmon на одном скриншоте: детальная информация о процессе в читабельной форме


Вы не только видите командую строку, но и имя файла, путь до исполняемого приложения, что Windows знает об этом (Windows Command Processor), идентификатор родительского процесса, командная строка родителя, запустившего cmd-шелл, а также реальное имя файла родительского процесса. Всё в одном месте, наконец-то!
Из лога Sysmon мы можем сделать вывод, что с высокой долей вероятности эта подозрительная командная строка, которую мы видели в сырых логах, не является результатом нормальной работы сотрудника. Скорее наоборот, она была сгенерирована C2-подобным процессом wmiexec, как я упоминал ранее и была напрямую порождена процессом WMI службы (WmiPrvSe). Теперь у нас есть индикатор того, что удалённый злоумышленник или инсайдер пробует корпоративную инфраструктуру на зуб.

Представляем Get-Sysmonlogs


Конечно замечательно, когда Sysmon располагает логи в одном месте. Но, наверное, было бы ещё лучше, если бы мы могли получить доступ к индивидуальным полям лога программным способом например, через команды PowerShell. В этом случае можно было бы написать небольшой PowerShell-скрипт, который бы автоматизировал поиск потенциальных угроз!
Не у меня первого возникла такая идея. И хорошо, что в некоторых постах форумов и GitHub проектах уже объяснено, как использовать PowerShell для парсинга Sysmon-лога. В моём случае мне хотелось избежать необходимости написания отдельных строк парсинг-скрипта для каждого поля Sysmon. Поэтому я использовал принцип ленивого человека и, как мне кажется, в результате придумал что-то интересное.
Первым важным моментом является возможность команды Get-WinEvent читать Sysmon логи, фильтровать нужные события и выводить результат в PS переменную, как здесь:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}


Если вы захотите самостоятельно проверить работу команды, то через отображение контента в первом элементе массива $events, $events[0].Message, на выходе можно получить серию текстовых строк с очень простым форматом: имя поля Sysmon, двоеточие и затем само значение.

Ура! Вывод Sysmon лога в готовый под JSON формат


Ура! Вывод Sysmon лога в готовый под JSON-формат


Вы думаете о том же, о чём и я? Приложив ещё немного усилий, можно сконвертировать вывод в отформатированную под JSON-строку и затем загрузить её напрямую в PS-объект с помощью мощной команды ConvertFrom-Json .
Я покажу PowerShell-код для конвертации он очень простой в следующей части. А пока что давайте глянем, что может делать моя новая команда под названием get-sysmonlogs, которую я установил как PS-модуль.
Вместо углубления в анализ логов Sysmon через неудобный интерфейс журнала событий, мы можем без усилий искать инкрементальную активность непосредственно из PowerShell-сессии, а также использовать PS-команду where (алиас ?) для сокращения результатов выдачи:

Список cmd-шеллов, запущенных через WMI. Анализ угроз задёшево с помощью нашей собственной команды Get-Sysmonlogs


Список cmd-шеллов, запущенных через WMI. Анализ угроз задёшево с помощью нашей собственной команды Get-Sysmonlogs


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

Sysmon и анализ графов


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

Если вы читали серию Приключения неуловимой малвари, то знаете, что хакеры любят создавать сложные многоэтапные атаки, в которых каждый процесс выполняет свою маленькую роль и готовит плацдарм для следующего шага. Такие вещи крайне сложно отловить просто из сырого лога.
Но с моей командой Get-Sysmonlogs и дополнительной структурой данных, которую мы рассмотрим далее по тексту (конечно же, это граф), у нас появится практичный способ обнаружить угрозы для чего требуется лишь выполнить правильный поиск по вершинам.
Как всегда в наших DYI блог-проектах, чем больше вы работаете над анализом деталей угроз в небольшом масштабе, тем лучше вы осознаёте, насколько сложным является детектирование угроз на уровне организации. И это осознание является крайне важным моментом.

Мы встретим первые интересные сложности во второй части статьи, где начнём связывать друг с другом Sysmon-события в куда более сложные структуры.
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Microsoft , Powershell , Блог компании varonis systems , Sysmon , Графы угроз

Перевод Руководство по анализу Sysmon-угроз, часть 2. Использование данных из Sysmon-событий для выявления угроз

08.07.2020 16:06:56 | Автор: admin


Эта статья является первой частью серии по анализу Sysmon-угроз. Все остальные части серии:
Часть 1. Знакомство с анализом логов Sysmon
Часть 2. Использование данных из Sysmon-событий для выявления угроз (мы тут)
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов

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

  1. Использование PowerShell для прямого доступа к гранулированной информации о процессах;
  2. Построение и визуализация иерархии процессов первый важный шаг в поиске угроз;
  3. Использование метаданных Sysmon для формирования важных метрик, полезных при углублённом расследовании угроз, таких как подсчёт частоты, с которой запускаются конкретные процессы.

Использование Get-Sysmonlogs


Давайте теперь подробнее рассмотрим мою замечательную команду, которая преобразовывает Sysmon-события в объекты PowerShell. Я в какой-то степени горжусь тем, что мне не пришлось прописывать вручную отдельные строки кода для каждого из полей. И вот, собственно, великое раскрытие кода:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 } foreach ($event in $events)  {    $ev = $event.Message -split "`r`n"    $jsons="{ "    foreach ($line in $ev) {        $line=$line -replace "\\","\\" `               -replace "\{"," " `               -replace "\}"," " `               -replace '"','\"' `               -replace "`n"," "         $line=$line -replace '(\s*[\w\s]+):\s*(.*)', '"$1":"$2",'        $jsons = $jsons + $line }         $jsons =$jsons + '"blah" : "blah" }'         ConvertFrom-Json -InputObject $jsons     }}

Весь код сейчас выложен на GitHub и вы можете его скачать и импортировать как Sysmon-модуль для собственного проекта. Единственная нестабильность связана с удалением нескольких неприятных символов скобки, бекслэши, символы конца строки, кавычки чтобы сделать вывод приближённым к JSON.
Итак, классическим сигналом нарушителя, копошащимся вокруг системы, является использование команды whoami, и зачастую следующей после hostname. Хакер (или, возможно, инсайдер), заполучивший чью-то учётную запись, хочет убедиться, что имперсонализация работает, поэтому он часто набирает вышеуказанные команды, как только оказывается на сервере жертвы. Для остальных же whoami и hostname это не те слова, которые они будут вводить в консоли собственной системы, даже если они когда-либо пользуются командной строкой.

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

Обычно, когда хакер проникает в сеть и получает доступ к командой строке, она представляет из себя устаревшую cmd кстати, именно так и происходит в случае взлома при помощи psexec или smbexec. Используя вывод get-symonlogs, можно отловить процессы whoami, которые были порождены этими устаревшими шеллами, и это будет хорошим доказательством угрозы.

Внимание: Whoami запустился через устаревший шелл cmd


Внимание: Whoami запустился через устаревший шелл cmd


С практической же точки зрения поиск по сырым логам журнала событий Windows и сопоставления процессов просто невозможно. Как мы только что видели, записи в Sysmon открывают множество возможностей для анализа угроз. Поэтому давайте продолжим наше исследование посредством сопоставления Sysmom-данных в более сложные структуры.

Азы структур данных: списки и графы


Логи Sysmon не только предоставляют нам командную строку родительского процесса, но и идентификатор этого процесса!

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

Сначала я думал, что мне придётся сдувать пыль с моей копии Структуры данных для поэтов и су-шефов, но тут меня выручили интернеты. Я наткнулся на шикарную коллекцию базовых алгоритмов Дага Финке (Doug Finke) на Gihub, написанную на PowerShell. Спасибо тебе, Даг!
После преодоления некоторой кривой обучения, я смог использовать его алгоритмы для структуризации моих событий Sysmon. Я построил структуры данных в виде списка и графа, а затем, с использованием API, написал PowerShell-функцию поиска команды и вывода иерархии процесса. Круто.

Я назвал её show-threat-path. Она осуществляет поиск в глубину по иерархии процесса и выводит имена приложений и ассоциированные с ними команды для корневого приложения, указанного в качестве входного параметра. В качестве моего первого теста я поискал по whoami.exe. И вот что увидел:

Иерархия процессов: процесс 2452 выглядит подозрительным!


Иерархия процессов: процесс 2452 выглядит подозрительным!


Дополнительный бонус тому, кто заметил на выводе выше, что whoami, ассоциированный с процессом 2452, был вызван через устаревший шелл cmd, который уже в свою очередь был запущен exe-файлом со странным именем в папке Windows.

Хммм. Если вы знакомы с механиками удалённых вызовов psexec, описанными здесь , то мысленно должны уже бить в колокола. Но я расскажу вам маленький секрет: играя роль хакера, я предварительно запустил данный whoami с удалённого сервера Linux с помощью python-скриптов Impacket.

Целью является демонстрация того, что с помощью обогащённых Sysmon логов и небольшой порции PowerShell, можно приготовить вполне практичную утилиту по выявлению уязвимостей, как я это только что проделал с show-threat-path.

Охота на угрозы с помощью направленных графов


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

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

На данном этапе было бы неплохо взглянуть на визуализацию того, о чём я веду речь. К счастью, существует великолепная утилита визуализации PowerShell графов под названием GraphViz, у которой есть чрезвычайно простые оболочки, доступные через PSQuickGraph. Тогда с помощью небольшого куска кода

#Let's graph it!!!$gv = New-Graph -Type BiDirectionalGraph # PSQuickGraphforeach ($e in $g.getAllEdges() )  { $g from Doug Fink's functions    $vs= $e.startvertex   $ve= $e.endvertex    PSQuickGraph\Add-Edge -From $vs.value.Key -To $ve.value.Key -Graph $gv |Out-Null}Show-GraphLayout -Graph $gv

можно визуализировать сложные взаимодействия между приложениями через интерфейс GraphViz:

GraphViz:Библиотека PowerShell для визуализации иерархий процессов


GraphViz: Библиотека PowerShell для визуализации иерархий процессов


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

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

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

В третьей части нашего обзора мы углубимся в анализ и применение алгоритмов и методов для поиска уязвимостей. Оставайтесь с нами!
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Графы , Powershell , Блог компании varonis systems , Sysmon , Графы и визуализация , Анализ угроз

Перевод Руководство по анализу Sysmon-угроз, часть 3. Углубленный анализ Sysmon-угроз с помощью графов

15.07.2020 16:21:33 | Автор: admin


Эта статья является третьей, и финальной, частью серии по анализу Sysmon-угроз. Все остальные части серии:

Часть 1. Знакомство с анализом логов Sysmon
Часть 2. Использование данных из Sysmon событий для выявления угроз
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов (мы тут)

Поиск нестандартных подграфов с данными событий Sysmon (простой пример)


Прежде чем мы ознакомимся с примером выявления аномалий в подграфах, указывающих на потенциальную угрозу (и если эти слова не пробуждают в вас ботаника, то ничто уже не пробудит!), давайте сделаем небольшое отступление.
В этом месте я обязан сделать предупреждение: данный пост вместе с кодом на GitHub не может заменить решение корпоративного класса. Оно может помочь выявить угрозы в меньшем масштабе, но моя благородная задача состоит в том, чтобы помочь представителям IT-безопасности понять и по достоинству оценить реальные решения по защите от угроз. И один из способов достичь этого самостоятельно создать собственное решение (с моей помощью).
Домашние эксперименты помогут понять, насколько сложно масштабировать DIY-софт по выявлению угроз. Вам придётся работать с наборами big data и со всем, что с ними связано: чисткой (что крайне непростая задача), эффективной обработкой (найти нужные структуры данных, алгоритмы и т.д.) и предоставлением результатов с низким количеством ложных cрабатываний, чтобы ваши же коллеги потом не полезли на вас с кулаками. С учётом этого вы можете рассмотреть уже готовое решение по обнаружению угроз но только после завершения нашей серии статей и проведения собственных экспериментов.

Выставление весовых коэффициентов графа


Один из простых способов построить решение по защите от угроз, которое не полагается на сигнатуры вредоносного софта, это использовать граф угроз из предыдущей части.
Такой граф соединяет вершины процессов на базе записей из журнала событий Sysmon. Обратите внимание: я не выделял каждое событие запуска процесса (Event ID 1 в событиях Sysmon) в отдельную вершину. Вместо этого я создал более абстрактный граф, который показывает, скажем, что вершина PowerShell имеет одну связь с любым приложением, которое она запустила из-под любого пользователя одну связь для Excel, одну для браузера и т.д.

Вид дерева PSQuickGraph моего графа угроз Sysmon. Обратите внимание на аномальную ветку под cmd.exe


Вид дерева PSQuickGraph моего графа угроз Sysmon. Обратите внимание на аномальную ветку под cmd.exe


Однако нам всё же желательно отслеживать частоту запускаемых процессов. Например, если PowerShell запустил whoami 1 раз и 10 раз устаревший Windows-редактор Notepad.exe, то данные ребра графа, отходящие от вершины PowerShell, должны быть отмечены соответствующими весами в 1 и 10 соответственно. Логично?
Во многих простейших алгоритмах детектирования угроз данный вес становится метрикой сравнения регионов графа. Основная мысль заключается в том, что подграф с более низким средним уровнем веса по сравнению со средним весом в целом, является подозрительным.
Не так ли? Редко посещаемая вершина является аномальной зоной. Поэтому если пользовательские действия при анализе потенциальных угроз уходят в сторону редко используемого подграфа, следует поднять уровень тревоги до жёлтого.
Описываемый мной подход и нижеприведённые PowerShell скрипты не предназначены для использования в практичных целях для больших инфраструктур. Но для отдельного сервера решение может оказаться рабочим, или, как минимум, предоставить независимую верификацию тех корпоративных решений, которые вы используете.
Говорил ли я уже, что алгоритмы Дага Финке в PowerShell для структур данных являются великолепным и мощным инструментом? Без его работы я бы ничего не достиг в своём проекте графа аномалий. Повторное тебе спасибо, Даг!
С помощью его PowerShell-библиотеки прекрасных граф-функций я легко могу посчитать вес моего Sysmon-графа угроз посредством всего нескольких строчек PS, а также узнать средний вес вершины для всего графа. По мере прохождения графа, код также назначает каждой вершине вес всех её исходящих рёбер:

$AW=0 #average weight$GW=0 #total weight$mset = [System.Collections.ArrayList]@() #master set of subraphs#calculate total weight by summing up the frequencies or weights of the edgesforeach ($e in $g.getAllEdges() ) {    $GW = $GW + $e.weight}write-host "Weight of Graph: " $GW$AW = $GW / $g.vertices.countwrite-host "Average weight per vertex: " $AW#assign weight of edges to verticefor ($i=0; $i -lt $g.vertices.count; $i++) {    $w=0   $v=$g.vertices[$i]   foreach($e in $v.getEdges()) {      if($e -eq $null) {continue}      $w=$w + $e.weight   }   $v.value.Weight = $w}


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

function extend-subgraph($v, $t) {    $vertexQueue = New-Object Queue        #initialize    $vertexQueue.enqueue($v)    $h=$v.value.Weight    $s=@() #subgraph    $s+=$v    $extend=$false    while (!$vertexQueue.isEmpty()) { #bfs        $currentVertex = $vertexQueue.dequeue()        $es= $currentVertex.getEdges()        foreach($e in $es) {            $ev= $e.endVertex                            if ((($h + $ev.value.Weight)/($s.count+1) -lt $th)  {                        #extend the sub-graph                $s+=$ev                $h =$h + $ev.value.weight                #queue it up                $vertexQueue.enqueue($ev)            }        }


Небольшая ремарка для любителей DIY: для создания массива массивов используйте тип arraylist и вы убережёте себя от большой головной боли.

Угрозы и подграфы с низким весом


Существует много разных алгоритмов аномальных графов. Тот, который я использовал, основывается на некоем graphBAD, который я нашёл на просторах интернетов, и я дам ссылку, как только найду его снова.
В целом, главной проблемой в практическом детектировании угроз является поиск хорошего набора данных для формирования базового уровня. Будучи фултайм-блоггером и парттайм специалистом по выявлению угроз, мне так и не удалось создать достаточно интересный Sysmon-лог, содержащий множество разных приложений. Было достаточно сложно сгенерировать аномальные подграфы, так как у меня не было достаточно большого разброса по весам. Так или иначе, при использовании реального сервера у вас может оказаться в руках куда лучший набор данных, чем эпизодическое использование AWS инстанса Windows, как в моём случае.
Написанный мной PS-скрипт аномальных графов вполне выдавал подозрительные подграфы с низкими средними весами. И мне удалось даже поймать несколько интересных окружений (см. ниже).

Алгоритм весов подграфов в действии: интересное окружение с низким весом подграфа 7


Алгоритм весов подграфов в действии: интересное окружение с низким весом подграфа 7


Как я упоминал ранее, существуют и другие алгоритмы обнаружения аномалий в графах с метриками, отличными от простых весовых коэффициентов, стоящие своего времени на изучение. Один из них ищет кластеры схожих вершин и подмечает соединения или связи между разными окружениями. В этом случае аномалия заключается в пользователе или процессе, который связывает окружения с помощью каких-то других характеристик. Логично, не так ли?
Если внутренний ботаник в вас силён, можете ознакомиться со SCAN (Structural Clustering Algorithm for Networks), который как раз осуществляет вышеописанное. Вместе с PowerShell алгоритмами Дага Финке вы даже можете его применить. Я сам хочу взяться за этот проект и выложить его скоро в свой GitHub.

Поиск аномалий посредством случайных обходов


Давайте закончим данный раздел ещё одним способом находить аномалии в графе угроз. Я ссылался на этот подход в конце предыдущей части . Для меня, как для человека с математикой на ты, он является более интуитивным. А фанаты старого ТВ-шоу numb3rs сразу же узнают концепцию [прочищает горло] цепей Маркова.
Для всех оставшихся вы можете рассматривать это как случайный обход по графу. На каждой из вершин мы кидаем кубик и выбираем ребро графа в зависимости от его веса: чем больше вес ребра, тем выше шанс, что мы пойдём по нему. Вам необходимо разбить граф на две части он называется двудольным графом в теории графов с пользователями в одной части и приложениями в другой.
Далее вы ранжируете все приложения-вершины, до которых можно дойти от пользователя, основываясь на вероятности добраться до конкретной вершины. Для анализа угрозы вы тогда будете искать запущенные приложения, и если какие-то из них имеют очень низкую вероятность их достичь, то вы, возможно, нашли реальную угрозу!
Плюс в карму тому, кто связал это с PageRank алгоритмом Google. Я опишу данный момент подробнее в следующей секции, но заинтересованные могут погуглить фразу random walk with restart.

Теория случайного обхода и EQL-практика


Давайте сделаем ещё одно отступление и проанализируем, чего мы пытаемся достичь с помощью лога Sysmon, являющимся великолепным инструментом детектирования угроз и проведения расследований после инцидентов.
  • В предыдущих частях нашей серии я показал, как обрабатывать и вывести базовую информацию о процессах из данных Sysmon. Но в Sysmon логе сокрыто ещё больше информации, если мы будем рассматривать взаимодействие родительского и дочернего процесса как звено графа.
  • В части 2 нашей серии мы преобразовали лог Sysmon в граф, получив тем самым куда больше контекста, что позволило нам продвинуться за пределы простого поиска конкретных вредоносных сигнатур.
  • В третьей части мы углубились в обзор одного простого алгоритма, рассматривающего связи рёбер как весовые коэффициенты. Секции графа, весящие меньше (в терминах рёбер), чем общий средний вес по всему графу, могут являться потенциальной угрозой. Я собираюсь выложить PowerShell скрипты алгоритмов из данной секции в моём GitHub (после наведения в них лоска).


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

Случайный обход графа уязвимостей из данных на базе событий Sysmon


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

Если вы посмотрите мой скрипт графа угроз на GitHub, то обнаружите, что эта частота сохраняется внутри каждого объекта-ребра с помощью чудесных PowerShell-алгоритмов Дага Финке.

Можно рассматривать частоту пересечения каждого из рёбер графа уязвимостей как вероятность!


Можно рассматривать частоту пересечения каждого из рёбер графа уязвимостей как вероятность!


Следующим шагом напрашивается использования этой информации для нахождения вероятности, скажем, запуска PowerShell-ом приложения taskmgr.exe, анализатора процессов Windows, блокнота или hostname.exe.

К чему я клоню?
Вкратце: я могу создать вероятностную матрицу переходов, так любимую последователями Маркова и частно используемую в системах моделирования. Фактически, бросание кубика, переход к следующему приложению в графе и повтор сих действий является случайным обходом графа. В конечном счёте, данный математический метод ранжирует каждую вершину графа в соответствии с вероятностью попадания туда из стартовой точки. И вы узнаете, что, скажем, запуск электронных таблиц из проводника Windows является крайне обыденным процессом, а движка сценариев Windows Script Host Engine теоретически крайне нестандартным и, соответственно, потенциально являющимся индикатором угрозы.
Данный метод известен как Random Walk With Restart (далее RWWR, случайный обход с перезапуском) и является вариацией ныне легендарного PageRank-алгоритма ранжирования Google.
Давайте рассмотрим кусок скрипта, который я написал для подсчёта этих рангов:

#lets build a row$row= @(0)*$g.vertices.count$w=0foreach($e in $start.getEdges()) {    #calculate total frequency    $w+=$e.weight}if ($w -eq 0)  {   #make it connected$row[$ix] =1}else {  #we assign probabilitys    #now create transition probability    foreach($e in $start.getEdges()) {        $ev = $e.endVertex        $p = $e.weight        $jx = v-index $ev.value.Key        $row[$jx]= $p/$w #normalize by dividing by total    }}$P[$ix] = $row  #yay! One row added to transition matrix


Для каждой вершины я рассчитываю итоговую частоту всех соседей и затем назначаю вероятность каждого перехода через нормализацию по суммарному значению. Таким образом, если PowerShell.exe имеет 20 визитов ко всем его соседям, но nc.exe только однажды посещалось от вершины PowerShell.exe, то вероятность перехода будет составлять 1/20 или 0.05. Логично?

Сложность заключается в расчёте матрицы, применяемой в RWWR, но для тех, кто посещал уроки вероятностного моделирования, данная процедура не составит труда. Есть неплохая обзорная статья на этот счёт на сайте Medium.
Мой скрипт, который я называю random-rater, ранжирует и выводит 10 наименьших значений из списка. Таким образом можно получить приложения, которые имеют наименьшую вероятность быть запущенными, начиная от заданной вершины графа угроз. Вот результат, если взять в качестве исходной точки PowerShell.exe:

Алгоритм Random Walk With Restart может выдавать гугл-подобное ранжирование угроз. Хммм, whoami имеет наименьшую вероятность быть запущенной


Алгоритм Random Walk With Restart может выдавать гугл-подобное ранжирование угроз. Хммм, whoami имеет наименьшую вероятность быть запущенной


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

Язык EQL (Event Query Language) для анализа угроз


Сейчас стоит отметить, что производители решений с использованием более сложных подходов для обнаружения угроз в своих продуктах далеко выходят за рамки того, что вы или я могут сделать самостоятельно. И, определённо, куда с более высокой точностью.
Для тех, кто хочет погрузиться в тематику обнаружения угроз, но при этом не хочет работать с моими скриптами я понимаю! существует Event Query Language , или EQL. Это проект с открытым кодом, позволяющий применять язык запросов к журналу Sysmon, и о котором вы можете узнать более подробно из чрезвычайно всеобъемлющего поста. EQL не только отлично подходит для расследования инцидентов, но и может быть использован как инструмент при условии, что у вас есть какая-никакая свежая копия лога Sysmon.
Набор EQL предоставляет обработчик событий, преобразующий лог в удобоваримый JSON. Вы можете ознакомиться с копией моей ветки на GitHub. В отличие от моего статичного show-threat-path PS-скрипта, EQL позволяет вам делать запросы на лету.
Допустим, что меня заинтересовали все шеллы cmd.exe, которые были запущены от лица scvhost.exe, это может являться признаком использования атакующим psexec.exe или smb.exe. Запрос будет выглядеть следующим образом:

Использование EQL для поиска шеллов cmd.exe, запущенного от svchost.exe. Кстати, jq это Linux-утилита для отображения JSON данных


Использование EQL для поиска шеллов cmd.exe, запущенного от svchost.exe. Кстати, jq это Linux-утилита для отображения JSON данных

Есть ещё более крутой и мощный способ получения данного результата через использование модификатора потомка. Такой EQL запрос позволяет искать по всем процессам с указанным предком, где угодно в иерархии. Например, вы можете искать приложения, которые, скажем, имели в качестве предка процесс regsvr32.exe и могли воспользоваться широко известной уязвимостью, о которой я рассказывал здесь.
Слишком многое хочется рассказать об EQL в этом и так большом посте, поэтому я лучше опубликую отдельную статью о деталях мастерства работы с EQL для поиска уязвимостей.

Заключительные мысли о DIY-решениях для выявления угроз


Я обещал загрузить репозиторий Sysmon со всеми скриптами обнаружения угроз, описанными в этой статье. Периодически заглядывайте на мой GitHub , так как я со временем буду добавлять новые PS-утилиты на базе графов для выявления угроз вместе с дополнительной документацией слишком много информации для раскрытия в одной статье.
Вы добрались до этого места, поздравляю!
Попробуйте мои скрипты или используйте их в качестве основы для разработки собственных идей по обнаружению угроз. PowerShell вполне подходит для применения в сложных алгоритмах. Для меня, выросшего на языке Linux-шелла, было приятной неожиданностью поработать со зрелым скриптовым языком. И я советую ознакомиться с галереей PowerShell, ещё одним отличным ресурсом готовых боевых скриптов: вам не нужно изобретать велосипед заново в мире PowerShell.
Другим более важным выводом из всей статьи будет осознание того, что производители решений корпоративного уровня не только используют куда более сложные технологии выявления угроз, чем те, которые ИТ-разработчик способен написать в своё свободное время, но и приспособленность этих решений для работы с трафиком уровня крупной организации. Конечно, использование DIY-решений для анализа недоиспользуемого сервера или дополнительной валидации работы корпоративных продуктов является хорошей идеей. Но анализ угроз и их выявление действительно является проблемой больших данных, и, очевидно, это не та задача, которую способен решить PowerShell.
Если вас заинтересовала возможность побольше узнать о том, как Varonis справляется с задачей анализа и выявления угроз, вы всегда можете запросить персональную демонстрацию.
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Big data , Powershell , Блог компании varonis systems , Sysmon , Выявление угроз , Анализ графов , Eql

Зачем внедрять EDR, если есть SIEM, Sysmon и антивирус?

23.07.2020 10:06:27 | Автор: admin
Без мониторинга конечных точек сегодня уже не получится в полной мере обеспечить безопасность и вовремя обнаруживать факты компрометации инфраструктуры. Джентельменский набор сетевой мониторинг, антивирус и стандартный аудит на конечных точках уже не позволяет противодействовать не только серьезным группировкам, но даже злоумышленникам с низким уровнем подготовки. Почему? Рассмотрим на конкретных примерах.


Кадр из мультфильма Жил-был пес

Итак, стандартных средств мониторинга становится недостаточно. Этому способствуют несколько факторов:

индикаторы компрометации (хеши, IP-адреса и доменные имена) часто бывают одноразовыми, так как их изменение не представляет труда для злоумышленника, особенно в случае с APT;

атакующие применяют в работе легитимные исполняемые файлы, штатные средства ОС и т. д.;

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

на практике часто встречается ВПО, которое не детектируется ни антивирусом, ни сетевыми сигнатурами;

с ростом инфраструктуры становится проблематично вовремя обновлять сигнатуры и лицензии.

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

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

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

DLL Hijacking
Living off the land
Использование Mimikatz

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

Расширенный аудит. Windows Event Logging


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

При грамотной настройке мы закрываем некоторые пробелы стандартного подхода и видим:

факты запуска процессов вместе с командной строкой;

запускаемые PowerShell-скрипты в декодированном виде (Script block logging);

частично работу с файлами и реестром;

активность, связанную с учетными записями (создание/удаление пользователей и так далее).

У нас появляется возможность детектировать новые техники:

некоторые варианты DLL hijacking по созданию файлов с определенными путями;

использование LOLBin и Mimikatz по паттернам в командной строке.

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



Код Mimikatz с измененными строками


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

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

2. Отсутствие контроля.
Если события перестанут регистрироваться или поступать в используемые системы мониторинга, вовремя понять это, скорее всего, не получится, так как нет централизации.

3. Простота противодействия.
Даже злоумышленники с низкой квалификацией знают, как скрываться от стандартного аудита. Вопрос только в том, насколько эффективно и незаметно они это сделают.

Примеры техник:

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

Приостановка потоков службы аудита с последующим выполнением вредоносных действий или удалением событий (например, с помощью инструмента github.com/QAX-A-Team/EventCleaner).

Сокрытие событий с помощью нарушения структуры соответствующего файла .evtx (http://personeltest.ru/aways/github.com/fox-it/danderspritz-evtx).

Временное перенаправление событий в отдельный файл. О такой технике мы писали в предыдущей статье.

4. Сама по себе настройка аудита не даст возможности организовать мониторинг. Для начала придется наладить централизованный сбор событий, а потом использовать дополнительные инструменты, например, SIEM, для их анализа.

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

Сходство Sysmon и EDR


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



Обратные вызовы ядра. Например, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Где и как вызываются эти и другие обратные вызовы, можно увидеть в соответствующих функциях ядра. Пример вызова callbackов при создании процесса приведен ниже:



Цикл вызова callbackов в CreateProcessW -> NtCreateUserProcess -> PspInsertThread.
То есть вызывает эти callbackи поток родительского процесса, вызвавший CreateProcess.

Event Tracing Windows (ETW).
В части появления событий ETW работает похожим образом. Снова рассмотрим пример с созданием процесса. При вызове CreateProcessW поток родительского процесса выполняет следующие действия (упрощенная схема):

CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, переход в режим ядра)
NtCreateUserProcess (ntoskrnl.exe, далее работа в режиме ядра)
PspInsertThread (здесь вызываются и callbackи)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite

Таким образом, поток родительского процесса является прямым инициатором создания события ETW. Примерно таким же образом работает запись остальных событий, например, сетевых. Ниже приведен пример создания событий, связанных с сетевой активностью:



Функция ядра EtwpNetProvTraceNetwork


Из всего вышесказанного следует два вывода:

1) И Sysmon, и EDR использует для сбора событий только встроенные возможности Windows, что обеспечивает надежность работы.

2) Злоумышленник может использовать методы сокрытия, которые будут применимы и к Sysmon, и к EDR. Обратные вызовы ядра можно снять в памяти ядра с помощью подписанного драйвера. А зная описанный механизм регистрации событий, можно понять, почему Sysmon и некоторые EDR не могут обнаружить определенные техники инжектирования в процесс (например, с помощью APC) или PPID spoofing.

Sysmon


Использование Sysmon позволяет расширить возможности стандартного аудита. События при этом записываются в отдельный журнал. Некоторые примеры информации, которой нет в аудите Windows, но есть в Sysmon:

более подробная информация о запускаемых исполняемых файлах (хеш, оригинальное имя, цифровая подпись и так далее);
загрузка драйверов и библиотек;
изменение статуса сервиса Sysmon;
создание потока в другом процессе;
доступ к процессу;
хеши файлов, создаваемых в альтернативных потоках данных;
создание пайпов.

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

1) копирование LOLBin под другим именем можно выявлять по соответствию полей OriginalFileName, Image и Hashes из события создания процесса;

2) можно детектировать загрузку неподписанных библиотек, что в некоторых случаях позволяет обнаружить DLL hijacking;

3) есть потенциальная возможность выявлять Mimikatz с помощью вышеупомянутых методов или по событию ProcessAccess к процессу lsass.exe.

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

При этом нужно учитывать следующие моменты:

Необходимость дополнительных инструментов. Так как события пишутся в журнал, то, как и в случае с расширенным аудитом Windows, Sysmon нужно использовать в связке с другими инструментами, например, SIEM.

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

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

Про способы обхода некоторых возможностей Sysmon можно почитать здесь, здесь и здесь.

Endpoint Detection & Response


С ростом размера и критичности инфраструктуры недостатки Sysmon становятся существенными. Качественные EDR имеют несколько преимуществ (специфические для конкретных продуктов возможности описывать не будем):

1) Расширенный набор регистрируемых событий
Здесь все зависит от конкретного продукта. Например, встречается логирование всего интерактивного ввода в командную строку, что позволяет детектировать техники, которые не видно ни с аудитом Windows, ни с Sysmon.

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

Логирование интерактивного ввода, в свою очередь, поможет детектировать такой случай, если Mimikatz не будет перекомпилирован (в нашем случае строки остались нетронутыми).

2) Централизованное управление и настройка
В большой инфраструктуре возможность централизованной проверки состояния и изменения настроек агента играет критическую роль. Без нее реагирование может затягиваться на часы, а то и на дни.

3) Самодостаточность
В большинстве случаев EDR это самостоятельный продукт со своим интерфейсом, который может использоваться не только в связке с другими инструментами, но и отдельно.

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

4) Возможность активного реагирования
Во время реагирования на инцидент необходимость выполнить какие-либо действия на множестве систем практически всегда становится проблемой.

EDR позволяет в удобной интерактивной форме выполнять множество действий:

работать с файлами и реестром
блокировать сетевые соединения
завершать процессы
сканировать yara-правилами
собирать артефакты для последующего анализа (например, образ памяти)
автоматизация всего вышеуказанного в той или иной степени
и многое другое.

Так как класс продуктов EDR изначально создавался для обеспечения хостового мониторинга и реагирования, недостатков у таких решений в этой области существенно меньше. Здесь все зависит от возможностей конкретного продукта. Не обходится и без слепых зон, например, отсутствует возможность углубленного анализа сетевой активности (проблема, которая успешно решается продуктами NTA/NDR).

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

Автор: Аскер Джамирзе, старший инженер технического расследования отдела расследования инцидентов JSOC CERT
Подробнее..
Категории: Информационная безопасность , Sysmon , Блог компании ростелеком-солар , Мониторинг сети , Edr , Антивирус , Впо

Работа с событиями аудита Windows сбор, анализ, реагирование

18.09.2020 20:23:44 | Автор: admin

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто засыпать сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества шумящих, малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые классические политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)) (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Категория аудита

Подкатегория аудита

События аудита

EventID

Комментарии

Вход учетной записи

Аудит проверки учетных данных

Успех, Отказ

4776

Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации.

Аудит службы проверки подлинности Kerberos

Успех, Отказ

4771

Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации.

4768

Запрос билета Kerberos, при этом следует анализировать коды ответа сервера.

Примечание:

Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%\debug\netlogon.log

Управление учетными записями

Аудит управления учетными записями компьютеров

Успех

4741

Заведение устройства в домен Active Directory; может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию может завести в домен 10 устройств, на которых может быть установлено неконтролируемое компанией ПО, в том числе вредоносное.

Аудит управления группами безопасности

Успех, Отказ

4728

Добавление члена глобальной группы.

4732

Добавление члена локальной группы.

4756

Добавление члена универсальной группы.

Аудит управления учетными записями пользователей

Успех, Отказ

4720

Создание учетной записи.

4725

Отключение учетной записи.

4740

Блокировка учетной записи.

4723

Смена пароля.

4724

Сброс пароля.

Подробное отслеживание

Аудит создания процессов

Успех

4688

При создании процесса.

4689

При завершении процесса.

Примечание:

Чтобы для командного интерпретатора велась запись введенных команд, следует включить политику Конфигурация компьютера - Конфигурация Windows - Административные шаблоны - Система - Аудит создания процессов -> Включать командную строку в события создания процессов.

Примечание:

Чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге Конфигурация компьютера - Конфигурация Windows - Административные шаблоны - Компоненты Windows - Windows PowerShell политики Включить ведение журнала модулей (в настройках политики указать все модули символом *) и Включить регистрацию блоков сценариев PowerShell (в настройках политики отметить check-box Регистрация начала или остановки вызова блоков сценариев). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell.

Вход/выход

Аудит выхода из системы

Успех

4634

Для неинтерактивных сессий.

4647

Для интерактивных сессий и RDP-подключений.

Примечание:

При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.).

Аудит входа в систему

Успех, Отказ

4624

При успешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации.

4625

При неуспешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771.

4648

При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе хакерской утилиты Mimikatz.

Примечание:

При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа - несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д.

Аудит других событий входа и выхода

Успех, Отказ

4778

RDP-подключение было установлено.

4779

RDP-подключение было разорвано.

Аудит специального входа

Успех

4672

При входе с административными полномочиями.

Доступ к объектам

Аудит сведений об общем файловом ресурсе

Успех, Отказ

5145

При доступе к системных сетевым ресурсам, таким как \\C$\ .

Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети.

Аудит других событий доступа к объектам

Успех, Отказ

4698

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

Изменение политики

Аудит изменения политики аудита

Успех

4719

Изменение политики аудита.

4906

Изменение настройки CrashOnAuditFail.

Примечание:

Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности в политике Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности.

Система

Аудит расширения системы безопасности

Успех

4610

4614

4622

При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно.

4697

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

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности политику Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам в значение Аудит всего. После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

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

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. подписок на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess="false"}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы Сборщик событий Windows (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить Тип запуска в значение Автостарт и запустить Службу удаленного управления Windows (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY\NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN\Event Log Readers (Читатели журнала событий). После этого необходимо перезапустить Службу удаленного управления Windows (WinRM) и службу Журнал событий Windows (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера... (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address...) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел Подписки (Subscriptions). Нажимаем правой кнопкой мыши и выбираем Создать подписку, задаем имя подписки. Далее выбираем опцию Инициировано исходным компьютером (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку Выбрать группы компьютеров (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем Выбрать события (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>  <Query Id="0" Path="Security">    <Select Path="Security">*</Select>  </Query></QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах Подписки можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе Журналы Windows Перенаправленные события (Windows Logs Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName - имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

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

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml файл конфигурации, sysmon64.exe файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации - Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню Вид и отметить check-box Отобразить аналитический и отладочный журналы.

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка Журналы Windows -> Безопасность / Security), нажатием правой кнопки мыши на имени журнала выберем пункт Фильтр текущего журнала. Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box Изменить запрос вручную. Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку Подробности, а там выбрать radio-button Режим XML, в котором в формате ключ-значение будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security - возьмем для примера имя Username:

<QueryList><Query Id="0" Path="Security"><Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]</Select></Query></QueryList>

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

<QueryList>  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>  </Query></QueryList>

3. Произведем поиск сразу по двум условиям - возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>  <Query Id="0" Path="Security">    <Select Path="Security">*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetUserName']='Username']]</Select>  </Query></QueryList>

4. Поиск по трем условиям - дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>  <Query Id="0" Path="Security">    <Select Path="Security">*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetUserName']='Username']] and*[EventData[Data[@Name='LogonType']='2']]</Select>  </Query></QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям - это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором ИЛИ, указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>  <Query Id="0" Path="Security">    <Select Path="Security">*[System[(EventID=4624)]]</Select><Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]or*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]</Suppress>  </Query></QueryList>

IRP-система штатными средствами Windows

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

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв Планировщик заданий (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке Триггеры мы увидим возможность создать свой триггер. При нажатии на кнопку Создать откроется новое окно, в котором в drop-down списке следует выбрать вариант При событии, а в открывшейся форме отображения установить radio-button Настраиваемое. После этих действий появится кнопка Создать фильтр события, нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

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

<QueryList>  <Query Id="0" Path="Security">    <Select Path="Security">*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetUserName']='Username']] and *[EventData[Data[@Name='LogonType']='2']]</Select>  </Query></QueryList>

Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">    <Select Path="Microsoft-Windows-Sysmon/Operational">*[System[(EventID=10)]] and *[EventData[Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']] and *[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]</Select>  </Query></QueryList>

Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

Подробнее..
Категории: Информационная безопасность , Sysmon , Логи , Аудит событий , События журнала , Журнал событий windows , Ibm qradar siem , Windows events , Xpath

Sysmon теперь может записывать содержимое буфера обмена

21.09.2020 16:09:27 | Автор: admin
О релизе 12 версии Sysmon сообщили 17 сентября на странице Sysinternals. На самом деле в этот день вышли также новые версии Process Monitor и ProcDump. В этой статье я расскажу о ключевом и неоднозначном нововведении 12 версии Sysmon типе событий с Event ID 24, в который логируется работа с буфером обмена.



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

Новое событие содержит следующие поля:

Image: процесс, данные из которого были записаны в буфер обмена.
Session: сеанс, в котором выполнилась запись в буфер обмена. Это может быть system(0)
при работе в интерактивном или удаленном режиме и т.д.
ClientInfo: содержит имя пользователя сеанса, а в случае удаленного сеанса исходное имя хоста и IP-адрес, если эти данные доступны.
Hashes: определяет имя файла, в котором был сохранен скопированный текст (аналогично работе с событиями типа FileDelete).
Archived: статус, был ли сохранен текст из буфера обмена в архивной директории Sysmon.

Пара последних полей вызывают тревогу. Дело в том, что с версии 11 Sysmon может (при соответствующих настройках) сохранять разные данные в свою архивную директорию. Например, Event ID 23 логирует в себя события по удалению файлов и может их сохранять всё в той же архивной директории. К имени файлов, созданных в результате работы с буфером обмена, добавляется тег CLIP. Сами файлы содержат точные данные, которые были скопированы в буфер обмена.

Так выглядит сохраненный файл
image

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

Так выглядит установка Sysmon с соответствующей настройкой архивной директории:
image

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

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

Подведем итог возможностей Sysmon по работе с буфером обмена.

Фиксируются:

  • Текстовая копия вставляемого текста через RDP и локально;
  • Захват данных из буфера обмена различными утилитами/процессами;
  • Копирование/вставка текста с/на локальную виртуальную машину, даже если этот текст ещё не был вставлен.

Не фиксируются:

  • Копирование/вставка файлов с/на локальную виртуальную машину;
  • Копирование/вставка файлов через RDP
  • Вредоносная программа, захватывающая ваш буфер обмена, записывает только в сам буфер обмена.


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

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

Чтобы узнать подробнее про InTrust, прочитайте наши предыдущие статьи или оставьте заявку в форме обратной связи.

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

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

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

А кто это сделал? Автоматизируем аудит информационной безопасности
Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Security , Софт , Блог компании gals software , Sysmon , Quest , Intrust , Gals software , Information security , Siem , Clm , Log management , Sysinternals

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru