В этой статье мы рассмотрим, как с помощью политик аудита Windows можно узнать какие программы запускались на компьютере. Довольно часто от администратора требуют предоставить информацию о том, какие приложения запускает пользователь, когда он запускал приложение в последний раз и т.д. Эту информацию можно собрать из журнала событий Windows и преобразовать в удобный отчет с помощью PowerShell.
Сначала нужно включить политику аудита запуска/остановки процессов в Windows.
- Откройте редактор локальной групповой политики gpedit.msc ;
Если вы хотите включить политику аудита процессов на компьютерах в домене Active Directory, нужно использовать редактор доменных GPO –
gpmc.msc
. - Перейдите в раздел GPO Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy;
- Включите политику Audit process tracking и тип событий Success;
- Сохраните изменения и обновите локальные политики на клиенте командой:
gpupdate /force
Откройте Event Viewer (
eventvwr.msc
) и разверните раздел Windows Logs -> Security. Теперь при запуске любой программы (процесса) в этом журнале событий появляется событие Process Creation с EventID 4688.
A new process has been created.
В информации о событии указан пользователь, запустивший программу (
Creator Subject
), имя исполняемого файла процесса (
New Process Name
) и родительский процесс, из которого было запущено приложение (
Creator Process Name
).
Обратите внимание, что при включении рассмотренной выше политики Audit process tracking в журнал Security начинают сохранятся все события, связанные с процессами. Если вы хотите уменьшить число событий в Event Viewer и сохранять только информацию о событиях запуска, можно отключить данную политику и включить только расширенную политику аудита Audit Process Creation (Windows Settings -> Security Settings -> Advanced Audit Policy Configurations -> System Audit Policy -> Detailed Tracking).
Чтобы в события аудита записывалась информация о параметрах запуска процессов (аргументы, с которыми запускаются программы), включите также параметр GPO Include command line in process creation events в Computer Configuration -> Administrative Templates -> System -> Audit Process Creation.
После включения этой политики в аргументе Process Command Line видно, с каким аргументом запускался тот или иной процесс.
Не забудьте увеличить размер журнала Security со стандартных 20 Мб. Это позволит хранить история запуска приложения за более длительный период. Для этого откройте свойства журнала Security и увеличьте значение параметра Maximum log size.
Для анализа программ, запущенных пользователем можно использовать фильтры Event Viewer. Но это не очень удобно. Ниже я покажу несколько PowerShell скриптов который позволят вам получить удобные списки событий с историей запуска приложений пользователями. Для получения событий из журнала Event Viewer мы будем использовать команду Get-WinEvent:
$processhistory = @()
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
$events=Get-WinEvent -FilterHashtable @{
LogName = 'Security'
starttime="$today"
ID = 4688
}
foreach ($event in $events){
$proc = New-Object PSObject -Property @{
ProcessName=$event.Properties[5].Value
Time=$event.TimeCreated
CommandLine=$event.Properties[8].Value
User=$event.Properties[1].Value
ParentProcess=$event.Properties[13].Value
}
$processhistory += $proc
}
$processhistory| Out-GridView
Данный PowerShell скрипт выберет все события запуска программ за сегодняшний день и выведет список процессов, времени запуска и пользователях в графическую таблицу Out-GridView.
Полученный массив объектов можно использовать для выполнения различных запросов.
Например,
- Найти всех пользователей, которые запускали определённое приложение:
$proc_name=”notepad++.exe”
$processhistory | where-object {$_.ProcessName –like “*$proc_name*”}|out-gridview
- Вывести список программ, которые запускал сегодня определенный пользователь:
$username="aivanov"
$processhistory | where-object {$_.User –like “*$username*”}|out-gridview
Такие скрипты часто используем для анализа запуска программ пользователей на серверах RDS фермы.
Также история запуска программ в Windows ведется в файле %SystemRoot%\AppCompat\Programs\Amcache.hve. Файл заблокирован Windows и прочитать его можно только, загрузившись с LiveCD или загрузочного/установочного диска. В файле есть метки запуска, установки/удаления программы, контрольные суммы исполняемого файла (SHA1). Для преобразования этого бинарного файла в текстовый формат нужно использовать сторонние утилиты (например, regripper).
Одна из часто встречающихся типов атак — порождение злонамеренного процесса в дереве под вполне себе добропорядочными процессами. Подозрение может вызвать путь к исполняемому файлу: частенько вредоносное ПО использует папки AppData или Temp, а это нехарактерно для легитимных программ. Справедливости ради, стоит сказать, что некоторые утилиты автоматического обновления исполняются в AppData, поэтому одной только проверки места запуска недостаточно для утверждения, что программа является вредоносной.
Дополнительный фактор легитимности — криптографическая подпись: многие оригинальные программы подписаны вендором. Можно использовать факт отсутствия подписи как метод выявления подозрительных элементов автозагрузки. Но опять же есть вредоносное ПО, которое использует украденный сертификат, чтобы подписать самого себя.
Ещё можно проверять значение криптографических хэшей MD5 или SHA256, которые могут соответствовать некоторым ранее обнаруженным вредоносным программам. Можно выполнять статический анализ, просматривая сигнатуры в программе (с помощью правил Yara или антивирусных продуктов). А ещё есть динамический анализ (запуск программы в какой-либо безопасной среде и отслеживание ее действия) и реверс-инжиниринг.
Признаков злонамеренного процесса может быть масса. В этой статье мы расскажем как включить аудит соответствующих событий в Windows, разберём признаки, на которые опирается встроенное правило InTrust для выявление подозрительного процесса. InTrust — это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.
При запуске программы, она загружается в память компьютера. Исполняемый файл содержит компьютерные инструкции и вспомогательные библиотеки (например, *.dll). Когда процесс уже запущен, он может создавать дополнительные потоки. Потоки позволяют процессу выполнять разные наборы инструкций одновременно. Существует много способов проникновения вредоносного кода в память и его запуска, рассмотрим некоторые из них.
Самый простой способ запустить вредоносный процесс — заставить пользователя запустить его напрямую (например, из вложения электронной почты), затем при помощи ключа RunOnce запускать его при каждом включении компьютера. Сюда же можно отнести «безфайловое» вредоносное ПО, которое хранит скрипты PowerShell в ключах реестра, которые выполняются на основе триггера. В этом случае сценарий PowerShell является вредоносным кодом.
Проблема с явным запуском вредоносного программного обеспечения заключается в том, что это известный подход, который легко обнаруживается. Некоторые вредоносные программы предпринимают более хитрые вещи, например, используют другой процесс, чтобы начать исполняться в памяти. Следовательно, процесс может создать другой процесс, запустив определенную компьютерную инструкцию и указав исполняемый файл (.exe) для запуска.
Файл можно указать, используя полный путь (например, C:\Windows\system32\cmd.exe) или неполный (например, cmd.exe). Если исходный процесс небезопасен, он позволит запускать нелегитимные программы. Атака может выглядеть так: процесс запускает cmd.exe без указания полного пути, злоумышленник помещает свой cmd.exe в такое место, чтобы процесс запустил его раньше легитимного. После запуска вредоносной программы она, в свою очередь, может запустить легитимную программу (например, C:\Windows\system32\cmd.exe), чтобы исходная программа продолжала работать должным образом.
Разновидность предыдущей атаки — DLL-инъекция в легитимный процесс. Когда процесс запускается, он находит и загружает библиотеки, которые расширяют его функциональные возможности. Используя DLL-инъекцию, злоумышленник создает вредоносную библиотеку с тем же именем и API, что и у легитимной. Программа загружает вредоносную библиотеку, а она, в свою очередь, загружает легитимную, и, по мере необходимости, для выполнения операций, вызывает её. Вредоносная библиотека начинает выполнять роль прокси для хорошей библиотеки.
Еще один способ поместить вредоносный код в память — вставить его в небезопасный процесс, который уже запущен. Процессы получают входные данные из различных источников — читают из сети или файлов. Обычно они выполняют проверку, чтобы убедиться в легитимности входных данных. Но некоторые процессы не имеют должной защиты при выполнении инструкций. При такой атаке не существует библиотеки на диске или исполняемого файла с вредоносным кодом. Всё хранится в памяти вместе с эксплуатируемым процессом.
Теперь разберемся методикой включения сбора подобных событий в Windows и с правилом в InTrust, которое реализует защиту от подобных угроз. Для начала, активируем его через консоль управления InTrust.
Правило использует возможности отслеживания процессов ОС Windows. К сожалению, включение сбора таких событий далеко не очевиден. Нужно изменить 3 разных настройки групповой политики:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit process tracking
Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit process creation
Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > Include command line in process creation events
После включения, правила InTrust позволяют обнаруживать неизвестные ранее угрозы, которые демонстрируют подозрительное поведение. Например, можно выявить описанное тут вредоносное ПО Dridex. Благодаря проекту HP Bromium, известно, как устроена такая угроза.
В цепочке своих действий Dridex использует schtasks.exe, чтобы создать запланированное задание. Использование именно этой утилиты из командной строки считается весьма подозрительным поведением, аналогично выглядит запуск svchost.exe с параметрами, которые указывают на пользовательские папки или с параметрами, похожими на команды «net view» или «whoami». Вот фрагмент соответствующего правила SIGMA:
detection:
selection1:
CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'
selection2:
ParentImage: '*\svchost.exe*'
CommandLine:
- '*whoami.exe /all'
- '*net.exe view'
condition: 1 of themВ InTrust всё подозрительное поведение включено в одно правило, потому что большинство этих действий не являются специфическими для конкретной угрозы, а скорее являются подозрительными в комплексе и в 99% случаев используются для не совсем благородных целей. Такой список действий включает, но не ограничивается:
- Процессы, выполняющиеся из необычных мест, таких как пользовательские временные папки.
- Хорошо известный системный процесс с подозрительным наследованием — некоторые угрозы могут попытаться использовать имя системных процессов, чтобы остаться незамеченными.
- Подозрительные исполнения административных инструментов, таких как cmd или PsExec, когда они используют учетные данные локальной системы или подозрительное наследование.
- Подозрительные операции теневого копирования — обычное поведение вирусов-вымогателей перед шифрованием системы, они убивают резервные копии:
— Через vssadmin.exe;
— Через WMI. - Регистровые дампы целых кустов реестра.
- Горизонтальное перемещение вредоносного кода при удаленном запуске процесса с использованием таких команд, как at.exe.
- Подозрительные локальные групповые операции и доменные операции с использованием net.exe.
- Подозрительные операции брандмауэра с использованием netsh.exe.
- Подозрительные манипуляции с ACL.
- Использование BITS для эксфильтрации данных.
- Подозрительные манипуляции с WMI.
- Подозрительные скриптовые команды.
- Попытки сдампить безопасные системные файлы.
Объединенное правило очень хорошо работает для обнаружения угроз, таких как RUYK, LockerGoga и других вирусов-вымогателей, вредоносных программ и наборов инструментов для киберпреступлений. Правило проверено вендором в боевых средах, чтобы минимизировать ложные срабатывания. А благодаря проекту SIGMA, большинство этих индикаторов производят минимальное количество шумовых событий.
Т.к. в InTrust это правило мониторинга, вы можете выполнить ответный сценарий в качестве реакции на угрозу. Можно использовать один из встроенных сценариев или создать свой собственный, а InTrust автоматически распространит его.
Кроме того, можно проверить всю связанную с событием телеметрию: скрипты PowerShell, выполнение процессов, манипуляции с запланированными задачами, административную активность WMI и использовать их для постмортемов при инцидентах безопасности.
В InTrust есть сотни других правил, некоторые из них:
- Выявление атаки понижения версии PowerShell — когда кто-то специально использует старую версию PowerShell, т.к. в более старой версии не было возможности аудита происходящего.
- Выявление входа в систему с высоким уровнем привилегий — когда учетные записи, которые являются членами определенной привилегированной группы (например, администраторы домена), случайно или из-за инцидентов безопасности интерактивно входят в систему на рабочих станциях.
InTrust позволяет использовать лучшие практики безопасности в виде предустановленных правил обнаружения и реакции. А если вы считаете, что нечто должно работать иначе — можно сделать свою копию правила и настроить как нужно. Отправить заявку на проведение пилота или получение дистрибутивов с временными лицензиями можно через форму обратной связи на нашем сайте.
Подписывайтесь на нашу страницу в Фейсбуке, публикуем там краткие заметки и интересные ссылки.
Почитайте другие наши статьи по теме информационной безопасности:
Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP
Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам
Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)
Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты
А кто это сделал? Автоматизируем аудит информационной безопасности
Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)
Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.
- Введение
- Знакомство с расширенным аудитом Windows
- Настройка политик аудита
- Усиление цифровой обороны
- Выводы
Введение
Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.
На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).
Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.
Знакомство с расширенным аудитом Windows
Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.
Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».
Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Рисунок 1. Политика аудита
Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Рисунок 2. Конфигурация расширенной политики аудита
Ниже на рисунке видно, как они коррелируют между собой.
Рисунок 3. Корреляция аудита и расширенного аудита
В общей сложности нам доступны 10 политик и 60 подкатегорий.
Таблица 1. Категории и подкатегории аудита
| Категория (Category) | Подкатегория (Subcategory) | |
| Вход учётной записи (Account Logon) | Аудит проверки учётных данных (Audit Credential Validation) | |
| Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service) | ||
| Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations) | ||
| Аудит других событий входа учётных записей (Audit Other Account Logon Events) | ||
| Управление учётными записями (Account Management) | Аудит управления группами приложений (Audit Application Group Management) | |
| Аудит управления учётными записями компьютеров (Audit Computer Account Management) | ||
| Аудит управления группами распространения (Audit Distribution Group Management) | ||
| Аудит других событий управления учётными записями (Audit Other Account Management Events) | ||
| Аудит управления группами безопасности (Audit Security Group Management) | ||
| Аудит управления учётными записями пользователей (Audit User Account Management) | ||
| Подробное отслеживание (Detailed Tracking) | Аудит активности DPAPI (Audit DPAPI Activity) | |
| PNP-действие аудита (Audit PNP Activity) | ||
| Аудит создания процессов (Audit Process Creation) | ||
| Аудит завершения процессов (Audit Process Termination) | ||
| Аудит событий RPC (Audit RPC Events) | ||
| Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше] | ||
| Доступ к службе каталогов DS (DS Access) | Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication) | |
| Аудит доступа к службе каталогов (Audit Directory Service Access) | ||
| Аудит изменения службы каталогов (Audit Directory Services Changes) | ||
| Аудит репликации службы каталогов (Audit Directory Service Replication) | ||
| Вход / выход (Logon / Logoff) | Аудит блокировки учётных записей (Audit Account Lockout) | |
| Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims) | ||
| Аудит расширенного режима IPsec (Audit IPsec Extended Mode) | ||
| Аудит основного режима IPsec (Audit IPsec Main Mode) | ||
| Аудит быстрого режима IPsec (Audit IPsec Quick Mode) | ||
| Аудит выхода из системы (Audit Logoff) | ||
| Аудит входа в систему (Audit Logon) | ||
| Аудит сервера политики сети (Audit Network Policy Server) | ||
| Аудит других событий входа и выхода (Audit Other Logon / Logoff Events) | ||
| Аудит специального входа (Audit Special Logon) | ||
| Доступ к объектам (Object Access) | Аудит событий, создаваемых приложениями (Audit Application Generated) | |
| Аудит служб сертификации (Audit Certification Services) | ||
| Аудит сведений об общем файловом ресурсе (Audit Detailed File Share) | ||
| Аудит общего файлового ресурса (Audit File Share) | ||
| Аудит файловой системы (Audit File System) | ||
| Аудит подключения платформы фильтрации (Audit Filtering Platform Connection) | ||
| Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop) | ||
| Аудит работы с дескрипторами (Audit Handle Manipulation) | ||
| Аудит объектов ядра (Audit Kernel Object) | ||
| Аудит других событий доступа к объектам (Audit Other Object Access Events) | ||
| Аудит реестра (Audit Registry) | ||
| Аудит съёмного носителя (Audit Removable Storage) | ||
| Аудит диспетчера учётных записей безопасности (Audit SAM) | ||
| Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging) | ||
| Изменение политики (Policy Change) | Аудит изменения политики аудита (Audit Policy Change) | |
| Аудит изменения политики проверки подлинности (Audit Authentication Policy Change) | ||
| Аудит изменения политики авторизации (Audit Authorization Policy Change) | ||
| Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change) | ||
| Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change) | ||
| Аудит других событий изменения политики (Audit Other Policy Change Events) | ||
| Использование привилегий (Privilege Use) | Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use) | |
| Аудит других событий использования привилегий (Audit Other Privilege Use Events) | ||
| Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use) | ||
| Система (System) | Аудит драйвера IPsec (Audit IPsec Driver) | |
| Аудит других системных событий (Audit Other System Events) | ||
| Аудит изменения состояния безопасности (Audit Security State Change) | ||
| Аудит расширения системы безопасности (Audit Security System Extension) | ||
| Аудит целостности системы (Audit System Integrity) | ||
| Аудит доступа к глобальным объектам (Global Object Access Auditing) | Файловая система (File system) | |
| Реестр (Registry) |
Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.
Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).
Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории
События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).
Рисунок 5. Аудит создания процессов регистрирует успешные события
Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.
Рисунок 6. Вкладка с описанием политики
Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).
Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.
Рисунок 7. Настройка SACL
Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).
Рисунок 8. Принудительное переопределение параметров политики аудита
Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».
Рисунок 9. Использование инструмента auditpol
Настройка политик аудита
Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.
Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.
Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.
Таблица 2. Рекомендуемые настройки аудита Windows
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Усиление цифровой обороны
Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.
Рисунок 10. Журналирование командной строки процесса
Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.
Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).
Рисунок 11. Путь к аудиту создания процессов
Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).
Рисунок 12. Настройка «Включать командную строку в события создания процессов»
После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.
В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.
Рисунок 13. Детектирование mimikatz
Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.
PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.
Список поддерживаемых ОС:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 8.1
- Windows 8
- Windows 7 SP1
Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.
Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)
Рисунок 14. Путь к аудиту Windows PowerShell
Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.
Рисунок 15. Включить регистрацию блоков сценариев PowerShell
После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.
Рисунок 16. Пример регистрируемого события 4104
Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.
Рекомендуем для всех основных журналов следующие объёмы:
- журнал «Установка» (Setup) — не менее 10 МБ,
- журнал «Система» (System) — не менее 50 МБ,
- журнал «Приложение» (Application) — не менее 50 МБ,
- журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).
При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).
Рисунок 17. Настройка хранения журналов аудита
Выводы
Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.
В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.
Using standard Windows auditing mechanisms, you can log all process creation events. This also works in the Home editions of Windows.
-
Enable auditing for process creation events:
%windir%\system32\auditpol.exe /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable -
Enable the
Include command line in process creation events feature:Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit] "ProcessCreationIncludeCmdLine_Enabled"=dword:00000001enable-command-line.reg
Every log message will contain this very verbose explanation:
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.This is particularly distracting when querying the event log from PowerShell. This PowerShell function therefore removes this explanation from each message:
function Get-ProcessAuditEvents {
[CmdletBinding()]
param(
[long]
$MaxEvents = [long]::MaxValue
);
Get-WinEvent -MaxEvents $MaxEvents -FilterHashtable @{
LogName = 'Security';
Id = 4688;
} | ForEach-Object -Process {
$_.Message = [regex]::Replace( $_.Message, '(\s+)Token Elevation Type indicates(.+)$', '', 'Singleline' );
$_.Message = [regex]::Replace( $_.Message, 'Token Elevation Type:\s+%%(\d+)', {
param(
[System.Text.RegularExpressions.Match]
$match
);
$line = $match.Groups[0];
$explain = switch( $match.Groups[1].Value ) {
'1936' { 'Full token'; }
'1937' { 'Elevated token'; }
'1938' { 'Limited token'; }
};
return "$line ($explain)";
});
$_.Message = [regex]::Replace( $_.Message, '(Process ID:\s+)0x([a-f0-9]+)', {
param(
[System.Text.RegularExpressions.Match]
$match
);
$header = $match.Groups[1].Value;
$id = [int32]::Parse(
$match.Groups[2].Value,
[System.Globalization.NumberStyles]::HexNumber
);
return "$header$id";
});
return $_;
}
}Get-ProcessAuditEvents.ps1
Additionally, the function will convert hexadecimal process IDs to the more familiar decimal notation. Use the function as follows:
PS> Get-ProcessAuditEvents -MaxEvents 1 | Format-List -Property TimeCreated, Message
TimeCreated : 2023-04-22 05:37:41
Message : A new process has been created.
Creator Subject:
Security ID: S-1-5-21-574766472-1934979887-525962139-1009
Account Name: Admin
Account Domain: DESKTOP-BHAKPDJ
Logon ID: 0x11A9F9
Target Subject:
Security ID: S-1-0-0
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 7032
New Process Name: C:\Windows\System32\notepad.exe
Token Elevation Type: %%1937 (Elevated token)
Mandatory Label: S-1-16-12288
Creator Process ID: 7940
Creator Process Name: C:\Windows\System32\cmd.exe
Process Command Line: "C:\Windows\System32\notepad.exe" C:\windows\system32\drivers\etc\hostsYou can also easily filter the events:
PS> Get-ProcessAuditEvents -MaxEvents 100 | Where-Object -Property 'Message' -Match -Value 'notepad' | Format-ListВсе запускаемые в Windows программы так или иначе оставляют в системе след, причем касается это не только установленных, но и портативных приложений. Следы запуска программ остаются в виде записей журнала, истории действий, ключей реестра, а также файлов префетчинга в папке %windir%\Prefetch. Данные могут быть использованы для отслеживания деятельности пользователя, в частности, истории запуска им исполняемых файлов программ, осталось только как-то унифицировать к этим данным доступ.
В действительности, в Windows имеется более простое и удобное решение — политики аудита. После активации настройки при каждом запуске исполняемого файла той или иной программы Windows станет автоматически создавать в системном журнале событий информативные записи, которые затем могут быть преобразованы в удобочитаемый формат с помощью средств командной строки или PowerShell.
Включаем политику аудита запуска процессов
- Запустите редактор CPO командой gpedit.msc;
- Перейдите в раздел политик, указанный на скриншоте;
- В правой колонке найдите настройку «Аудит отслеживания процессов» и включите ее. Тип событий выберите «Успех»;
- Сохраните настройки и обновите политики, выполнив в командной строке команду gpupdate /force.
Чтение записей аудита
- Откройте системный журнал событий командой eventvwr.msc и разверните ветку Журналы Windows -> Безопасность;
- Нажмите справа «Фильтр текущего журнала» и отсортируйте события по коду 4688.
Этот код событий имеют все записи, указывающее на запуск процессов, например, с помощью политик аудита мы установили, что 05.05.2022 в 12:30:42 пользователем user был запущен мессенджер Telegram.
Да, стоит обратить внимание, что указанной выше политикой отслеживается все связанные с созданием процессов события, из-за чего раздел журнала может оказаться довольно пухлым. Чтобы исключить эти второстепенные события, вместо «Аудита отслеживания процессов» используйте политику «Аудит создания процессов».
Парсинг файла Amcache.hve
Получить доступ к истории запуска десктопных и универсальных приложений без использования аудита можно проанализировав файл Amcache.hve, расположенный в папке %windir%\AppCompat\Programs.
Открыть его в работающей системе не получится, скопировать его можно только из-под LiveCD.
Amcache.hve — бинарный файл, для извлечения из него данных в удобочитаемом виде вам понадобится тулза RegRipper.
Скачайте архив с утилитой со странички разработчика github.com/keydet89/RegRipper3.0, распакуйте и запустите исполняемый файл rr.exe.
В поле «Hive File» укажите путь к файлу Amcache.hve, в поле «Report File» — путь к текстовому файлу отчета и нажмите «Rip!».
В результате вы получите лог со списком путей исполняемых файлов программ и прикрепленными к ним временными метками LastWrite (открывавшиеся последними).
