Windows credentials editor что это

Обновлено: 04.07.2024

Поставщики учетных данных являются основным механизмом проверки подлинности пользователей — они в настоящее время являются единственным способом подтвердить свою личность, необходимую для входа в систему и других сценариев проверки подлинности системы. с Windows 10 и введением Microsoft Passport поставщики учетных данных важнее, чем когда-либо. они будут использоваться для проверки подлинности в приложениях, веб-сайтах и других.

корпорация майкрософт предоставляет множество поставщиков учетных данных в составе Windows, таких как пароль, пин-код, карта и Windows Hello (отпечаток пальца, лицо и распознавание iri). Они называются "системными поставщиками учетных данных" в этой статье. Поставщики вычислительной техники, предприятия и другие сущности могут создавать собственные поставщики учетных данных и легко интегрировать их в Windows. Они называются "сторонними поставщиками учетных данных" в этой статье. Обратите внимание, что поставщики учетных данных v1 и v2 поддерживаются в Windows 10. Для понимания этих рекомендаций важно быть создателями и руководителями сторонних поставщиков учетных данных.

Поставщики системных учетных данных

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

Сценарий А

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

Сценарий Б

Пользователь учетной записи MSA/AD/AAD настроил стороннего поставщика учетных данных и регулярно использует его для входа на устройство. Один день, пользователь устанавливает на устройстве некоторое обновление, которое прерывает работу стороннего поставщика учетных данных, и пользователь не знает об этом изменении перед перезапуском компьютера.

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

Заключение

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

Настраиваемые поставщики учетных данных

платформа поставщика учетных данных Windows позволяет разработчикам создавать пользовательские поставщики учетных данных. Когда служба Winlogon хочет получить учетные данные, Пользовательский интерфейс входа в систему запрашивает у каждого поставщика учетных данных количество учетных записей, которые он хочет перечислить. После того как все поставщики перечисляют плитки, Пользовательский интерфейс входа отображает их пользователю. Затем пользователь взаимодействует с плиткой для предоставления необходимых учетных данных. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности. Поставщики учетных данных также могут использоваться в пользовательском интерфейсе учетных данных, если требуются учетные данные. Список сценариев, в которых может поддерживаться поставщик учетных данных, см. в разделе _ _ _ сценарий использования поставщика учетных данных .

Благодаря этой системе гораздо проще создать поставщик учетных данных, чем в прошлом. Большая часть работы обрабатывается сочетанием Winlogon, пользовательского интерфейса входа и пользовательского интерфейса учетных данных. Для этого необходимо создать собственную реализацию икредентиалпровидер и ICredentialProviderCredential. Если вы реализуете поставщик учетных данных версии 2 (рекомендуется), необходимо также реализовать ICredentialProviderCredential2.

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

объединив поставщики учетных данных с поддерживаемым оборудованием, вы можете расширить Windows для поддержки входа в систему с помощью биометрических данных, паролей, пин-кодов, сертификатов или любого настраиваемого пакета проверки подлинности, который вы решили создать. Вы также можете настроить процедуру входа для пользователя различными способами. Например, когда пользовательский интерфейс входа в систему запрашивает у поставщика учетных данных сведения о плитках с учетными данными, можно указать плитку по умолчанию, чтобы обеспечить пользовательский интерфейс для пользователя. Поставщики учетных данных могут быть даже разработаны для поддержки единого входа (SSO), проверки подлинности пользователей в защищенной точке доступа, а также для входа на компьютер.

поставщики учетных данных регистрируются на Windows компьютере и отвечают следующим.

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

Помните, что на одном компьютере можно установить несколько поставщиков учетных данных.

Создание оболочек для поставщиков учетных данных

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

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

В logon-сессиях Windows сохраняет информацию о любых успешных входах в систему. Информация включает в себя имя пользователя, имя рабочей группы или домена, а также LM/NT-хеши паролей.

Logon-сессии

Вне зависимости от того, как именно легитимный пользователь заходит в систему: интерактивно или удаленно через RDP – в любом случае, локальная подсистема безопасности (Local Security System - LSA) сохраняет учетные данные пользователей в памяти.

Ниже представлена модель входа и аутентификации в Windows NT:

Модель входа и аутентификации в Windows NT

Аналогичные данные сохраняются и для процессов, “запускаемых от имени…” (Run As) и служб, выполняющихся в контексте определенного пользователя. Пароли служб сохраняются в незашифрованном виде, и могут быть получены из секретов LSA.

Механизм SSO функционирует благодаря тому, что сегодня практически все сервисы Windows (исключением является подключение по RDP) наряду с аутентификацией по паролю поддерживают аутентификацию по NT/LM-хешам.

Получение logon-сессий

