Означает ли Event ID 4624 интерактивный вход пользователя?

Нет. Event ID 4624 означает успешный вход, но он может относиться к службе, сетевому доступу, пакетному заданию или системной операции. Интерпретируйте событие по Logon Type вместе с Account Name, Source Network Address, Workstation Name, Authentication Package и ролью сервера.

Может ли доменная GPO отменить локальную политику аудита?

Да. Локальная политика подходит для автономного сервера или пилота, но на члене Active Directory её изменения не гарантированно сохранятся после следующего применения доменной политики. Сначала определите GPO, которая назначена компьютеру или OU, где находится сервер. В доменной GPO включите требуемые подкатегории в Advanced Audit Policy Configuration и свяжите политику с нужным OU. Проверьте security filtering и наследование. Если одновременно используются старая категориальная Audit Policy и детальные подкатегории, включите параметр Security Options с именем, близким к Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Он разрешает конфликт в пользу подкатегорий, но не защищает настройки от более приоритетной GPO. После обновления политики, в том числе через gpupdate /force в согласованное окно, проверьте фактический результат на сервере командой auditpol. Значение в редакторе GPO показывает намерение, а вывод auditpol — реально применённую политику.

Что означает Event ID 4740 и как найти источник блокировки?

Event ID 4740 означает блокировку учётной записи, но не доказывает перебор паролей извне. Проверьте поля Account That Was Locked Out и Caller Computer Name, затем найдите связанные события 4625. Причиной часто оказывается служба, задача или клиент, где сохранён старый пароль.

Почему в Event ID 4688 нет командной строки?

Событие 4688 появляется при включённой подкатегории Audit Process Creation с результатом Success, однако имя исполняемого файла само по себе не гарантирует запись аргументов. Чтобы получить поле Command Line, отдельно включите административный параметр с именем, близким к Include command line in process creation events, обычно в Administrative Templates → System → Audit Process Creation. На доменном сервере закрепите обе настройки в применяемой GPO, а не только в локальной политике. После обновления политики проверьте через auditpol, что Process Creation находится в состоянии Success. Затем в согласованной административной сессии можно выполнить безвредную команду whoami и найти новый 4688: New Process Name должен указывать на whoami.exe, а Command Line — содержать вызов. Учтите, что аргументы процессов могут содержать пароли, токены и другие секреты. Доступ к Security Log следует ограничить, а передачу реквизитов в командной строке — исключать.

Доказывает ли Event ID 1102 компрометацию сервера?

Нет. Event ID 1102 означает, что был очищен именно Security Log, но очистка может быть санкционированным действием администратора при обслуживании. Зафиксируйте субъекта, время и компьютер, проверьте причину операции и изучите сохранённую внешнюю копию журнала для анализа событий до очистки.

Аудит Windows Server: Security Log, Advanced Audit Policy и PowerShell

Q: Всегда ли Event ID 4625 означает атаку на Windows Server?

Нет. Серия 4625 не доказывает атаку без контекста. Сначала сгруппируйте события по Account Name, Source Network Address, Workstation Name и Logon Type. Например, повторяющиеся события с типом входа 5 и одним сервером-источником могут указывать на службу, которая продолжает использовать старый пароль. Серия сетевых или удалённых входов с множеством учётных записей и единым внешним источником требует более тщательной проверки. Проверьте Status и SubStatus: среди типичных причин встречаются несуществующая учётная запись, неверный пароль, блокировка или отключение учётной записи. Эти поля зависят от версии Windows, типа аутентификации и обновлений, поэтому не следует строить вывод только по одному коду. Также выясните, появился ли после неудачных попыток успешный вход 4624 для той же учётной записи.

Начинайте аудит Windows Server не с включения всех журналов, а со сценариев обнаружения: неудачные входы, привилегированные сессии, создание учётных записей, запуск процессов и очистка журнала. Для этого включают нужные подкатегории расширенной политики аудита, проверяют их фактическое состояние через auditpol и анализируют события вместе с пользователем, хостом, источником, типом входа и временем. Журналы PowerShell дополняют журнал безопасности Windows: Script Block Logging и Module Logging пишут события в Operational-канал, а Transcription сохраняет отдельные текстовые файлы.

Зависимости от версии и роли сервера

Названия разделов Local Security Policy и Group Policy Management, доступные подкатегории, поля событий и возможности PowerShell зависят от выпуска Windows Server, обновлений, роли хоста, версии PowerShell и применённых административных шаблонов. Ниже приведён типовой порядок по документации Microsoft. Перед массовым развёртыванием сверяйте названия параметров и состав событий с официальным руководством Microsoft для используемой версии Windows и PowerShell.

Сначала определите сценарии и владельца журналов

Аудит формирует аудиторский след, но сам по себе не доказывает атаку. Для каждого сценария заранее назначьте владельца разбора: администратора, дежурную смену или команду ИБ. Без этого даже полезные события останутся нерассмотренными.

Минимальный набор сценариев для Security Event Log

Сценарий	Основные события	Что сопоставлять	Первое действие аналитика
Перебор паролей или ошибочная настройка клиента	`4625`	Учётную запись, источник, тип входа Windows, Status, SubStatus, частоту	Отделить ошибку службы или пользователя от серии попыток с необычных источников
Успешный вход	`4624`	Logon Type, Account Name, Workstation Name, Source Network Address, Logon ID	Проверить, соответствует ли источник и тип входа роли учётной записи
Новая привилегированная сессия	`4672` вместе с `4624`	Logon ID, Subject, перечень Privileges, время	Связать с конкретным входом и последующими действиями этой сессии
Создание или блокировка учётной записи	`4720`, `4740`	Для `4720` — Subject, Target Account и Target Domain; для `4740` — заблокированную учётную запись и Caller Computer Name; для обоих — время и компьютер, где записано событие	Подтвердить ожидаемое административное действие или начать проверку
Запуск подозрительного процесса	`4688`	New Process Name, Command Line, Creator Process Name, Subject, Logon ID	Оценить цепочку процессов и ожидаемость команды
Очистка Security Log	`1102`	Subject, время, компьютер	Сохранить контекст из централизованного хранилища и проверить действия до события

Журналы могут содержать секреты

Security Log, командные строки в 4688, Script Block Logging и особенно транскрипты PowerShell могут содержать персональные данные, имена серверов, пути, токены и пароли, переданные аргументами команд. Ограничьте доступ к журналам и файлам транскриптов, установите срок хранения по политике организации и учитывайте эти данные при пересылке. Настройка централизованного хранения, WEF и SIEM рассматривается в статье «Централизованный сбор журналов безопасности: события, корреляция и оповещения».

Выберите источник политики: локальная настройка или доменная GPO

Обычная Audit Policy задаёт крупные категории аудита, а Advanced Audit Policy — отдельные подкатегории внутри них. Для задач расследования используйте подкатегории: они точнее и позволяют не включать несвязанные события. Локальная политика безопасности подходит автономному серверу или пилоту, но на члене домена её могут заменить доменные GPO.

Подкатегории Advanced Audit Policy для указанных сценариев

Сценарий и Event ID	Категория	Подкатегория	Рекомендуемый результат аудита
`4624`, `4625`: успешные и неудачные входы	Logon/Logoff	Audit Logon	Success и Failure
`4672`: специальные привилегии в новой сессии	Logon/Logoff	Audit Special Logon	Success
`4720`, `4740`: управление учётными записями	Account Management	Audit User Account Management	Success; Failure включают, если нужен контроль неуспешных операций
`4688`: создание процесса	Detailed Tracking	Audit Process Creation	Success
Аутентификация доменной учётной записи на контроллере домена	Account Logon	Подкатегория зависит от протокола и сценария, например Credential Validation	Выбирать после проверки требуемого сценария; это не замена Audit Logon на целевом сервере
Системные изменения	System	Audit System Events	По отдельному сценарию; не требуется для генерации `1102`

Событие 1102 — «The audit log was cleared» — записывается при очистке именно Security Log и, согласно документации Microsoft, генерируется независимо от настройки подкатегории Audit System Events. Это не означает автоматически компрометацию: журнал мог очистить уполномоченный администратор в рамках обслуживания. Но действие требует проверки причины, субъекта и внешней копии журнала.

Применение Advanced Audit Policy

Настраивайте политику через тот источник управления, который фактически является авторитетным для сервера.

1
Определите, является ли сервер доменным
На автономном сервере настраивайте локальную политику. На сервере в Active Directory сначала определите GPO, назначенную на OU или компьютер. Не рассчитывайте, что изменение в локальной оснастке сохранится после следующего обновления доменной политики.
2
Настройте доменную GPO для доменного сервера
В Group Policy Management создайте или измените GPO, область действия которой включает нужные серверы. В разделе Security Settings обычно доступен узел Advanced Audit Policy Configuration с категориями Logon/Logoff, Account Management, Detailed Tracking, Privilege Use и System. Включите подкатегории из таблицы, затем свяжите GPO с нужным OU и проверьте security filtering и наследование.
3
Включите переопределение legacy-категорий
В той же доменной GPO включите параметр Security Options с именем, близким к Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Он нужен, чтобы настройки детальных подкатегорий имели приоритет над конфликтующими настройками старой категориальной Audit Policy. Этот параметр не отменяет более приоритетную GPO, которая меняет те же настройки.
4
Настройте автономный сервер
Откройте Local Security Policy с административными правами и в разделе Advanced Audit Policy Configuration включите те же подкатегории. Для контроллера домена и рядового доменного сервера состав нужных событий различается: события управления доменными пользователями обычно формируются на контроллере домена, а локальными пользователями — на компьютере, где выполнена операция.
5
Обновите и зафиксируйте применённую политику
После изменения доменной GPO дождитесь обычного обновления политики либо выполните gpupdate /force в согласованное окно. Затем проверьте результат через auditpol непосредственно на целевом сервере. Значение в редакторе GPO — намерение, а вывод auditpol — фактическая политика.

Проверьте фактически применённую политику через auditpol

Запускайте auditpol из командной строки с повышенными правами на самом сервере. Имена подкатегорий локализованы: сначала получите полный список, затем используйте написание, которое возвращает конкретный хост.

Показывает эффективные категории и подкатегории аудита. Найдите строки Logon, Special Logon, User Account Management и Process Creation.

auditpol /get /category:*

Вывод:

Ожидаемый результат: для нужных подкатегорий указан `Success and Failure`, `Success` или другой явно понятный режим. Если вместо ожидаемого режима указано `No Auditing`, проверьте применённые GPO, их приоритет и параметр переопределения legacy-категорий.

Типовой точечный просмотр ключевых подкатегорий в англоязычной системе. В локализованной Windows подставьте имена из вывода `auditpol /get /category:*`.

auditpol /get /subcategory:"Logon","Special Logon","User Account Management","Process Creation"

Вывод:

Ожидаемая конфигурация для базового набора: Logon — Success and Failure; Special Logon — Success; User Account Management — Success; Process Creation — Success.

Пример включения Audit Logon на автономном сервере или в контролируемом тесте. Для постоянной доменной конфигурации предпочтительна GPO, иначе следующее применение GPO может отменить изменение.

auditpol /set /subcategory:"Logon" /success:enable /failure:enable

auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable
auditpol /set /subcategory:"Process Creation" /success:enable

Выполните команды последовательно. Они включают аудит успешных событий для остальных ключевых подкатегорий. Если ОС локализована, используйте имена подкатегорий из вывода auditpol /get /category:*.

Безопасная контрольная проверка

Не создавайте тестовые привилегированные аккаунты в production, не очищайте Security Log и не выполняйте намеренно неудачные входы чужими учётными записями. После включения Process Creation можно запустить безвредную команду в согласованном окне, например whoami, и найти новый 4688. События 4624 и 4672 обычно появляются при следующем штатном входе администратора; проверяйте их на тестовом сервере или в рамках разрешённой операции.

Как читать ключевые события Security Log

Откройте Event Viewer → Windows Logs → Security и фильтруйте журнал по Event ID. Для локального поиска в PowerShell можно использовать Get-WinEvent. Поля зависят от версии Windows и обновлений, поэтому при автоматизации ориентируйтесь на XML-представление события и проверяйте его на целевом выпуске ОС.

Выводит ключевые события Security за последние сутки. Для большого журнала ограничивайте период и Event ID, а для расследования открывайте полное XML-содержимое конкретной записи.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4672,4688,4720,4740,1102; StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated, Id, ProviderName, Message

Интерпретация ключевых Event ID

