Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Сегодня мы разберем «безумную» по сложности машину с Hack The Box. Она называется Pivotapi и посвящена пентесту Active Directory. Нам предстоит заняться OSINT, провести атаку AS-Rep Roasting, декомпилировать приложение на .NET, получить точку опоры через эксфильтрацию данных из Microsoft SQL, взломать базу KeePass, проэксплуатировать LAPS для повышения привилегий и поюзать BloodHound. Программа очень плотная, начинаем немедля!
warning
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
Добавляем IP-адрес машины в /etc/hosts
:
10.10.10.240 pivotapi.htb
И сканируем порты.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта.
#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr 'n' ',' | sed s/,$//)nmap -p$ports -A $1
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A
).
Результат работы скрипта
Мы нашли много открытых портов, давай пройдемся по порядку:
В итоге мы получаем очень важную информацию. Во‑первых, мы можем работать со службой FTP без авторизации, а во‑вторых, SQL Server дал нам имена домена (LICORDEBELLOTA
) и текущей машины (PIVOTAPI
).
Давай скачаем все файлы с FTP-сервера для дальнейшего анализа. Сделаем это с помощью wget
:
wget ftp://pivotapi.htb/*
В документах ничего важного для продвижения не нашлось, но тема интересная — они описывают способы эксплуатации различных уязвимостей. Но, как отмечается в любом курсе OSINT (разведка на основе открытых источников), если мы смогли получить какие‑либо документы, нас могут заинтересовать метаданные, а именно атрибуты «создатель» и «владелец». Из них иногда можно узнать имена, подходящие в качестве логинов. Смотреть эти данные можно разными методами, я воспользуюсь exiftool (устанавливается командой sudo apt install exiftool
).
Свойства документа notes1.pdf
Создав простой конвейер на Bash, получим из всех документов поля Creator
и Author
.
exiftool * | grep "Creator|Author" | awk '{print $3}'
Владельцы и создатели файлов
Откинув сомнительные записи, мы можем составить список из пяти возможных имен пользователей: saif
, byron
, cairo
, Kaorz
, alex
.
Так как на хосте работает Kerberos, мы можем проверить, существует ли какая‑то учетная запись. В этом нам поможет атака ASRep Roasting. Смысл ее в том, что мы посылаем на сервер аутентификации анонимный запрос для предоставления определенному пользователю доступа к какой‑либо услуге. Сервер в ответ:
UAF Don't Require PreAuth
;
Выполнить атаку мы можем с помощью скрипта GetNPUsers, входящего в состав пакета скриптов impacket. Задаем скрипту следующие параметры: контроллер домена (-dc-ip
), способ аутентификации Kerberos (-k
), опция «без пароля» (-no-pass
), список пользователей (-usersfile
) и целевой хост в формате домен/хост
.
GetNPUsers.py -dc-ip 10.10.10.240 -no-pass -k -usersfile users.txt LICORDEBELLOTA/pivotapi.htb
Результат работы скрипта
Нам говорят, что, кроме пользователя Kaorz
, в базе Kerberos больше никого нет, причем для учетной записи Kaorz
сервер аутентификации вернул нам хеш! Давай разберемся, что это за хеши и почему их раздают кому попало.
Дело в том, что, когда клиент посылает сообщение c идентификатором пользователя на сервер аутентификации и запрашивает доступ к услуге для какого‑то пользователя, сервер аутентификации смотрит, есть ли пользователь в базе Kerberos, после чего проверяет его учетные данные. Если учетные данные неверны, сервер отвечает сообщением UAF Don’t Require PreAuth
.
Но есть одно ограничение: у учетной записи пользователя может быть активирован флаг DONT_REQ_PREAUTH
, который означает, что для данной учетной записи не требуется предварительная проверка подлинности Kerberos. Для этого пользователя учетные данные не проверяются и сервер аутентификации генерирует секретный ключ, хешируя пароль пользователя, найденный в базе данных. Получается, мы можем пробрутить хеш и узнать пароль пользователя!
Брутить хеш будем по словарю программой hashcat. При запуске нам нужно передать номер типа хеша (параметр -m
), поэтому сначала узнаем его, запросив справку и отфильтровав только нужный нам тип.
hashcat --example | grep krb5asrep -A2 -B2
Получение номера типа хеша
Искомый номер — 18200. Теперь запускаем перебор, при этом в параметрах указываем перебор по словарю (-a 0
), тип хеша krb5asrep (-m 18200`), файл с хешем и словарь.
hashcat -a 0 -m 18200 hash.krb5asrep ~/wordlists/rockyou.txt
Результат перебора хеша
Очень быстро находим искомый пароль учетной записи Kaorz
. Так как у нас появились учетные данные, нужно попробовать с ними подключиться ко всем доступным ресурсам. FTP учетных данных не требует, поэтому проверим SMB. Для этого я обычно использую утилиту smbmap.
smbmap -u Kaorz -p Roper4155 -H 10.10.10.240
Доступные ресурсы SMB
В выводе получим список доступных ресурсов SMB и разрешения для каждого. Чтобы долго не ходить по директориям и не искать интересные файлы, есть удобная возможность вывести все содержимое ресурсов рекурсивно. Для этого в smbmap нужно указать опцию -R
. Пролистав список, обращаем внимание на каталог HelpDesk
, который содержит исполняемый файл и два файла msg
, то есть какие‑то сообщения.
smbmap -u Kaorz -p Roper4155 -H 10.10.10.240 -R
Содержимое каталога HelpDesk
Чтобы заполучить файлы, можем запустить любой клиент SMB. Я буду использовать smbclient, поскольку он тоже входит в набор impacket.
smbclient.py LicorDeBellota/Kaorz:[email protected]
use NETLOGON
cd HelpDesk
get Restart-OracleService.exe
get Server MSSQL.msg
get WinRM Service.msg
exit
Загрузка файлов с SMB
Файл .msg содержит электронное письмо в формате Microsoft Outlook и включает данные отправителя и получателя, тему и текст письма. Также в виде файла .msg может быть сохранена информация о встрече или ином событии из календаря Outlook, данные контакта из адресной книги, сведения о задаче. Его можно конвертировать в обычный текстовый формат с помощью утилиты msgconvert. Но сначала ее следует установить.
sudo apt install libemail-outlook-message-perl libemail-sender-perl
msgconvert Server MSSQL.msg
msgconvert WinRM Service.msg
Содержимое сообщения Server MSSQL
Содержимое сообщения WinRM Service
В первом сообщении говорится, что в 2010-е годы была установлена база Oracle, но в 2020 году решили перейти на MS SQL. При этом найденное приложение Reset-Service.exe
было создано для рестарта службы Oracle. Что здесь очень важно — это функция логина, то есть приложение работает с учетными данными.
Во втором сообщении упоминается блокировка службы WinRM и исходящего трафика по протоколам TCP, UDP и ICMP.
Перейдем к анализу третьего файла — исполняемого. Откроем его в любом дизассемблере (я использую IDA Pro) и первым делом глянем список импортируемых функций. Это позволит нам составить первое мнение об этой программе и примерно понять, для чего она нужна.
Список импортируемых функций
Обратим внимание на функцию ShellExecuteEx
, которая должна выполнять команды в командной строке. Еще здесь много функций для работы с файлами (DeleteFile
, CreateFile
, GetTempPathW
и прочие). Чтобы наглядно отследить работу с файлами и запуск команд, активируем Process Monitor. После запуска создадим фильтр, который будет отслеживать только наш целевой процесс.
Фильтр Process Monitor
Когда все будет готово, запустим исполняемый файл и просмотрим вывод Process Monitor.
События в Process Monitor
В событиях мы видим создание файлов .tmp и запись (скорее всего, копирование) скрипта .bat. Далее создается процесс командного интерпретатора cmd.exe
. А раз он запускается, то мы можем воспользоваться CMDWatcher. Эта утилита будет приостанавливать процесс и показывать аргументы при запуске CMD в любых процессах. Запустим CMDWatcher, а потом анализируемое приложение. Мы увидим, как запускается приложение, а затем — как активируется сценарий bat.
Событие запуска приложения Restart-OracleService.exe
Событие запуска файла bat
Пройдем в директорию с запускаемым скриптом и увидим в ней сам скрипт и файл с расширением tmp.
Содержимое каталога /AppData/Local/Temp/
Заглянем в скрипт. В начале видим проверку на запуск от имени определенного пользователя. Сразу сохраняем себе его имя — пригодится! Затем данные записываются в файл C:programdataoracle.txt
. Кодировка напоминает Base64.
Содержимое скрипта
После записи создается еще один файл — C:programdatamonta.ps1
, он содержит код на PowerShell. Этот код считывает данные из файла C:programdataoracle.txt
, декодирует их из Base64 и записывает в C:programdatarestart-service.exe
. Затем удаляются и файл с данными Base64, и скрипт на PowerShell и запускается новосозданный исполняемый файл restart-service.exe
. После выполнения он удаляется.
Содержимое скрипта
Давай получим этот исполняемый файл для дальнейшего анализа. Для этого немного модернизируем наш батник: в начале скрипта уберем проверку пользователей, а в конце — любые удаления файлов (команда del
), уберем также запуск создающегося исполняемого файла.
Модернизированный bat-скрипт (начало)
Модернизированный bat-скрипт (конец)
Запустим измененный скрипт, после чего проверим каталог C:programdata
, там нас будет ждать файл с данными, скрипт на PowerShell и целевая программа.
Содержимое каталога C:programdata
Исполняемый файл открываем в IDA Pro, чтобы посмотреть импортируемые функции. Но там не было ничего интересного, а для статического анализа файл великоват. Именно по этой причине я решил использовать приложение API Monitor. Оно может отображать все вызовы API-функций вместе с передаваемыми в них аргументами.
После запуска API Monitor нужно указать целевой исполняемый файл, для чего выбираем Monitor New Process. В разделе справа увидим все вызванные приложением функции.
Стартовое окно приложения API Monitor
Выбор исполняемого файла
Результат анализа файла
Часто вызывается GetProcAddress
. Дело в том, что DLL может загружаться приложением не только статически (при запуске), но и динамически (во время выполнения) с помощью функции LoadLibrary
. А для получения адреса функции в загруженной DLL как раз используется функция GetProcAddress
, которая в качестве параметра получает имя импортируемой функции. Эта техника усложняет статический анализ, а именно скрывает важные функции из таблицы импорта.
Давай узнаем, какие функции хотел спрятать разработчик. Для этого необходимо установить фильтр, чтобы в выводе присутствовали только функции GetProcAddress
. В контекстном меню выбираем Include → API Name.
Установка фильтра
Отфильтрованный список функций API
Сразу видим множество функций для работы с реестром, но это пока ничего не говорит. Чтобы сложить целостную картину, просмотрим абсолютно все загружаемые функции (это займет 5–10 минут). Во время анализа останавливаемся на CreateProcessWithLogonW
. Это важная функция!
Отфильтрованный список API-функций
Она создает новый процесс и его первичный главный поток. Новый процесс затем запускает заданный исполняемый файл в контексте системы безопасности определенного пользователя. Дело в том, что эта функция принимает учетные данные пользователя в качестве аргументов. Давай найдем ее вызов, чтобы получить эти параметры. Для этого выбираем в окне Display пункт Add Filter, а затем указываем условие API Name is CreateProcessWithLogonW
.
Создание фильтра
Событие вызова функции CreateProcessWithLogonW
Обрати внимание на параметры lpUsername
и lpPassword
, где содержатся имя пользователя и его пароль. Так как это учетные данные для сервера базы данных, попробуем на нем и авторизоваться. Увы, моя первая попытка зайти как svc_oracle:#oracle_s3rV1c3!2010
провалилась — сервер ответил, что имя пользователя или пароль неверные.
Источник: xakep.ru