Следующие утилиты помогают слить logon-сессии: msvctl от TrueCrypt идеально подходит для 32-битных Windows XP/2003. Последняя версия gsecdump сольет logon-сессии в независимости от версии и архитектуры Windows. Из недавних разработок TrueSec стоит также отметить lslsass: утилита была спроектирована специально для систем Windows Vista и выше. Lslsass безупречно работает как на 32-x, так и на 64-x разрядных системах.

Самые известные утилиты для управления logon-сессиями Windows – это Windows Credentials Editor (WCE) и ее предшественница Pass-the-Hash Toolkit (PTK). Обе утилиты представляют собой результат плодотворной работы основателя компании Amplia Security Хернана Очоа (Hernan Ochoa). По своим разработкам он сделал несколько презентаций, среди которых:

, представленная на конференции по безопасности Hack In The Box в Малазии в конце 2008 года. Презентация проливает свет на историю и механизмы работы пост-эксплойтов, и в частности на атаку передачи хеша (“Pass-The-Hash”) и реализацию атаки в утилите Pass-The-Hash Toolkit. , представленная на конференции RootedCon в начале 2011 года в Мадриде. В презентации поясняются механизмы, которые лежат в основе работы WCE, а также то, как Windows хранит в памяти учетные данные пользователей в системах до и после Windows Vista. – презентация представлена в июле 2011 года. Если вы впервые слышите о logon-сессиях и атаке передачи хеша, то я рекомендую вам начать свое знакомство с ними именно с этой простой и понятной презентации с примерами. Также можете почитать FAQ-страничку WCE.

Из двух утилит я по ряду причин предпочитаю WCE: во-первых, WCE – это самостоятельный EXE-файл; во-вторых, WCE безопаснее, поскольку не приводит к падению процесса LSASS при чтении памяти; и в-третьих, утилита работает на всех версиях и архитектурах Windows.

Специально для целей статьи я установил Windows Server 2003 Service Pack 2 со всеми обновлениями (NetBIOS-имя w2k3r2), и произвел следующие действия:

Локальный пользователь Administrator интерактивно зашел на консоль. Длина пароля пользователя Administrator – 15 символов.
Два локальных пользователя inquis и foobar подключились к системе по RDP. Первый пользователь подключился через mstsc, а второй через rdesktop.
Запущено несколько сервисов СУБД IBM DB2 в контексте локального администратора db2admin.

Утилита lslsass была намеренно исключена из эксперимента, так как она работает только на системах Windows Vista и выше.

Все тестируемые утилиты удачно слили logon-сессии. Ниже показан результат работы Windows Credential Editor:

Мы получили имя пользователя, имя домена/рабочей группы и LM/NT-хеши. Результаты тестируемых утилит и утилит для получения хеша из SAM очень похожи, за исключением того, что тестируемые утилиты могут отобразить учетные данные не только локальных, но и доменных пользователей тоже.

Следующий скриншот также подтверждает удачность атаки:

Получение logon-сессий с помощью Windows Credential Editor (WCE) на Windows Server 2003 R2

(Administrator имеет доступ к консоли, два пользователя подключены удаленно по RDP и один процесс выполняется в контексте локального пользователя)

Во время проведения эксперимента я понял, что независимо от того, как именно завершаются сессии, logon-сессии все равно остаются в памяти. Например, неважно как вы закроете RDP-соединение: нажмёте X в левом верхнем углу RDP-клиента или выйдете из системы через меню “ПУСК” – logon-сессия все равно останется в памяти. Подобные вещи происходят и в Windows Server 2008 R2 Enterprise Service Pack 1. В системах Windows Vista и выше logon-сессии стираются из памяти спустя пару минут после выхода пользователя из системы.

Вышеописанное поведение продемонстрировано на следующем скриншоте:

Получение logon-сессии после отключения от RDP пользователя foobar: его logon-сессия осталась в памяти

Получение logon-сессии после принудительного отключения от RDP пользователя foobar: его logon-сессия осталась в памяти

Logon-сессия db2admin также осталась в памяти, несмотря на то, что соответствующий сервис был остановлен.

Какие угрозы влечет за собой получение logon-сессии

Тогда попробуйте слить logon-сессии. Если вам удастся получить logon-сессию доменного администратора, то вы победили: осталось только использовать полученную logon-сессию, чтобы выдать себя за администратора и получить доступ к командной строке. Такая атака также известна, как “pass-the-hash” (“передача хеша”) или кража logon-сессии.

В командной строке наберите следующее:

C:\>wce.exe -s : : : -c cmd.exe

В новом открывшемся окне командной строки подключитесь по SMB (например, с помощью утилиты PsExec компании Sysinternals) к корневому контроллеру домена. Система, скорее всего, успешно аутентифицирует вас как администратора домена, потому что, по сути, вы предоставили учетные данные именно этого пользователя.

Если же logon-сессии администратора домена на захваченной вами системе нет, то проверьте (с помощью утилиты keimpx), на какие еще системы в домене пользователь может войти. Есть вероятность, что новые захваченные системы содержат необходимую вам информацию об учетных данных администратора домена, и поэтому, повторяя те же самые действия, вам, возможно, удастся захватить контроллер домена.

