KomuraSoft LLC
Связаться с нами
Меню

Политика аудита безопасности Windows и расследование журнала событий на практике — как стать ИТ-службой, которая умеет читать 4625

· · Windows, Безопасность, Журнал событий, Политика аудита, Проектирование журналов, PowerShell, Информационные системы

«С прошлой ночи одна учётная запись снова и снова блокируется. Разберитесь, почему». «Хочу проверить, не пытался ли кто-то войти под учёткой уволенного сотрудника». «На этом сервере можно узнать, кто, когда и что запускал?» — такие запросы в один прекрасный день внезапно прилетают ИТ-сотруднику малого или среднего бизнеса или разработчику, который сдал систему заказчику. И тогда последней опорой оказывается журнал событий Security в Windows.

Но стоит реально открыть «Просмотр событий», и вас ждут две реальности. Нужного события нет в журнале (политика аудита не включена) либо оно похоронено под горой событий и нечитаемо (журнал раздут шумом). Аудит безопасности «пишется, если его включить», но если не спроектировать, что именно и насколько глубоко писать, в нужный момент он не поможет.

Две реальности, которые ждут в «Просмотре событий»Открыв «Просмотр событий», вы либо не находите нужное событие, потому что политика аудита не включена, либо не можете его прочитать, потому что журнал раздут шумом и похоронен под массой событий, поэтому нужно спроектировать, что и насколько писатьне записанопохороненоОткрыть «Просмотр событий»Какая реальность ждёт?Нужное событие не записаноНечитаемо из-за массы событийПолитика аудита выключенаРаздуто шумомСпроектировать, что и насколько писать

Рис. 1: «Не записано» или «похоронено и нечитаемо». В обоих случаях причина — не спроектирован охват записи.

Эта статья по первичным источникам на август 2026 собирает устройство политики аудита (две системы — базовая и расширенная), подкатегории, которые в среде малого и среднего размера стоит включить как минимум, чтение типовых идентификаторов событий вроде 4624/4625/4740/4688, расчёт ёмкости журнала Security и практику расследования через PowerShell. Если статьи этого сайта про аудит NTLM, подпись SMB, BitLocker и брандмауэр были про «укрепить защиту», эта статья — про «сделать так, чтобы потом можно было подтвердить, что произошло», продолжение, которое связывает их вместе.

1. Сначала вывод

  • У политики аудита две системы — «базовая» и «расширенная (Advanced Audit Policy)» — и их нельзя смешивать. Microsoft явно пишет, что использование обеих оставляет результаты аудита в непредсказуемом состоянии. Унифицируйте на расширенной стороне (более 40 подкатегорий).1
  • Текущее состояние смотрите командой auditpol /get /category:*. Она перечисляет настройки аудита, которые реально действуют сейчас, независимо от того, пришли они из GPO или из локальной настройки.2
  • «Включить всё» делать нельзя. Включение подкатегорий, которые порождают огромный объём событий, хоронит нужные события под шумом и бьёт по производительности. Отправная точка — базовые рекомендации Microsoft, дальше добавляйте только необходимое.34
  • Успешный вход — 4624, неудачный — 4625. У 4624 «какой это был вход» читают по типу входа (2 = Interactive, 3 = Network, 10 = RemoteInteractive и так далее).5
  • У 4625 причину отказа даёт код Status/Sub Status. Типовые: 0xC0000064 = несуществующее имя пользователя, 0xC000006A = неверный пароль, 0xC0000072 = отключённая учётка, 0xC0000234 = блокировка.6
  • Где записывается событие, задано жёстко. 4624/4625 пишутся на машине, к которой обращались; проверка учётных данных (4776) и отказ предварительной проверки подлинности Kerberos (4771) — на контроллере домена. Смотрите не ту машину — и ошибочно решите, что «журнала нет».678
  • Половина проектирования журнала Security — сама ёмкость: максимальный размер и хранение. Если хранение в режиме перезаписи, старые события исчезают первыми. Проверьте максимальный размер и число записей через Get-WinEvent -ListLog Security и расширьте, считая назад от нужного числа дней хранения.910
  • Запись командной строки при создании процесса (4688) мощная, но ценой того, что секреты попадают в журнал открытым текстом. Перед включением проверьте скрипты.1112

2. Основы политики аудита — не смешивать «базовую» и «расширенную»

Политика аудита Windows существует в двух системах.1

  • Базовая политика аудита: девять категорий в «Локальные политики > Политика аудита». Это старая система, ещё до Windows Vista.
  • Расширенная конфигурация политики аудита (Advanced Audit Policy Configuration): более 40 настроек подкатегорий в «Параметры безопасности > Расширенная конфигурация политики аудита». Каждую базовую категорию она раскладывает на несколько подкатегорий: например, одной базовой категории «Аудит событий входа учётной записи» на расширенной стороне соответствуют четыре подкатегории. Включить одну базовую категорию — то же самое, что включить все соответствующие подкатегории, и тогда пишется большой объём событий, которые вам могут быть вовсе не интересны.1

Важно то, что эти две системы несовместимы. Microsoft прямо пишет: «Не используйте одновременно базовую и расширенную политику аудита — это может дать непредсказуемые результаты аудита». Когда расширенная политика аудита применяется через Group Policy, существующие настройки аудита этого компьютера сначала очищаются, затем применяются расширенные; с этого момента надёжно управлять аудитом можно только с расширенной стороны. В средах, которые пользуются расширенной стороной, включите параметр безопасности «Аудит: принудительно применять параметры подкатегории политики аудита», чтобы базовая сторона не перезаписала её (на автономных машинах это включено по умолчанию).14

Связь базовой и расширенной политики аудитаБазовая и расширенная политика аудита несовместимы, и использование обеих оставляет результаты аудита в непредсказуемом состоянии, поэтому унифицируют на расширенной стороне и включают принудительное применение подкатегорий, чтобы базовая сторона не перезаписала настройкиданетБазовая политика аудита（9 категорий）Используют обе?Расширенная политика аудита（40+ подкатегорий）Непредсказуемый результат аудитаУнифицировать на расширеннойВключить принудительные настройки подкатегорийНе дать базовой перезаписать

Рис. 2: Две системы несовместимы. Унифицируйте на расширенной стороне и параметром «принудительно» не дайте базовой перезаписать настройки.

Проверить текущее состояние — одна команда, из командной строки с правами администратора.2

rem список действующих настроек аудита по подкатегориям
auditpol /get /category:*

rem резервная копия в CSV до изменений и восстановление
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

Вывод auditpol — это «политика, которая в результате реально действует», независимо от того, пришла она из GPO или из локальной настройки. Им же удобно сверяться, когда настройка, которую должны были раздать через GPO, похоже, не применилась. Изменение самих настроек аудита записывается как событие 4719, поэтому «аудит кто-то выключил, и никто не заметил» тоже можно проследить задним числом.12

auditpol показывает результирующую политикуВывод auditpol — это действующая политика аудита независимо от того, пришла она из GPO или из локальной настройки, им можно сверяться когда GPO не применился, а изменение самих настроек аудита остаётся в событии 4719Настройки, розданные GPOПолитика, которая реально действуетЛокальные настройкиСписок через auditpol /getСверка, когда GPO не применилсяИзменение самой политики аудита4719 пишется, можно проследить

Рис. 3: auditpol возвращает действующие настройки независимо от источника. Само изменение политики аудита остаётся в 4719.

3. Таблица решения: какие подкатегории включать как минимум

Почему «на всякий случай включить всё» — плохой ход, ясно. Microsoft предупреждает, например, что аудит успеха для подкатегорий использования привилегий порождает такой объём событий, что другие записи в журнале безопасности становится трудно найти, и это ещё и заметно бьёт по производительности.4 Ёмкость журнала (глава 5) конечна, поэтому чем больше шума вы пишете, тем сильнее съедается срок хранения событий, которые реально нужны. Проектирование аудита — это решение, что не записывать.

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

Рис. 4: «Включить всё» хоронит как раз те события, которые важны. Проектирование аудита — решить, что не записывать.

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

Подкатегория (категория) Основные идентификаторы Что даёт Рекомендация для малого и среднего
Вход в систему (вход/выход) 4624 / 4625 Успех и отказ входа, тип входа, источник Успех + отказ. С Windows 10 1809 успех и отказ и так включены по умолчанию3
Специальный вход (там же) 4672 / 4964 Вход с привилегиями администратора Успех
Блокировка учётной записи (там же) 4625 Неудачный вход к уже заблокированной учётке Отказ (4625 — событие отказа; у этой подкатегории нет событий успеха)13
Управление учётными записями пользователей (управление учётными записями) 4720 / 4726 / 4738 / 4740 Создание, удаление, изменение, блокировка учётки Успех + отказ
Управление группами безопасности (там же) 4728 / 4732 / 4756 (добавление), 4729 / 4733 / 4757 (удаление) Добавление и удаление членов административных и других групп (глобальные/локальные/универсальные) Успех (у этой подкатегории нет событий отказа)14
Проверка учётных данных (вход учётной записи) 4776 Успех или отказ проверки подлинности NTLM. Для доменной учётки пишется на DC7 Успех + отказ
Служба проверки подлинности Kerberos (там же, только DC) 4768 / 4771 Выдача TGT и отказ предварительной проверки (неверный пароль и т. п.)8 Успех + отказ на DC
Создание процесса (подробное отслеживание) 4688 Кто что запустил и из какого родительского процесса Успех. Перед включением записи командной строки прочитайте предостережение главы 7
Другие события доступа к объектам (доступ к объектам) 4698 Создание назначенного задания (типовой приём закрепления)15 Рассмотреть включение успеха
Изменение политики аудита (изменение политики) 4719 Изменение самих настроек аудита Успех + отказ

Наоборот, аудит доступа к объектам файловой системы и реестра, использование привилегий и подкатегории пакетного фильтра (5152 и подобные) по умолчанию лучше не трогать. Они полезны при узком SACL или на ограниченный период разбора, а не как постоянно включённые на полную — иначе они съедят журнал.4

Как обращаться с подкатегориями большой массы событийАудит доступа к объектам файловой системы и реестра, использование привилегий и пакетный фильтр при постоянном включении на полную съедают журнал, поэтому они полезны при узком SACL или только на период разборавсегда на полнуюузкий SACLтолько на период разбораПодкатегории с массой событийКак включать?Аудит доступа к объектамИспользование привилегий и пакетный фильтрЖурнал будет съеденПолезноПолезно

Рис. 5: Доступ к объектам и использование привилегий не держат постоянно на полную. Польза — когда сузили объект и срок.

4. Как читать типовые идентификаторы событий

4.1. 4624 — успешные входы разбирают по типу входа

4624, «Учётная запись успешно вошла в систему», записывается на машине, где создан сеанс входа (на стороне, к которой обращались).5 Событие идёт большим объёмом, поэтому первый шаг чтения — разобрать по типу входа (Logon Type).5

Тип входа Имя Смысл на практике
2 Interactive Вход с консоли этого ПК
3 Network Доступ по сети (общие папки, средства администрирования и т. п.). Самый частый: срабатывает по числу машин
4 Batch Пакетный запуск (назначенные задания и т. п.)
5 Service Запуск службы (через диспетчер управления службами)
7 Unlock Снятие блокировки экрана
8 NetworkCleartext Сетевой вход, при котором пароль передали пакету проверки подлинности открытым текстом
9 NewCredentials Дублирование существующего токена с другими учётными данными (эквивалент runas /netonly)
10 RemoteInteractive Удалённый рабочий стол
11 CachedInteractive Вход по кэшированным учётным данным (когда DC недоступен)

Рядом стоит смотреть имя учётки в «New Logon», адрес источника в «Network Information», «Authentication Package» (NTLM или Kerberos) и «Elevated Token» (есть ли у сеанса привилегии администратора). Если нужно отслеживать только входы с привилегиями администратора, полезно и событие 4672 (Special privileges assigned to new logon), которое пишется с тем же Logon ID.5

Как разбирать 46244624 идёт большим объёмом, поэтому сначала разбирают по типу входа, затем смотрят имя учётки и источник, пакет проверки подлинности и повышенный токен, а вход с привилегиями администратора сверяют с 4672 того же Logon ID4624 успешный входРазбор по типу входаПроверить ключевые поляИмя учётки и источникПакет проверки подлинностиПовышенный токенОтслеживание привилегий администратора4672 с тем же Logon ID

Рис. 6: 4624 сначала разбирают по типу входа, затем читают поля. Привилегированный вход коррелируют с 4672.

4.2. 4625 — причину отказа фиксируют кодом Status/Sub Status

4625, «Ошибка входа учётной записи в систему», записывается на машине, на которой пытались войти.6 На формулировку поля «Failure Reason» лучше не полагаться: надёжнее читать шестнадцатеричный код Status/Sub Status. Типовые такие.6

  • 0xC0000064: несуществующее имя пользователя. Частая серия за короткое окно может указывать на атаку перебора учёток
  • 0xC000006A: неверный пароль. Повторяющиеся отказы к конкретной учётке могут указывать на подбор пароля
  • 0xC000006D: неверное имя пользователя или сведения для проверки подлинности
  • 0xC000006F: вне разрешённых часов входа
  • 0xC0000070: с рабочей станции, которой вход не разрешён
  • 0xC0000072: учётка отключена администратором (попытки к учётке уволенного сотрудника видны здесь)
  • 0xC000015B: запрошенный тип входа на этой машине не разрешён
  • 0xC0000193: срок учётки истёк
  • 0xC0000234: блокировка

«Кто, откуда и почему не вошёл» фиксируется тройкой: целевая учётка + источник (имя рабочей станции / IP-адрес) + этот код. В главе 6 есть PowerShell, который извлекает все три сразу.

Как фиксировать причину отказа 4625Причину отказа 4625 фиксируют шестнадцатеричным кодом Status/Sub Status, по тенденции кода читают признаки атаки и определяют событие тройкой целевая учётка плюс источник плюс кодсерия 0xC0000064серия 0xC000006A0xC00000724625 неудачный входПроверить код Sub StatusКакова тенденция кода?Признак перебора учётокПризнак подбора пароляПопытки к уволеннымФиксировать тройкойучётка+источник+код

Рис. 7: Причину отказа фиксируют кодом и читают тройкой: целевая учётка, источник и код.

4.3. 4740 — источник блокировки — поле «Caller Computer Name»

4740, «Учётная запись пользователя заблокирована» (подкатегория: управление учётными записями пользователей). Главное поле этого события — «Caller Computer Name»: в нём записано, с какого компьютера пришла попытка входа, вызвавшая блокировку.16 Канон расследования — определить по этому полю машину-источник и вычистить на ней оставшиеся старые учётные данные. В большинстве случаев причина — что-то, что после смены пароля продолжает использовать старые учётные данные: сохранённые учётные данные, оставшийся отключённым сеанс RDP, служба или назначенное задание со старым паролем.

Канон расследования блокировки учётной записиПо Caller Computer Name события 4740 определяют машину-источник и вычищают на ней сохранённые учётные данные, оставшиеся отключёнными сеансы RDP и службы или задания со старым паролем4740 блокировкаПроверить Caller Computer NameОпределить машину-источникВычистить старые учётные данныеСохранённые учётные данныеОставшиеся отключённые сеансы RDPСлужбы и задания со старым паролем

Рис. 8: По «Caller Computer Name» события 4740 находят источник и вычищают на этой машине старые учётные данные.

Есть одна оговорка. 4625 записывается на компьютере, который принял попытку входа. Если причина — сетевой вход с машины-источника, например, к файловому серверу, в собственном журнале Security машины-источника 4625 не остаётся; след остаётся в 4625 сервера назначения или, для доменной учётки, в 4776 (NTLM) / 4771 (отказ предварительной проверки подлинности Kerberos) на DC.78 Когда «на машине-источнике в журнале ничего нет», идите смотреть принимающую сторону.

На какой машине остаётся след отказаОтказ сетевого входа на самой машине-источнике не остаётся, а пишется как 4625 на сервере назначения, который принял попытку входа, и для доменной учётки след также остаётся в 4776 или 4771 на DCсетевой входпроверка доменной учёткиМашина-источник（на ней 4625 не остаётся）Сервер назначенияПишется 4625Контроллер домена4776（NTLM）/4771（Kerberos）

Рис. 9: 4625 остаётся на принявшей стороне. Если на машине-источнике пусто, смотрите сервер назначения и сторону DC.

4.4. Семейство 4720 — создание и изменение учёток, добавление в группы

События управления учётными записями идут соседними номерами: 4720 (создана учётная запись пользователя)17, 4726 (удалена), 4738 (изменена) и, на стороне групп, добавление/удаление члена. Важно, что какой идентификатор события срабатывает при смене членства, зависит от типа группы. Для локальных групп это 4732/4733, для глобальных — 4728/4729, для универсальных — 4756/4757.14 Domain Admins — глобальная группа, поэтому добавление в неё видно как 4728 — если алертить только на 4732, вы как раз пропустите событие, которое больше всего хотите поймать. В повседневности это в основном запись работы службы поддержки, но «обычного пользователя внезапно добавили в группу администраторов» или «создали учётку, которой никто не знает» стоит расследовать даже как единичный случай. Сама Microsoft приводит неожиданное добавление членов в привилегированные группы как пример события, на которое стоит алертить по одному случаю.3

Тип группы и событие добавления членаДобавление члена в группу даёт разные идентификаторы событий в зависимости от типа группы, локальная пишет 4732, глобальная 4728, универсальная 4756, поэтому добавление в глобальную Domain Admins смотрят в 4728локальнаяглобальнаяуниверсальнаяДобавление члена в группуКакой тип группы?Пишется 4732Пишется 4728Пишется 4756Добавление в Domain Admins — здесьМониторинг только 4732 пропускает

Рис. 10: Идентификатор события добавления члена зависит от типа группы. Добавление в Domain Admins — это 4728.

4.5. 4688 — создание процесса. Запись командной строки — отдельный переключатель

4688, «Создан новый процесс», при каждом создании процесса записывает создавшую учётку, путь к исполняемому файлу нового процесса, родительский процесс и тип повышения токена.11 Это событие высокой ценности для расследования: им можно ответить «кто что запускал на этом сервере».

По умолчанию, однако, аргументы командной строки не записываются. Только после отдельного включения параметра Group Policy «Include command line in process creation events» (Административные шаблоны > Система > Аудит создания процессов) поле «Process Command Line» события 4688 начинает заполняться аргументами.1112 Для расследования подозрительных запусков вроде powershell -EncodedCommand ... это по сути обязательная настройка, но включайте её, только поняв риск попадания секретов, описанный в главе 7.

Связь 4688 и записи командной строкиВключение аудита создания процессов пишет в 4688 учётку, путь к исполняемому файлу и родительский процесс, но аргументы командной строки появляются только после включения отдельного Group Policy и несут риск секретов открытым текстомкак по умолчаниюдоп. включить GPOВключить аудит создания процессовПишется 4688Учётка, путь, родительский процессНужны и аргументы?Командная строка пустаАргументы записываютсяРиск секретов в открытом виде

Рис. 11: Запись командной строки 4688 — отдельный переключатель. Перед включением сначала проверьте риск попадания секретов.

4.6. 4698 — создание назначенного задания

4698, «Создано назначенное задание», записывает имя задания и полный XML определения задания (включая команду запуска). Регистрация назначенного задания — типовой приём, которым вредоносное ПО переживает перезагрузку, поэтому Microsoft рекомендует мониторить события создания заданий.15 Даже в средах, которые для бизнеса активно пользуются назначенными заданиями, само создание — не ежедневное событие, поэтому уровень шума сравнительно невелик.

Закрепление через регистрацию задания и 4698Вредоносное ПО как типовой приём закрепления регистрирует назначенное задание, чтобы пережить перезагрузку, поэтому мониторинг 4698 при создании задания позволяет дойти до определения задания включая команду запускаЗакрепление вредоносаРегистрирует задание и выживаетПишется 4698Полный XML с командой запускаОбнаружение мониторингом созданияСоздание не ежедневно, шум мал

Рис. 12: Регистрация задания — типовой приём закрепления и остаётся в 4698. По полному XML определения можно дойти до команды запуска.

Ещё одно, что стоит помнить, — 1102, «Журнал аудита очищен». Очистка журнала Security всегда оставляет это событие, поэтому когда «журнал пуст», по наличию 1102 можно отличить операцию от аварии.18

Разбор очистки журнала по 1102Очистка журнала Security всегда оставляет 1102, поэтому когда журнал пуст, по наличию или отсутствию 1102 можно отличить операцию очистки от аварииестьнетЖурнал пустОчистка всегда оставляет 1102Есть ли 1102?Была операция очисткиПодозревать аварию

Рис. 13: Очистка журнала Security всегда оставляет 1102. Пустой журнал по наличию 1102 отличают операцию от аварии.

5. Проектирование ёмкости журнала — максимальный размер и хранение

Прежде чем добавлять политику аудита, проверьте принимающую ёмкость. У журнала Security есть максимальный размер и режим хранения: в режиме перезаписи (типичная конфигурация) по достижении максимума новые события перезаписывают самые старые. Наоборот, в режиме хранения (не перезаписывать) при заполнении журнала отбрасываются уже новые события.10 Оба поведения могут оставить вас с «нужного журнала просто нет», поэтому сначала поймите текущее состояние.

# Проверить ёмкость журнала Security: режим хранения, максимальный размер, текущее число записей
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Сколько дней реально хранится сейчас (время старейшего события)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog возвращает конфигурацию журнала и число записей вместе.9 Разница между «временем старейшего события» и текущим временем — фактический срок хранения; если он не дотягивает до вашего требования (на сколько дней назад вы хотите уметь расследовать), увеличьте максимальный размер. Задать его можно через wevtutil sl Security /ms:<число байт> или раздать через Group Policy.10

Расчёт ёмкости от срока хранения назадЧерез ListLog у Get-WinEvent смотрят конфигурацию и число записей, по времени старейшего события считают фактический срок хранения и если его не хватает для расследования инцидента увеличивают максимальный размерхватаетне хватаетListLog: конфигурация и число записейПроверить время старейшего событияПосчитать фактический срок храненияХватает по требованию?Оставить текущий размерУвеличить максимальный размерЗадать wevtutil sl или GPO

Рис. 14: Проверьте, сколько дней реально остаётся, и от нужного срока расследования назад задайте максимальный размер.

Есть ещё параметр безопасности «Аудит: немедленно завершать работу системы, если невозможно внести в журнал записи аудита безопасности» (известен как CrashOnAuditFail). Если он включён и система не может записать событие аудита, она останавливается с ошибкой STOP C0000244. Это настройка для требований проверки подлинности, при которых след аудита нельзя потерять ни при каких обстоятельствах, и по умолчанию она выключена. Сама Microsoft предупреждает, что её можно превратить в DoS: злоумышленник намеренно порождает поток событий, чтобы остановить сервер, — поэтому в типичной среде малого и среднего размера её не включают просто так.19

Поведение при заполнении журналаРежим хранения бывает перезаписью или без перезаписи, и если без перезаписи аудит записать уже нельзя, при включённом отдельном параметре CrashOnAuditFail система останавливается с ошибкой STOP C0000244режим перезаписине перезаписыватьдаЖурнал Security достиг максимумаКакой режим хранения?Перезаписываются самые старыеНовые события отбрасываютсяОба — причина «журнала нет»CrashOnAuditFail тоже включён?Остановка STOP C0000244

Рис. 15: Хранение — это перезапись или отбрасывание. CrashOnAuditFail — отдельный параметр, который при невозможности записи останавливает систему.

6. Практика расследования — фильтры, Get-WinEvent и экспорт

6.1. Сужение в «Просмотре событий»

Для разового расследования «Просмотра событий» достаточно. Откройте журнал Security и в «Фильтровать текущий журнал» задайте идентификатор события (например, 4625) и диапазон времени. Условия, которые смотрите снова и снова, сохраните как «Настраиваемое представление» — в следующий раз это будет один щелчок. Если нужно сузить не только по идентификатору события, но и по конкретной учётке, XPath-запрос можно править напрямую на вкладке XML диалога фильтра.

6.2. Выборка через Get-WinEvent

Для расследований с большим числом записей, несколькими условиями или регулярным запуском переключайтесь на Get-WinEvent в PowerShell. Главное — использовать -FilterHashtable, который применяет фильтр на стороне сервера.9

Как выбирать средство расследованияРазовое расследование закрывает фильтр «Просмотра событий», повторяющиеся условия сохраняют как настраиваемое представление, а при большом числе записей, нескольких условиях или регулярном запуске переходят на Get-WinEventразовоеповторяющиеся условиямного, несколько условий, по расписаниюКакое расследование?Сузить в «Просмотре событий»Сохранить как настраиваемое представлениеПерейти на Get-WinEventСужать FilterHashtable

Рис. 16: Разовое — «Просмотр событий», повторяющееся — настраиваемое представление, при большом объёме — Get-WinEvent.

# Получить неудачные входы (4625) за последние 24 часа
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Свести в таблицу «кто, откуда и почему»
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Один такой шаблон — вытащить EventData из XML-представления события — можно тем же приёмом крутить и для 4624, и для 4688. Проектирование сужения Get-WinEvent (когда FilterHashtable, когда XPath, как чинить медленный запрос) подробно разобрано в «Практическое исследование журналов событий через Get-WinEvent — скорость фильтрации определяет время расследования».

Шаблон вытаскивания EventData в таблицуСобытия, полученные через Get-WinEvent, преобразуют в XML, вытаскивают поля EventData и сводят в таблицу, и этот шаблон тем же приёмом годится не только для 4625, но и для 4624 и 4688Получить через Get-WinEventПреобразовать событие в XMLВытащить EventDataСвести в таблицу и агрегироватьТот же приём для 4624 и 4688

Рис. 17: Шаблон «вытащить EventData из XML и свести в таблицу» переиспользуется при смене идентификатора события.

6.3. Экспорт через wevtutil

Журналы исследуемой машины сначала экспортируют и сохраняют копию, пока их не перезаписали.10

rem сохранить весь журнал Security как evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem экспортировать только события 4625, сузив XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Экспортированный .evtx на другой машине разбирают тем же способом: Get-WinEvent -Path C:\logs\security-20260801.evtx.9 Привычка сначала сохранить, потом разбирать — та же мысль, что «сначала закрепить дамп» при расследовании сбоя (см. «Введение в сбор дампов сбоев Windows — WER/ProcDump/WinDbg»).

Сначала сохранить, потом разбиратьЖурнал Security исследуемой машины сохраняют в файл evtx через wevtutil epl и на другой машине разбирают тем же способом через Path у Get-WinEventИсследуемая машинаСохранить evtx через wevtutil eplВынести на другую машинуРазбор через Get-WinEvent -PathСохранить до перезаписи

Рис. 18: Сначала сохранить, потом разбирать. Закрепив evtx, можно так же смотреть на другой машине.

7. Ловушки — четыре, в которые легко попасть на месте