Event ID и источник	Сценарий и ключевые поля	Частая ложная трактовка	Действие аналитика
`4624`, Security, целевой компьютер	Успешный вход. Проверяйте Account Name/Domain, Logon Type, Logon ID, Workstation Name, Source Network Address и Authentication Package.	«Любой 4624 означает интерактивный вход человека». Событие может быть связано со службой, сетью или системной операцией.	Сопоставьте тип входа, источник и Logon ID с ожидаемой активностью и, при необходимости, с `4672` и `4688`.
`4625`, Security, целевой компьютер	Неудачный вход. Проверяйте Account Name, Logon Type, Workstation Name, Source Network Address, Status и SubStatus.	«4625 всегда означает атаку». Его вызывают опечатки, устаревший пароль службы, задача, сохранённые реквизиты или неверная настройка клиента.	Группируйте по учётной записи, IP, типу входа и времени; выясните, какая система или служба инициирует попытки.
`4672`, Security, компьютер, где создана сессия	Назначение чувствительных привилегий новой сессии. Важны Subject, Logon ID и список Privileges.	«4672 означает, что пользователь повысил права». Событие показывает привилегии, назначенные при создании сессии, а не сам факт эскалации.	Свяжите Logon ID с `4624`, затем просмотрите последующие процессы и административные изменения.
`4688`, Security, компьютер, где создан процесс	Создание процесса. Важны New Process Name, Process ID, Creator Process Name, Subject, Logon ID и Command Line, если включена.	«Имени `powershell.exe` достаточно для вывода». Без родительского процесса и командной строки контекст часто отсутствует.	Оцените родительский процесс, путь, аргументы, пользователя и время; сравните с назначением сервера.
`4720`, Security	Создана учётная запись. Важны Subject, Target Account, Target Domain и атрибуты новой учётной записи.	«Событие всегда будет на каждом сервере домена». Операция с доменной учётной записью обычно аудируется на контроллере домена; локальная — на соответствующем хосте.	Подтвердите заявку, автора и назначение учётной записи; проверьте последующие изменения группы и входы.
`4740`, Security	Учётная запись заблокирована. Важны Account That Was Locked Out и Caller Computer Name.	«Это доказательство перебора паролей извне». Причиной может быть служба или клиент со старым паролем.	Найдите связанные `4625`, определите вызывающий компьютер и проверьте легитимные процессы. Настройка блокировки рассматривается в статье «Парольная политика, блокировка учётных записей и MFA в Windows Server».
`1102`, Security	Security Log очищен. Проверяйте Subject и время; сохранённая внешняя копия даёт контекст до очистки.	«1102 однозначно доказывает действия злоумышленника». Очистка может быть санкционированной, но требует объяснения и проверки.	Зафиксируйте событие, проверьте владельца операции и целостность централизованно сохранённых записей; не очищайте журнал для теста.

Почему для 4624 и 4625 недостаточно номера события

Для 4624 и события 4625 решающим контекстом является тип входа. Типичные значения: 2 — интерактивный вход за консолью, 3 — сетевой доступ, 4 — пакетное задание, 5 — служба, 7 — разблокировка рабочей станции, 8 — NetworkCleartext, 9 — NewCredentials, 10 — удалённый интерактивный вход, включая обычные RDP-сценарии, 11 — cached interactive. Это не полный список и не универсальное доказательство способа доступа: интерпретируйте значение вместе с источником и ролью сервера.

В 4625 поля Status и SubStatus объясняют, почему вход не состоялся. Среди типичных кодов Status встречаются 0xC000006D — общая ошибка входа, 0xC0000064 — учётная запись не существует, 0xC000006A — неверный пароль, 0xC0000234 — учётная запись заблокирована. SubStatus может уточнять причину, например 0xC000006A для неверного пароля или 0xC0000072 для отключённой учётной записи. Набор и заполнение полей различаются между версиями Windows, типами аутентификации и обновлениями; не стройте правило обнаружения только по одному коду.

Разбор серии неудачных входов

1. Разбор серии неудачных входов

Применение:На сервере появились десятки 4625 за короткий период.

Почему:Сначала сгруппируйте события по Account Name, Source Network Address, Workstation Name и Logon Type. Серия с одним Logon Type 5 и одним сервером-источником может указывать на службу со старым паролем. Серия сетевых или удалённых входов с множеством учётных записей и общим внешним источником требует более тщательной проверки. Сверьте Status и SubStatus, а также наличие последующих 4624 для той же учётной записи.

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

Включите командную строку в событии 4688

