Если вы скомпрометировали хост Windows и не можете или не хотите делать дамп открытых паролей с помощью традиционных методов (например, sekurlsa::logonpasswords от mimikatz или дамп LSASS), вам следует проверить настройки делегирования учетных данных. Если он включен, он позволяет получать пароли в открытом виде, не затрагивая процесс LSASS или даже не имея прав администратора (ограниченно только паролем текущего пользователя)!
Эта статья также позволяет защитникам и владельцам систем просматривать настройки в своих средах и оценивать, подвержены ли они риску кражи учетных данных с помощью этого метода.
Технический бэкграунд ?
RDP (удаленный рабочий стол/терминальный сервер) совместим с SSO. Если вы используете устройство Windows, присоединенное к домену, вы можете удаленно подключиться к серверу с помощью RDP с вашей текущей учетной записью пользователя AD без повторного ввода пароля. Но вы должны знать, что открытие сеанса RDP преобразуется в интерактивное открытие сеанса на стороне сервера. Это важно, так как это означает, что ваш пароль отправляется на сервер, конечно, защищенный при передаче, но, тем не менее, удаленный сервер в конечном итоге получает пароль в открытом виде.
Теперь вы понимаете, к чему мы идем? Потратьте время, чтобы угадать, что может пойти не так… ?
➡️ Если вы догадались, что мы можем реализовать злонамеренный сервер и получить пароль, то вы правы!
В фоновом режиме эта функция RDP SSO опирается на компоненты «CredSSP/TSSSP/TSPKG», которые обеспечивают «делегирование учетных данных». Для пуристов: обратите внимание, что эти аббревиатуры не находятся на одном уровне: «SSP» = поставщик поддержки безопасности, «TSSSP» = «SSP служб терминалов», а «TSPKG» — поставщик аутентификации (он реализован в sekurlsa::logonpasswords от mimikatz). а точнее
секурлса::цпкг).
Бенджамин @gentilkiwi Дельпи напомнил нам в твите 2016 года, что активация делегирования учетных данных приводит к наличию паролей в памяти даже в Windows 10! Для этого требуются некоторые настройки, и по умолчанию они не настроены, что означает, что они не включены, и эта функция не работает…
Подсказка ?: в вашей среде, если вы всегда вводите свой пароль при подключении к RDP, даже с вашей собственной текущей учетной записью: это означает, что эти настройки, вероятно, не включены… Но это может быть сложнее, например, другие службы, чем RDP (например, удаленное взаимодействие PowerShell, служба виртуальной консоли Microsoft, удаленная отладка Visual Studio и т. д.) может использовать это и быть включенным вместо этого, поэтому все равно прочитайте остальное!
Также обратите внимание, что для RDP это работает только с серверами, на которых включен NLA. NLA — это аутентификация на уровне сети, которая позволяет пройти аутентификацию перед открытием графического сеанса. Если вы вводите учетные данные в поле на своем клиенте, используется NLA. Если ваш RDP-клиент открывает графический сеанс и вы вводите свой пароль на удаленном сервере, NLA не используется.
Соответствующие настройки
Как я уже сказал, для этого требуются некоторые настройки, какие они?
Мы можем найти их в редакторе групповой политики (GPO) в разделе «Конфигурация компьютера\Административные шаблоны\Система\Делегирование учетных данных».
Некоторые из них являются настройками «Разрешить», а другие — «Запретить». Чтобы быть активными, они должны быть включены, затем должны быть определены один или несколько авторизованных серверов. Например:
Мы видим похожие варианты для разных типов:
Учетные данные по умолчанию
Новые учетные данные
Сохраненные учетные данные
Нас здесь интересуют «учетные данные по умолчанию», поскольку они являются текущими учетными данными для аутентифицированного пользователя. Принимая во внимание, что, если я правильно понял, «свежие учетные данные» — это, например, те, которые вы вводите при подключении к удаленному серверу с помощью RDP, а «сохраненные учетные данные» — это учетные данные, которые вы сохранили в своем хранилище Windows (см. команды mimikatz vault::...) .
Многие учебники и даже инструменты Microsoft, по-видимому, изменяют эти настройки. В полях авторизованных серверов разрешены подстановочные знаки «», и обычно можно увидеть «TERMSRV/» или «TERMSRV/.domain.example.com» («TERMSRV» означает RDP) или то же самое с префиксом «HOST/» , или даже просто «*»! На самом деле в пользовательском интерфейсе упоминаются «серверы», но, поскольку используется нотация имени участника-службы, более уместно говорить об «авторизованных службах», поскольку не все службы, размещенные на сервере, авторизованы. И имена участников-служб могут быть связаны с учетными записями служб, а не только с учетными записями компьютеров.
Параметры в этой папке GPO преобразуются в значения реестра в
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation.
«Разрешить делегирование учетных данных по умолчанию» сопоставляется с «AllowDefaultCredentials», а «Разрешить делегирование учетных данных по умолчанию с проверкой подлинности сервера только NTLM» сопоставляется с «AllowDefCredentialsWhenNTLMOnly».
Вот как выглядит реестр для настроек GPO, установленных выше:
Очевидно, сохраняется и то, что настройки включены, и авторизованный сервер.
Вы заметили флажок «Объединить значения ОС по умолчанию с входными данными выше» (установлен по умолчанию)? Он также сопоставляется с ключами реестра, но что это за «значения ОС по умолчанию»?
Они хранятся в
«HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults»,
но, похоже, у них нет эквивалентов GPO. На моих устройствах они кажутся пустыми/неопределенными, например:
Возможно, в будущих версиях Windows это изменится? ?
Kekeo предлагает команду tsssp::list для красивого отображения содержимого этих разделов реестра:
И, когда ничего не определено:
В заключение, вы должны помнить, что эти параметры являются обязательными для работы «делегирования учетных данных» и что ни один из них не включен и не настроен по умолчанию.
Настройки используются в два разных момента:
Тот факт, что эти настройки используются при входе в систему, означает, что после их включения требуется цикл выхода из системы (или перезагрузка, если вы хотите быть более уверенным).
Как только делегирование учетных данных будет включено, ваш пароль будет сохранен в памяти. Какая конкретная опция включена и с какими авторизованными серверами будет зависеть только то, какую технику использовать и насколько сложно ее сбросить.
Кража учетных данных
Вы наверняка заметили, что есть две похожие настройки:
«Разрешить делегирование учетных данных по умолчанию»: в описании объекта групповой политики указано, что «этот параметр политики применяется, когда аутентификация сервера была достигнута с использованием доверенного сертификата X509 или Kerberos».
«Разрешить делегирование учетных данных по умолчанию с проверкой подлинности сервера только NTLM»: в описании объекта групповой политики говорится, что «этот параметр политики применяется, когда проверка подлинности сервера была достигнута с помощью NTLM».
Если первый параметр включен, обратитесь к первому разделу ниже для «Сервер Kerberos». И если второй параметр включен, обратитесь ко второму разделу ниже для «сервера NTLM».
Сервер Kerberos («Разрешить делегирование учетных данных по умолчанию»)
Вы могли заметить, что авторизованные серверы обозначаются с помощью нотации SPN: «SERVICE/host.fqdn», и это имеет смысл при использовании Kerberos. На самом деле мы должны говорить «авторизованные службы» вместо «авторизованные серверы», поскольку SPN может разрешить только одну службу на хосте.
При использовании CredSSP/TSSSP с Kerberos используется обычный процесс проверки подлинности. Следовательно, SPN, указанный с аргументом «/target» Kekeo, должен существовать, чтобы Служба выдачи билетов могла найти его и доставить нам наш Сервисный билет. Kerberos позволяет клиенту проверить подлинность сервера, с которым он связывается. Таким образом, в дополнение к тому, что аргумент «/ target» должен быть действительным, он должен быть действительным для сервера, к которому мы просим нашего клиента Kekeo подключиться. Более того, общие имена участников-служб, такие как «TERMSRV/…» или «HOST/…», связаны с учетными записями компьютеров, а не с учетными записями пользователей! Поэтому наш сервер Kekeo должен работать как идентификатор целевого сервера. Самый простой способ — запустить его как «NT AUTHORITY\SYSTEM».
Сценарий здесь заключается в том, что вы скомпрометировали авторизованный сервер (через выполнение кода как SYSTEM, или украденный пароль учетной записи компьютера, или украденный TGT для учетной записи компьютера и т. д.) и вы злоупотребляете им для получения паролей пользователей с других компьютеров.
В следующем примере нашим клиентским компьютером является «client.lab.test» (слева), и мы используем удаленный сервер «adcs.lab.test» (справа). Это сервер ADCS (сервер AD PKI), но здесь он не имеет значения, и это может быть любой компьютер Windows, присоединенный к домену. Оба присоединены к AD, а «HOST/adcs.lab.test» авторизован в политике делегирования учетных данных клиентского компьютера. Итак, мы хотим получить пароль для текущего «пользователя», активного на «клиентском» компьютере, благодаря авторизованному серверу «adcs», который мы скомпрометировали. Мы обязательно запускаем сервер Kekeo на «adcs» как SYSTEM, используя «psexec -s» (или один из многих других методов).
У нас есть подтверждение на стороне сервера, что «Kerberos» используется в строке «[Пакет]», и мы получаем на стороне клиента Kekeo учетные данные для пользователя «user», под которым работает клиент Kekeo, с его четким паролем.
Для тех, кому интересно, вот два Service Ticket, полученные в процессе «клиентским» компьютером:
(Если вам интересно, почему нет сервисного билета «TERMSRV/adcs.lab.test», что странно, поскольку мы упомянули RDP SSO, и почему вместо него есть сервисный билет «cifs/adcs.lab.test», я попробую объясните позже, как Kekeo реализует это?).
Сервер NTLM («Разрешить делегирование учетных данных по умолчанию с аутентификацией сервера только NTLM»)
NTLM легче использовать, поскольку клиентский компьютер не может проверить подлинность сервера. Поэтому нам не нужно подделывать личность легитимного авторизованного удаленного сервера, и это работает даже локально.
Для этой демонстрации я решил включить все («разрешить делегирование учетных данных по умолчанию» и «разрешить делегирование учетных данных по умолчанию с аутентификацией сервера только NTLM») для всех серверов («*» для обоих):
Я запускаю два экземпляра Kekeo на одном компьютере. Сначала я запускаю сервер с правой стороны с помощью tsssp::server. Затем я запускаю клиент с левой стороны с помощью tsssp::client /target:A
Мы видим, что учетные данные получены на сервере Kekeo, включая пароль в
открытом виде. Строка «[Пакет]» подтверждает, что используется «NTLM».
Для подтверждения позвольте мне показать вам, что оба экземпляра Kekeo запускаются под пользователем «user», который не является администратором:
Он также работает с удаленным компьютером, если он находится в том же домене. Вам просто нужно обозначить его аргументом «/pipe», например:
tsssp::client /target:B /pipe:\\192.168.42.1\pipe\kekeo_tsssp_endpointПараметр «/target» обязателен, и его значение должно попадать в список авторизованных целей, но это не обязательно должен быть существующий компьютер ?. При использовании NTLM «/target» проверяется политикой клиента, но серверу все равно. Итак, в этом примере, если политика разрешает только «TERMSRV/toto», я должен указать его как «/target», но я могу отправить его на любой сервер (здесь 192.168.42.1 не «toto»), и это все равно работает:
В этой дополнительной демонстрации я включил защиту LSASS, поэтому в нижнем левом окне вы можете видеть, что даже при наличии «NT AUTHORITY\SYSTEM» и после включения привилегии SeDebug (которая на самом деле не требуется) я не могу сбрасывать учетные данные, поскольку mimikatz не может получить доступ к LSASS. Однако с помощью этой
методики я могу получить пароль пользователя «user», под чьим именем я подключаюсь, даже если это не admin.
Обратите внимание, что мои тесты показывают, что это не работает, если включена только настройка «Разрешить делегирование учетных данных по умолчанию с аутентификацией сервера только NTLM»… Параметр «Разрешить делегирование учетных данных по умолчанию», похоже, также требуется.
Устранение неполадок
Прежде чем получить идеальные результаты, представленные выше, я изо всех сил пытался и столкнулся с несколькими ошибками. Я определил их ниже с их возможными объяснениями, основанными на моем понимании (без гарантии правильности).
Первая проблема, которую вы заметите, заключается в том, что иногда она останавливается на несколько секунд в середине операции: это кажется нормальным, и в конце концов она завершается…
Ошибки именованных каналов:
WaitNamedPipe (0x00000002) — «Система не может найти указанный файл»
Ошибка в имени хоста, или имени именованного канала, или сервер не
прослушивается (не забывайте перезапускать tsssp::server при каждой
попытке!)WaitNamedPipe (0x0000052e) — «Ошибка входа в систему: неизвестное имя пользователя или неверный пароль». Сервер не может аутентифицировать клиента. Это может произойти, если сервер не находится в том же домене, что и клиент, или не может связаться с KDC…
Ошибки делегирования учетных данных:
0x8009035E — «Политика клиента не разрешает делегирование учетных данных
целевому серверу». Аргумент «/target» указывает цель, которая не авторизована политикой делегирования учетных данных. Или политика не авторизует ни один
сервер…0x8009030e — «В пакете безопасности нет доступных учетных данных»
Происходит, если политика делегирования учетных данных включена для
«серверов только для NTLM», но не для обычных серверов. Я не знаю,
почему…
Кажется, это также происходит, если мы не вышли из системы и не вошли в
систему после включения делегирования учетных данных. Это кажется
нормальным, так как пароли пользователей еще не сохранены в памяти.0x8009035f — «Политика клиента не разрешает делегирование учетных данных целевому серверу только с аутентификацией NLTM» Сообщение явно: мы пытаемся выполнить делегирование учетных данных с помощью NTLM, но политика не разрешает это. Это означает, что «/ target» отсутствует в политике «NTLM-only server». По умолчанию клиент попытается использовать Kerberos, но в некоторых случаях вернется к NTLM. Если имя участника-службы, указанное с помощью «/target», не зарегистрировано в Active Directory (подключитесь к LDAP или как-то еще и проверьте).
Имейте в виду, что «TERMSRV/<сервер>» не всегда является объявленным именем участника-службы! В отличие от «HOST/<server>», который, кажется, всегда присутствует и должен использоваться вместо него, если он авторизован в политике. Также обратите внимание, что Kerberos можно использовать только с удаленными серверами, так как он отключен на локальном хосте (или любом варианте имени) с помощью детектора обратной связи:
Таким образом, если клиент и сервер Kekeo находятся на одном компьютере, он вернется к NTLM и вызовет эту ошибку, если NTLM не разрешен политикой делегирования учетных данных. (На самом деле, похоже, это работает локально, когда сервер Kekeo работает с TGT другого компьютера… Требуется расследование!)
0x80090322 — «Неверное имя целевого участника». Либо «/target» недействителен (проверьте в AD, что это допустимое объявленное имя участника-службы), либо сервер Kekeo не работает под идентификатором серверного компьютера (т. е. не как СИСТЕМА, или олицетворение учетной записи компьютера не сработало) .
Что делать, если делегирование учетных данных не включено или если политика слишком ограничительна?
Иногда вам очень нужны учетные данные, но делегирование учетных данных не включено или не так, как вы хотели… Тогда вы можете изменить конфигурацию! ? Но при проведении пентеста вы должны сначала получить разрешение, и вы должны максимально избегать изменения конфигурации клиента, особенно когда это означает снижение уровня безопасности, как здесь… В любом случае, не забудьте отменить изменения в их первоначальная стоимость!
Как локальный администратор у вас есть технические разрешения на изменение политики делегирования учетных данных в реестре.
Если делегирование учетных данных не включено, вы можете включить его.
Это позволит вам получить пароли для учетных записей, которые вошли в
систему после изменения.Если делегирование учетных данных включено, но список авторизованных
серверов слишком ограничен, вы можете изменить его в любое время,
например, добавив простой подстановочный знак. Это изменение вступает в
силу немедленно.
Вот несколько команд для включения делегирования учетных данных для всех серверов, использующих Kerberos или NTLM. Опять же, используйте с осторожностью, так как это в основном отключает безопасность…
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefaultCredentials /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefault /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials /v 1 /t REG_SZ /d "*"
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefCredentialsWhenNTLMOnly /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefNTLMOnly /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefCredentialsWhenNTLMOnly /v 1 /t REG_SZ /d "*"
Эти команды взяты из твита Бенджамина @gentilkiwi Delpy, который предложил это для получения паролей в открытом виде. Предлагаемой альтернативой для этого является повторное включение WDigest, но он более популярен и, следовательно, имеет больше шансов вызвать тревогу.
И чтобы сбросить все, удалив все настройки делегирования учетных данных:
reg delete HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /fКак сбросить учетные данные других пользователей?
Во всех демонстрациях выше я получил пароль для пользователя, под которым я запускал клиент Kekeo. Можно возразить, что он менее эффективен, чем sekurlsa::logonpasswords от mimikatz, который сбрасывает учетные данные для всех пользователей с открытыми сессиями.
Найдите время, чтобы подумать о решении здесь…
➡️ Идея состоит в том, чтобы запускать клиент Kekeo в контексте сеанса каждого интересующего вас пользователя.
Для этой демонстрации я запущу свой сервер Kekeo локально под пользователем «user», который не является администратором. Представим, что я добился выполнения команды как SYSTEM и вижу, что у пользователя «admin» есть открытая сессия. Сначала я перечисляю его процессы:
Я буду запускать сервер Kekeo как дочерний процесс его процессов regedit (PID 3344). Таким образом, дочерний процесс Kekeo будет работать не как SYSTEM, а как пользователь «admin».
Я предпочитаю использовать команду mimikatz process::runp, но в вашем распоряжении есть несколько альтернатив.
Команда следующая:
process::runp /pid:3344 /run:"kekeo.exe \"tsssp::client /target:A\" exit"Итак, каков ваш вывод? Разве это не так мощно? ?
Что делать, если авторизованы только определенные серверы?
Как объяснялось выше, вы можете изменить политику, если вы являетесь администратором. Или, если это не так, вы можете выдать себя за авторизованный сервер. Есть несколько способов: золотой билет, обладание хэшем пароля учетной записи компьютера, скомпрометация PKI (и, таким образом, возможность сгенерировать сертификат для целевого сервера)…
Benjamin @gentilkiwi Delpy прекрасно показывает это в своей демо-версии BlueHat.
Как Kekeo это реализует?
Я особо не вникал в детали того, как это реализовано в Kekeo, но ясно, что он не использует протокол RDP (TCP/3389)! Вместо этого он использует удаленный именованный канал между своим клиентом и компонентами сервера через SMB (TCP/445). Помните, я сказал, что CredSSP/TSSSP в основном используется с RDP, но я также сказал, что он используется и другими протоколами, поэтому мы можем предположить, что он также работает по SMB!
Волшебный материал Kekeo с открытым исходным кодом, так что наслаждайтесь чтением kuhl_m_tsssp.c
Как насчет Credential Guard в Защитнике Windows?
Эта функция, которая изолирует LSASS в защищенной виртуальной машине (также называемая «LSAIso»), защищает от этого, согласно сообщению Бенджамина @gentilkiwi Delpy, поскольку она просто отключает CredSSP.
Значит, нет RDP SSO для пользователей Credential Guard?