(1) Секреты попадают в командную строку 4688. Включение записи командной строки кладёт аргументы каждого процесса в журнал Security открытым текстом. Microsoft явно пишет, что «любой пользователь с правом чтения событий безопасности сможет прочитать аргументы командной строки каждого успешно созданного процесса. Аргументы командной строки могут содержать конфиденциальные или личные сведения, например пароли».12 Если хотя бы одно бизнес-приложение или скрипт запускает что-то вроде myapp.exe /user:admin /password:P@ssw0rd, это раскрытие секрета всем, кто может смотреть журнал. Перед включением найдите места, которые передают секреты аргументами командной строки, и исправьте их. Куда журнал экспортируют или пересылают, тоже нужно обращаться с тем же уровнем конфиденциальности.

Порядок включения записи командной строкиПеред включением записи командной строки 4688 выявляют бизнес-приложения и скрипты, которые передают секреты аргументами, исправляют такие места и только потом включают, а к месту хранения и пересылки журнала требуют тот же уровень обращенияестьнетНайти передачу секретов аргументамиЕсть совпадения?Исправить эти местаВключить запись командной строкиТо же обращение к месту хранения и пересылки

Рис. 19: Запись командной строки включают в порядке «найти, исправить, потом включить». Обратный порядок — это публикация секретов.

(2) Эксплуатация без понимания, что будет, когда журнал заполнится. В режиме перезаписи старые следы тихо исчезают; в режиме «не перезаписывать» отбрасываются новые события; при включённом CrashOnAuditFail останавливается вся система (глава 5).1019 Правильный ход — знать, какое поведение вы выбрали, и поставить механизм — регулярный экспорт или платформу сбора журналов — который забирает данные до перезаписи.

(3) На контроллере домена и на рабочей станции смотреть нужно разные журналы. 4624/4625 записываются на машине, к которой обращались.56 Проверка учётных данных доменной учётки (4776 NTLM), напротив, пишется на машине, у которой есть власть над этими учётными данными — для доменной учётки это DC7, — а отказ предварительной проверки подлинности Kerberos (4771) пишется только на DC.8 «На файловом сервере нет 4625» не значит «атаки не было»; полная картина появляется, только когда вы ещё сверите 4776/4771 на DC. Как реально течёт каждый протокол проверки подлинности — в «NTLM и Kerberos на схемах — почему проверка подлинности «падает» на NTLM».

(4) Расхождение часов ломает сопоставление. Выстроить журналы нескольких машин в ряд и проследить «на какой станции прямо перед этим 4740 вышел 4625» можно, только если часы всех машин совпадают. В доменной среде сам Kerberos ставит верхнюю границу расхождения часов (по умолчанию 5 минут), за которой уже падает сама проверка подлинности.20 С точки зрения расследования даже расхождение в несколько секунд — не говоря о пяти минутах — может заставить неверно прочесть порядок событий, поэтому проверку синхронизации w32time стоит ставить самым первым шагом процедуры расследования. Ещё учтите, что время события хранится в UTC, а отображается по часовому поясу машины просмотра, поэтому при чтении .evtx с зарубежной площадки или с сервера, настроенного на UTC, не забудьте пересчитать часовой пояс.

Синхронизация времени как предпосылка сопоставленияСопоставление журналов нескольких машин по времени предполагает совпадение часов, расхождение в секунды уже ломает порядок, а сверх 5 минут по умолчанию падает сама проверка подлинности Kerberos, поэтому проверку синхронизации w32time ставят первым шагом процедурысовпадаютна секундыбольше 5 мин по умолчаниюСвести журналы нескольких машинЧасы должны совпадатьРасхождение часов?Можно идти по времениНеверно прочесть порядокKerberos-аутентификация падаетСначала проверить w32time

Рис. 20: Сопоставление нескольких машин предполагает совпадение часов. Даже расхождение в секунды ведёт к неверному чтению порядка.

8. Итог

  • У политики аудита две системы, «базовая» и «расширенная», и смешение даёт непредсказуемый результат. Унифицируйте на расширенной стороне, проверьте текущее состояние через auditpol /get /category:* и проектируйте оттуда.
  • «Включить всё» убивает расследование шумом и раздуванием. Отправная точка — базовые рекомендации Microsoft и таблица решения главы 3 вокруг входа, управления учётными записями и создания процессов.
  • 4624 читают по типу входа, 4625 — по коду Status/Sub Status, 4740 — по Caller Computer Name, 4688 — по родительскому процессу и командной строке: у каждого события есть поле, которое нужно смотреть.
  • Ёмкость журнала (максимальный размер и режим хранения) — половина проектирования аудита. Проверьте, сколько дней реально хранится, задайте размер, считая от требования назад, и экспортируйте или сводите до перезаписи.
  • Перед включением записи командной строки 4688 проверьте риск попадания секретов. Где какое событие записывается и синхронизация часов — предпосылки сопоставления между машинами.
  • Расследование начинают с фильтров «Просмотра событий»; для повторяющегося переходят на Get-WinEvent -FilterHashtable; сохраняют через wevtutil epl. Порядок «сначала сохранить, потом разбирать» не ломайте.

Похожие статьи

Смежные области консультирования

KomuraSoft LLC занимается консультациями по политике аудита и проектированию журналов в среде Windows, расследованием «когда, кто и что сделал» по журналам событий и анализом причин сбоев бизнес-приложений вокруг проверки подлинности и аудита. Начать можно уже с этапа «сказали посмотреть журналы, но непонятно, с чего начать».

Справочные ссылки

  1. Microsoft Learn, Advanced security auditing FAQ. О различии базовой политики аудита (девять настроек в локальных политиках) и расширенной политики аудита; о том, что включение одной базовой категории эквивалентно включению всех соответствующих подкатегорий; о несовместимости двух систем, из-за которой совместное использование оставляет результаты аудита в непредсказуемом состоянии и их нельзя смешивать; о том, что применение расширенной стороны через Group Policy очищает существующие настройки аудита; о необходимости включить «Аудит: принудительно применять параметры подкатегории политики аудита»; и о минимизации объёма событий через выявление и сужение до важных ресурсов, действий и пользователей. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. О том, что команда auditpol умеет показывать (/get), задавать (/set), сохранять в CSV (/backup), восстанавливать (/restore) и очищать (/clear) системную политику аудита. ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. О таблице значений Windows по умолчанию, базовых и усиленных рекомендаций отдельно для рабочих станций и серверов; о том, что рекомендации — только отправная точка и их нужно рассматривать и тестировать против угроз и допустимого риска каждой организации; о том, что у подкатегории входа с Windows 10 1809 по умолчанию включены и успех, и отказ; о важности мониторинга не только серверов, но и рабочих станций; о примерах событий, на которые стоит алертить по одному случаю, например неожиданное добавление членов в привилегированные группы; и о выявлении всплесков неудачных входов сравнением с базовой линией. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. О возможности точно управлять аудитом более чем по 40 подкатегориям; о том, что оставлять эту настройку включённой — рекомендуемая практика, а значение по умолчанию Enabled и для клиентов, и для рядовых серверов, и для DC; и о предупреждении, что настройки, порождающие огромный объём событий, например включение аудита успеха для всей подкатегории использования привилегий, затрудняют поиск других записей в журнале безопасности и могут заметно сказаться на производительности. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. О том, что 4624 записывается на машине, к которой обращались, в момент создания сеанса входа; о списке типов входа (2 = Interactive, 3 = Network, 4 = Batch, 5 = Service, 7 = Unlock, 8 = NetworkCleartext, 9 = NewCredentials, 10 = RemoteInteractive, 11 = CachedInteractive); о флаге Elevated Token; о пакете проверки подлинности (NTLM/Kerberos/Negotiate) и Package Name у NTLM (NTLM V1/V2/LM); и о корреляции по Logon ID с событиями вроде 4672. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. О том, что 4625 записывается на компьютере, на котором пытались войти (для попытки на рабочей станции пользователя — на этой станции); о подкатегориях «блокировка учётной записи» и «вход в систему»; о смысле кодов Status/Sub Status (0xC0000064 = неверное имя пользователя, 0xC000006A = неверный пароль, 0xC000006D = неверное имя пользователя или сведения для проверки подлинности, 0xC000006F = вне разрешённых часов входа, 0xC0000070 = запрещённая рабочая станция, 0xC0000072 = отключённая учётка, 0xC000015B = запрещённый тип входа, 0xC0000193 = истёкшая учётка, 0xC0000234 = блокировка); и о том, что повторяющиеся 0xC0000064 могут указывать на атаку перебора учёток. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. О том, что 4776 записывается при каждой проверке учётных данных для проверки подлинности NTLM; о том, что пишется только на компьютере, у которого есть власть над этими учётными данными — контроллер домена для доменной учётки или локальный компьютер для локальной; и о том, что записываются и успех, и отказ. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. О том, что 4771 записывается при каждом отказе KDC выдать Kerberos TGT (неверный пароль, истечение срока и т. п.); и о том, что это событие порождается только на контроллерах домена. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). О получении конфигурации журнала (LogMode, MaximumSizeInBytes, RecordCount) через -ListLog; об эффективной фильтрации через -FilterHashtable, заданный как хэш-таблица LogName, Id, StartTime и т. п.; о чтении сохранённого файла .evtx через -Path; и о выборке событий от старых к новым и по числу через -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. О задании максимального размера (/ms) и режима хранения (/rt) через set-log (sl); о том, что режим хранения true означает: существующие события сохраняются, а новые отбрасываются, когда журнал заполнен, а false — новые события перезаписывают самые старые существующие; об экспорте журнала событий в файл через export-log (epl) с параметром /q для сужения XPath-запросом; и о выполнении запроса через query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. О том, что 4688 записывается при каждом запуске нового процесса; о том, что в него входят создавшая учётка, путь к исполняемому файлу нового процесса, имя создавшего (родительского) процесса и тип повышения токена; и о том, что поле Process Command Line по умолчанию пусто и заполняется только после включения параметра Group Policy «Include command line in process creation events». ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. О том, что для записи командной строки нужны и аудит создания процессов расширенной политики аудита, и «Include command line in process creation events» (Административные шаблоны > Система > Аудит создания процессов, по умолчанию не задано); о предупреждении, что после включения сведения командной строки каждого процесса пишутся в журнал событий безопасности открытым текстом и любой пользователь с правом чтения событий безопасности сможет прочитать аргументы командной строки каждого успешно созданного процесса, в которых могут быть конфиденциальные сведения вроде паролей; и о том, что если расширенную политику аудита перезапишут базовые настройки, пишется событие 4719, чему мешает параметр «принудительно». ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. О том, что подкатегория блокировки учётной записи аудирует неудачные попытки входа к уже заблокированной учётке; о том, что порождаемое событие — 4625(F); о том, что у этой подкатегории нет событий успеха, поэтому включать для неё аудит успеха бессмысленно; и о рекомендации аудита отказа для всех типов компьютеров. ↩

  14. Microsoft Learn, Audit Security Group Management. О том, что эта подкатегория аудирует создание, изменение и удаление групп безопасности, а также добавление и удаление членов; о том, что идентификаторы событий добавления/удаления члена различаются по типу группы — 4732/4733 для локальных, 4728/4729 для глобальных, 4756/4757 для универсальных; о наличии событий специально для доменных групп, например 4728; и о том, что у этой подкатегории нет событий отказа, поэтому аудит успеха рекомендуется для всех типов компьютеров. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. О том, что 4698 записывается при каждом создании назначенного задания; о том, что подкатегория — другие события доступа к объектам; о том, что записываются имя задания и полный XML определения задания, включая команду запуска; и о рекомендации мониторить события создания заданий, особенно на важных машинах, потому что вредоносное ПО часто использует назначенные задания, чтобы закрепиться после перезагрузки. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. О том, что 4740 записывается при каждой блокировке учётной записи пользователя; о том, что подкатегория — управление учётными записями пользователей; и о том, что поле Caller Computer Name записывает имя компьютера, с которого пришла попытка входа, вызвавшая блокировку. ↩

  17. Microsoft Learn, 4720(S): A user account was created. О том, что 4720 записывается на контроллерах домена, рядовых серверах и рабочих станциях при каждом создании нового объекта пользователя; и о том, что подкатегория — управление учётными записями пользователей. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. О том, что событие 1102 записывается при каждой очистке журнала аудита безопасности Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. О том, что при включённой настройке, если записи аудита безопасности записать нельзя, система останавливается с сообщением STOP C0000244 {Audit Failed}; о значении по умолчанию Disabled; о том, что это можно превратить в DoS намеренным порождением большого объёма событий безопасности, чтобы принудить к завершению работы; и о риске, что из-за внезапной остановки данные приложений станут непригодны. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. О том, что Kerberos v5 использует метки времени как защиту от атак повтора, поэтому для расхождения часов клиента и контроллера домена задан максимальный допуск (и по умолчанию, и по рекомендации — 5 минут), за которым метка времени уже не считается подлинной. ↩

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Мы ничего не настраивали в политике аудита. Почему тогда в журнале Security уже есть 4624 и 4625?
Потому что в Windows есть подкатегории аудита, включённые по умолчанию. Например, у подкатегории «Вход в систему» начиная с Windows 10 версии 1809 по умолчанию включён аудит и успеха, и отказа, поэтому 4624 (успех) и 4625 (отказ) пишутся, даже если вы сами ничего не задавали. При настройках по умолчанию, однако, многие события, которые реально нужны в расследовании — проверка учётных данных (4776) или создание процесса (4688) — не записываются. Что включено в вашей среде, можно проверить командой auditpol /get /category:*. Дальше стандартная практика — явно включить недостающие подкатегории на стороне расширенной политики аудита.
Хочу разобрать неудачный вход, но события 4625 в журнале Security целевого сервера нет. Куда смотреть?
Сначала подтвердите принцип: 4625 записывается на «компьютере, на котором пытались войти». Неудачный вход на рабочей станции пользователя — смотрите станцию; неудачный доступ к файловому серверу — смотрите файловый сервер. Затем через auditpol /get /category:* проверьте, включён ли аудит отказа для подкатегории «Вход в систему». Для доменных учёток след часто остаётся в проверке учётных данных (4776) или в отказе предварительной проверки подлинности Kerberos (4771) на контроллере домена, и когда станцию не удаётся определить, быстрее начать со стороны DC. Если и тогда ничего нет, проверьте, не стёрло ли перезаписью старые события (максимальный размер журнала и время старейшего события).
Стоит ли включать запись командной строки при создании процесса (4688)?
Ценность для расследования очень высока, но это настройка, которую включают только поняв риск. После включения аргументы командной строки каждого процесса пишутся в журнал Security открытым текстом. Если хотя бы один скрипт или бизнес-приложение передаёт пароль или ключ API аргументом командной строки, этот секрет становится виден всем, кто может читать журнал Security. Сама Microsoft явно фиксирует это предупреждение. Рекомендуемый порядок — сначала проверить, не передают ли ваши скрипты секреты аргументами командной строки, исправить такие места и только потом включать настройку.
Каким должен быть максимальный размер журнала Security?
Правильный подход — считать от «сколько дней мы хотим держать под рукой», а не искать универсальное число. Текущую настройку и фактическое поведение можно проверить через Get-WinEvent -ListLog Security; разница между временем старейшего события и текущим временем — это «сколько дней реально хранится сейчас». Добавление подкатегорий аудита увеличивает объём событий, поэтому после смены настроек обязательно перепроверяйте этот фактический срок хранения. При реагировании на инциденты нередко нужны журналы недель или месяцев давности, поэтому спокойнее либо регулярно экспортировать журнал до перезаписи, либо сводить его на другую машину механизмом сбора журналов.
Как расследовать причину блокировки учётной записи (4740)?
Первая зацепка — поле «Caller Computer Name» события 4740. В нём записан компьютер, с которого пошла неудачная попытка входа, вызвавшая блокировку. Но сама запись отказа (4625) остаётся не на машине-источнике, а на стороне, которая приняла попытку входа. Если источник — сетевой вход, идите по времени через 4625 на сервере назначения или, для доменной учётки, через 4776/4771 на контроллере домена. Когда машина-источник найдена, проверьте на ней всё, что всё ещё держит старые учётные данные после смены пароля: сохранённые учётные данные, оставшийся отключённым сеанс удалённого рабочего стола, службу или назначенное задание со старым паролем. Если блокировки повторяются, проверьте также, не разъехалась ли синхронизация часов.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.

Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal
Вернуться в блог