Windows код события 4625

Время на прочтение4 мин

Количество просмотров309K

Картинка с сайта: habr.com

Рэнди Франклин Смит (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 компьютеров.

В этой статье мы покажем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определенное время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.

Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть.

The referenced account is currently locked out and may not be logged on to ….

Картинка с сайта: winitpro.ru

Как проверить, что аккаунт пользователя AD заблокирован?

Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:

Get-ADUser -Identity aaivanov -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout

Или:

Get-ADUser avivanov2 -Properties Name,Lockedout, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name, Lockedout, @{n='LastLogon';e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}, @{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}}, @{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True). Также в выводе команды вы видите информацию о времени смены пароля пользователя в домене и времени блокировки аккаунта.

Можно вывести сразу все заблокированные аккаунты в домене с помощью командлета Search-ADAccount:

Search-ADAccount -UsersOnly -lockedout

Вы можете вручную снять блокировку учетной записи с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Для этого в свойствах учетной записи пользователя на вкладке Account, включите опцию Unlock account. This account is currently locked out on this Active Directory Domain Controller (Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована) и сохраните изменения.

Картинка с сайта: winitpro.ru

Также можно немедленно разблокировать учетную запись с помощью командлета PowerShell Unlock-ADAccount:

Get-ADUser -Identity aaivanov | Unlock-ADAccount

Информацию о времени блокировки учетной записи, количестве неудачных попыток набора пароля, времени последнего входа пользователя в домен можно получить в свойствах учетной записи в консоли ADUC на вкладке редактора атрибутов или с помощью PowerShell

Get-ADUser aaivanov -Properties Name, lastLogonTimestamp,lockoutTime,logonCount,pwdLastSet | Select-Object Name,@{n='LastLogon'; e={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}, @{n='lockoutTime';e={[DateTime]::FromFileTime($_.lockoutTime)}},  @{n='pwdLastSet';e={[DateTime]::FromFileTime($_.pwdLastSet)}},logonCount

Картинка с сайта: winitpro.ru

Политики блокировки учетных записей в домене

Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой Default Domain Policy в консоли gpmc.msc. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политики:

• Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована;
• Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически);
• Reset account lockout counter after (Время до сброса счетчика блокировки) – через какое время будет сброшен счетчик неудачных попыток авторизации.

Картинка с сайта: winitpro.ru

Для защиты от перебора паролей рекомендуется использовать стойкие пароли пользователей в AD (использовать длину пароля не менее 8 символов и включить требования сложности. Это настраивается в разделе Password Policy в политиках Password must meet complexity requirements и Minimum password length. Периодически нужно выполнять аудит паролей пользователей.

Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.

Чтобы решить проблему самопроизвольной блокировки учетной записи пользователя, администратору нужно разобраться с какого компьютера и какой программой была заблокирован аккаунт пользователя Active Directory.

События блокировки пользователей EventID 4740, 4625

В первую очередь администратору нужно разобраться с какого компьютера/сервера домена происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:

• Audit Account Lockout
• Audit Logon
• Audit Logoff

Затем перейдите в раздел Account Management и включите политику:

• Audit User Account Management: Success

Проще всего включить эти параметры GPO через консоль
gpmc.msc
, отредактировав политику Default Domain Controller Policy.

Картинка с сайта: winitpro.ru

Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Account lockout threshold, учетная запись пользователя временно блокируется.

При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:

(Get-AdDomain).PDCEmulator

Событие блокировки учетной записи домена можно найти в журнале Security (Event Viewer > Windows Logs) на контролере домена. Отфильтруйте журнал безопасности (Filter Current Log) по событию с Event ID 4740. Должен появиться список последних событий блокировок учетных записей контроллером домена. Переберите все события, начиная с самого верхнего и найдите событие, в котором указано, что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).

Примечание. В большой инфраструктуре AD, в журнале безопасности фиксируется большое количество событий, которые постепенно перезаписываются более новыми. Поэтому желательно увеличить максимальный размер журнала на DC и приступать к поиску источника блокировки как можно раньше.

Картинка с сайта: winitpro.ru

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – WKS-TEST1.

Если в поле Computer Name указано неизвестное имя компьютера/устройства, который не резолвится в вашей сети через DNS (недоменный компьютер, или не Windows устройство с поддержкой Kerberos аутентфикации), вы можете получить IP адрес этого устройства. Для этого нужно включить следующие параметры аудита в Default Domain Controller Policy. Перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Configuration и настройте следующие параметры:

Account Logon

• Audit Kerberos Authentication Service: Success, Failure
• Audit Kerberos Service Ticket Operations: Success, Failure

Logon/Logoff

• Audit Special Logon: Success, Failure

Откройте журнал Event Viewer -> Security и включите фильтр по Event ID 4740 и 4741. Обратите внимание, что теперь перед появлением события блокировки пользователя (4740) появляется событие 4771 (неуспешная kerberos аутентфикация) от Kerberos Authentication Service. В нем указано имя пользователя, который пытался выполнить аутентификацию и IP адрес устройства (поле Network Information -> Client Address), с которого пришел запрос.

Картинка с сайта: winitpro.ru

Если удаленное устройство использует NTLM для аутентификации в домене, нужно выполнить поиск события EventID 4625 (неуспешная NTLM аутентификация) на контроллерах домена (оно появится только на DC, через который была выполнена попытка аутентифицироваться через NTLM).

Откройте последнее найденное событие с EventID 4625 для вашего пользователя (Account name). Здесь видно, что при попытке выполнить NTLM аутентификацию (Authentication Package: NTLM, Logon Process: NtLmSsp) учетная запись была заблокирована (
Failure Reason: Account locked out, Status: 0xC0000234
). В описании события указаны как имя компьютера (Workstation Name), так и его IP адрес (Source Network Address).

Картинка с сайта: winitpro.ru

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

nltest /dbflag:2080ffffff

Перезапустите службу Netlogon

net stop netlogon && net start netlogon

Выполните поиск в файле netlogon.log событий:

• 0xc000006a – An invalid attempt to login has been made by the following user
• 0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Можно найти события блокировки пользователя a.berg в файле netlogon.log с помощью команды:

type C:\Windows\debug\netlogon.log | findstr a.berg| findstr /i "0xC000006A"

Картинка с сайта: winitpro.ru

В данном примере видно, что пользователь a.berg блокируется с устройства DESKTOP-74G6LB.

Поиск компьютера, с которого блокируется пользователь с помощью PowerShell

Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла. Скрипт выполняет поиск событий с Event ID в Event Log:

$Username = 'username1'
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Properties[1].value + ' ' + $_.TimeCreated}

Картинка с сайта: winitpro.ru

Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:

$Username = 'username1'
Get-ADDomainController -fi * | select -exp hostname | % {
$GweParams = @{
‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

Утилита Microsoft Account Lockout and Management Tools

Для поиска источника блокировки пользователя можно использовать графическую утилиту Microsoft Account Lockout and Management Tools —
Lockoutstatus.exe
(скачать ее можно тут). Данная утилита проверяет статус блокировки учетной записи на всех контроллерах домена.

Запустите утилиту Lockoutstatus.exe, укажите имя заблокированной учетной записи (Target User Name) и имя домена (Target Domain Name).

Картинка с сайта: winitpro.ru

В появившемся списке будет содержаться список DC и состояние учетной записи (Locked или Non Locked). Дополнительно отображается время блокировки и компьютер, с которого заблокирована данная учетная запись (Orig Lock).

Картинка с сайта: winitpro.ru

Атрибуты badPwdCount и LastBadPasswordAttempt не реплицируются между контролерами домена.

Прямо из утилиты Lockoutstatus можно разблокировать пользователя, или сменить его пароль.

Картинка с сайта: winitpro.ru

Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).

Как определить программу, из которой блокируется учетная запись пользователя?

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

Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля. Чаще всего это значит, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространенные места, в которых пользователь мог сохранить свой старый пароль:

• Сетевые диски, подключенные через
  net use
  (Map Drive);
• Задания планировщика Windows Task Scheduler;
• Ярлыки с настроенным режимом
  RunAs
  (используется для запуска от имени другого пользователя);
• В службах Windows, которые настроены на запуск из-под доменной учетной записи;
• Сохранённые пароли в менеджере паролей в панели управления (Credential Manager). Выполните команду
  rundll32.exe keymgr.dll, KRShowKeyMgr
  и удалите сохраненные пароли;

  Пароли пользователей могут быть сохранены в контексте SYSTEM. Чтобы вывести их, нужно запустить командную строку от имени SYSTEM с помощью
  psexec -i -s -d cmd.exe
  и выполнить команду
  rundll32 keymgr.dll,KRShowKeyMgr
  чтобы открыть список сохраненных паролей для NT AUTHORITY\SYSTEM.

• Программы, которые хранят и используют закэшировнный пароль пользователя;
• Браузеры;
• Мобильные устройства (например, использующееся для доступа к корпоративной почте);
• Программы с автологином или настроенный автоматический вход в Windows;
• Незавершенные сессии пользователя на других компьютерах или терминальных RDS фермах или RDP серверах (поэтому желательно настраивать лимиты для RDP сессий);
• Сохраненные пароли для подключения к Wi-FI сетям (WPA2-Enterprise 802.1x аутентификацию в беспроводной сети);
• Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.

Совет. Существует ряд сторонних утилит (в основном коммерческих) позволяющих администратору выполнить проверку удаленной машины и детектировать источник блокировки учетных записей. В качестве довольно популярного решения отметим Account Lockout Examiner от Netwrix.

Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на компьютере, на котором нужно отследить источник блокировки, откройте редактор локальной групповой политики gpedit.msc и включите следующие параметры в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

Картинка с сайта: winitpro.ru

Затем обновите настройки групповых политик на клиенте:

gpupdate /force

Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:

An account failed to log on.
Failure Reason: Account locked out.

Картинка с сайта: winitpro.ru

Из описания события видно, что источник блокировки учетной записи (Caller Process Name) – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.

После окончания анализа, выявления и наказания виновника не забудьте отключить действие включенных групповых политик аудита.

Если вы так и не смогли найти причину блокировки учетной записи на конкретном компьютере, попробуйте просто переименовать имя учетной записи пользователя в Active Directory (измените SAMaccountName и UPN пользователя в домене AD). Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.

WINDOWS

Understanding Windows security event logs is paramount for any organization that seeks to fortify its IT infrastructure. Among the plethora of events logged, IDs 4625 and 4771 are particularly vital in tracking failed authentication attempts. This article provides an in-depth analysis of these event IDs, exploring their significance in uncovering security threats and vulnerabilities through Windows Event Log analysis.

Understanding Windows Event ID 4625

Event ID 4625 indicates a failed logon attempt. This event is crucial for identifying unauthorized access attempts against Windows systems. It chronicles details about the failure, including the user account involved, the type of authentication, and the source of the logon request.

Key Components of Event ID 4625

When analyzing Event ID 4625, you will encounter several key fields within the event log:

• Subject: Contains information about the account that attempted the logon.

• Logon Type: Indicates the type of logon attempt; it can be interactive, network, batch, etc.

  • Common logon types include:

    • 2: Interactive logon

    • 3: Network logon

    • 10: Batch logon

• Status: Provides a status message detailing why the logon failed.

• Source Network Address: Shows the IP address from which the logon attempt was made.

Example of Event ID 4625 Log Entry

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     - 
    Logon ID:           0x0

Logon Type:             3
Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       Admin
    Account Domain:     DOMAIN

Failure Information:
    Failure Reason:      Unknown user name or bad password
    Status:             0xC000006D
    Sub Status:         0xC000006A

Network Information:
    Workstation Name:    WORKSTATION
    Source Network Address: 192.168.1.10
    Source Port:        12345

Process Information:
    Caller Process ID:   1234
    Caller Process Name: C:\Windows\System32\svchost.exe

Understanding Windows Event ID 4771

Event ID 4771 pertains to Kerberos pre-authentication failures. This event is crucial in environments that utilize Kerberos for authentication, particularly in domain environments.

Key Components of Event ID 4771

When delving into Event ID 4771, the following components are essential for accurately interpreting the event:

• Account Name: Indicates the account for which pre-authentication failed.

• Pre-Authentication Type: Specifies the mechanism used for authentication.

• Failure Code: Provides insights into why the authentication failed.

  • Common failure codes include:

    • 0x18: Pre-authentication failed

    • 0x18: Bad password

• Client Address: Shows the IP address from which the authentication request originated.

Example of Event ID 4771 Log Entry

Kerberos pre-authentication failed.

Account:
    Security ID:        DOMAIN\User
    Account Name:       User
    Account Domain:     DOMAIN

Client Address:     192.168.1.50
Service Name:       krbtgt/DOMAIN

Pre-Authentication Type: 
    0x0 (none)

Failure Code:       0x18

Importance of Monitoring Event IDs 4625 and 4771

Monitoring these event IDs is crucial for maintaining robust network security. Here’s why:

• Identifying Brute Force Attacks: A spike in Event ID 4625 occurrences can indicate a brute force attack on user accounts. Organizations should implement alerting mechanisms when a certain threshold is exceeded.

• Vulnerability Situations: Event ID 4771 may hint at compromised user credentials or configurations that need to be addressed, particularly focusing on accounts with pre-authentication failures.

• Security Audits and Compliance: Regular audits of these events are essential for compliance with security protocols and regulations. Documentation and analysis can help mitigate risks.

Best Practices for Mitigation

To protect against the risks highlighted by these event IDs, consider the following best practices:

• Implement Account Lockout Policies: Set policies that lock an account after a specific number of failed attempts to prevent unauthorized access.

• Monitor and Analyze Logs Regularly: Establish a routine for reviewing event logs, focusing on patterns of failure that may indicate potential attacks.

• Enable Multi-Factor Authentication (MFA): Enhance security by requiring additional verification for users, reducing the possibility of compromised credentials.

Conclusion

Windows Event IDs 4625 and 4771 serve as critical indicators within the Windows security log that aid in identifying failed authentication attempts and proactively managing security threats. By diligently monitoring these events, organizations can strengthen their security posture and reduce vulnerabilities associated with unauthorized access. Leveraging the information gathered from these logs can be instrumental in not just defending against current threats but also anticipating future risks in an ever-evolving cybersecurity landscape.

For comprehensive security management, consider integrating a Security Information and Event Management (SIEM) solution to gather insights and respond to anomalies in real-time. This proactive approach is vital to ensuring sustained compliance and security integrity.

Suggested Articles

4625: An account failed to log on

On this page

• Description of this event
• Field level details
• Examples

This is a useful event because it documents each and every failed attempt to logon to the local computer regardless of logon type, location of the user or type of account.

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
4625

Subject:

Identifies the account that requested the logon — NOT the user who just attempted logged on. Subject is usually Null or one of the Service principals and not usually useful information. See New Logon for who just logged on to the system.

• Security ID
• Account Name
• Account Domain
• Logon ID

Logon Type:

This is a valuable piece of information as it tells you HOW the user just logged on:  See 4624 for a table of logon type codes.

Account For Which Logon Failed:

This identifies the user that attempted to logon and failed.

• Security ID:  The SID of the account that attempted to logon. This blank or NULL SID if a valid account was not identified — such as where the username specified does not correspond to a valid account logon name.
• Account Name: The account logon name specified in the logon attempt.
• Account Domain: The domain or — in the case of local accounts — computer name.

Failure Information:

The section explains why the logon failed.

• Failure Reason: textual explanation of logon failure.
• Status and Sub Status: Hexadecimal codes explaining the logon failure reason. Sometimes Sub Status is filled in and sometimes not. Below are the codes we have observed.

Process Information:

• Caller Process ID: The process ID specified when the executable started as logged in 4688.
• Caller Process Name: Identifies the program executable that processed the logon. This is one of the trusted logon processes identified by 4611.

Network Information:

This section identifies where the user was when he logged on. Of course if logon is initiated from the same computer this information will either be blank or reflect the same local computers.

• Workstation Name: The computer name of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. Workstation may also not be filled in for some Kerberos logons since the Kerberos protocol doesn’t really care about the computer account in the case of user logons and therefore lacks any field for carrying workstation name in the ticket request message.
• Source Network Address: The IP address of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. If this logon is initiated locally the IP address will sometimes be 127.0.0.1 instead of the local computer’s actual IP address.  This field is also blank sometimes because Microsoft says «Not every code path in Windows Server 2003 is instrumented for IP address, so it’s not always filled out.»
• Source Port: Identifies the source TCP port of the logon request which seems useless since with most protocols’ source ports are random.

Detailed Authentication Information:

• Logon Process: (see 4611)
• Authentication Package: (see 4610 or 4622)
• Transited Services: This has to do with server applications that need to accept some other type of authentication from the client and then transition to Kerberos for accessing other resources on behalf of the client.  See http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/
• Package name: If this logon was authenticated via the NTLM protocol (instead of Kerberos for instance) this field tells you which version of NTLM was used.  See security option «Network security: LAN Manager authentication level»
• Key Length: Length of key protecting the «secure channel».  See security option «Domain Member: Require strong (Windows 2000 or later) session key».  If value is 0 this would indicate security option «Domain Member: Digitally encrypt secure channel data (when possible)» failed

Supercharger Enterprise

Картинка с сайта: www.ultimatewindowssecurity.com

If you’ve ever managed a Windows system, you’ve likely come across Event ID 4625: “An account failed to log on.” It often pops up on Windows Server 2008 and Windows Vista systems, causing both confusion and concern. This event occurs when a logon attempt fails, and it’s logged on the targeted computer. Let’s dive into the nitty-gritty details to understand this better.

Картинка с сайта: bytebitebit.com

For instance, imagine someone in your network trying to access a shared folder but typing the wrong password. This would trigger Event ID 4625. One of the critical pieces of information in this event is the Security ID (SID), which identifies the user account that attempted the logon. If the SID can’t be resolved, it might show up as a NULL SID, indicating that the username doesn’t correspond to a valid account.

To troubleshoot this, we often use Task Scheduler. We go to the “Task Status” pane and filter for tasks running at specific times, especially around the time this event crops up regularly. By checking these logs, we can pinpoint which tasks might be causing the issue. So next time you see Event ID 4625, don’t panic. It’s a valuable alert that helps keep your network secure!

Event ID 4625 is a log entry in the Windows Security Log that indicates a failed logon attempt. Let’s break down what this event tells us.

When we see Event ID 4625, it typically means a logon request didn’t succeed. This can be due to various reasons such as wrong passwords or user accounts trying to access a network.

Here are the key details you might find:

Security ID: Shows which account reported the logon failure. Sometimes, it will display as NULL SID if no valid account was identified.

Logon Process: Indicates the specific process attempting the logon, like Winlogon.exe or Services.exe.

Authentication Package: Displays which package was used, such as NTLMSSP.

Transited Services: If the logon attempt used services, they might be listed here.

We can use a table to present more information clearly:

Authentication Information: This might show details like the Key Length used during the attempt, which is relevant for security analysis.

Category and Subcategory

These help in classifying the type of security event recorded. Microsoft-Windows-Security-Auditing is the category under which Event ID 4625 falls.

Our experience shows that frequently encountering Event ID 4625 might indicate an ongoing brute force attack. Always ensure your systems are up-to-date and secure. If it appears frequently at the same time each day, as mentioned in the search results, it might be caused by a scheduled task or an automated process.

We hope this breakdown is helpful in understanding and analyzing Event ID 4625. It’s crucial for maintaining security and identifying potential issues early.

Common Causes of Event ID 4625

Event ID 4625 often pops up when a logon attempt fails. It’s like our computer’s way of waving a red flag saying, “Hey, something went wrong here!” Let’s break down some common reasons:

Bad Password: We all forget passwords sometimes. Typing the wrong password is a frequent cause.

Unknown User Name: Sometimes, a user might use a name that doesn’t exist on the system.

Disabled Account: If the account is disabled, any logon attempt will fail.

Account Locked Out: If an account gets too many wrong password attempts, it can be locked out. We’ve all been there, right?

Account Currently Disabled: If administrators disable an account for any reason, it will throw event 4625.

Service Failures: Occasionally, services like Server service or Winlogon.exe on the local system might trigger this event when they attempt to authenticate a user.

Network Issues: Problems with network connectivity can also cause authentication failures.

These are some of the main culprits behind Event ID 4625. We’ve likely faced some of these ourselves, making it easier to spot when they happen again.

Troubleshooting Event ID 4625

Event ID 4625 in the Microsoft-Windows-Security-Auditing log indicates a failed logon attempt. This can occur due to various reasons, such as incorrect passwords, account lockouts, or policy conflicts. Let’s walk through some key steps.

Checking User Account Status

We start by examining the user account related to the failed logon.

• Account Lockouts: Is the account locked out? A locked account can’t log in until it’s unlocked by the system or admin.

• Logon ID: Check the Logon ID to identify the specific session of the attempt.

• Caller Process ID and Name: These fields help us find which processes attempted the logon. For instance, Winlogon.exe might point to login screen issues.

Reviewing Security Policies

Next, we review relevant security policies to ensure they’re correctly configured.

• Account Lockout Policy: Define how many failed attempts trigger a lockout and how long the lockout lasts.

• Audit Policy: Make sure it logs Account Logon and Logon events so we can track failures.

• Network Security: Evaluate protocols and settings in our network policies that might deny valid logons. The Source Network Address and Source Port fields in the event can reveal where the attempt came from.

Investigating Failed Logon Attempts

Finally, let’s investigate the failed logons.

• Failure Reason and Sub Status: These codes detail why the logon failed. For example, wrong password or expired account.

• Workstation Name: This shows which machine the attempt came from, helpful for isolating issues in a network.

• Source Network Address and Source Port: Useful in tracing attempts from unknown or unauthorized addresses.

• Active Directory and Domain Controller: In large networks, check AD for replication issues or policy conflicts affecting logons. The local computer might not sync properly with the domain.

Mitigating Security Risks Associated with Event ID 4625

Mitigating security risks related to Event ID 4625 requires a multi-layered approach. By focusing on password policies, implementing multi-factor authentication, and setting up monitoring systems, we can significantly reduce the risks posed by failed logon attempts.

Strengthening Password Policies

We need to make sure our passwords are tough to crack. Simple passwords make it easier for attackers to guess them.

Make sure to enforce a minimum password length, like 12 characters. Frequent password changes can discourage attackers. Remember, layers of security make our accounts more secure.

Implementing Multi-Factor Authentication

Adding an extra layer of security helps a ton. Multi-Factor Authentication (MFA) is one way to do this.

Integrating MFA across our services protects sensitive data, reducing the risk of a successful attack.

Monitoring and Alerting Systems

Monitoring systems help us detect weird activities fast. Real-time alerts allow us to react quickly to potential threats.

We can use tools like PowerShell to filter specific logs and quickly identify problems. Setting up a robust monitoring system helps us stay on top of our network security processes.