
Всем привет! Меня зовут Дмитрий Неверов, я руковожу направлением анализа защищенности внутренней инфраструктуры в Бастионе. Сегодня представлю метод локального повышения привилегий на Windows 10.
Сам подход не новый и уже после его тестирования я обнаружил статью, в которой описывается нечто похожее, но с использованием C2 и стороннего хоста. В моем случае есть только один хост.
TL; DR:
Принудительно включаем службу WebClient.
На хосте запускаем NTLMRelayx, в качестве цели указываем контроллер домена и применяем технику Shadow Credentials.
Выполняем принудительную аутентификацию компьютера на самого себя.
С помощью полученного сертификата запрашиваем TGT-билет Kerberos для компьютера.
Используем технику S4U2Self, чтобы получить сервисный билет Kerberos.
Используем SCMUACBypass для получения привилегий SYSTEM.
Предыстория
Обычно на проектах по тестированию инфраструктуры на базе Active Directory заказчик предоставляет нам доменную учетную запись и доменную машину без прав локального администратора. Лично я не особо трачу время на повышение привилегий и сразу иду в инфраструктуру. Но если появляется возможность получить доступ уровня администратора, почему бы и не повыситься? При отсутствии LAPS можно извлечь хэш пароля от локальной учетной записи администратора и проверить его на других хостах или среди пользователей домена.
Напомню, что ретрансляция NTLM-аутентификации из SMB в LDAP заблокирована по умолчанию на контроллерах домена из-за включенной подписи SMB. А вот выполнять ретрансляцию из HTTP в LDAP можно (пока). При этом сама машина имеет возможность изменять свои атрибуты. Это открывает возможности для техник вроде:
RBCD (делегирование Kerberos на основе ресурсов);
Shadow Credentials (теневые учетные записи).
При выполнении работ мы собираем информацию о запущенной службе WebClient на доступных компьютерах, выполняем принудительную аутентификацию компьютера и ретранслируем NTLM-аутентификацию на контроллер домена для настройки атрибутов. Затем используем наши настройки для получения удаленного доступа к хосту с правами локального администратора.
Мой коллега Евгений Комзалов обнаружил, что принудительную аутентификацию компьютера можно использовать локально и в качестве слушателя можно указать этот же хост. Получается некая вариация SelfCoerce. Основная идея подхода — использовать службу WebClient для ретрансляции NTLM-аутентификации в LDAP, чтобы получить локальное повышение привилегий.
Подготовка
Для выполнения атаки была подготовлена лаборатория:
WS-536 — доменная рабочая станция с Windows 10 с последними обновлениями;
DC01 — контроллер домена с поддержкой PKINIT;
Pentester — доменная учетная запись без привилегий в домене, имеющая удаленный доступ на компьютер WS-536 по протоколу RDP.
Используемые инструменты:
NTLMRelayx — используется для ретрансляции NTLM-аутентификации и включении службы «WebClient»;
Coercer — используется для выполнения принудительной аутентификации;
Rubeus — утилита для работы с Kerberos;
SCMUACBypass — утилита для получения консоли с правами SYSTEM.
Эксплуатация
Теперь, когда все готово, можно приступить к эксплуатации.
Принудительное включение службы WebClient
Есть несколько способов включить WebClient на хосте без привилегий локального администратора. Рассмотрим один из них.
Запускаем консоль PowerShell и проверяем статус службы WebClient:
Get-Service WebClient
Если служба остановлена, то запускаем NTLMRelayx. В качестве цели указываем любой хост, на данном этапе это совершенно не важно.
Так как у нас нет привилегий локального администратора, мы не можем использовать smbserver
. Поэтому укажем ключ --no-smb-server
при запуске NTLMRelayx:
.\ntlmrelayx.exe -t ldap://blah.domain.local --no-smb-server
Теперь нам нужно спровоцировать систему на запуск службы WebClient. Если обратиться из проводника по UNC-пути и указать 80 порт, то WebClient запустится автоматически при попытке подключения. А почему бы при запущенном NTLMRelayx не обратиться к самому себе? Запускаем проводник и в адресной строке выполняем следующий запрос:
\\ws-536@80\test.txt
Другой вариант — использовать PowerShell. Запускаем новую консоль PowerShell и выполняем следующую команду:
$cred = Get-Credential
New-PSDrive -Name "Temp" -PSProvider "FileSystem" -Root "\\ws-536\share" -Credential $cred
Важно: указывайте только имя компьютера без домена, иначе трюк не сработает.
В консоли, где запущен NTLMRelayx, можно обнаружить, что программа выдала ошибку, что такого хоста не существует. Останавливаем выполнение команд в двух консолях с помощью CTRL+C и проверяем, что служба WebClient запустилась.