Подкатегория Audit Process Creation создаёт событие 4688, но имя исполняемого файла редко даёт достаточно контекста. Для записи аргументов включите административный параметр с именем, близким к Include command line in process creation events, обычно расположенный в Administrative Templates → System → Audit Process Creation. Он действует при включённом Audit Process Creation и добавляет Command Line в 4688.

Командная строка раскрывает аргументы

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

Проверка Process Creation и командной строки

1
Включите Audit Process Creation
Проверьте через auditpol, что Process Creation имеет состояние Success. Если сервер доменный, зафиксируйте параметр в применяемой GPO, а не только локально.
2
Включите запись Command Line
В локальной политике автономного сервера или в доменной GPO включите параметр Include command line in process creation events. Обновите политику и убедитесь, что параметр не переопределён более приоритетной GPO.
3
Сгенерируйте безопасное контрольное действие
В согласованной административной сессии запустите whoami. Затем в Security найдите новый 4688 и проверьте, что New Process Name указывает на whoami.exe, а поле Command Line содержит вызов. Если поля нет, повторно проверьте Audit Process Creation, применённые GPO и версию события.

Настройте PowerShell logging по назначению

PowerShell logging не заменяет Security Log: 4688 показывает создание процесса, а PowerShell-механизмы могут дать содержание выполненного кода или сеанса. Script Block Logging записывает текст блоков сценария, в том числе динамически сформированного кода. Module Logging регистрирует выполнение командлетов, функций и модулей, выбранных политикой. Транскрибирование PowerShell создаёт текстовый протокол ввода и вывода сеанса в файле.

Механизмы журналирования PowerShell

Механизм	Что фиксирует	Где искать	Основной риск
Module Logging	Команды и данные, относящиеся к выбранным модулям	Обычно `Microsoft-Windows-PowerShell/Operational`, типичное событие `4103` для Windows PowerShell	Высокий объём и попадание аргументов или данных команд
Script Block Logging	Текст блоков сценария, который обрабатывает движок PowerShell	Обычно `Microsoft-Windows-PowerShell/Operational`, типичное событие `4104` для Windows PowerShell	Скрипты и встроенные значения могут содержать секреты или чувствительные данные
Transcription	Текстовый протокол ввода и вывода интерактивного или сценарного сеанса	Файлы в каталоге, заданном политикой или командой Start-Transcript	В файле может оказаться вывод команд, реквизиты и данные приложения

Для Windows PowerShell Operational-канал обычно называется Microsoft-Windows-PowerShell/Operational. В PowerShell 7 используется канал PowerShellCore/Operational, если он доступен и включён в конкретной конфигурации. События 4103 и 4104 обычно связывают соответственно с Module Logging и Script Block Logging в канале Windows PowerShell; точный канал, Event ID и состав полей проверяйте для используемой версии PowerShell и политики.

Проверка и включение журналирования PowerShell

1
Проверьте наличие Operational-канала
В Event Viewer откройте Applications and Services Logs и найдите Microsoft-Windows-PowerShell/Operational; для PowerShell 7 отдельно проверьте PowerShellCore/Operational. Канал может быть отключён, отсутствовать в старой конфигурации или иметь другое доступное содержимое в зависимости от установленной версии.
2
Включите Script Block Logging по политике
В Local Group Policy Editor для автономного сервера либо в доменной GPO найдите административный шаблон Windows PowerShell и включите политику Turn on PowerShell Script Block Logging. Применяйте её сначала к пилотной группе серверов, потому что содержание сценариев и объём журнала могут заметно вырасти.
3
Включите Module Logging только для нужной области
В том же наборе административных шаблонов включите Turn on Module Logging и задайте модули согласно сценарию. Широкий шаблон * может быть оправдан для ограниченного пилота или высокорискового контура, но создаёт больше данных; оцените объём и чувствительность до постоянного включения.
4
Настройте Transcription отдельно
Включите Turn on PowerShell Transcription и явно задайте Output Directory на защищённом локальном или сетевом пути с контролируемыми правами. При необходимости включите заголовки вызовов, если они нужны для расследования. Не выбирайте общий доступный пользователям каталог и не используйте путь без контроля резервного копирования и срока хранения.
5
Проверьте безопасным сценарием
В тестовом или согласованном сеансе выполните безвредную команду. Для проверки Script Block Logging можно использовать Get-Date и искать типичное событие 4104. Для проверки Module Logging выполните командлет из модуля, который явно указан в политике, и ищите типичное событие 4103; например, Get-Date подходит только при журналировании модуля Microsoft.PowerShell.Utility или шаблона *. После включения Transcription проверьте создание файла в настроенном каталоге. Если ожидаемая запись или файл не появились, проверьте фактически применённую GPO, выбранные модули, версию PowerShell, состояние канала и права на каталог транскриптов.

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

