Microsoft windows security auditing special logon

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

Картинка с сайта: www.anti-malware.ru

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Картинка с сайта: www.anti-malware.ru

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

Картинка с сайта: www.anti-malware.ru

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

Картинка с сайта: www.anti-malware.ru

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

Картинка с сайта: www.anti-malware.ru

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

Картинка с сайта: www.anti-malware.ru

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Картинка с сайта: www.anti-malware.ru

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

Картинка с сайта: www.anti-malware.ru

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

Картинка с сайта: www.anti-malware.ru

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

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Картинка с сайта: www.anti-malware.ru

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

Картинка с сайта: www.anti-malware.ru

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

Картинка с сайта: www.anti-malware.ru

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Картинка с сайта: www.anti-malware.ru

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

Картинка с сайта: www.anti-malware.ru

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

Картинка с сайта: www.anti-malware.ru

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Картинка с сайта: www.anti-malware.ru

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Картинка с сайта: www.anti-malware.ru

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Здравствуйте, я не очень продвинутый пользователь. Недавно, заметил, мерцающие и исчезающие окна при работе на ноутбуке. Похоже, на командную строку, быстро исчезают. Если, что-то пишу в документе или еще что-то делаю, происходит прерывание и т.д., на очень короткий срок.

Пользователь один с паролем. Система W10.

Нашел события, посмотрев в интернете, не смог разобраться.

Просмотр событий — Журналы Windows — Безопасность

4672 Special Logon

4624 Logon

Насчитал 24 раза Special Logon и Logon за последний час, само мерцающее окно, заметил пару раз.

Спасибо за помощь!

С появлением Windows Server 2008 и Windows Vista произошли существенные изменения в аудите Windows Server и журнале событий безопасности. И очень обнадеживает, что большинство перемен — положительные. Журнал Security стал немного аккуратнее и понятнее, но, чтобы в нем разобраться, все же требуются некоторые знания о мерах безопасности Windows и опыт диагностики. Последние десять лет я занимался исследованием механизмов безопасности и аудита Windows, а с некоторых пор углубился в Windows 2008 и Vista и могу сообщить полезные сведения об измененной кодировке событий, новых, более детализированных способах обработки политики аудита, формате XML-журнала и усовершенствованиях в оснастке Event Viewer консоли Microsoft Management Console (MMC).

Новые коды событий

Администраторы, знакомые с журналом Windows Security, в первую очередь заметят отсутствие привычных кодов событий (ID) в программе просмотра событий Windows 2008. То есть как раз в то время, когда наконец-то удалось запомнить разницу между событиями ID 528 и ID 529, Microsoft изменила коды. На самом деле многие события Windows Server 2003 сохранились, но их номера увеличились на 4096. Например, событие с ID 528 в Windows 2003 стало событием с ID 4624 в Windows 2008.

В сущности, не так уж плохо, что все коды событий изменены, так как специалисты Microsoft полностью переработали все поля в описании каждого события. В Windows 2003 были сохранены коды событий, унаследованные от Windows 2000 Server, но изменились события, которым они соответствовали; некоторые события были объединены, и изменился порядок полей в описаниях. Это привело к путанице в программах автоматического анализа журналов. Благодаря новой нумерации можно разместить на предприятии компьютеры Windows 2008 и собирать журналы, не меняя существующих фильтров, предупреждений и определений в отчетах. Нужно лишь добавить определения для новых кодов событий.

Подкатегории политики аудита

Пользователи часто спрашивают, как можно помешать Windows записывать в журнал Security много бесполезной информации, из-за которой трудно найти важные события. Невозможно настроить журнал Windows Security так, чтобы избавиться от шума; это задача для системы управления журналами.

Компания Microsoft сделала небольшой шаг навстречу администраторам, позволив уменьшить поток лишней информации. Это сделано не так, как предпочел бы я, — с помощью набора правил, аналогичного для брандмауэра, в котором определены критерии отбора записываемых событий для каждого кода. Вместо этого компания Microsoft увеличила число политик аудита (категорий) с 9 в Windows 2003 до 52 в Windows 2008.