Помимо WCE есть и другие утилиты, способные провести атаку передачи хеша: например, msvctl и RunhAsh от TrueSec. Все новые утилиты я добавил в таблицу. Буду рад вашим отзывам и предложениям!

Ключевая роль Windows Credentials Editor v1.2 (WCE) в процессе проникновения

Вчера G0t3n болтал, G0t3n говорил о программном обеспечении Windows Credentials Editor v1.2 (WCE), помимо перехвата HASH, он также может внедрять HASH-атаки и повышать уровень полномочий администратора домена.

Параметры следующие:
-l List logon sessions and NTLM credentials (default).
-s Changes NTLM credentials of current logon session.
Parameters: <UserName>:<DomainName>:<LMHash>:<NTHash>.
-r Lists logon sessions and NTLM credentials indefinitely.
Refreshes every 5 seconds if new sessions are found.
Optional: -r<refresh interval>.
-c Run <cmd> in a new session with the specified NTLM credentials.
Parameters: <cmd>.
-e Lists logon sessions NTLM credentials indefinitely.
Refreshes every time a logon event occurs.
-o saves all output to a file.
Parameters: <filename>.
-i Specify LUID instead of use current logon session.
Parameters: <luid>.
-d Delete NTLM credentials from logon session.
Parameters: <luid>.
-v verbose output.

Протестируйте его сейчас, войдите на сервер, загрузите WCE и затем выполните команду: wce -l, чтобы вывести список HASH пользователей, которые вошли в систему.

Здесь, чтобы объяснить, имя домена или компьютера находится между каждым именем пользователя: номером и HASH: номером на рисунке. Имя домена на рисунке: BIGTH. Имя компьютера: BKKWEB01 - отображаемое имя компьютера.
Пользователь, соответствующий BKKWEB01, является локальным пользователем без полномочий домена. BIGTH является пользователем домена и может войти на любой хост в домене.

После получения HASH пользователя домена воспользуйтесь инструментом для взлома радужной таблицы, и пароль выйдет примерно через 1 минуту. Войдите в контроллер домена и используйте FTP для передачи программного обеспечения WCE.

Затем снова WCE -l, на этот раз вы также можете получить HASH контроллера домена.

Ниже представлена модель входа и аутентификации в Windows NT:

Модель входа и аутентификации в Windows NT

Получение logon-сессий

Logon-сессии можно получить, при условии, что у вас есть доступ к командной строке с административными правами. Существует два метода получения logon-сессий: внедрение кода в процесс lsass.exe и чтение памяти LSASS.Следующие утилиты помогают слить logon-сессии: msvctl от TrueCrypt идеально подходит для 32-битных Windows XP/2003. Последняя версия gsecdump сольет logon-сессии в независимости от версии и архитектуры Windows. Из недавних разработок TrueSec стоит также отметить lslsass: утилита была спроектирована специально для систем Windows Vista и выше. Lslsass безупречно работает как на 32-x, так и на 64-x разрядных системах.

Локальный пользователь Administrator интерактивно зашел на консоль. Длина пароля пользователя Administrator – 15 символов.
Два локальных пользователя inquis и foobar подключились к системе по RDP. Первый пользователь подключился через mstsc, а второй через rdesktop.
Запущено несколько сервисов СУБД IBM DB2 в контексте локального администратора db2admin.

Утилита lslsass была намеренно исключена из эксперимента, так как она работает только на системах Windows Vista и выше.

Все тестируемые утилиты удачно слили logon-сессии. Ниже показан результат работы Windows Credential Editor:

Следующий скриншот также подтверждает удачность атаки:

Получение logon-сессий с помощью Windows Credential Editor (WCE) на Windows Server 2003 R2

Вышеописанное поведение продемонстрировано на следующем скриншоте:

Получение logon-сессии после отключения от RDP пользователя foobar: его logon-сессия осталась в памяти

Logon-сессия db2admin также осталась в памяти, несмотря на то, что соответствующий сервис был остановлен.

Какие угрозы влечет за собой получение logon-сессии

Ситуация сейчас такая же, как и при получении секретов LSA и информации из кэшированных входов в домен: вы получили права Local System на системе, входящей в один или несколько доменов, и вы хотите взять под контроль весь домен (домены). Никакой информации об учетных данных доменных пользователей из секретов LSA и из кэша вам узнать не удалось.Тогда попробуйте слить logon-сессии. Если вам удастся получить logon-сессию доменного администратора, то вы победили: осталось только использовать полученную logon-сессию, чтобы выдать себя за администратора и получить доступ к командной строке. Такая атака также известна, как “pass-the-hash” (“передача хеша”) или кража logon-сессии.

В командной строке наберите следующее:

C:\>wce.exe -s . -c cmd.exe

Читайте также: