Объекты отвечающие за вход в систему
Интерактивный диспетчер входа в систему работает в процессе winlogon.exe. Этот диспетчер отвечает за интерактивный вход в систему. Он создает первый пользовательский процесс при входе пользователя в систему.
Пользовательский интерфейс входа в систему работает в процессе logonui.exe. Он предоставляет пользователям интерфейс для аутентификации различными методами. Эти методы зависят от поставщиков учетных данных (CP).
Поставщики учетных данных (CP) – это COM-объекты. Они запускают процесс logonui.exe и могут использовать различные данные для аутентификации пользователя: логин и пароль, PIN-код смарткарты или биометрические данные.
Разница между отключённой, просроченной и заблокированной учётной записью
Данная статья посвящена заблокированным аккаунтом (в английской версии это locked out). Но кроме блокировки аккаунта, возможны следующие причины, почему пользователь не может войти в домен:
- аккаунт отключён
- аккаунт просрочен
- пользователь ограничен определённым временем или компьютером для входа
Отключённые аккаунты (disabled)
Администратор домена может вручную отключить (деактивировать) аккаунт пользователя. Если пользователь отключён, то будет выведено сообщение:
Ваша учётная запись отключена. Обратитесь к системному администратору.
Включение аккаунта выполняется администратором (вручную или через скрипт), но не может быть выполнено автоматически, например, по истечении определённого срока действия.
Заблокированные аккаунты (locked out)
Учётная запись может быть заблокирована автоматически в соответствии с политикой блокировки учётной записи организации. Если пользователь ввёл неправильный пароль более определённого количества раз (порог устанавливается политикой паролей), то его аккаунт автоматически блокируется на время, которое также устанавливается политикой паролей.
На период блокировки пользователь будет получать следующее сообщение при каждой попытке входа:
Учётная запись заблокирована и не может использоваться для входа в сеть.
Блокировка может быть снята автоматически после истечения сроки блокировки, установленной в политике паролей домена. Также администратор может ускорить этот процесс и снять блокировку вручную.
Если время разблокировки в групповой политике пароля установлено на 0, то такая учётная запись никогда не будет разблокирована автоматически, для её разблокировки требуется действие администратора домена.
Учётные записи с истекшим сроком действия (expired)
Учётная запись пользователя может быть бессрочной или действующий в течение определённого времени. Удобно установить срок действия учётной записи для временных пользователей, которые должны иметь доступ в домен, например, на период действия контракта с ними. При установки срока истечения действия, системный администратор не пропустит момент когда нужно отключить пользователя.
Запрет доступа по другим причинам
Пользователю может быть разрешено входить только на определённые компьютеры и/или только в определённые часы. Пример сообщения, когда пользователю не разрешено выполнить вход на этом компьютере:
Вы не можете пользоваться этим компьютером из-за ограничений вашей учётной записи. Попробуйте воспользоваться другим компьютером.
Пример сообщения, когда пользователь пытается войти в неурочное время или день:
Вы не можете сейчас войти в систему из-за ограничений вашей учётной записи. Попробуйте ещё раз позже.
Данные ограничения могут перестать действовать в определённые часы или на определённых компьютерах. Эти ограничения устанавливает и снимает администратор домена.
Этапы эксплуатации Zerologon
Согласно техническому документу Secura, процесс эксплуатации Zerologon состоит из трех этапов.
- Отправка нулевых байтов. Вместо отправки восьми случайных байтов атакующий отправляет 8 нулевых байтов. Злоумышленник повторяет отправку таких сообщений, пока сервер успешно не примет одно из них, и тем самым обходит процесс аутентификации. В случае с Zerologon для успешного соединения с сервером требуется в среднем 256 попыток отправки сообщения ClientChallenge, состоящего из одних нулей.
- Отключение механизма RPC signing and sealing. MS-NRPC использует механизм RPC signing and sealing для шифрования транспортного уровня. Обычно шифрование — обязательный процесс при передаче данных, но в MS-NRPC этот механизм не является обязательным и управляется клиентом. Сервер не будет отказывать в установлении соединения клиентам, которые не запрашивают использование шифрования. Это означает, что вы можете просто отключить шифрование в заголовке сообщения. Собственно, вторая стадия и заключается в отключении механизма RPC signing and sealing, чтобы сообщения отправлялись в открытом виде и атакующий мог использовать методы протокола MS-NRPC.
- Изменение пароля учетной записи. Третья стадия эксплуатации уязвимости Zerologon заключается в изменении пароля для учетной записи контроллера домена, соединение от имени которого было установлено ранее. Атакующие при помощи метода NetrServerPasswordSet в MS-NRPC могут изменить пароль учетной записи компьютера. Самый простой способ использования этого метода заключается в удалении текущего пароля или, другими словами, установке пароля в пустое значение. Также возможно изменить пароль, просто отправив запрос с предпочтительным новым паролем. После смены пароля атакующие могут использовать учетную запись контроллера домена для развития атаки, например, как упоминалось ранее, выполнить репликацию базы данных Active Directory.
Назначение зоны _msdcs.ForestName
Главным образом эта зона предназначена для определения расположения ключевых сервисов AD DS, таких как Глобальный каталог (см. Global catalog — Глобальный каталог), PDC (см. PDC emulator — Эмулятор первичного контроллера домена), Kerberos, LDAP, а также для определения GUID контроллеров домена AD (по записи GUID клиенты найдут контроллеры домена в случае переименования домена). В этой области каждый контроллер домена регистрирует SRV-записи собственных служб и отвечает за этот процесс служба Netlogon. Сама область является частью компонента Domain controller locator (Locator) , внедренного в Windows Server 2003:
Дело в том, что в норме для версий Windows Server 2003 и старше эта зона должна располагаться на том же уровне, что и зона корневого домена. Выглядит это примерно так (пример с моей тестовой инфраструктуры):
Но на серверах DNS в продакшене она являлась поддоменом корневого домена и отсутствовала на уровне раздела леса:
На самом деле в этом нет ничего плохого, поскольку во всем лесу у меня существует лишь один домен, но если доменов будет больше, это может вызвать проблемы. В BPA (Best Practices Analyzer) при этом вылезали ошибки отсутствия зоны (скриншоты для Windows Server 2012 R2 и 2008 R2 соответственно):
Почему так произошло? Дело в том, что в версиях Windows Server старше 2003 все устроено несколько иным образом и зона _msdcs действительно должна находиться на уровне поддомена корневого домена AD и при миграции с 2000 на 2003 должна быть перенастроена. По крайней мере это единственная известная мне причина .
Пришло время все привести к тому виду, в котором оно и должно быть.
Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом
Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:
The trust relationship between this workstation and the primary domain failed.
1 |
The trust relationship between this workstation and the primary domain failed. |
Не удалось восстановить доверительные отношения между рабочей станцией и доменом.
1 |
Не удалось восстановить доверительные отношения между рабочей станцией и доменом. |
Также ошибка может выглядеть так:
The security database on the server does not have a computer account for this workstation trust relationship.
1 |
The security database on the server does not have a computer account for this workstation trust relationship. |
База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.
1 |
База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией. |
Вчем суть уязвимости Zerologon
Zerologon это уязвимость впротоколе шифрования, который
использует служба Netlogon. Протокол позволяет компьютерам
проходить аутентификацию наконтроллере домена иобновлять пароль
своего аккаунта вActive Directory. Именно эта особенность делает
Zerologon опасной. Вчастности, уязвимость позволяет атакующему
выдать себя законтроллер домена иизменить его пароль. Злоумышленник
получает доступ кконтроллеру домена cнаивысшими привилегиями,
аследовательно иккорпоративной сети. После смены пароля атакующий
может использовать учетную запись контроллера домена для развития
атаки, например, выполнив
атаку DCSync (получение учетных записей Active Directory через
механизм репликации).
Всентябре голландский исследователь безопасности Том Тервоорт
изкомпании Secura опубликовал подробное описание уязвимости.
Выяснилось, что Zerologon вызвана недостатком всхеме
криптографической аутентификации, которую использует Netlogon
Remote Protocol (MS-NRPC). Рукопожатие иаутентификация MS-NRPC
предполагают использование режима AES-CFB8 (с8-битным режимом
обратной связи пошифротексту). Это вариант блочного шифра AES,
который предназначен для работы сблоками входных данных по8байт
вместо обычных 16байт (128-бит).
Как обнаружил Тервоорт, применение шифрования AES-CFB8к
состоящему изодних нулей открытому тексту приведет ктакомуже
состоящему изодних нулей зашифрованному тексту. Это происходит
из-за ошибки реализации для 1из256ключей.
Обычно клиентский компьютер, который хочет взаимодействовать
ссервером Netlogon, таким как контроллер домена Windows, начинает
сотправки восьми случайных байтов (то, что часто называют nonce,
сокращая фразу number used once) насервер.
Вавгусте 2020 года врамках августовского вторника Microsoft
выпустила исправление уязвимости. Этот патч сделал механизмы
безопасности Netlogon (которые отключал Zerologon) обязательными
для всех аутентификационных операций, что эффективно предотвращает
атаки. Релиз второго патча, полностью закрывающего уязвимость,
запланирован нафевраль 2021года.
Свойства событий
Каждый столбец это определенное свойство события. Все эти свойства отлично описал Дмитрий Буланов здесь. Приведу скриншот. Для увеличения нажмите на него.
Устанавливать все столбцы в таблице не имеет смысла так как ключевые свойства отображаются в области просмотра. Если последняя у вас не отображается, то дважды кликнув левой кнопкой мышки на событие в отдельном окошке увидите его свойства
На вкладке Общие есть описание этой ошибки и иногда способ ее исправления. Ниже собраны все свойства события и в разделе Подробности дана ссылка на Веб-справку по которой возможно будет информация по исправлению ошибки.
Ошибка netlogon 5781
И так после устранения ошибки 14550 DfsSvc у вас может появиться ошибка netlogon 5781, хотя и совместно они могут присутствовать. Полный текст звучит вот так:
Ошибка при динамической регистрации или удалении одной или нескольких записей DNS, связанных с доменом DNS «ваш домен.». Эти записи используются другими компьютерами для поиска данного сервера как контроллера домена (если указан домен Active Directory) или как сервера LDAP (если указанный домен является разделом приложений). И код 5781, а источник NETLOGON
Кто не в курсе NETLOGON это служба DNS.
В журналах событий для DNS вы можете обнаружить вот такое сообщение: Разрешение имен для имени истекло после отсутствия ответа от настроенных серверов DNS (Код события 1014 в DNS Client Events). Тут решением будет проверить разрешается ли с данного компьютера или контроллера домена нужное имя DNS (зона), и проверяйте сетевые настройки как выше и DNS сервера.
Если с сетевым подключением у вас все отлично, то попробуйте вот такой еще вариант. В начале нужно проверить с помощью специальной утилиты репликацию DFS, так как именно этот механизм работает в Active Directory. Делается это командой dcdiag.
dcdiag /a или /e
- /a > это в рамках домена
- /e > в рамках предприятия
Можете как раз тут отследить ошибки репликации папки SysVOL.
Так же советую попробовать на контроллере домена, где выскакивает ошибка netlogon 5781, вот такую вещь, а именно удалить файлы:
- netlogon.dns
- netlogon.dnb
Сохраняем их копию и будем удалять исходные, после чего они пересоздадуться. Во первых открываем командную строку от имени администратора, далее вводим команду
ipconfig /registerdns (регистрируем запись компьютера в DNS, на всякий случай)
net stop netlogon (останавливаем службу)
Копируем файлы netlogon.dns и netlogon.dnb в надежное место, после чего удаляем их из C:\Windows\System32\config
Запускаем службу командой net start netlogon и перезагружаемся.
Проверяем наличие ошибки netlogon 5781, она должна пропасть.
Что такое netlogon.exe?
netlogon.exe это исполняемый файл, который является частью Инструменты разработчика, серверы разработанный Microsoft, Версия программного обеспечения для Windows: 1.0.0.0 обычно 129248 в байтах, но у вас может отличаться версия.
Расширение .exe имени файла отображает исполняемый файл. В некоторых случаях исполняемые файлы могут повредить ваш компьютер. Пожалуйста, прочитайте следующее, чтобы решить для себя, является ли netlogon.exe Файл на вашем компьютере — это вирус или вредоносная программа, которую вы должны удалить, или, если это действительно допустимый файл операционной системы Windows или надежное приложение.
(опциональное предложение для Reimage — Cайт | Лицензионное соглашение | Персональные данные | Удалить)
Что такое домен в локальной сети
Под доменом локальной сети принято понимать такую сеть, которая объединяет компьютеры под одной общей политикой безопасности и управляется централизовано. Таким образом при объединении компьютеров сети в рабочие группы взаимодействие машин основывается на принципе «клиент-клиент», а в домене это уже «клиент-сервер». В качестве сервера выступает отдельная машина, на которой хранятся все учетные записи пользователей сети. Так же можно хранить и профиль каждого пользователя.
Целесообразность организации такого доступа обусловлена несколькими факторами:
- локальная сеть постоянно развивается и количество пользователей растет;
- видоизменяется топология и география сети;
- необходимо разграничить доступ к ресурсам для каждого пользователя или группы;
- контроль за использованием ресурсов глобальной сети интернет.
При организации доступа на основе рабочих групп, такой контроль организовать просто невозможно. Однако, когда сеть состоит из всего нескольких компьютеров, то совершенно не имеет никакого смысла ставить отдельный сервер домена, это просто экономически нецелесообразно.
Если ЛВС организована на основе Microsoft Windows Server, то служба, которая отвечает за контролер домена называется AD (Active Directory), если под управлением *nix (Unix, Linux, FreeBSD) служба управляющая пользователями имеет название LDAP (Lightweght Directory Access Protocol).
Могу ли я удалить или удалить netlogon.exe?
Не следует удалять безопасный исполняемый файл без уважительной причины, так как это может повлиять на производительность любых связанных программ, использующих этот файл. Не забывайте регулярно обновлять программное обеспечение и программы, чтобы избежать будущих проблем, вызванных поврежденными файлами. Что касается проблем с функциональностью программного обеспечения, проверяйте обновления драйверов и программного обеспечения чаще, чтобы избежать или вообще не возникало таких проблем.
Однако, если это не вирус и вам нужно удалить netlogon.exe, вы можете удалить Инструменты разработчика, Серверы с вашего компьютера, используя его деинсталлятор. Если вы не можете найти его деинсталлятор, то вам может понадобиться удалить Developer Tools, Servers, чтобы полностью удалить netlogon.exe. Вы можете использовать функцию «Установка и удаление программ» на панели управления Windows.
1. в Меню Пуск (для Windows 8 щелкните правой кнопкой мыши в нижнем левом углу экрана), нажмите Панель управления, а затем под Программы:o Windows Vista / 7 / 8.1 / 10: нажмите Удаление программы.o Windows XP: нажмите Установка и удаление программ.if(typeof ez_ad_units!=’undefined’){ez_ad_units.push(,’windowsbulletin_com-large-leaderboard-2′,’ezslot_11′,550,’0′,’0′])};__ez_fad_position(‘div-gpt-ad-windowsbulletin_com-large-leaderboard-2-0′);if(typeof ez_ad_units!=’undefined’){ez_ad_units.push(,’windowsbulletin_com-large-leaderboard-2′,’ezslot_12′,550,’0′,’1′])};__ez_fad_position(‘div-gpt-ad-windowsbulletin_com-large-leaderboard-2-0_1’);.large-leaderboard-2-multi-550{border:none!important;display:block!important;float:none!important;line-height:0;margin-bottom:15px!important;margin-left:auto!important;margin-right:auto!important;margin-top:15px!important;max-width:100%!important;min-height:250px;min-width:250px;padding:0;text-align:center!important;width:100%}
2. Когда вы найдете программу Инструменты разработчика, серверыщелкните по нему, а затем:o Windows Vista / 7 / 8.1 / 10: нажмите Удалить.o Windows XP: нажмите Удалить or Изменить / Удалить вкладка (справа от программы).
3. Следуйте инструкциям по удалению Инструменты разработчика, серверы.
PoC и эксплоиты
Первый PoC опубликовала компания Secura на GitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения он немедленно завершит работу и не будет выполнять никаких действий через Netlogon.
Что касается эксплоитов, на момент публикации этой статьи их появилось уже много. Однако все они ведут себя одинаково: либо сбрасывают пароль, либо устанавливают его в определенное пользователем значение.
Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Но он используется вместе с другими уязвимостями и заслуживает отдельной статьи.
Обычная проверка подлинности
Обычная проверка подлинности является широко используемым стандартным методом получения сведений об имени пользователя и пароле. Обычная проверка подлинности проходит следующим образом:
- В веб-обозревателе пользователя открывается диалоговое окно, в которое пользователь должен ввести ранее назначенные ему имя учетной записи пользователя Windows 2000 и пароль.
- После этого веб-обозреватель предпринимает попытку установить подключение с использованием введенных данных. (Перед передачей через сеть пароль зашифровывается по схеме Base64).
- Если сервер отвергает эту информацию, веб-обозреватель продолжает отображать диалоговое окно до тех пор, пока пользователь не введет действительное имя пользователя и пароль или не закроет диалоговое окно.
- Веб-сервер проверяет, что имя пользователя и пароль соответствуют действительной учетной записи Windows, и устанавливает соединение.
Для получения дополнительной информации об установке обычной проверки подлинности см. раздел Включение и конфигурирование проверки подлинности.
Преимуществом обычной проверки подлинности является то, что она является частью спецификации HTTP и поддерживается большинством обозревателей. К недостаткам относится то, что веб-обозреватели при использовании этого метода передают пароли в незашифрованном виде. Наблюдая за передачей информации в сети, можно легко перехватить и расшифровать эти пароли с помощью общедоступных средств. Следовательно, обычный способ проверки подлинности не рекомендуется использовать, за исключением тех случаев, когда есть полная уверенность в безопасности соединения пользователя и веб-сервера (например, прямое кабельное соединение или выделенная линия). Дополнительные сведения см. в разделе Шифрование.
Примечание Встроенная проверка подлинности имеет приоритет перед обычной проверкой подлинности. Обозреватель выберет встроенную проверку подлинности Windows и будет пытаться использовать текущую учетную информацию Windows перед тем, как запросить имя пользователя и пароль. В настоящий момент только Internet Explorer версии 2.0 и более поздней поддерживает встроенную проверку подлинности.
Пароль учетной записи компьютера в домене Active Directory
Когда компьютер вводится в домен Active Directory, для него создается отдельная учетная запись типа computer. У каждого компьютера в домене, как и у пользователей есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Однако, в отличии от паролей пользователя, пароли компьютеров задаются и меняются автоматически.
Несколько важных моментов, касающихся паролей компьютеров в AD:
- Компьютеры должны регулярно (по умолчанию раз в 30 дней) менять свои пароли в AD.Совет. Максимальный срок жизни пароля может быть настроен с помощью политики Domain member: Maximum machine account password age, которая находится в разделе: Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options. Срок действия пароля компьютера может быть от 0 до 999 (по умолчанию 30 дней).
- Срок действия пароля компьютера не истекает в отличии от паролей пользователей. Смену пароля инициирует компьютер, а не контроллер домена. На пароль компьютера не распространяется доменная политика паролей для пользователей. Даже если компьютер был выключен более 30 дней, его можно включить, он нормально аутентифицируется на DC со старым паролем, и только после этого локальная служба
Netlogon
1
Netlogon
изменит пароль компьютера в своей локальной базе (пароль хранится в ветке реестра HKLM\SECURITY\Policy\Secrets\$machine.ACC) и затем в аккаунте компьютера в Active Directory.
- Пароль компьютера меняется на ближайшем DC, эти изменения не отправляются на контроллера домена с FSMO ролью эмулятора PDC (т.е. если компьютер сменил пароль на одном DC, то он не сможет авторизоваться на другом DC, до момента выполнения репликации изменений в AD).
Если хэш пароля, который компьютер отправляет контроллеру домена не совпадает с паролем учетной записи компьютера, компьютер не может установить защищённое подключение к DC и выдает ошибки о невозможности установить доверенное подключение.
Почему это может произойти:
- Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Если вы откатите такой компьютер на предыдущее состояние, это компьютер попытается аутентифицироваться на DC со старым паролем.
- В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;
- Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD);
- Довольно редкий случай, когда сбилось системное время на компьютере.
Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:
- Сбросить аккаунт компьютера в AD;
- Под локальным админом перевести компьютер из домена в рабочую группу;
- Перезагрузить компьютер;
- Перезагнать компьютер в домен;
- Еще раз перезагрузить компьютер.
Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.
Есть более элегантный способ восстановить доверительные отношения с помощью PowerShell без перевключения в домен и без перезагрузок компьютера.
Как посмотреть текущих хозяев операций в Active Directory (роли контроллеров домена)
Итак, наша задача на сегодня — узнать в текущем лесу и в текущем домене — какие контроллеры домена какие роли хозяев операций несут. Т.е. нас интересует:
- Кто является хозяином схемы
- Кто является хозяином именования доменов
- Кто является хозяином RID домена
- Кто является хозяином инфраструктуры
- Кто является основным контроллером домена
Есть два пути: через GUI (собирать информацию из разных мест) или через консоль (одним списком, быстро и четко).
Путь 1. Через консоль
Заходим на контроллер домена (например, через RDP) и выполняем через CMD:
C:> ntdsutilntdsutil: rolesfsmo maintenance: connectionsserver connections: connect to server
Привязка к . Подключен к с помощью учетных данных локального пользователя.
server connections: quitfsmo maintenance: select operation targetselect operation target: list roles for connected server
Серверу » » известно о 5 роляхСхема — CN=NTDS Settings,CN=SERVER1,CN=Servers,CN=CENTER,CN=Sites,CN=Configuration,DC=hotelsХозяин именования — CN=NTDS Settings,CN=SERVER1,CN=Servers,CN=CENTER,CN=Sites,CN=Configuration,DC=hotelsPDC — CN=NTDS Settings,CN=SERVER2,CN=Servers,CN=CENTER,CN=Sites,CN=Configuration,DC=hotelsRID — CN=NTDS Settings,CN=SERVER2,CN=Servers,CN=CENTER,CN=Sites,CN=Configuration,DC=hotelsИнфраструктура — CN=NTDS Settings,CN=SERVER3,CN=Servers,CN=CENTER,CN=Sites,CN=Configuration,DC=hotels
select operation target: quitfsmo maintenance: quitntdsutil: quit
Здесь вместо укажите имя сервера — контроллера домена. Например того, с которого Вы и выполняете эту команду.
Как видно в выводе команды — указанному серверу известно — кто является хозяином операции по каждой роли. Имена серверов видны после записей «CN=» (вторых по счету — первая запись — это «NTDS Settings»). В нашем примере мы видим, что хозяинами соответствующих операций являются: SERVER1, SERVER2 и SERVER3.
Путь 2. Через GUI
Определяем основной контроллер, хозяина RID и хозяина инфраструктуры
Три роли можно посмотреть в одном месте. Там мы увидим:
- Основной контроллер домена
- Хозяина RID
- Хозяина инфраструктуры
Для этого:
1) Открываем:Пуск -> Администрирование -> Active Directory — Пользователи и компьютеры
2) Щелкаем правой кнопкой мыши на названии нужного домена в левой части окна и выбираем пункт меню «Хозяева операций».
3) В открывшемся окне будет три вкладки: «RID», «PDC» (основной контроллеро домена) и «Инфраструктура». Соответственно, заходя в ту или иную вкладку Вы можете наблюдать текущего хозяина роли в верхней строке.
Определяем сервер с ролью хозяина схемы
1) Для того, чтобы увидеть оснастку «Схема Active Directory», из которой мы сможем увидеть хозяина схема, выполним (с правами локального админа):
Пуск -> Выполнить -> «mmc» -> Enter
3) В открывшемся пустом окне MMC давим:
Файл -> Добавить или удалить оснастку
4) Выбираем оснастку «Схема Active Directory»
6) Правой кнопкой по «Схема Active Directory» в MMC и выбираем «Хозяин операций»
В открывшемся окне мы можем видеть текущего хозяина роли «Хозяин схемы» в верхней строчке.
Определяем сервер с ролью хозяина именования
Пуск -> Администрирование -> Active Directory — Домены и доверия
В открывшемся окне в левой части кликаем правой кнопкой мыши на «Домены и доверия» и выбираем пункт «Хозяин операций».
В открывшемся окне, в верхней строчке мы можем видеть текущего хозяина именования.
Включить ведение журнала отладки для службы входа в сеть
Процедура включения или отключения ведения журнала отладки для службы входа в сеть требует изменения реестра
Поэтому рекомендуется сделать резервную копию реестра или создать точку восстановления системы в качестве меры предосторожности на случай, если процедура пойдет не так
Версия Netlogon.dll с включенной трассировкой устанавливается по умолчанию во всех поддерживаемых в настоящее время версиях Windows. Чтобы включить ведение журнала отладки, установите нужный флаг отладки, используя Nltest.exe через командная строка или же реестр.
Включение или отключение ведения журнала отладки через командную строку
Для включения сделайте следующее:
- Запустить командную строку (нажмите Пуск и введите cmd, затем нажмите Enter).
- В окне командной строки скопируйте и вставьте команду ниже и нажмите Enter:
Чтобы отключить, сделайте следующее:
- Запустите командную строку (нажмите Пуск и введите cmd, затем нажмите Enter).
- В окне командной строки скопируйте и вставьте приведенную ниже команду и нажмите Enter:
Включение или отключение ведения журнала отладки через реестр
Чтобы включить его, сделайте следующее:
- Запустите редактор реестра (нажмите клавишу Windows и введите regedit, затем нажмите Enter).
- Перейдите к следующему разделу реестра:
Если DBFlag существует, удалите значение Reg_SZ записи реестра, создайте значение REG_DWORD с тем же именем, а затем добавьте 2080FFFF шестнадцатеричное значение.
Закройте редактор реестра.
Чтобы отключить, сделайте следующее:
- Запустите редактор реестра.
- Перейдите к следующему разделу реестра:
- Измените значение данных DBFlag на 0x0.
- Закройте редактор реестра.
В обоих случаях обычно нет необходимости останавливать и перезапускать службу Netlogon для Windows 2000 Server / Professional или более поздних версий операционной системы, чтобы отключить ведение журнала Netlogon. Действия, связанные с входом в сеть, регистрируются в:
Убедитесь, что в этот журнал не записывается новая информация, чтобы определить, требуется ли перезапуск службы Netlogon. Если вам необходимо перезапустить службу, откройте окно административной командной строки и выполните следующие команды:
net stop netlogon
net start netlogon
Microsoft также предлагает Простые исправления для включения или отключения, что вы можете Скачать здесь.
Вот и все, ребята! Надеюсь, этот пост окажется для вас полезным.
Протокол PNRP
Тип запуска: вручную. Учетная запись: локальная служба. Дополнительные привилегии: SECHANGENOTIFYPRIVILEGE, SECREATEGLOBALPRIVILEGE, SEIMPERSONATEPRIVILEGE. Файлы службы: p2psvc.dll. Исполняемый файл: svchost.exe -k LocalServiceNetworkRestricted. Подраздел реестра: PNRPsvc. Службы, необходимые для работы данной: ДИСПЕТЧЕР УДОСТОВЕРЕНИЯ СЕТЕВЫХ УЧАСТНИКОВ (p2pimsvc).
Поддерживает механизм бессерверного однорангового разрешения имен через Интернет, без работы которого некоторые приложения, работающие с одноранговыми сетями (например, Windows Messenger), работать не будут.
Настройки групповой политики
Операционная система Windows Vista содержит ряд настроек групповой политики, при помощи которых можно изменить параметры работы в одноранговых сетях. Все они находятся в разделе КОНФИГУРАЦИЯ КОМПЬЮТЕРА/АДМИНИСТРАТИВНЫЕ ШАБЛОНЫ/СЕТЬ/СЛУЖБЫ ОДНОРАНГОВЫХ СЕТЕЙ MICROSOFT, и подразделах, вложенных в него.
Данные политики изменяют значения параметров REG_DWORD типа, расположенных в ветви реестра HKLMSOFTWAREPoliciesMicrosoftPeernet.
- IgnoreDomainPasswordPolicyForNewGroups. Если значение данного параметра равно 1, тогда при создании одноранговой группы и указании пароля, указанный пароль не будет проверяться согласно требованиям надежности, определенным операционной системой локального компьютера (то есть, можно будет указывать любой пароль).
- Disabled. Если значение данного параметра равно 1, тогда службы одноранговой сети, реализованные в операционной системе Windows, будут запрещены.
- Также вы можете воспользоваться параметрами REG_DWORD типа DisableMulticastBootstrap и строкового типа SeedServer, чтобы отключить возможность использования протокола PNRP для поиска компьютеров в сети и оповещения, а также для задания сервера инициализации. Эти параметры, в зависимости от области действия, могут находиться в одном из следующих подразделов ветви реестра HKLMSOFTWAREPoliciesMicrosoftPeernetPnrp: IPv6-Global (настройки для глобального облака), IPv6-LinkLocal (настройки для локального облака связи) и IPv6-SiteLocal (настройки для локального облака узла).
Параметры настройки службы
Параметры настройки протоколов PNRP, обслуживаемых данной службой, содержатся в подразделах ветви реестра HKLMSoftwareMicrosoftWindows NTCurrentVersionPeerNetPNRPIPV6-LinkLocal. Например, ниже перечислены самые интересные параметры.
- Disabled. Данный параметр REG_DWORD типа позволяет отключить сетевое подключение.
- SeedServer. Данный параметр строкового типа содержит в себе список начальных серверов, перечисленных через запятую.
- DisableMulticastPublish. Данный параметр REG_DWORD типа позволяет отключить использование широковещательных пакетов при публикации.
- DisableMulticastSearch. Данный параметр REG_DWORD типа позволяет отключить использование широковещательных пакетов при поиске.
- NumPeersToFlood. Данный параметр REG_DWORD типа позволяет указать количество одноранговых соединений, превышение которого будет считаться флудом (переполнением).
- PeriodBetweenMaintenanceInSecond. Данный параметр REG_DWORD типа позволяет указать интервал (в секундах) между сохранением.
- MaxStartupTimeInMillisecond. Данный параметр REG_DWORD типа позволяет указать максимальное время загрузки в миллисекундах.
- MaxDelayForCPAAuthorizationInSecond. Данный параметр REG_DWORD типа позволяет указать максимальную задержу (в секундах) авторизации CPA.
- MinCPALigeTime. Данный параметр REG_DWORD типа позволяет указать минимальное время жизни CPA.
Также параметры работы данной службы можно найти в ветви реестра HKLMSystemCurrentControlSetServicesPNRPsvcparameters. Например, в данной ветви реестра может содержаться параметр строкового типа SeedServer, содержащий в себе список начальных серверов для работы службы, перечисленных через запятую.
Выводы
Описанные выше правила на основе журналов событий Windows, сетевой телеметрии, а также YARA-правило можно использовать как по отдельности, так и вместе, что позволит не только детектировать факты эксплуатации Zerologon, но и повысить скорость классификации инцидента.
Новости о том, что информационные системы той или иной компании зашифрованы в ходе атаки с использованием Zerologon, появляются все чаще. Поэтому не стоит забывать, что одной лишь возможности обнаружить факты эксплуатации Zerologon для защиты недостаточно. Значительно снизить риски поможет установка закрывающих уязвимость обновлений безопасности от Microsoft.