В результате получаем запущенную службу WebClient.
Выполнение техники Shadow Credentials
Запустим NTLMRelayx. В качестве цели укажем контроллер домена, а в качестве полезной нагрузки — технику Shadow Credentials:
.\ntlmrelayx.exe -t ldaps://dc01.domain.local --no-smb-server --shadow-credentials --shadow-target 'ws-536$'
Как работает PKINIT и почему это важно для атаки
В Active Directory реализован механизм предварительной аутентификации Kerberos с использованием асимметричных ключей, известный как PKINIT. У клиента есть пара открытого и закрытого ключа, он шифрует данные предварительной аутентификации Kerberos своим закрытым ключом, а KDC расшифровывает его открытым ключом клиента. Обмен открытыми ключами происходит с помощью центра сертификации, который поддерживает Certificate Trust. Обычно этот метод применяется для сертификатов и смарт-карт.
Начиная с Windows Server 2016 Microsoft реализовала поддержку Key Trust, в котором доверие устанавливается на основе ключей, а не сертификатов. Открытый ключ клиента хранится в многозначном атрибуте msDS-KeyCredentialLink
. Хотя эта реализация не требует выпуска сертификатов, KDC по-прежнему необходим собственный сертификат для обмена сеансовыми ключами. Это означает, что в инфраструктуре должен быть развернут центр сертификации.
Таким образом, если атакующий может записывать данные в атрибут msDS-KeyCredentialLink
, у него появляется возможность получить TGT для клиента. Но помимо возможности изменения атрибута для злоупотребления должны выполняться следующие условия:
В домене должен быть хотя бы один контроллер домена под управлением Windows Server 2016 и выше.
Контроллер домена должен иметь действующую пару открытого и закрытого ключей, то есть в инфраструктуре должен быть настроен центр сертификации (ADCS) или использоваться сторонний удостоверяющий центр (CA). Проверить это можно, выполнив команду
certutil.exe
.
Если условия не выполняются, придется пойти другим путем и в качестве полезной нагрузки использовать настройку RBCD.
Теперь выполним принудительную аутентификацию текущей машины на нее саму, используя службу WebClient:
.\coercer.exe -d domain.local -u pentester -p Qwerty123 -wh localhost -t ws-536
В результате мы получим сертификат и пароль от него:

Получение TGT-билета через PKINIT
Полученный сертификат можно использовать для получения TGT-билета Kerberos для учетной записи нашей машины. Для этого воспользуемся утилитой Rubeus.
Сначала удалим текущие билеты:
.\Rubeus.exe purge
Теперь запросим TGT-билет Kerberos:
.\Rubeus.exe asktgt /user:ws-536$ /certificate:G4LrRzpE.pfx /password:jXTIRX0oywZFQM9u52DM
/domain:domain.local /nowrap

Выполнение S4U2Self для получения сервисного билета
S4U2Self позволяет службе получить билет службы от имени пользователя для себя. Это расширение может использоваться любой учетной записью, имеющей хотя бы один SPN.
Его также можно использовать для создания сервисного билета самому себе от имени другого пользователя домена, даже если этот пользователь является «чувствительным к делегированию» или входит в группу Protected Users с усиленной защитой от злоупотреблений в Kerberos.
Запрашиваем сервисный билет с использованием S4U2Self и полученным ранее TGT-билетом Kerberos для компьютера. Учетная запись администратора домена admin
будет использоваться для имперсонализации.
.\Rubeus.exe s4u /self /user:ws-536$ /impersonateuser:admin /altservice:host/ws-536 /ptt /ticket:<base64>

Получение привилегий SYSTEM
Завершающим шагом запустим SCMUACBypass для получения консоли с правами SYSTEM:

Стоит учитывать, что иногда SCMUACBypass не запускается нормально и не выводит никаких ошибок.
Приводим систему к исходному виду
После эксплуатации желательно очистить следы, чтобы не оставлять в системе «зацепок».
От SYSTEM удаляем установленную службу:
sc.exe delete UacBypassedService
Если не удалить службу, при выполнении команды Start-Service UacBypassedService будет появляться консоль с правами SYSTEM.
В контексте компьютера очистить атрибут «msDS-KeyCredentialLink» с помощью Whisker:
.\Whisker.exe clear /target:ws-536$
Заключение
Метод остается рабочим в актуальных версиях Windows 10, если не приняты меры защиты. Используйте его только в легитимных целях — в рамках пентеста или оценки защищенности.
Чтобы предотвратить подобные атаки, рекомендую:
включить LDAP Signing и LDAP Binding на контроллерах домена;
заблокировать запуск службы WebClient через групповые политики;
настроить фильтры для RPC, чтобы предотвратить возможность принудительной аутентификации.