Журналы событий Windows и Event ID, которыми чаще всего пользуются защитники

#Что такое журналы событий Windows

Windows непрерывно записывает, что происходит на машине: запускаются службы, падают программы, входят пользователи. Каждая такая запись называется событием. У события есть метка времени, provider (компонент, который его записал), числовой Event ID, уровень и набор полей, зависящий от типа события. События сгруппированы в журналы, они же каналы, и хранятся в файлах .evtx в каталоге %SystemRoot%\System32\Winevt\Logs.

Для начала нужны три журнала:

• Application содержит события от программ и некоторых компонентов Windows. Падение приложения или неудачное обновление обычно попадают сюда.
• System содержит события самой Windows и драйверов: запуск и остановку служб, старт службы журнала событий при загрузке (Event ID 6005), ошибки драйверов.
• Security содержит события аудита: входы, выходы, использование чувствительных привилегий, создание процессов, изменения учётных записей и политик. Этому журналу посвящена почти вся статья, и только его из трёх обычный пользователь открыть не может.

Разницу в доступе видно из PowerShell. На машине, где проверялась статья (Windows 11, Windows PowerShell 5.1), эта команда выполнялась в оболочке без прав администратора:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

Когда в ту же команду добавили Security, для этого журнала появилась ошибка: Windows не смогла получить сведения, потому что операция не авторизована. Количество записей у вас будет другим.

#Зачем это нужно

Многие детекты для Windows построены на журнале Security. Правило SIEM на подбор паролей считает события 4625. Правило на подозрительную админскую сессию смотрит на 4624 и 4672 вместе. Правило на вмешательство в журнал следит за 1102. Как устроены такие правила, описано в статье о SIEM из Полевого руководства. Если прочитать события вручную на одной машине, можно проверить, верны ли допущения правила для ваших систем.

В журнале Security есть только то, что Windows велит записывать политика аудита. Если политика не включает аудит неудачных входов, Windows не пишет события 4625, и правило, которое их считает, никогда не сработает. Со стороны SIEM это выглядит точно так же, как спокойная машина. Поэтому сначала проверяют политику аудита и только потом читают журнал.

#Как работает аудит

#Политика аудита определяет, что будет записано

Windows делит настройки аудита на категории, а категории на подкатегории. Каждая подкатегория может записывать успешные события, неудачные, и те и другие или ничего. Категории такие: Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use и System.

В категории Logon/Logoff находятся подкатегории, которые дают большинство событий из этой статьи: Logon (4624 и 4625), Logoff (4634), Account Lockout (Microsoft указывает её и для 4625) и Special Logon (4672). Создание процессов, событие 4688, относится к подкатегории Process Creation в Detailed Tracking.

Встроенная утилита для чтения политики называется auditpol. Команда auditpol /list выводит названия категорий и подкатегорий и работает в обычной оболочке. Команда auditpol /get читает сами настройки. В справочнике Microsoft сказано, что ей нужно разрешение Read на политику или право «Manage auditing and security log» (SeSecurityPrivilege), а у обычной оболочки без повышения прав нет ни того, ни другого.

auditpol /list /category /v

На машине, где проверялась статья, Windows работает на португальском языке. Там эта команда выполнилась без повышения прав и вывела каждую категорию с переведённым названием и GUID. У Logon/Logoff был GUID {69979849-797A-11D9-BED3-505054503030}. Английское название там тоже сработало: auditpol /list /subcategory:"Logon/Logoff" показала двенадцать подкатегорий. Если система отвергает название, передайте GUID.

#Event ID, которые понадобятся чаще всего

#4624 и 4625: входы

Оба события записываются на компьютере, где произошёл вход. Если кто-то вводит неверный пароль на вашем ноутбуке, 4625 появится в журнале Security этого ноутбука. Большинство полей у этих событий общие:

• Subject указывает учётную запись, сообщившую о входе, часто сам компьютер или SYSTEM.
• Logon Type говорит, как был выполнен вход. Обычные значения: 2 (Interactive, за клавиатурой), 3 (Network, например общая папка), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Remote Desktop) и 11 (CachedInteractive, доменные учётные данные из кэша машины).
• New Logon (в 4624) или Account For Which Logon Failed (в 4625) указывает учётную запись, под которой выполняется вход, с её Security ID, именем и доменом. В 4624 этот раздел содержит ещё и Logon ID новой сессии.
• Failure Information (только в 4625) содержит коды Status и Sub Status. Microsoft перечисляет коды, за которыми стоит следить: 0xC000006A для неверного пароля, 0xC0000064 для несуществующего имени пользователя, 0xC000006D для неверного имени пользователя или неверных данных аутентификации, 0xC0000072 для отключённой учётной записи. На той же странице 0xC0000234 («Account locked out») назван типичным статусом при сбое из-за заблокированной учётной записи. Несколько сбоев 0xC0000064 подряд могут означать, что кто-то перебирает имена пользователей.
• Process Information показывает процесс, который пытался выполнить вход, а Network Information даёт имя рабочей станции, адрес и порт источника. 127.0.0.1 или ::1 означают localhost, а при интерактивном входе порт равен 0.

