Расширенный аудит Windows. Или с чего начать расследование инцидентов?

Когда я начал разбираться в SOC (Security Operations Center), то довольно быстро понял, что стандартная Windows не дает особого понимания, что вообще внутри нее происходит. События входа, создание процессов, изменение политик – все это просто не пишется либо пишется в достаточно урезанном виде.

Здесь я хотел бы показать (конечно, частично), каким вообще образом настроить аудит безопасности Windows 10/11 так, чтобы получить вполне читаемые и полезные события, которые можно будет использовать для расследования инцидентов ИБ. Разберемся, что и зачем мы включаем, что такое Event ID и как потом выглядят события на реальной практике. Все действия будут выполняться на ВМ, дабы не затрагивать хост.

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

• ОС: Windows 10 Pro, 22H2, сборка 19045.6456;

• Гипервизор (виртуализация) второго типа: VMware Workstation 17 Pro 17.6.4 build-24832109.

Аудитом в Windows управляет служба LSASS (Local Security Authority Subsystem Service). LSASS запускается при старте ОС и работает в фоне. Особенностью ее работы является то, что она постоянно находится в оперативной памяти и хранит временные данные об активных сеансах пользователей. Именно это позволяет быстро переключаться между учетными записями без необходимости постоянного ввода пароля. Основной задачей данной службы является управление учетными записями пользователей, обработка запросов на вход в систему и обеспечение защиты конфиденциальной информации. Также служба выполняет еще некоторые функции:

• Проверка учетных записей пользователей;

• Контроль доступа к защищенным ресурсам;

• Хранение паролей и ключей шифрования;

• Взаимодействие с контроллерами домена Active Directory (AD) в корпоративных сетях.

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

1. Базовый аудит (9 категорий) – настраивается через secpol.msc;

2. Расширенный аудит (53 подкатегории) – настраивается через утилиту auditpol.

Я буду рассматривать именно расширенные категории, так как именно расширенные политики позволяют включать не просто «Аудит входа в систему» в целом, а подходить к настройке аудитов более тонко, включать, например, только «Вход в систему» и «Специальный вход», дабы не захламлять журнал событиями IPsec и Kerberos (которых просто не имеется на локальной машине, точнее, они будут работать только в доменной среде AD).

Каждая категория имеет свой собственный неизменяемый идентификатор GUID и локализованное имя (в зависимости от языка системы). В русской версии Windows, например, «Вход в систему», «Выход из системы» и так далее. Это имеет значение, так как команды, отличные от языка системы, не будут корректными.

Ключевые подкатегории для мониторинга и реагирования на инциденты:

Я перечислил только те, которые являются основными и без которых вообще никуда. Весь список подкатегорий можно посмотреть командой auditpol /list /subcategory:*. А GUID-ы для каждой подкатегории – в документации Microsoft.

Перейдем к практике. На чистой ВМ откроем командную строку от имени администратора, так как auditpol требует прав администратора на изменение политик безопасности.
Включаем базовый набор подкатегорий:

auditpol /set /subcategory:"Вход в систему" /success:enable /failure:enableauditpol /set /subcategory:"Выход из системы" /success:enable /failure:enableauditpol /set /subcategory:"Блокировка учетной записи" /success:enable /failure:enableauditpol /set /subcategory:"Специальный вход" /success:enable /failure:enableauditpol /set /subcategory:"Другие события входа и выхода" /success:enable /failure:enableauditpol /set /subcategory:"Управление учетными записями" /success:enable /failure:enableauditpol /set /subcategory:"Управление группой безопасности" /success:enable /failure:enableauditpol /set /subcategory:"Файловая система" /success:enable /failure:enableauditpol /set /subcategory:"Реестр" /success:enable /failure:enableauditpol /set /subcategory:"Объект-задание" /success:enable /failure:enableauditpol /set /subcategory:"Создание процесса" /success:enable /failure:enableauditpol /set /subcategory:"Завершение процесса" /success:enable /failure:enableauditpol /set /subcategory:"Аудит изменения политики" /success:enable /failure:enableauditpol /set /subcategory:"Изменение политики проверки подлинности" /success:enable /failure:enableauditpol /set /subcategory:"Другие системные события" /success:enable /failure:enable

После включения категорий, проверяем командой:

auditpol /get /category:*

Каждая включенная подкатегория должна нам показывать Успех и сбой. Если где-то «Без аудита», это значит, что либо мы не включили данную подкатегорию, либо не совпало имя подкатегории (или нужен GUID, о чем ниже).

Что же делать, если имя все равно не совпадает?

Некоторые подкатегории, например Использование прав, затрагивающие конфиденциальные данные, могут не включиться даже с правильно введенным именем. В таком случае на помощь нам приходит GUID. Это неизменяемый идентификатор, одинаковый для всех языков ОС, например для этой же категории:

auditpol /set /subcategory:"{0cce9222-69ae-11d9-bed3-505054503030}" /success:enable /failure:enable

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

Отдельного внимания заслуживает PowerShell. Это основной инструмент администрирования, но он может выступать и основным инструментом атакующего в Windows-среде. Стандартный аудит процессов (Event ID: 4688) покажет только факт запуска powershell.exe и его аргументы. Но если злоумышленник будет использовать обфускацию (кодирование в Base64, вызов команды через Invoke-Expression), командная строка будет нечитаемой.

Для таких случаев в Windows предусмотрели встроенное логирование PowerShell, которое записывает декодированное содержимое скриптов. Включается оно через реестр:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f

Эта настройка включает Script Block Logging – запись каждого блока кода, который выполняется PowerShell, в журнал Microsoft-Windows-PowerShell/Operational.

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

Тут может возникнуть логичный вопрос: что же нам это дает?

• Событие 4104 (Script Block Logging) – содержит поле ScriptBlockText с полным текстом выполненного скрипта. Если злоумышленник запускал powershell -enc <Base64>, то в журнале будет декодированная версия, а не битый Base64;

• Событие 4103 (Module Logging) – показывает, какие модули PowerShell загружались. Это полезная штука для обнаружения нестандартных модулей (скрипты Invoke-Mimikatz, PowerView и т. п.).

Как это выглядит на практике:

Сначала выполним безобидную команду в PowerShell:

Write-Output "This is a test script"Get-Process

Первая команда выводит строку This is a test script в консоль. Вторая команда уже выводит список всех запущенных процессов в системе.

Затем сделаем что-то похожее на обфускацию, как это нередко делают вредоносные скрипты:

$cmd = "Write-Output 'test'"Invoke-Expression $cmd

Первая команда сохраняет безобидную строку Write-Output 'test' в переменную $cmd. Вторая команда выполняет содержимое данной переменной как команду PowerShell через Invoke-Expression.

После чего смотрим в Event Viewer: Журналы приложений и служб → Microsoft → Windows → PowerShell → Operational. Включаем фильтрацию по ID 4103, 4104 и видим введенные команды в исходном виде.

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

Далее важным считаю рассказать про аудит создания процессов (Event ID 4688). Это событие записывается каждый раз в журнал Безопасность, когда в системе запускается исполняемый файл. Но есть одно но: по умолчанию поле Command Line (командная строка процесса) в этом событии будет пустым.

Для SOC командная строка – важная информация. Именно она показывает, с какими аргументами запущен процесс. Например:

• net user backdoor Passw0rd! /add – создание пользователя с паролем;

• powershell -enc SQBFAFgA... – выполнение закодированного скрипта;

• reg save HKLM\SAM C:\temp\sam.save – попытка дампа SAM.

Без командной строки мы видим только, что запущен какой-то процесс, например net.exe или powershell.exe, но не видим, что именно они делали.

Включение аудита командной строки (включается через реестр cmd от имени администратора):

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Существует также альтернативный способ включения через групповые политики (gpedit.msc): Конфигурация компьютера → Административные шаблоны → Система → Аудит создания процессов → Включить параметр «Включать командную строку в событиях создания процессов». Результат будет тот же.

После применения (и желательно перезагрузки) в событии 4688 появится заполненное поле Process Command Line.

Можно заметить на рисунке выше, что у нас теперь поле Process Command Line содержит полную команду с аргументами. В нашем случае: whoami /all.

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

Тест 1: Успешный вход – Event ID 4624.

Блокируем экран Win + L, входим обратно под пользователем krix с корректным паролем. В журнале безопасности по фильтру 4624 видим событие с ключевыми полями:

• Logon Type (Тип входа) – 2: интерактивный;

• Account Name (Имя учетной записи) – кто вошел: kr1x;

• Workstation Name (Имя рабочей станции) – с какого компьютера: DESKTOP-SCS7L35;

• Process Name (Имя процесса) – процесс, обработавший вход: C:\Windows\System32\svchost.exe (обычно svchost.exe, как в моем случае, или winlogon.exe).

Тест 2: неудачный вход – Event ID 4625.

Блокируем экран Win + L и намеренно вводим неправильный пароль 2-3 раза. В журнале безопасности по фильтру 4625 видим событие, с ключевыми полями:

• Account Name (Имя учетной записи) – учетная запись, под которую пытались войти: kr1x.

• Failure Reason/Status (Причина отказа) – код ошибки. Самые частые:

  • 0xC000006A – неверный пароль (наш случай);

  • 0xC0000072 – учетная запись отключена;

  • 0xC0000234 – учетная запись заблокирована (в результате множества неудачных попыток).

В SOC множественные 4625 на одну учетную запись за короткий промежуток времени могут означать брутфорс. А если на множество учетных записей, то Password Spraying.

Тест 3: Создание процесса с аргументами – Event ID 4688.

Открываем cmd и выполняем:

whoami /all > C:\temp\test_process.txt

whoami /all выводит полную информацию о текущем пользователе (имя, SID, группы в которых состоит пользователь) и перенаправляет этот вывод в .txt файл.

В журнале безопасности по фильтру 4688 видим событие с whoami.exe, с ключевыми полями:

• Creator Process ID (PID процесса-создателя): в моем случае 0xf38;

• New Process ID (PID нового процесса): в моем случае 0x7f0;

• Command Line (Командная строка процесса): полная команда с аргументами: whoami /all.

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

Тест 4: Создание пользователя и добавление в администраторы – Event ID 4720, 4732.

Открываем cmd и выполняем:

net user testuser TestPass123 /addnet localgroup administrators testuser /add

Первая команда создает локального пользователя testuser и паролем TestPass123. Вторая команда добавляет данного пользователя в группу administrators выдавая ему полные права в системе.

В журнале безопасности по фильтру 4720, 4732 видим событие:

• 4720 – Создание пользователя. Ключевые поля:

  • Account name (Имя учетной записи. Кого создали): в моем случае testuser;

  • Subject Account Name (Имя учетной записи. Кто создал): в моем случае kr1x;

  • Attributes (Параметры пользователя): в моем случае «значение не задано».

• 4732 – Добавление в группу. Ключевые поля:

  • Member Name (Имя учетной записи. Кого добавили): в моем случае запись отсутствует, хотя ИД безопасности заполнено корректно. Это может быть связано с тем, что пользователь testuser был только что создан: Windows присваивает SID (Security Identifier) сразу, однако служба LSASS не всегда успевает разрешить этот SID в читаемое имя пользователя к моменту записи события 4732, особенно если добавление в группу происходит сразу же после создания учетной записи. В таком случае в журнал попадает SID (который уникален и неизменен), а поле имени остается пустым. Если возникает такая ситуация, всегда нужно обращать внимание на поле ИД безопасности, такая ситуация не является признаком атаки, это техническая особенность;

  • Group Name (Имя группы. В какую группу): в моем случае Администраторы;

  • Subject Account Name (Имя учетной записи. Кто выполнил): в моем случае kr1x.

Если в реальной системе мы видим 4720 на учетную запись, и вы знаете, что эту учетную запись точно никто не должен был создавать – это эскалация.

Тест 5: Создание запланированной задачи.

Создаем задачу в cmd от имени администратора:

$task = Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" | Where-Object { $_.Id -eq 106 } | Select-Object -Skip 1 -First 1$task.ToXml()

Событие 4698 в журнале Безопасность (которое должно было появиться при создании задачи) на локальной Windows 10 без домена, как выяснилось, не генерируется. Это особенность системы.

Вместо этого буду использовать журнал TaskScheduler/Operational, событие 106 (Task register). Его можно быстро найти в PowerShell (от имени администратора):

$task = Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" | Where-Object { $_.Id -eq 106 } | Select-Object -Skip 1 -First 1$task.ToXml()

Первая команда извлекает из журнала TaskScheduler/Operational все события с ID 106, пропускает первое из них (так как в моем случае это оказалась задача OneDrive) и сохраняет второе. Вторая команда выводит XML-содержимое данного события.

В ответе мы можем наблюдать базовую информацию о событии 106: задача с таким-то именем зарегистрирована таким-то пользователем. Однако мы не видим само тело задачи, а только ее задачи и учетную запись.

Ключевые поля, на которые стоит обратить внимание:

• TaskName (Имя задачи): TestTask3;

• UserContext (Кто зарегистрировал задачу): DESKTOP-SCS7L35\kr1x.

Но также мы понимаем, что все задачи планировщика хранятся в виде XML-файлов по пути C:\Windows\System32\Tasks\. Имя файла соответствует имени задачи \TestTask3, и файл находится по пути C:\Windows\System32\Tasks\TestTask3 . Это стандартное расположение задач, и его необходимо знать.

Выполняем команду:

Get-Content "C:\Windows\System32\Tasks\TestTask3"

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

Получаем полное содержимое XML-файла, в котором уже можем увидеть саму команду: cmd.exe с аргументом: /c echo test, триггером является однократный запуск: 2026-07-18T23:00:00, и пользователь, от имени которого задача выполняется: DESKTOP-SCS7L35\kr1x. Замечу, что указывается не только учетная запись пользователя, от имени которого выполняется задача, но и уровень привилегий: LeastPrivilege. Это значит, что данная задача выполняется с минимальными правами текущего пользователя, без эскалации до прав администратора. В настоящей атаке злоумышленник всеми силами старался бы получить уровень привилегий: HighestAvailable, чтобы получить максимальные права в системе.

То, что мы обсудили в данной статье, – это базовый, но минимально достаточный набор для первичного анализа инцидентов. События 4624, 4625, 4688, 4720, 4732 и 4104 уже позволяют ответить на ключевые вопросы: кто зашел в систему, кто пытался зайти (но это было неудачно), какие процессы и с какими аргументами запускались, создавались ли новые пользователи и задачи.

Но необходимо понимать, что расширенный аудит Windows – это первый слой. Для полноценного мониторинга его необходимо совмещать с более глубокими утилитами мониторинга, например, с Sysmon, который дает куда более детальное представление: родительские процессы, хеши исполняемых файлов, сетевые соединения, операции с памятью и многое другое.

Главное, что я выделяю для себя: аудит в Windows нужно настраивать осознанно, понимая, какие Event ID вам нужны и вообще зачем. Когда вы создаете аудиты, их обязательно нужно тестировать на работоспособность. Хорошим способом является начальная настройка в виртуальной (изолированной от хоста) среде, чтобы проверить, что и как работает.