Get-WinEvent -ListLog 'Microsoft-Windows-PowerShell/Operational','PowerShellCore/Operational' -ErrorAction SilentlyContinue | Select-Object LogName, IsEnabled, RecordCount, MaximumSizeInBytes

Ищет типичные события Module Logging (`4103`) и Script Block Logging (`4104`) Windows PowerShell за последние сутки. Для PowerShell 7 при наличии канала замените LogName на `PowerShellCore/Operational` и сначала проверьте доступные Event ID на своём хосте.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4103,4104; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message

Настройте размер и сохранение Security Log

Размер Security Log нельзя выбрать универсальным числом: он зависит от роли сервера, числа входов, аудита процессов, включённых полей и срока до централизованной доставки. В свойствах Security Log в Event Viewer или через политику задаются максимальный размер и действие при заполнении, например перезапись старых событий либо архивирование при заполнении. Выбор должен соответствовать требуемому сроку локальной доступности и процедуре реакции.

Не допускайте тихой потери истории

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

Эта инструкция не заменяет базовую защиту ОС, настройку удалённого доступа, парольной политики или реагирование на инцидент информационной безопасности. Связанные темы: hardening Windows Server, защита RDP, Windows Defender Firewall и реагирование при взломе сервера.

Термины в статье

Script Block Logging: Script Block Logging — механизм журналирования PowerShell, записывающий текст блоков сценариев, обрабатываемых движком, включая динамически сформированный код.
Аудиторский след: Аудиторский след — упорядоченный по времени набор записей о действиях и изменениях, позволяющий установить, кто, когда, над чем и с каким результатом выполнил операцию, а также откуда поступил запрос.
Блокировка учётной записи: Блокировка учётной записи — временное или административное запрещение входа для аккаунта, обычно после заданного числа неудачных попыток аутентификации.
Журнал безопасности Windows: Журнал безопасности Windows — системный журнал событий, фиксирующий результаты аудита входов, доступа к объектам, изменений политик и привилегий в Windows.
Идентификатор события 4625: Событие с идентификатором 4625 — запись аудита в журнале безопасности Windows о неудачной попытке входа, содержащая сведения о причине и источнике.
Идентификатор события 4688: Идентификатор события 4688 — запись журнала безопасности Windows о создании нового процесса, формируемая при аудите успешных событий Audit Process Creation.
Инцидент информационной безопасности: Инцидент информационной безопасности — выявленное или обоснованно подозреваемое событие, нарушающее политику защиты либо создающее угрозу конфиденциальности, целостности или доступности.
Локальная политика безопасности: Локальная политика безопасности — хранящиеся на компьютере параметры безопасности Windows, действующие для этого узла; доменные GPO могут переопределять конфликтующие настройки.
Пересылка событий Windows: Пересылка событий Windows — механизм доставки записей журналов Windows с источников на сервер-коллектор по подпискам, без установки отдельного агента сбора.
Привилегированная учётная запись: Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Расширенная политика аудита: Расширенная политика аудита — механизм Windows, задающий детальные подкатегории аудита безопасности вместо общих категорий базовой политики аудита.
Событие аудита: Событие аудита — действие, попытка действия или изменение состояния, регистрируемое системой согласно политике аудита для последующей проверки.
Событие безопасности: Событие безопасности — наблюдаемое действие или изменение состояния системы либо сети, значимое для защиты; оно может быть штатным, связанным с ошибкой или подозрительным.
Тип входа Windows: Тип входа Windows — числовое поле в событиях аудита входа, указывающее характер выполненного или запрошенного входа: интерактивного, сетевого, удалённого или служебного.
Транскрибирование PowerShell: Транскрибирование PowerShell — функция журналирования, сохраняющая текстовый протокол ввода и вывода сеанса PowerShell в отдельный файл транскрипции.