В сущности, 9 существующих категорий сохранились, но были разбиты на подкатегории, каждую из которых можно активизировать для удачного и/или неудачного события. При желании политикой аудита можно управлять с использованием 9 категорий верхнего уровня. На экране 1 показаны 9 категорий и 52 подкатегории. По адресу http://www.ultimatewindowssecurity.com/newauditpol  приведена таблица деления 9 категорий на подкатегории и дано краткое описание событий и действий, отслеживаемых с помощью каждой категории.

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

Все вышеизложенное настраивает на оптимистический лад. С помощью более детализированной политики аудита можно исключить старые бесполезные события и некоторые новые события, добавленные в Windows 2008, среди которых тоже много избыточных. Например, большинство администраторов предпочтет отключить подкатегории Filtering Platform Packet Drop и Filtering Platform Connection, которые выдают очень много лишних событий, поскольку записывают сетевой трафик на уровне пакетов.

Однако не все новости приятные: политиками аудита нельзя управлять на уровне подкатегорий с использованием групповой политики. Компания Microsoft добавила 52 новые подкатегории, но не дополнила групповую политику новыми политиками, чтобы включать или отключать подкатегории. Кстати, подкатегории недоступны из интерфейса пользователя. Единственный способ включать и выключать события на уровне подкатегорий обеспечивает команда Auditpol. В статье Microsoft «Security auditing settings are not applied to Windows Vista client computers when you deploy a domain-based policy» (http://support.microsoft.com/kb/921468 ) описан метод настройки подкатегорий аудита через сценарии запуска, определенные с помощью групповых политик, но этот способ довольно неуклюжий.

Работаем с политикой аудита

Познакомимся поближе с командой Auditpol и способами разрешения возможных конфликтов между политикой аудита, настроенной в объектах групповой политики (GPO), и политикой подкатегории, заданной с использованием Auditpol. Чтобы выяснить текущее состояние 52 подкатегорий аудита, достаточно обратиться к нужному компьютеру и ввести команду

auditpol /get /category:*

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

Чтобы изменить аудит для подкатегории, достаточно запустить команду auditpol с параметром /set, указать подкатегорию и включить или выключить успешные события и/или отказы. Например,

auditpol /set

/subcategory: «System Integrity»

/failure:enable /success:enable

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

Что происходит, если политики аудита для 9 категорий верхнего уровня, настроенные в использованием групповой политики, конфликтуют с политиками, назначенными для 52 подкатегорий в Auditpol, или наоборот? Например, компьютер W08-YHWH расположен в организационной единице (OU) Servers в Active Directory (AD). Администратор изменяет объект GPO, связанный с этой OU, отключая категорию верхнего уровня Audit logon events (или Logon/Logoff) как для успешных событий, так и для неуспешных. Затем администратор регистрируется на компьютере W08-YHWH и включает подкатегорию Logon для успешных и неуспешных событий с помощью команды Auditpol. Каким будет результат?

По умолчанию, если определить значение для одной из 9 категорий верхнего уровня в локальной политике безопасности компьютера или в применяемом объекте GPO, политика верхнего уровня будет иметь приоритет перед настройками на уровне подкатегорий. По умолчанию политики подкатегорий в Windows действуют только в тех случаях, если категория верхнего уровня не определена в локальной политике безопасности и всех объектах GPO. Необходимо подчеркнуть, что таков порядок по умолчанию, так как в редакторе Group Policy Object Editor (GPE), в разделе Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options, появился новый параметр с названием Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Будучи активизирован, параметр изменяет порядок применения политики аудита на противоположный, и любые настройки подкатегорий, сделанные с помощью Auditpol, отменяют 9 политик верхнего уровня, заданные с использованием групповой политики.

Трудно представить, каким образом компания Microsoft выпустила Vista и тем более Windows 2008, не обеспечив управление этой чрезвычайно важной областью безопасности через групповую политику, но тем не менее это произошло. А решение, предложенное в упомянутой выше статье Microsoft, ненадежно и подвержено сбоям. Кроме того, поразительно, что невозможно применить команду Auditpol к удаленным компьютерам; она действует только локально.

Как бы то ни было, в качестве отправной точки при формировании политики аудита на верхнем уровне рекомендуется включить System, Policy Change, Logon/Logoff, Account Logon, Account Management и, на контроллерах домена (DC), DS Access, что позволит отслеживать важные изменения в организационных единицах и объектах GPO. Активизация этих категорий для успешных событий и отказов позволит собрать наиболее важные сведения, исключив основные источники избыточной информации, такие как Privilege Use и Object Access. Если требуется выполнить аудит системных файлов, включите подкатегорию File System категории Object Access.

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

Выборочное отключение подкатегорий позволяет исключить лишние события. Чтобы найти и подтвердить отменяемые подкатегории, нужно отыскать избыточные события в программе просмотра событий и определить имя их подкатегории (Task Category в программе просмотра событий). Прежде чем отключить подкатегорию, убедитесь, что не нуждаетесь в других событиях, принадлежащих этой подкатегории и типу успех/отказ. Принять решение проще, если отфильтровать записи журнала в программе просмотра событий, показав только события данной подкатегории. Кроме того, список событий каждой категории приведен в бесплатной энциклопедии Windows Server 2008 Security Log Encyclopedia по адресу http://www.ultimatewindowssecurity.com/encyclopedia.apx . Если в подкатегории нет важных событий для данного типа успех/отказ, то отключите подкатегорию для успешных событий, отказов или событий обоих типов (в зависимости от конкретной ситуации).

Не забудьте: чтобы настройки подкатегории вступили в силу, требуется изменить параметр групповой политики Audit: Force audit policy subcategory settings (в Windows Vista и более поздних версиях), отменив настройки категории политики аудита, как описано выше.

Формат событий

Компания Microsoft использует новый формат событий в Windows 2008. Изменен как физический формат файла журналов событий Windows, так и логические поля, которые составляют каждое событие, пересылаемое в журнал. Энтузиасты XML найдут XML-схему для журналов событий по адресу http://schemas.microsoft.com/win/2004/08/events/event ; в остальном новый формат мало затрагивает интересы администраторов. Для программистов, работающих с журналами событий, в Windows сохранены старые интерфейсы Win32 Event API; познакомиться с новыми можно по адресу http://msdn2.microsoft.com/en-us/library/aa382610.aspx .

Гораздо важнее логический формат событий (представленный в окне свойств события программы просмотра событий). На экране 2 показано событие с ID 4625. В каждом событии по-прежнему есть несколько стандартных полей и текстовое описание. В стандартных полях содержится информация, применимая к любому событию, независимо от его кода, в том числе сведения о дате и времени, источнике, категории и результате — успех/отказ. Сообщение и данные в текстовом описании различны у событий с разными кодами.

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

An account was successfully logged on.

Subject:

Security ID:	SYSTEM
Account Name:	WIN-K2SF4WMIK17$
Account Domain:	ACME
Logon ID:	0x3e7

Таким образом, концепция стандартных полей и индивидуального описания события осталась прежней. Изменились отдельные стандартные поля и вставляемые строки для событий с разными кодами. Сравните событие с ID 4625 (экран 2) с его предшественником, событием ID с 529 в Windows 2003 (экран 3). Понять большинство изменений стандартных полей нетрудно, например замену Date and Time на Logged, но в некоторых случаях необходимы дополнительные пояснения. Во-первых, обратите внимание, что в событиях Windows 2008 не отображается старая категория верхнего уровня, так как в Windows 2008 категории аудита верхнего уровня относятся только к политике аудита (т.е. записываются или нет события с данными кодами). События, записываемые в журнал Windows 2008, распределяются по подкатегориям, именуемым Task Category, в программе просмотра событий. Очевидно, разработчикам показалось слишком скучным согласовывать команду Auditpol с использованием Subcategory.

Type больше не существует. Вместо него появились Level и Keywords. Похоже, все события в журнале безопасности имеют уровень Information и ключевое слово Audit Failure или Audit Success.

Значительно изменились описания событий. Windows 2008 вставляет в описания много динамических значений, и компания Microsoft обеспечила некоторый уровень единообразия в описаниях событий с различными кодами. Описания событий — хороший пример того, как благодаря продуманной XML-схеме упрощается обработка записей данных со схожей структурой, но динамическими изменениями между экземплярами.

В описаниях многих событий есть общие элементы данных. Например, почти каждому событию необходимо записывать информацию о субъекте («кто»). Как показано из экране 2 и следует из сказанного выше, в информацию о субъекте входят SID, имя учетной записи, домен и код регистрации. Исторически внесение этой информации для различных событий не было унифицировано в Windows. Данные порой пропускались или отмечались разными способами.

В качестве примера сравните данные о субъекте в событиях Account Logon операционной системы Windows 2003. Имя учетной записи отмечено несколькими способами, и в некоторых событиях часть данных отсутствует.

В Windows 2008 появилось несколько общих разделов для большинства событий, в частности уже упомянутый раздел Subject. События, которые отслеживают действия с объектами определенного типа, например доступ к файлу, располагают разделом Object со всеми полями, необходимыми для идентификации объекта, такими как тип и полное имя объекта. Во всех событиях, которые отмечают участие системного процесса, есть раздел Process Information, содержащий идентификатор процесса (PID) и имя исполняемого файла.

И наконец, в нижней части некоторых описаний расширен пояснительный текст о событии или значениях, приведенных в описании. Однако дополнительные сведения имеются не везде и часто неполны. Энциклопедия Security Log Encyclopedia по-прежнему пригодится администраторам.

Новая программа просмотра событий

Новая оснастка Event Viewer консоли Microsoft Management Console (MMC) все еще не стала полноценным решением для управления журналами событий, но гораздо лучше подходит для беглого просмотра событий безопасности.

Первая примечательная особенность Event Viewer — новая панель задач (справа на экране 4), благодаря которой существенно уменьшается число щелчков при выполнении типовых задач, таких как установка и последующее удаление фильтра. Event Viewer располагает теми же основными фильтрами для журнала безопасности, что и в прошлом, но с рядом улучшений.

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

В результате щелчка на Filter Current Log в панели задач появляется окно, показанное на экране 5. В раскрывающемся поле Logged гораздо проще определить временной диапазон анализа, указав периоды Last hour, Last 12 hours, Last 24 hours, Last 7 days, Last 30 days и, конечно, пользовательский диапазон Custom. Это значительное улучшение по сравнению с Windows 2003 и прежними версиями, в которых требовалось указать точную дату и период времени.

Представление можно ограничить успешными событиями или отказами с помощью раскрывающегося поля Keywords и фильтровать события по подкатегориям с использованием раскрывающегося поля Task category. Поле Task category не заполнено 52 подкатегориями аудита до тех пор, пока не выбран пункт Microsoft Windows security auditing в раскрывающемся списке Event sources. Чтобы увидеть результаты применения фильтра, достаточно нажать OK.

Удачное новшество: после того как фильтр настроен, его можно сохранить для дальнейшего использования с помощью функции Save Filter to Custom View в панели задач. В диалоговом окне Save Filter to Custom View нужно ввести имя, описание и местонахождение в папке Custom Views (экран 4).

Впервые с помощью Event Viewer легко связать события с задачами, которые автоматически выполняются при возникновении события. Предположим, старшим руководителям компании выделен специализированный сервер Microsoft SharePoint. Администратора необходимо уведомлять обо всех случаях блокирования учетной записи, чтобы помочь руководителю получить доступ к серверу с минимальными неудобствами (по крайней мере, для руководителя). Можно передавать сообщение по электронной почте, выводить его на консоль или запускать команду или сценарий всякий раз при возникновении события блокировки учетной записи.

Самый простой способ связать задачу с событием — выбрать нужное событие в Event Viewer и щелкнуть на функции Attach Task To This Event в панели задач. При этом запускается мастер Create Basic Task. Мастер запрашивает имя задачи и просит определить программу, сообщение электронной почты или экранное сообщение. По окончании работы мастера можно просмотреть событие, его свойства и историю, открыв оснастку Task Scheduler консоли MMC, которая находится в меню StartAll ProgramsAccessoriesSystem Tools.

Однако нередко необходим более точный критерий срабатывания, нежели простое указание кода события. К счастью, любой критерий, который можно задать в фильтре специального представления, можно указать и в триггере события. Это относится и к сложным фильтрам, составленным на языке XML. К сожалению, триггер нельзя построить в программе просмотра событий, необходимо использовать планировщик задач. Откройте планировщик задач и щелкните на Create Task. Укажите имя и описание события, а также учетную запись для выполнения задачи на вкладке General.

Затем требуется выбрать вкладку Trigger и нажать кнопку New. В диалоговом окне New Trigger выберите пункт On an event из раскрывающегося списка Begin the task. Выберите Custom из раскрывающегося поля Settings и щелкните New Event Filter. На экране появляется то же диалоговое окно, что и при создании специального представления в Event Viewer. Можно указать критерий фильтра на вкладке Filter или построить сложный фильтр с использованием синтаксиса XML на вкладке XML. После того как критерий запуска готов, можно перейти на вкладку Actions и указать одно или несколько действий, выполняемых планировщиком задач.

Еще одно достоинство Event Viewer — обновленные параметры политики сохранения журналов, которые отображаются, когда пользователь открывает свойства журнала безопасности. Старый параметр Overwrite events older than…days заменен на Archive the log when full, do not overwrite events, который открывает доступ к функции, существовавшей давно, но прежде доступной только через раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLogServiceAutoBackupLogFiles. Если выбрать режим Archive the log when full option, то журнал безопасности автоматически архивируется в каталоге C:WindowsSystem32winevtLogs.

Предупреждение: Windows продолжит записывать и архивировать события до заполнения диска, поэтому необходимо автоматизировать процесс перемещения журналов. В конечном итоге не существует полноценной замены настоящему решению управления журналами от независимого разработчика. Можно, например, обратиться к статье на сайте журнала Windows IT Pro «Технологии управления журналами событий» (http://www.osp.ru/win2000/2007/06/4473876/ ).

Приступаем к работе

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

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

Еще одно важное новшество, связанное с журналами событий Windows 2008 и Vista, — функция перенаправления событий, благодаря которой в Windows впервые появляется возможность автоматически пересылать события на другие серверы, где теоретически можно централизованно управлять событиями. Сбор журналов из многих компьютеров — гигантская задача, и метод на основе HTTP, применяемый в Windows 2008 для перенаправления событий, годится только для малых массивов событий, определенных очень узкими критериями.

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

Рэнди Франклин Смит (rdsmith@ultimatewindowssecurity.com ) — редактор Windows IT Pro, консультант по вопросам информационной безопасности, главный управляющий компании Monterey Technology Group. Преподает на курсах Ultimate Windows Security и имеет сертификаты SSCP, CISA и MVP

Your Domain Controller’s Windows Event Viewer might be logging tons of security events with strange usernames, misspelled names, attempts with expired or lockout accounts, or strange logon attempts outside business hours— all labeled with the Event ID 4776.

The “Event ID 4776: The computer attempted to validate the credentials for an account” gives you valuable information to help identify the sources of these attempts. Knowing how to troubleshoot and monitor these events can be detrimental to identifying potential brute force dictionary attacks or mal-intentional account uses.

In this post, we’ll go through the technical explanation of what is the Windows Event ID 4776, the details on how to read it, how to troubleshoot or solve the events, and how to monitor and audit using specific software.  

Introduction: What is Windows Event ID 4776

“Event ID 4776: The computer attempted to validate the credentials for an account”

You might have come across the log Event ID 4776 while looking at your event logs in a Domain Controller (DC). This event tells you that this specific DC (but also servers and workstations) was used as a logon server to validate credentials. The event ID 4776 is logged every time the DC tries to validate the credentials of an account using NTLM (NT LAN Manager).

Event ID 4776 is a credential validation event that can either represent success or failure. It is displayed in Windows 2008 R2 and 7, Windows 2012 R2 and 8.1, Windows 2016 and 10, and Windows Server 2019 and 2022.

Note: The Event ID 4776 is not only logged for domain controllers attempting to validate credentials but also for other member Windows servers or workstations used for logon attempts with a local SAM account. This is because the NTLM is the default authentication mechanism for local logon.

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

Let’s go over the details of the Windows Event ID 4776

• The domain controller attempted to validate the credentials for an account.
• Authentication Package: Always "MICROSOFT_AUTHENTICATION_PACKAGE_V1_0"
• Logon Account: name of the account
• Source Workstation: computer name where logon attempt originated
• Error Code: 0x0

Every logon attempt on a domain controller is recorded on the DC. The DC logs the event ID 4776 when it validates the credentials and either succeeds or fails to authenticate a user via NTLM (not Kerberos). In addition, if there was a logon attempt via a local SAM account, where a server or a workstation validates credentials, then the event ID 4776 is logged on the local machine.

The event (as described in the details above) specifies:

• The authentication package specifies the package, which is always “MICROSOFT_AUTHENTICATION_PACKAGE_V1_0”.
• The Logon Account is the account name of the user or computer that attempted to log on. A logon account can also be a well-known security principle.
• The Source Workstation is the client’s computer name (source workstation) used to initiate the logon.
• Error Code The Error Code describes whether the authentication succeeded or failed (and the reasons). If you succeed, you’ll see an 0x0 error code, but if it fails, you’d see something other than 0x0—more on error codes in the next section.

Details on Windows Event ID 4776 Error Code

• Error Code equals (0x0) If this field is 0x0, the credentials were successfully validated as “Authentication Success – Event ID 4776 (S)”. No errors.
• Error Code not equal to (0x0) If the field is not equal to 0x0, it means that the credentials were not successfully validated (failed) “Authentication Failure – Event ID 4776 (F)”. Below is a table with more descriptions of the error code- not equal to 0x0.

Troubleshooting the Windows Event ID 4776

If the Windows Event ID 4776 (S) is successful, you don’t have a problem. However, the problem starts when you get a few to hundreds or thousands of Windows Event ID 4776 (F) failed attempts. Although this would start to look like a problem, let us not draw quick conclusions just yet.

Although the evidence might indicate that your workstation is being a target of a brute force dictionary or rainbow attack, it could also indicate a relatively inoffensive system (such as a printer) is trying to authenticate with expired credentials.

How to solve the Windows Event ID 4776 failed attempts

• Start by identifying the logon account and the source workstation As you learned from the previous section, Event ID 4776 shows you the account name and the source workstation. Remember authentication happens via NTLM, which can help you identify the user or workstation quickly. But still, the source workstation could be attempting to log from outside, carrying a blank name, and also, the account could be random (made up). So, you’ll have to dig deeper.
• If this source workstation is blank or unknown To find out the source of an unknown workstation, you’ll need to involve other tools.
  • Packet Sniffer Use third-party tools such as Wireshark deployed on the DC to capture the traffic at the same time as these events. You’ll need to use capture and display filters on Wireshark to be able to find exactly the source of these events. And also be able to correlate the exact time in Windows Event Viewer with Wireshark when this event happens. In addition, with Wireshark, you can quickly identify IP addresses to start drawing a better picture of where these logons are coming from.
  • Network debugger Another handy third-party tool is a network debugger. Enable the NetLogon debugging utility on your DC. This tool will generate a log file with all these authentication requests. You can review this log file and find out where they originate.
  • DCDiag The DCDiag is a Domain Controller Health Check tool that helps you with troubleshooting. Aside from running different health checks on the DC, the DCdiag also logs additional details like errors, warnings, or informational messages. Use the DCDiag with the verbose output (/v) to expand the output size.

• If a remote client is trying to authenticate using RDP (port 3389) You or the sys admin might have the port 3389 (RDP) open for users that connect remotely to machines inside the domain. When using the RDP, bear in mind that RDP prefers Kerberos to authenticate, but if it fails, it will fall back to using NTLM instead. Thus, this could be a reason you received the Event ID 4776 with an unknown source workstation. Below are a few solutions you can try:
  • Use your firewall One of the most simple solutions is to use the firewall. Instead of using the denylists (allow all block some), use the zero-trust (or whitelists) approach (block all allow some) to only allow authorized attempts originating outside the network.
  • Use a VPN A more advanced and efficient solution is to set up a VPN that allows remote users to connect to the local server and then authenticate normally.

Why should you monitor the Windows Event ID 4776

Always monitor the Windows Event ID 4776 to discover and list all the NTLM authentication attempts in your domain. Look for the events ID 4776 that were initiated by the accounts that are unauthorized or shouldn’t be using NTLM in the first place. Always remember that NTLM should only be used for local logon attempts (this is why you shouldn’t use RDP, but a VPN instead).

The reasons to monitor Event ID 4776:

• Identify relay and cracking attacks The NTLM authentication mechanism is vulnerable to relay attacks (fraudulent interception of information). First and most importantly, NTLM does not support modern cryptographic algorithms like SHA-256 or AES-256. This lack of encryption also makes it vulnerable to offline cracking attacks.
• Find reverse brute force, brute force, or enumeration attacks Monitor the Windows Event ID 4776 and keep track of multiple logon attempts within a short period, and with particular qualities like using multiple incorrect usernames. This type of behavior is strongly related to reverse brute force and enumeration attacks. In a similar case, you can keep track of this event and look for multiple logon attempts with incorrect (or misspelled password) within short periods. This behavior is related to brute-force attacks.
• Find potential malicious intent Keeping track of the Windows Event ID 4776 can help you find logon attempts outside authorized business hours or from unauthorized workstations. If these logon attempts are coming from a high-value account, then it might relate to malicious intent. In addition, logon attempts from locked expired, or disabled accounts could indicate mal-intentional use of resources.

Although it could be optimal to use more secure protocols such as the Kerberos (v5) and avoid these NTLM vulnerabilities, disabling NTLM authentication requests will ultimately hurt productivity and usability. There are still many NTLM authentication requests that need to be verified.

Kerberos is now the preferred authentication method used in Active Directory environments. As a good practice, before using more secure protocols like Kerberos and forcing Windows to limit NTLM traffic, it is first recommended to audit all security logs and events related to NTLM authentication. For these audits, there are a variety of tools you could use.

How to Monitor the Windows Event ID 4776

The Windows Event ID 4776 is a type of event log that should be monitored on an ongoing daily basis. You could use different practices and tools. We recommend knowing first how to properly use the Windows Event Viewer (along with its built-in capabilities) and then expanding to more robust audit tools like the ADAudit Plus.

ManageEngine ADAudit Plus – FREE TRIAL

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

ManageEngine ADAudit Plus is an UBA-driven audit solution for full visibility into Active Directory environments. It provides real-time monitoring, behavior analytics, and reporting. This solution is perfect for monitoring the Windows Event ID 4776, as well as other events like ID 4724, 4726, 4769, 4768, 4740, and more.

Key Features

• Apply granular filters to look for specific threats.
• Get notified via email and SMS.
• Detect abnormal behaviors with UEBA (User and Entity Behavior Analytics).
• Out-of-the-box compliance reports for SOX, HIPAA, PCI, FISMA, GLBA, and the GDPR.

ADAudit Plus is a tool designed to monitor logons, analyze lockouts, and spot changes made to users, groups, OUs, or any Active Directory object. In addition, with the ADAudit Plus, you can also monitor local logons (NTLM), including changes made to users, groups, and security policies on Windows Servers. You can also monitor and audit various aspects within Windows workstations, including active time, changes to local users, security policies, USB activity, and more.

Download a 30-day ADAudit Plus trial, and start monitoring the Windows Event ID 4776, today.

ManageEngine ADAudit Plus
Access a 30-day FREE Trial!

Windows Event Viewer

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

Windows Event Viewer (From Windows Vista 7, Server 2008, and newer versions) allows you to introduce automation by associating a task to a specific event or log. When an event such as the Event ID 4776 is generated, you can associate it with a specific automated task. For instance, you can link it to an email, “Send me an email when Windows Event ID 4776 is generated”.

Windows Event Viewer does have some limitations, especially when it comes to its alerting and reporting engine. For instance, the email won’t give you granular information, such as the type of errors (i.e., attempts from unauthorized workstations, locked accounts, misspelled usernames, or outside business hours). In addition, Event Viewer also does not provide granular filtering capabilities to help you find what you are looking for.

Summary

The Windows Event ID 4776 (Audit Failure) – “The domain controller attempted to validate the credentials for an account” is an important event log that alerts you when a failed authentication event happens through the NTLM. This event log gives you valuable information, such as the workstation name, account, and the system or server used to pass the login request.

A way to solve this type of vulnerability is to audit NTLM authentication on this domain, monitor it, and, if possible, restrict it.

To audit and monitor this event successfully, learn how to use the Windows Event Viewer properly and then expand to more robust audit tools like the ADAudit Plus.

Windows Event ID 4776 FAQs