4719 Windows Server, AD и Роли

Event ID 4719: Политика аудита системы была изменена (Audit Policy Changed)

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура подсистемы аудита Windows (LSASS)

Событие 4719 логируется в журнале Security операционной системы при изменении настроек Локальной или доменной политики аудита (Audit Policy). Подсистема Local Security Authority (LSASS) фиксирует, какие именно категории событий безопасности (входы, доступ к файлам, изменение групп) должны записываться в журнал. С точки зрения непрерывности ИБ, событие 4719 — это важнейший триггер целостности мониторинга. Злоумышленники (или недобросовестные инсайдеры) при компрометации сервера первым делом пытаются ослепить системы мониторинга (SIEM), отключая аудит критических событий через утилиту auditpol.exe, чтобы их дальнейшие действия не оставили следов в логах.

Анализ полей события 4719:

Поле лога	Значение	Маркер угрозы (IoC)
`Category / Subcategory`	Категория аудита (например, Logon/Logoff)	Указывает, какой именно сегмент видимости был изменен.
`Audit Policy Change`	Success / Failure / Removed	Если значение меняется с Success на 'Removed' (Отключено) — это прямой признак саботажа.
`SubjectUserName`	Инициатор	Кто выполнил команду (Admin или SYSTEM).

Сценарии расследования попыток отключения аудита (Blind Attack)

Сценарий 1: Выявление фактов отключения аудита (Removed)

Мониторинг журнала на предмет отключения политик аудита администраторами или скриптами.

# Поиск событий изменения политик аудита с фиксацией новых значений
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4719; StartTime=(Get-Date).AddDays(-30)} | 
    Select-Object TimeCreated, 
    @{N='ChangedBy';E={$_.Properties[4].Value}}, 
    @{N='Subcategory';E={$_.Properties[2].Value}}, 
    @{N='NewSetting';E={$_.Properties[3].Value}} | 
    Where-Object {$_.NewSetting -match 'Removed'} | Format-Table -AutoSize

Сценарий 2: Восстановление политик аудита (Force Advanced Audit Policy)

Если хакер отключил аудит локально через auditpol /clear, вы должны обеспечить принудительное восстановление политик через доменные GPO.

Откройте редактор GPO, привязанный к вашим серверам.
Перейдите: Конфигурация компьютера -> Политики -> Параметры Windows -> Параметры безопасности -> Расширенная политика аудита.
Настройте необходимые категории (Success/Failure).
Чтобы локальные настройки (Classic Audit) не конфликтовали с GPO, включите параметр: Локальные политики -> Параметры безопасности -> Аудит: принудительно переопределять параметры классической политики аудита (Force audit policy subcategory settings).

Сценарий 3: Настройка критического SIEM Алерта

В любой SIEM системе (Wazuh, Splunk) событие 4719 должно иметь уровень Critical. Если событие инициировано учетной записью SYSTEM, обычно это нормальное применение GPO (обновление). Но если инициатором выступает конкретный пользователь (например, DOMAIN\Admin01) — это ручное вмешательство в подсистему безопасности, требующее немедленной реакции.

Типовые ошибки администраторов

Использование классических политик вместо расширенных: Настройка аудита в старом разделе 'Локальные политики -> Политики аудита' включает генерацию огромного количества мусорных событий (включая аудит фильтрации пакетов WFP). Всегда используйте 'Расширенную политику аудита' (Advanced Audit Policy) для точечной настройки.

Журналы безопасности серверов внезапно перестали собирать события?
Отключение политик аудита — классический этап атаки перед кражей данных или внедрением шифровальщика. Не оставайтесь 'слепыми': доверьте безопасность экспертам ITSTM. Настроим жесткий Hardening ОС, внедрим надежный сбор логов (WEF/ELK) и защитим журналы от стирания.

💡 Практика специалистов: Экспертная практика: Если хакер использует продвинутые техники (например, утилиты типа 'AuditPol-Bypass' или патчинг процесса LSASS в оперативной памяти), он может отключить запись событий без вызова API изменения политик. В этом случае событие 4719 не сгенерируется. Мониторинг должен включать не только лог Windows, но и проверку целостности агента EDR/Sysmon.

Частые вопросы (FAQ)

Почему событие 4719 генерируется каждый час на всех серверах?

Служба групповых политик (Group Policy Client) по умолчанию обновляет параметры безопасности в фоновом режиме (каждые 90-120 минут). В момент применения GPO система фиксирует применение политик аудита, генерируя 4719 от имени SYSTEM.

Чем событие 4719 отличается от 1102?

Событие 4719 означает, что кто-то изменил ПРАВИЛА того, что нужно записывать. Событие 1102 (The audit log was cleared) означает, что кто-то физически УДАЛИЛ (очистил) весь журнал Security.

Как проверить текущие настройки аудита из командной строки?

Запустите командную строку от имени администратора и выполните: auditpol /get /category:* . Эта команда покажет реальный результирующий набор политик аудита, активный в данный момент в памяти ядра LSASS.

Можно ли запретить администраторам менять политику аудита?

Только частично. Локальный администратор всегда имеет право управлять системой. Для защиты логов используют централизованную отправку событий в изолированный SIEM (Syslog/WEF) в режиме реального времени, до того как хакер успеет сменить настройки.