Время на прочтение4 мин
Количество просмотров309K
Рэнди Франклин Смит (CISA, SSCP, Security MVP) имеет в своем арсенале очень полезный документ, рассказывающий о том, какие события (event IDs) обязательно должны отслеживаться в рамках обеспечения информационной безопасности Windows. В этом документе изложена крайне полезная информация, которая позволит Вам “выжать” максимум из штатной системы аудита. Мы подготовили перевод этого материала. Заинтересованных приглашаем под кат.
О том, как настроить аудит, мы уже обстоятельно писали в одном из наших постов. Но из всех event id, которые встречаются в журналах событий, необходимо остановить свое внимание на нескольких критических важных. На каких именно – решать каждому. Однако Рэнди Франклин Смит предлагает сосредоточить внимание на 10 важных событиях безопасности в Windows.
Контроллеры доменов
Event ID — (Категория) — Описание
1) 675 или 4771
(Аудит событий входа в систему)
Событие 675/4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. Обычно причиной этого является несоответствующий пароль, но код ошибки указывает, почему именно аутентификация была неудачной. Таблица кодов ошибок Kerberos приведена ниже.
2) 676, или Failed 672 или 4768
(Аудит событий входа в систему)
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.
3) 681 или Failed 680 или 4776
(Аудит событий входа в систему)
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.
4) 642 или 4738
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.
5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.
6) 624 или 4720
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя
7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа
517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности
Вход и выход из системы (Logon/Logoff)
Event Id — Описание
528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)
Типы входов в систему (Logon Types)
Тип входа в систему — Описание
2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)
Коды отказов Kerberos
Код ошибки — Причина
6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена
Коды ошибок NTLM
Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание
3221225572 — C0000064 — Такого имени пользователя не существует
3221225578 — C000006A — Верное имя пользователя, но неверный пароль
3221226036 — C0000234 — Учетная запись пользователя заблокирована
3221225586 — C0000072 — Учетная запись деактивирована
3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)
3221225584 — C0000070 — Ограничение рабочей станции
3221225875 — C0000193 — Истек срок действия учетной записи
3221225585 — C0000071 — Истек срок действия пароля
3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему
Еще раз продублируем ссылку на скачивание документа на сайте Рэнди Франклина Смита www.ultimatewindowssecurity.com/securitylog/quickref/Default.aspx. Нужно будет заполнить небольшую форму, чтобы получить к нему доступ.
P.S. Хотите полностью автоматизировать работу с журналами событий? Попробуйте новую версию NetWrix Event Log Manager 4.0, которая осуществляет сбор и архивирование журналов событий, строит отчеты и генерирует оповещения в режиме реального времени. Программа собирает данные с многочисленных компьютеров сети, предупреждает Вас о критических событиях и централизованно хранит данные обо всех событиях в сжатом формате для удобства анализа архивных данных журналов. Доступна бесплатная версия программы для 10 контроллеров доменов и 100 компьютеров.
| Operating Systems |
Windows 2008 R2 and 7
Windows 2012 R2 and 8.1 Windows 2016 and 10 Windows Server 2019 and 2022 |
|
Category • Subcategory |
Account Management • User Account Management |
| Type | Success |
|
Corresponding events in Windows 2003 and before |
627
|
4723: An attempt was made to change an account’s password
On this page
- Description of this event
- Field level details
- Examples
The user attempted to change
his/her own password
. Subject and Target should always match. Don’t confuse this event with 4724.
This event is logged as a failure if his new password fails to meet the password policy.
If the user fails to correctly enter his old password this event is not logged. Instead, for domain accounts, a 4771 is logged with kadmin/changepw as the service name.
This event is logged both for local SAM accounts and domain accounts.
You will also see event ID 4738 informing you of the same information.
Free Security Log Resources by Randy
- Free Security Log Quick Reference Chart
- Windows Event Collection: Supercharger Free Edtion
- Free Active Directory Change Auditing Solution
- Free Course: Security Log Secrets
Description Fields in
4723
Subject:
The user and logon session that performed the action.
- Security ID: The SID of the account.
- Account Name: The account logon name.
- Account Domain: The domain or — in the case of local accounts — computer name.
- Logon ID is a semi-unique (unique between reboots) number that identifies the logon session. Logon ID allows you to correlate backwards to the logon event (4624) as well as with other events logged during the same logon session.
Target Account:
- Security ID: SID of the account
- Account Name: name of the account
- Account Domain: domain of the account
Supercharger Free Edition
Centrally manage WEC subscriptions.
Free.
Stay up-to-date on the Latest in Cybersecurity
Sign up for the Ultimate IT Security newsletter
to hear about the latest webinars, patches, CVEs, attacks, and more.
Используя групповые политики Active Directory можно настроить аудит смены паролей и других действий связанные с пользователями. Эти события можно получить используя оснастку Event Viewer и Powershell. В этой статье мы разберем эти возможности на примерах и создадим команду Powershell, которая сделает этот процесс более простым.
Настройка политики аудита
Самый удобный способ создать политику — использовать оснастку ‘Group Policy Management’. Эта оснастка может быть открыта через RSAT или на домен-контроллер. Оснастку групповых политик так же открывается командой:
gpedit.mscВам необходимо выбрать OU, где находятся компьютеры, и создать в ней новую политику. Можно выбрать так же сайт или домен если вы планируете охватить область большую чем OU:
В примерах я использую OU Moscow. Через Powershell создать и привязать политику тоже можно. Это делается следующим образом:
# Создаем политику
$gpo = New-GPO -Name 'PasswordAudit'
# Соединяем политику с OU Moscow
New-GPLink -Name 'PasswordAudit' -Target 'OU=Moscow,DC=domain,DC=local'
Политика, которая нам нужна, называется ‘Audit account management/Аудит управления учетной записью’. Она включает аудит связанный с изменением пользователя, пароля и групп. Что бы это сделать пройдите по следующему пути
- ‘Computer Configuration’ — ‘Policies’ — ‘Windows Settings’ — ‘Security Settings’ — ‘Local Policies’ = ‘Audit Policy’;
- ‘Конфигурация компьютера’ — ‘Параметры Windows’ — ‘Параметры безопасности’ — ‘Локальные политики’ — ‘Политика аудита’.
В этой политике нужно включить учет успешных попыток изменения данных (Success) и провала (Failure):
Powershell плохо предназначен для настройки политик. Основная проблема в том, что в качестве пути до политики мы должны указывать ветку реестра и знать значения, которые планируем менять. Политики аудита, связанные с безопасностью, не имеют веток реестра вообще и из-за этого установить их командами Powershell не возможно.
Ниже, для примера, показано как через Powershell устанавливается политика включающая заставку через 900 секунд:
# Set-GPRegistryValue -Name "Созданная политика" -Key "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop" -ValueName "ScreenSaveTimeOut" -Type DWORD -Value 900У домен контроллеров есть роль FSMO, которая отвечает за пароли. Ее название PDC — ‘Primary domain controller’. На домен контроллере, который держит эту роль, и будут собираться все события связанные с политикой аудита. Увидеть кому принадлежит эта роль можно так:
(Get-ADDomain).PDCEmulator
На клиентских компьютерах запустим обновление политик:
Invoke-GPUpdate -Force -Target 'Computer'Получение событий
Учитывая, что включенная политика касается не только паролей, можно настроить фильтр через Powershell или GUI. Мы настроим фильтры, которые будут выводить события связанные с определенными идентификаторами ‘Event ID’. Нас интересуют следующие идентификаторы:
- 4723 — попытка смены пароля;
- 4724 — попытка сброса пароля;
- 4740 — пользователь был заблокирован;
- 4767 — пользователь был разблокирован.
Фильтрация логов с Event Viewer
Что бы выполнить фильтрацию через GUI — откройте логи ‘Security’ в ‘Event Viewer’ на домен-контроллере. Открыв журнал вы увидите множество событий не касающихся паролей:
Эти фильтры мы можем применить зайдя в соответствующее меню:
В новом окне мы должны указать идентификаторы событий, их источник и категорию:
После этих установок у нас будут отображаться только нужные события.
Фильтрация логов с Powershell
В Powershell есть две команды для работы с логами:
- Get-WinEvent — получает логи из всех журналов;
- Get-Eventlog — получает логи из журналов Application, System, or Security. Является устаревшим командлетом.
Обе команды имеют параметр ‘ComputerName’, с помощью которого можно подключаться удаленно.
У получения логов средствами Powershell есть две проблемы:
- Процесс получения логов медленный. Выполнение одного запроса может выполняться больше 1 секунды;
- Если брать другие команды Powershell, то их вывод всегда структурирован в виде ‘Ключ’=’Значение’. При получении логов журнала, так же как в EventViewer, часть информации будет представлена как строка, т.е ‘Ключ’= ‘Ключ=Значение Ключ=Значение’. В разных случаях может придется использовать регулярные выражения и парсить значения.
Что бы максимально ускорить процесс получения логов можно использовать 3 параметра фильтрации: FilterXPath, FilterHashtable, FilterXml.
XPath — это язык запросов, который был создан для работы с XML. Мы можем не создавать свой запрос XPath, а увидеть уже составленный на созданном раннее фильтре, на вкладке XML:
Команда, которая получит подобные логи с домен-контроллера ‘AD1’ и используя запрос XPath, будет выглядеть следующим образом:
Get-WinEvent -ComputerName 'AD1' -LogName 'Security' -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task = 13824 and (EventID=4723 or EventID=4724 or EventID=4740 or EventID=4767)]]"
Аналогичное можно сделать использовав HashTable. Мы не должны указывать тип логов, т.к. это сделано в массиве:
$log = @{
LogName='Security';
ProviderName='Microsoft-Windows-Security-Auditing';
ID=4723,4724,4740;
}
Get-WinEvent -ComputerName 'AD1' -FilterHashtable $log
Если вам больше нравится вариант с запросом через hashtable, но вы не понимаете как правильно его составить, можно использовать следующий подход. Мы должны найти хоть один лог, который нам нужен используя любые средства Powerhsell. Затем мы выводим все свойства через ‘SELECT *’ и заполняем ими нашу таблицу:
Get-WinEvent -ComputerName 'AD1' -LogName 'Security' | where id -eq 4634 | select *
Отличия между массивом hashtable и обычными средствами Powershell в скорости. Если вы будете фильтровать вывод используя Powerhsell (как в примере выше) — это будет медленнее. Кроме указанных параметров в документации можно найти дополнительные варианты.
Создание команды
Создадим функцию с помощью который мы сможем выполнять эти действия более удобным для нас способом. Эта функция должна будет учитывать следующие моменты:
- возможность указания времени, указывающие на начало создания лога;
- понятный вывод сообщения соответствующий идентификаторам;
- источник и цель аудита. Например администратор изменивший пароль пользователя;
- тип события — success или fail.
Что бы получить события начинающиеся с определенной даты мы можем использовать существующее свойство ‘StartTime’ в массиве. ‘EndTime’ указывает обратное. В примере ниже мы получим события созданные за сутки:
# минус день от сегодняшней даты
$date = (Get-Date).AddDays(-1)
$hash = @{
LogName='Security';
ProviderName='Microsoft-Windows-Security-Auditing';
ID=4723,4724,4740;
StartTime=$date
}
Get-WinEvent -ComputerName 'AD1' -FilterHashtable $hash
Выше уже описывалась, что одна из проблем работы с журналом — это отсутствие форматирования каких-то данных. В примере ниже свойство ‘Messages’ хранит сплошной текст, а ‘Properties’ только некоторые отформатированные данные из ‘Messages’:
(Get-WinEvent -ComputerName 'AD1' -FilterHashtable $hash -MaxEvents 1).Message
(Get-WinEvent -ComputerName 'AD1' -FilterHashtable $hash -MaxEvents 1).Properties
Пример выше — скорее идеальный случай. У вас может отличаться порядок или другая информация в ‘Properties’. Эти данные точно будут отличаться в логах с разными ID. В случае с одинаковыми ID — это так же может случатся.
Готовая функция, выводящая информацию об этих событиях, будет следующей:
Function Get-ADPasswordEvent {
[CmdletBinding()]
Param(
# массив с идентификаторами для проверки событий
[array]$EventID = @(4723,4724,4740,4767),
# поиск логов от указанной даты
[datetime]$BeginTime,
# тип события, которые мы ищем Удача/Провал
[ValidateSet("Success","Failure")]
[array]$EventType,
# IP/DNS имя удаленного компьютера
[string]$ComputerName
)
Process {
# составляем массив для поиска
$log_table = @{
LogName='Security';
ProviderName='Microsoft-Windows-Security-Auditing';
ID=$EventID;
}
# ниже проверяем какие параметры переданы пользователем
# и добавляем их в массив
# пользователь указал дату
if ($BeginTime){
$log_table += @{StartTime=$BeginTime}
}
# пользователю нужен только успех/провал
if ($EventType -eq 'Success'){
$log_table += @{Keywords=9007199254740992}
}
elseif ($EventType -eq 'Failure') {
$log_table += @{Keywords=4503599627370496}
}
$parameters = @{
FilterHashtable=$log_table
}
# если пользователь указал удаленный компьютер
if ($ComputerName){
$parameters += @{ComputerName=$ComputerName}
}
# передаем все параметры в команду
$events = Get-WinEvent @parameters
# массив, который вернем пользователю
# со всеми событиями
$formatted_events = @()
foreach ($event in $events){
# проверяем каждое событие
# и устанавливаем для него свое описание
Switch ($event.ID) {
4723 {
$Description = "Попытка изменения пароля"
Break
}
4724 {
$Description = "Попытка сброса пароля"
Break
}
4740 {
$Description = "Пользователь заблокирован"
Break
}
4767 {
$Description = "Пользователь разблокирован"
Break
}
Default {
# если его идентификатор не найден
$Description = $event.Message
Break
}
}
# определяем тип события
if ($event.KeywordsDisplayNames -like '*Success*'){$type = 'Успех'}
else {$type = 'Провал'}
# создаем массив текущего события
# и добавляем его к остальным найденным
$formatted_events += [PSCustomObject]@{
"Дата создания" = (Get-Date $event.TimeCreated -Format "dd-MM-yyyy HH:mm");
"ID" = $event.ID;
"Описание" = $Description;
"Тип" = $type;
"Цель (имя)" = $event.Properties[0].Value;
"Цель (компьютер)" = $event.Properties[1].Value;
"Кем (имя)" = $event.Properties[4].Value;
"Кем (компьютер)" = $event.Properties[5].Value;
"Цель (SID)" = $event.Properties[2].Value;
"Кем (SID)" = $event.Properties[3].Value;
}
}
# возвращаем составленный массив пользователю
return $formatted_events | ft
}
}Примеры работы
Варианты использования функции:
# возвращаем все события по идентификаторам 4723,4724,4740,4767
Get-ADPasswordEvent
# возвращаем те же события, но за сутки
Get-ADPasswordEvent -BeginTime (Get-Date).AddDays(-1)
# возвращаем события провала с удаленного компьютера
Get-ADPasswordEvent -ComputerName 'AD1' -EventType 'Failure'
# возвращаем события используя другой идентификатор
Get-ADPasswordEvent -EventID 4724
…
Теги:
#powershell
#ad
To check the password change history in Active Directory (AD), it’s crucial to understand that AD doesn’t natively store a comprehensive historical log of all password changes indefinitely. However, there are ways to track recent password changes using Event Logs, PowerShell, and by enabling auditing.
Method 1: Using Event Logs
When users change their passwords, Event Logs in Windows Server capture these events, assuming password change auditing is enabled.
- Enable Auditing (if not already enabled):
- Open Group Policy Management (
gpmc.msc). - Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff.
- Enable Audit Logon Events and Audit Account Logon Events.
- Ensure that Audit Directory Service Access is enabled in Security Settings > Advanced Audit Policy.
- Open Group Policy Management (
- View the Event Logs:
- Open Event Viewer (
eventvwr.msc). - Go to Windows Logs > Security.
- Look for Event ID 4723 (Password change attempt), Event ID 4724 (Password reset), and Event ID 628 (Password change).
- Filter the logs for these events to track password change history.
- Open Event Viewer (
- Event Details:
- In the Event Details, you’ll find information about the user account and the timestamp of the password change.
Method 2: Using PowerShell (with Auditing Enabled)
PowerShell can help you query password-related events if auditing is enabled.
-
Search Event Logs for Password Changes: Run the following command to search for password change events:
Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4723 -or $_.Id -eq 4724 -or $_.Id -eq 628 } | Format-Table TimeCreated, Id, Message -AutoSize -
Interpret the Results: This command will display the time of the password change and associated user details for each relevant event.
The output will show something like this:
| TimeCreated | Id | Message |
|---|---|---|
| 2/3/2025 10:15:45 AM | 4723 | An attempt was made to change the password of user ‘john.doe’ |
| 2/3/2025 10:20:30 AM | 4724 | The password of user ‘admin’ was reset by user ‘jane.doe’ |
- TimeCreated shows the time when the event occurred.
- Id represents the Event ID (4723, 4724, 628).
- Message provides additional details like the user who performed the action or the target user account.
Method 3: Using a Third-Party Tool (Optional)
If you need more detailed history and reporting capabilities, you can consider third-party tools like Netwrix Auditor, Lepide Auditor, or Specops that can provide more granular tracking of password changes, including change history over time and additional reporting features.
Limitations and Considerations:
- Default retention: Event logs are not retained indefinitely by default; old events may be overwritten after a period depending on your server’s log settings (log size, retention period). If you need to keep a long history, consider increasing log retention or exporting logs to a central logging solution.
- PowerShell speed: On large networks, querying logs using PowerShell might take time depending on the number of events. In such cases, filtering logs to a specific time range could improve performance.
Tracking password changes in Active Directory requires enabling auditing, then reviewing Event Logs or using PowerShell to query those logs. The main events to look for are Event IDs 4723, 4724, and 628. By ensuring auditing is set up correctly, you can capture and track password change attempts and resets efficiently.