В Windows 10 и новее у 4624 есть ещё поле Elevated Token, которое показывает, есть ли у сессии привилегии администратора.

#4634: выход и зачем нужен Logon ID

4634 сообщает, что сессия входа завершилась. Само по себе это событие говорит мало. Ценность ему придаёт Logon ID: одно и то же шестнадцатеричное значение есть в 4624, открывшем сессию, в 4672 для этой сессии, если они были, в событиях 4688 для запущенных ею процессов и в 4634, которым она закрылась. Если пройти по одному Logon ID через журнал, сессия восстанавливается от начала до конца. Microsoft отмечает, что Logon ID уникальны только в промежутке между перезагрузками одного компьютера, поэтому всегда привязывайте ID к диапазону времени.

#4672: особые привилегии

Windows пишет 4672, когда новый вход получает одну из привилегий из списка чувствительных, например SeDebugPrivilege (отладка программ), SeBackupPrivilege (резервное копирование файлов и каталогов) или SeTcbPrivilege (работа как часть операционной системы).

Каждый вход SYSTEM порождает 4672, поэтому таких событий в журнале много. Microsoft советует смотреть на те, где учётная запись отличается от LOCAL SYSTEM, NETWORK SERVICE и LOCAL SERVICE и где это не админ, которому такие привилегии положены.

#4688: создание процесса

4688 записывается при каждом запуске нового процесса, если включён аудит подкатегории Process Creation. В событии есть имя нового процесса, имя родительского процесса, учётная запись, Token Elevation Type (с каким токеном работал процесс: полным, повышенным или ограниченным) и уровень целостности.

Есть и поле Process Command Line, по умолчанию пустое. На странице Microsoft сказано, что оно заполняется, только если включён параметр групповой политики «Administrative Templates\System\Audit Process Creation\Include command line in process creation events». Без него вы знаете, что запустился powershell.exe, но не знаете, что ему велели сделать.

#1102: журнал очищен

1102 означает, что кто-то очистил журнал Security. Событие пишет provider Microsoft-Windows-Eventlog, и в нём указана учётная запись, которая это сделала. Рекомендация Microsoft короткая: в норме такого события быть не должно, причин очищать журнал Security вручную почти не бывает, и каждый случай стоит расследовать.

#Что добавляет Sysmon

Sysmon (System Monitor) — это утилита Sysinternals от Microsoft. Она устанавливается как служба и драйвер, продолжает работать после перезагрузок и пишет собственные события в Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Sysmon скачивается отдельно и в стандартную установку Windows не входит. Microsoft указывает как поддерживаемые Windows 11 и Windows Server 2019 или новее.

По сравнению со встроенным журналом Security Sysmon даёт больше подробностей об активности, которую иначе видно лишь частично:

• Event ID 1, создание процесса, содержит полную командную строку, хеши файла (по умолчанию SHA1, доступны также MD5, SHA256 и IMPHASH) и ProcessGuid, который не повторяется, даже когда Windows повторно использует ID процессов.
• Event ID 3 записывает сетевые соединения и процесс, стоящий за каждым из них. По умолчанию он отключён.
• Другие ID охватывают создание файлов (11), DNS-запросы (22), изменения реестра, именованные каналы, подписки WMI и открытие одного процесса другим, например lsass.exe (10).

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

Установка Sysmon меняет систему, поэтому в лабораторной работе этой статьи его нет.

#Практика: найдите свой неудачный вход

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

#Шаг 1: откройте PowerShell с повышенными правами

Щёлкните правой кнопкой по Windows PowerShell или Terminal и выберите Run as administrator. Проверьте, что права действительно повышены:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True означает, что вы можете читать журнал Security. На машине, где проверялась статья, доступная оболочка вернула False. Команды ниже всё равно выполнялись там, и их сбои описаны как есть, потому что о них полезно знать. Там, где должен был быть вывод с повышенными правами, статья называет поля, которые нужно искать, по документации Microsoft.

#Шаг 2: проверьте политику аудита

auditpol /get /category:"Logon/Logoff"

В оболочке с повышенными правами команда выведет каждую подкатегорию и её настройку. Найдите строку Logon. Для этой работы в ней должно быть Failure, то есть «Success and Failure» или «Failure». Если там «No Auditing», Windows не запишет 4625 и дальше вы ничего не найдёте.

Без повышения прав на машине, где проверялась статья, команда вывела ошибку 0x00000522 с сообщением, что у клиента нет требуемой привилегии, и завершилась с кодом 1314.

#Шаг 3: создайте событие

Нажмите Win+L, чтобы заблокировать экран. Один раз введите неверный пароль, затем войдите с правильным. Запомните время.

Используйте пароль, а PIN оставьте в стороне. Если вы обычно входите через Windows Hello, выберите на экране входа вариант с паролем. Что даёт неверный PIN, в этой статье не проверялось.

#Шаг 4: найдите сбой с помощью Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

-FilterHashtable применяет фильтр прямо при чтении событий, и в документации Microsoft это описано как более эффективный способ, чем передавать всё в Where-Object. -MaxEvents 5 оставляет пять самых новых совпадений, потому что Get-WinEvent возвращает сначала новые.

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

• Logon Type. В примере 4625 от Microsoft показан интерактивный вход, тип 2, с вызывающим процессом C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed: здесь должна быть ваша учётная запись.
• Status и Sub Status. При неверном пароле ищите 0xC000006A в одном из них.
• Source Network Address и Source Port. При входе за собственной клавиатурой ожидайте локальное значение вроде 127.0.0.1 и порт 0, как в примере Microsoft.

Без повышения прав эта команда вводит в заблуждение. На машине, где проверялась статья, она не сообщила о нехватке прав и вывела ошибку, что событий, подходящих под критерии, не найдено. Простая команда Get-WinEvent -LogName Security -MaxEvents 1 в той же оболочке назвала настоящую причину: операция не авторизована. Если оболочка без повышенных прав отвечает «no events found», проверьте права, прежде чем решить, что журнал пуст.

#Шаг 5: найдите успешный вход

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

Вы должны увидеть событие 4624, записанное через несколько секунд после вашего 4625, а вокруг него другие события 4624, потому что службы и система входят постоянно. Откройте полное сообщение события, ближайшего к вашему времени, и проверьте Logon Type и имя учётной записи. Если добавить в хеш-таблицу StartTime=(Get-Date).AddMinutes(-15), поиск ограничится последними пятнадцатью минутами.

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

#Шаг 6: тот же поиск через wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

wevtutil — более старая консольная утилита для журналов событий. qe запрашивает события, /c:5 ограничивает их количество, /rd:true читает сначала новые, /f:text выводит текст вместо XML, а /q принимает фильтр XPath. С повышенными правами вы получите те же события, что на шаге 4. Уберите /f:text, чтобы увидеть сырой XML с именами полей, которые используют правила детектирования, например TargetUserName, Status и LogonType. В Windows на другом языке текст сообщения переведён, а имена полей в XML остаются английскими.

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

#Шаг 7: посмотрите в Event Viewer

Запустите eventvwr.msc. Если появится запрос, разрешите запуск от имени администратора. Перейдите в Windows Logs > Security, выберите Filter Current Log и введите 4625 в поле Event IDs. Откройте событие. На вкладке General то же сообщение, что вы читали в PowerShell. На вкладке Details в режиме XML видны сырые имена полей. Не закрывайте это событие: в статье о Sigma с ним сравнивается правило.

#Частые ошибки

• Верить ответу «no events found» в обычной оболочке. Как показал шаг 4, запрос Get-WinEvent -FilterHashtable к журналу Security без повышения прав может сообщить об отсутствии совпадений вместо отказа в доступе.
• Считать, что событие есть, не проверив политику. Нет настройки аудита, нет и события. То же с полями: командная строка в 4688 остаётся пустой, пока её не включит отдельная политика.
• Читать событие в отрыве от других. Один 4625 мало что значит. Смотрите на следующий за ним 4624, на Logon ID и на диапазон времени.
• Очищать журнал после лабораторной работы ради порядка. Вы уничтожите только что созданные свидетельства и породите 1102, который кому-то, возможно, придётся расследовать.
• Забывать, что журналы перезаписываются. На машине, где проверялась статья, Get-WinEvent -ListLog Application показала максимальный размер 20971520 байт в режиме Circular: когда журнал заполняется, старые события затираются. Проверьте журнал Security тем же способом, с повышенными правами, прежде чем рассчитывать на события прошлого месяца.

#Что дальше

• Прочитайте страницу Microsoft о каждом событии из этой статьи. В конце каждой есть рекомендации по мониторингу безопасности, почти готовые идеи для детектов.
• Поднимите виртуальную машину в легальной домашней лаборатории, установите там Sysmon с конфигурационным файлом, выполните несколько команд и сравните событие Sysmon 1 с 4688 для одного и того же процесса.
• Превратите найденное событие в детект: в следующей статье, как написать первое правило Sigma, создаётся и проверяется правило именно для этого 4625.

#Источники

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil