Вход в личный кабинет Eventid 4740: событие блокировки учетной записи
В первую очередь администратору нужно разобраться с какого компьютера/сервера домена происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO рольюэмулятора PDC (именно он отвечает за обработку блокировок учетных записей).
Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Accountlockoutthreshold, учетная запись пользователя временно блокируется.
При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:
(Get-AdDomain).PDCEmulator
Irp-система штатными средствами windows
Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий – мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.
Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку.
В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер.
При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.
Xpath-запросы
Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации – Log Management и SIEM-системы).
Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала».
Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.
Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.
Приведем несколько полезных XPath запросов с комментариями.
Аудит доменных служб active directory в windows server 2008 r2
ИТ среда не является статичной. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных.
Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее.
Аудит изменений стал неотъемлемой частью управления ИТ инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает.
Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям.
Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.
Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2.
Как определить программу, из которой блокируется учетной запись пользователя?
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь нужно понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля. Чаще всего это значит, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространенные места, в которых пользователь мог сохранить свой старый пароль:
Мгновенное оповещение.
Чем хороши мгновенные оповещения, так это тем, что нет необходимости постоянно проверять почту на предмет новых сообщений — сообщения приходят сами и дают о себе знать сразу же (В зависимости от настроек клиента, конечно же).
Лично для себя я сделал, чтобы сообщения открывались поверх всех окон. Конечно, чтобы не заспамит самого себя, такие оповещения отправляются на критически важные события.
К критически важным я отнес: неудачные попытки входа на контролеры домена, неудачные попытки входа на сервис VPN (PPTP на WIndows). Так же добавил эту функцию в скрипты мониторинга за AD. Т.к. у меня доступ к AD имеют несколько человек, то со временем можно потерять нить актуальных данных (что-то, когда-то, кого-то удалил/переместил/добавил а ты и не в курсе). И данные сообщения будут как раз кстати, чтобы в реальном времени знать об изменениях.
Поиск компьютера/сервера, с которого блокируется пользователь с помощью powershell
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
Поиски решения
Когда мне пришла идея о таком роде оповещения (учитывая тот факт, что у нас в организации достаточно активно используется Jabber-сервис) первое что я сделал, это забил к гугл
. Первой же ссылкой меня отправило на
не безызвестного на просторах форумов
. То что я там увидел меня не могло не порадовать: «А знаете ли вы, что оснастка NetCmdlets, включающая командлеты для работы с огромным количеством сетевых протоколов, доступна совершенно бесплатно для некоммерческого использования?»
И приводится список доступных команд. «Это то что мне нужно, да еще и бесплатно!!!» — подумал я и огорчился когда прошел на сайт разработчика этой оснастки командлетов, оказывается у них нет бесплатной версии, есть только триальная на 1 месяц, после чего нужно вновь запрашивать ключ. Только после этого я обратил внимание на дату статьи, она оказалась 2008 года – старовата :(.
Ради эксперимента скачал триальную версию. Установил на сервер, на котором хочу использовать оповещения. Установка прошла на УРА. Сразу же стали доступны новые коммандлеты. Синтаксис у них довольно простой и с отправкой сообщений проблем не возникло.
Какое-то время я так и использовал эту триальную лицензию, раз в месяц ее перерегистрировав. Но само ощущение, что используешь триальную версию меня угнетало, еще больше угнетал тот факт, что необходимо ее каждый месяц регистрировать для каждого сервера, где она установлена.
Когда со временем стало посвободнее, я решил добить эту идею. Необходимо было средство, позволяющее посредством Powershell, отправлять сообщения, используя протокол XMPP. При этом важным фактором должно быть условия использования данного средства — оно должно быть бесплатным.
Я снова начал мучать гугл. И мои усилия не пропали даром. В один прекрасный клик я попал на страничку с утилитой, которая как раз таки позволяет отправлять сообщения из PS-консоли, используя XMPP-протокол.Особенно меня порадовала надпись, красующаяся в заголовке страницы:
Политики аудита windows
Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.
Категория аудита | Подкатегория аудита | События аудита | EventID | Комментарии |
Вход учетной записи | Аудит проверки учетных данных | Успех, Отказ | 4776 | Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации. |
Аудит службы проверки подлинности Kerberos | Успех, Отказ | 4771 | Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации. | |
4768 | Запрос билета Kerberos, при этом следует анализировать коды ответа сервера. | |||
Примечание: Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%debugnetlogon.log | ||||
Управление учетными записями | Аудит управления учетными записями компьютеров | Успех | 4741 | Заведение устройства в домен Active Directory; может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию может завести в домен 10 устройств, на которых может быть установлено неконтролируемое компанией ПО, в том числе вредоносное. |
Аудит управления группами безопасности | Успех, Отказ | 4728 | Добавление члена глобальной группы. | |
4732 | Добавление члена локальной группы. | |||
4756 | Добавление члена универсальной группы. | |||
Аудит управления учетными записями пользователей | Успех, Отказ | 4720 | Создание учетной записи. | |
4725 | Отключение учетной записи. | |||
4740 | Блокировка учетной записи. | |||
4723 | Смена пароля. | |||
4724 | Сброс пароля. | |||
Подробное отслеживание | Аудит создания процессов | Успех | 4688 | При создании процесса. |
4689 | При завершении процесса. | |||
Примечание: Чтобы для командного интерпретатора велась запись введенных команд, следует включить политику «Конфигурация компьютера – Конфигурация Windows – Административные шаблоны – Система – Аудит создания процессов -> Включать командную строку в события создания процессов». Примечание: Чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге «Конфигурация компьютера – Конфигурация Windows – Административные шаблоны – Компоненты Windows – Windows PowerShell» политики «Включить ведение журнала модулей» (в настройках политики указать все модули символом «*») и «Включить регистрацию блоков сценариев PowerShell» (в настройках политики отметить check-box «Регистрация начала или остановки вызова блоков сценариев»). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell. | ||||
Вход/выход | Аудит выхода из системы | Успех | 4634 | Для неинтерактивных сессий. |
4647 | Для интерактивных сессий и RDP-подключений. | |||
Примечание: При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). | ||||
Аудит входа в систему | Успех, Отказ | 4624 | При успешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации. | |
4625 | При неуспешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771. | |||
4648 | При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе «хакерской» утилиты Mimikatz. | |||
Примечание: При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа – несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д. | ||||
Аудит других событий входа и выхода | Успех, Отказ | 4778 | RDP-подключение было установлено. | |
4779 | RDP-подключение было разорвано. | |||
Аудит специального входа | Успех | 4672 | При входе с административными полномочиями. | |
Доступ к объектам | Аудит сведений об общем файловом ресурсе | Успех, Отказ | 5145 | При доступе к системных сетевым ресурсам, таким как \C$ . Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети. |
Аудит других событий доступа к объектам | Успех, Отказ | 4698 | При создании задания в «Планировщике задач», что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе. | |
Изменение политики | Аудит изменения политики аудита | Успех | 4719 | Изменение политики аудита. |
4906 | Изменение настройки CrashOnAuditFail. | |||
Примечание: Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге «Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Параметры безопасности» в политике «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности». | ||||
Система | Аудит расширения системы безопасности | Успех | 4610 4614 4622 | При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно. |
4697 | При создании нового сервиса, что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе. | |||
Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Параметры безопасности» политику «Сетевая безопасность:
ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя.
Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.
Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра – следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.
Политики аудита входа на dc
Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:
- Audit Account Lockout
- Audit Logon
- Audit Logoff
Проще всего включить эту политику через консоль gpmc.msc, отредактировав политику DefaultDomainControllerPolicy, либо на уровне всего домена с помощью Default Domain Policy.
Политики блокировки учетных записей в домене
Политики блокировки учетных записей и паролей обычно задаются сразу для всего домена политикой DefaultDomainPolicy в консоли gpmc.msc. Интересующие нас политики находятся в разделе ComputerConfiguration ->
WindowsSettings -> SecuritySettings -> AccountPolicy -> AccountLockoutPolicy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политики:
- Accountlockoutthreshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована;
- Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически);
- Reset account lockout counter after (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации.
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Чтобы решить проблему самопроизвольной блокировки учетной записи пользователя, администратору нужно разобраться с какого компьютера и какой программой была заблокирован аккаунт пользователя Active Directory.
Рекомендации.
Именно подобные скрипты у меня работают на VPN-сервере и на всех контролерах домена.
Теперь я всегда знаю, когда и кто подключается к VPN, например. Или когда кто-то пытается подобрать пароль на доступ к серверу.
Так же рекомендую навесить такой скрипт на те сервисы, которые «светятся» в Интернет, к примеру службы терминального доступа.
А запись в отдельный файл, позволит Вам, в будущем, проанализировать подключения. Лог, кстати говоря, можно открыть через табличный редактор (MS Excel или OO Calc) и уже работать с логом как с таблицей (сортировать, фильтровать и т.д.).
Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен.
Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.
Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:
Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
The referenced account is currently locked out and may not be logged on to ….