Введение
Поскольку среда становится все более безопасной и контролируемой, злоумышленникам необходимо изобретать новые способы взлома систем, тогда как администраторам и защитникам необходимо предотвращать и обнаруживать такие попытки взлома. За последнее десятилетие обе стороны добились значительных успехов. Если изначально злоумышленники могли просто запускать практически любую полезную нагрузку в системе, пока они не касались диска, то сегодня у защитников гораздо больше видимости благодаря антивирусному программному обеспечению нового поколения, а также программному обеспечению обнаружения и реагирования на конечные точки (EDR), которое постепенно внедряется все больше и больше систем во все большем числе организаций.
Если программное обеспечение EDR запущено и активно контролируется SOC, у злоумышленников есть несколько способов действовать:
- Оставаться незамеченными, внимательно рассматривая возможные телеметрические данные и оповещения, генерируемые для каждого выполняемого действия (что в любом случае полезно делать);
- Попытаться отключить или ослепить программное обеспечение AV/ EDR, уничтожив его процессы или отключив функции, передающие информацию в эти системы безопасности;
- Попытаться остаться вне поля зрения программного обеспечения EDR, углубившись и используя драйверы.
Однако есть еще один путь, который до сих пор еще не очень широко использовался и исследовался. Этот подход заключается в том, чтобы избегать выполнения действий на конечной точке, где работает программное обеспечение EDR, и вместо этого использовать конечную точку в качестве точки поворота на уровне сети в целевую сеть с использованием прокси-сервера SOCKS.
SOCKS уже регулярно используется злоумышленниками для выполнения сценариев через сетевые туннели для выполнения действий против систем в целевой среде. Однако в этой области можно получить гораздо больше, если знать, какие действия системные администраторы Windows могут выполнять со своих административных рабочих станций в системах во всей среде. При выполнении взаимодействия с красной командой оператор красной команды фактически является наступательным администратором в чужой сети; почему бы такому агрессивному администратору не использовать все мощные инструменты и протоколы, встроенные в Windows, для разведки, горизонтального перемещения и действий по повышению привилегий!? Однако для этого требуется расширенная настройка для поддержки маршрутизации таких протоколов, как Kerberos, в целевую среду.
Эта статья помогает опытным специалистам более эффективно использовать SOCKS и наступательные функции инструментов, изначально доступных в Windows, в своих операциях. Кроме того, менее опытным «красным командам» предоставляется комплексное руководство по настройке машины злоумышленника, в котором инструментарий выполняет прозрачную аутентификацию Kerberos в целевой среде, сочетаясь с законными действиями.
Сначала в статье будет обсуждаться настройка виртуальных машин в системе злоумышленника, состоящей из виртуальных машин Linux и Windows, чтобы предоставить атакующей виртуальной машине Windows доступ к целевой сети. В следующей части будет обсуждаться, как получить учетные данные из системы-жертвы в целевой сети, а затем разместить их на атакующей виртуальной машине Windows. После того как все предварительные условия выполнены, предоставляются различные примеры использования атакующей виртуальной машины Windows. Это проиллюстрирует большое разнообразие действий, которые можно выполнять из Windows как в целевом домене, так и в системах и службах в целевом домене, чтобы достичь целей, поставленных для взаимодействия красной команды. Все это возможно, оставаясь при этом незамеченным для программного обеспечения EDR в системе-жертве.
Для проведения наступательных действий на удаленных системах я запустил новую инициативу под названием «Жизнь за счет чужой земли» ( LOFL ). Этот проект служит базой знаний для злоумышленников, администраторов и защитников о том, какие функции Windows предоставляет для удаленного управления другими системами Windows, службами и Active Directory. Жизнь за счет чужой земли ( LOFL ), в отличие от жизни за счет земли ( LOL ), означает, что командлеты и двоичные файлы LOFL ( LOFLCAB ) способны выполнять действия из локальной (наступательной Windows) системы в УДАЛЕННУЮ систему. Каждый из LOFLCAB документирует тип деятельности, которую он может выполнять, например командные строки, возможные случаи оскорбительного использования.
LOFLCAB подразделяются на следующие категории:
- Командлеты PowerShell ( LOFLCmdlet );
- Двоичные файлы, как консольные, так и графические ( LOFLBin );
- Оснастки консоли управления Microsoft ( MMC );
- Скрипты VBS и CMD;
- Классы WMI.
Помимо того, что злоумышленники используют этот проект для использования LOFLCAB для выполнения своих действий, а защитники — для создания правил оповещения для IOC, системные администраторы Windows также могут получить большую выгоду от этого проекта. Этот проект может помочь в эффективном управлении сетью, используя однострочники для прямого использования оснасток MMC на удаленном хосте или используя командлеты и классы WMI в сценариях для быстрого сбора информации в больших масштабах или выполнения действий на нескольких системах одновременно.
Наконец, эта статья и связанный с ней веб-сайт LOFL -Project также могут быть полезны специалистам по реагированию на инциденты безопасности для безопасного сбора информации и выполнения действий против скомпрометированного домена с зараженными серверами и рабочими станциями.
Веб-сайт LOFL-Project, вдохновленный замечательными веб-сайтами LOLBAS и GTFOBins , можно найти по адресу https://lofl-project.github.io/ . Помимо веб-интерфейса, доступны API для программного доступа к LOFLCAB для любой автоматизированной обработки. Более того, скрипты, используемые для установки, доступны в репозитории LOFL GitHub 4 по адресу https://github.com/bitsadmin/lofl .
Поскольку до сих пор я был единственным участником и существует множество LOFLCAB, веб-интерфейс также предоставляет флажок, отображающий записи, которые, как я ожидаю, могут быть использованы в качестве LOFLCAB, однако еще не полностью документированы. Любые запросы на включение в дополнение к ним очень приветствуются в репозитории LOFL-Project GitHub по адресу https://github.com/LOFL-Project/LOFLCAB .
Из-за большого объема данная статья разделена на три части:
- Настройка виртуальной машины Linux для маршрутизации SOCKS (эта статья)
- Настройка виртуальной машины Windows для Kerberos и получение/использование учетных данных: часть 2
- Жизнь за счет чужой земли: Часть 3
Прежде чем углубиться в настройку, вероятно, будет полезно прочитать о возможных атаках со стороны наступательной виртуальной машины Windows злоумышленника с использованием Kerberos в части 3 статьи .
Теперь давайте углубимся в первую часть — настройку виртуальной машины Linux для маршрутизации SOCK!
SOCKS
Поскольку жизнь за границей во многом зависит от SOCKS, эта статья начнется с объяснения того, что такое SOCKS и в чем разница между его различными версиями.
SOCKS
SOCKS означает Socket Secure и представляет собой протокол, используемый для сетевого взаимодействия уровня 4 модели OSI (TCP/UDP) между клиентом и сервером через промежуточный прокси-сервер. SOCKS используется для таких целей, как сокрытие вашего фактического IP-адреса по соображениям конфиденциальности и для доступа к хостам, которые недоступны напрямую. Это выглядит следующим образом.
Когда приложение не настроено на использование SOCKS, оно просто подключается напрямую к целевому хосту. Если это невозможно, соединение прервется. Однако в случае, как на рисунке, есть сервер SOCKS, который может достичь целевого хоста, этот сервер SOCKS может отправлять пакеты, поступающие от клиента к цели, и отправлять ответы от цели обратно клиенту.
В этом примере мы предполагаем, что приложение поддерживает SOCKS, что означает, что его можно настроить на использование сервера SOCKS (2.2.2.2:1080) для любых сетевых подключений. На техническом уровне, когда приложению дается команда на подключение, приложение, работающее на клиенте (1.1.1.1), устанавливает TCP-соединение с сервером SOCKS (2.2.2.2), который по умолчанию прослушивает порт 1080/TCP. Как только соединение установлено, клиент запрашивает SOCKS-сервер подключиться к цели (3.3.3.3), например, через порт 80/TCP. Затем сервер SOCKS пытается установить TCP-соединение с целью (3.3.3.3:80). Предполагая, что соединение установлено успешно, клиент может затем отправлять данные через сервер SOCKS, инкапсулированные в SOCKS, и любые ответы отправляются от цели на сервер SOCKS, который, в свою очередь, отправляет их обратно клиенту. Это эффективно описывает функциональность SOCKS4.
SOCKS4A
SOCKS4A — это незначительное расширение SOCKS4, в котором вместо возможности обмениваться данными только с IP-адресами через SOCKS он также добавляет возможность взаимодействия с именами хостов.
В случае использования SOCKS4A клиентское приложение может запросить сервер SOCKS для установления соединения Target.com:80(в отличие от 3.3.3.3:80 предыдущего примера). Затем SOCKS-сервер разрешит имя домена и установит соединение с ним (в данном случае 3.3.3.3:80). Клиентскому приложению сервер SOCKS сообщает фиктивный IP-адрес частного использования (например 224.0.0.1), который можно использовать только при связи с сервером SOCKS. Всякий раз, когда Клиент через сервер SOCKS пытается подключиться к этому фиктивному IP-адресу, сервер SOCKS проверяет, заканчивается ли соединение правильным хостом, сопоставленным с этим фиктивным IP-адресом.
SOCKS5
В дополнение к SOCKS4A, SOCKS5 добавляет поддержку аутентификации на сервере SOCKS, но, что наиболее важно, поддержку IPv6 и UDP. Поддержка UDP туннелирует дейтаграммы UDP через туннель SOCKS (TCP) на другую целевую сторону и обратно.
Однако имейте в виду, что SOCKS5 является стандартом, но программное обеспечение, реализующее этот стандарт, может реализовывать только часть функций стандарта SOCKS5. На момент написания этой статьи, как будет обсуждаться в следующем разделе, лишь несколько реализаций фактически поддерживают так называемую функцию SOCKS5 UDP ASSOCATE, определенную в стандарте.
Вкратце, в следующей таблице перечислены различные версии SOCKS, их стандарт RFC и поддерживаемые функции.
Программное обеспечение, не поддерживающее SOCKS
Помимо использования приложения со встроенной поддержкой SOCKS, также можно использовать программное обеспечение, такое как proxychains-ng 5 , чтобы заставить программное обеспечение, в котором невозможно настроить SOCKS, для работы через сервер SOCKS. Это достигается с помощью proxychains-ng путем запуска программного обеспечения, которое перехватывает любые функции, связанные с сетевым подключением, и в тот момент, когда программное обеспечение пытается взаимодействовать с сетью, оно в фоновом режиме проверяет использование туннеля SOCKS. Пример использования proxychains-ng для сетевой утилиты netcat выглядит следующим образом: proxychains ncat -v target.com 80. Proxychains загрузит ncat двоичный файл, перехватывающий функции сетевого подключения и принудительно использующий их через прокси, настроенный в /etc/proxychains.conf файле конфигурации proxychain-ng, например, socks4 2.2.2.2 1080.
Теперь понятно, что такое SOCKS и как его можно использовать, на следующем занятии мы обсудим, почему SOCKS так важен для красной команды.
Красная команда и SOCKS
Во время красного наступления часто используется программный имплант C2 для получения доступа к системе в целевой сети. Из этого имплантата, который находится в памяти системы, выполняется код для выполнения операций по разведке, обнаружению, горизонтальному перемещению и в зависимости от цели таких действий, как сбор, эксфильтрация или даже развертывание (поддельных) программ-вымогателей.
Десять лет назад код, выполняемый из имплантата в памяти, раньше представлял собой команды через cmd.exe или сценарии PowerShell. Поскольку обнаружение такого поведения увеличивалось, оно затем перешло на сборки .NET в процессе, порожденном процессом имплантации. В последнее время программное обеспечение для обеспечения безопасности, такое как антивирус нового поколения и программное обеспечение для обнаружения и реагирования на конечные точки ( EDR ), становится все более распространенным и позволяет лучше контролировать действия, происходящие в системе и внутри запущенных процессов. Чтобы повысить операционную безопасность ( OPSEC ), злоумышленники стали чаще использовать объектные файлы маяков (BOF) и сборки .NET, которые выполняются в процессе работы имплантата.
Однако недостатком BOF и сборок .NET, выполняющихся в системе, является то, что программное обеспечение безопасности внимательно следит за процессом маяка и его поведением при взаимодействии с различными API Windows. Программное обеспечение безопасности также может выдать предупреждение в консоли безопасности при достижении порога вредоносных действий. Здесь может помочь SOCKS.
С2
Большинство программ C2 имеют встроенную функциональность SOCKS. После запуска сервера SOCKS на сервере C2 или клиенте C2 в системе злоумышленника открывается порт SOCKS. Затем из системы злоумышленника можно использовать инструменты через туннель SOCKS для подключения к портам целевой сети. В результате имплант C2 используется только в качестве маршрутизатора сетевого трафика уровня 4 OSI и не загружает и не выполняет вредоносный код внутри своей памяти, что приводит к меньшему количеству действий, которые может инициировать программное обеспечение безопасности на конечной точке. На следующей диаграмме показано, как программное обеспечение C2 в системе Victim подключается к серверу C2, а на сервере C2 предоставляется порт SOCKS. Затем злоумышленник может использовать proxychains-ng с netcat, чтобы дать указание SOCKS подключиться к серверу (4.4.4.4) в целевой сети по порту.80/TCP. Затем соединение SOCKS инкапсулируется в трафик C2, и система-жертва, на которой работает (обратный) сервер SOCKS, подключается к серверу через порт 80/TCP.
Помимо использования встроенных функций SOCKS программного обеспечения C2, существуют также различные другие настройки, которые позволяют получить доступ к целевой сети через SOCKS. Эти настройки будут обсуждаться в следующих подразделах.
SSH
Клиент SSH, который в настоящее время присутствует как в Windows, так и в Linux, имеет встроенную функциональность SOCKS. При подключении по SSH к удаленному хосту с помощью SSH-клиента можно указать параметр -Dс номером порта для SSH-клиента, который затем откроет прослушиватель SOCKS4a на клиентском хосте. Например, ssh 2.2.2.2 -D 1080 он подключится к SSH-серверу, работающему на порту 22/TCP, 2.2.2.2 а затем на клиенте ( 1.1.1.1) запустит прослушиватель SOCKS4a на интерфейсе обратной связи на порту 1080/TCP.
Аппаратный имплантат
Во время красного наступления также можно использовать немного более сложную настройку с аппаратным имплантатом, таким как Raspberry Pi, который, например, подключен к сетевой розетке в конференц-зале. Затем этот аппаратный имплант автоматически подключается обратно через ключ 4G/5G к размещенному в сети промежуточному серверу Linux, где в соединении указывается параметр, -R 2222:127.0.0.1:22 раскрывающий порт SSH аппаратного имплантата на промежуточном сервере. Затем это позволяет злоумышленнику подключиться к промежуточному серверу и через порт 2222 этого промежуточного сервера получить доступ к аппаратному имплантату, где снова-D Параметр SSH-клиента используется для запуска SOCKS-сервера на стороне злоумышленника. Это затем предоставляет злоумышленнику доступ к сети, к которой подключен аппаратный имплант. Синие линии на схеме показывают, что эти соединения проходят через ключ 4G/5G аппаратного имплантата.
Reverse SOCKS
Однако часто в качестве «красной команды» получается доступ к конечной точке пользователя, которая недоступна напрямую из Интернета. В таком случае требуется, чтобы скомпрометированная конечная точка инициировала соединение с сервером, контролируемым злоумышленником, что, в свою очередь, позволяет туннелировать SOCKS-трафик через скомпрометированную конечную точку в целевую сеть. К счастью, такие инструменты существуют, и примерами таких инструментов являются Chisel and gost. Диаграмма обратного SOCKS выглядит аналогично схеме C2, за исключением того, что протокол может отличаться от C2 в том смысле, что часто используется TCP-соединение, которое поддерживает соединение, тогда как в C2 часто используется временное HTTP-соединение, которое периодически проверяет, существует ли какие-либо ожидающие действия.
Chisel
Chisel— отличный инструмент, написанный Хайме Пиллорой (@jpillora) на Go, который состоит из клиентского и серверного компонентов и позволяет устанавливать обратные SOCKS-соединения, туннелируемые через HTTP. В репозитории Releases of the Chisel доступны двоичные файлы для различных операционных систем и архитектур. Настроить Chisel очень просто.
- На сервере, контролируемом злоумышленником, запустите Chisel в серверном режиме с флагом, --reverse где порт ( 1234) должен быть доступен из системы-жертвы:chisel server -p 1234 --socks5 --reverse
- На системе-жертве запустите Chisel в клиентском режиме, где указаны IP-адрес и порт сервера:chisel client 2.2.2.2:1234 R:socks
- Как только система-жертва подключится к серверу, сервер откроет порт 1080/TCP, который разрешает входящие соединения SOCKS5.
Обратите внимание, что на момент написания этой статьи реализация SOCKS5 на GitHub jpillora еще не поддерживает функцию UDP ASSOCIATE SOCKS5. Однако форк и запрос на включение , созданные пользователем GitHub Meteorite, поддерживают эту функцию SOCKS5. Двоичные файлы AMD64 для Windows и Linux ( chisel64.exeи chisel64) можно собрать следующим образом:
Gost
Gost — это инструмент, написанный ginuerzh (@ginuerzh), который расшифровывается как GO Simple Tunnel и часто используется для обхода Великого китайского файрвола (GFW). Gost поддерживает множество протоколов и типов транспорта. Кроме того, gost также поддерживает создание сервера SOCKS и перенаправление обратного TCP-порта. Объединив эти две функции, можно создать сервер SOCKS в клиентской (жертве) системе, а затем предоставить доступ к этому серверу SOCKS через обратный порт. Поскольку gost поддерживает так много опций, протоколов и типов транспорта, поначалу его настройка может оказаться сложной задачей, однако его полезно смешивать с другим трафиком. Как и в случае с Chisel, в Релизах репозитория госта доступны двоичные файлы для различных операционных систем и архитектур.
Пример настройки обратного SOCKS-туннеля по протоколу ssh:
- Запустите gost SSH-сервер на сервере, контролируемом злоумышленником, где порт ( 1234) должен быть доступен системе-жертве:gost -L=sshd://:1234
- Запустите SOCKS-сервер и перенаправьте порт на клиентской (жертве) системе:gost.exe -L=socks5://127.0.0.1:4321 -- -L=rtcp://:1080/127.0.0.1:4321 -F=sshd://1.1.1.1:1234
- Как только система-жертва подключится к серверу, сервер откроет порт 1080/TCP, который разрешает входящие соединения SOCKS5.
Следует иметь в виду, что существует две разные версии gost: v2 — устаревшая версия и v3 — версия, перестроенная с нуля. Приведенные выше команды действительны для версии 3 и не тестировались на версии 2. См. ниже таблицу со ссылками на две версии.
Другие варианты
Помимо обратных SOCKS-серверов, существуют и другие ситуации, в которых можно использовать SOCKS.
Рассмотрим, например, инструмент SocksOverRDP 10 , написанный Балашем Буксаем (@xoreipeip), который добавляет модуль к mstsc.exe клиенту RDP ( ) или Citrix на стороне злоумышленника. После запуска серверного компонента SocksOverRDP на стороне сервера RDP/Citrix клиент RDP/Citrix открывает порт SOCKS, через который можно получить доступ к сети, в которой находится сервер RDP/Citrix, через SOCKS.
Другим примером является инструмент под названием Pivotnacci, написанный Элой Перес (@Zer1t0), который можно использовать для перехода через скомпрометированный веб-сервер в сеть, в которой он расположен. Инструменты состоят из скрипта ( .aspx или .jsp) .php, который размещается на веб-сервере, и скрипта Python, который выполняется на стороне злоумышленника и подключается к веб-серверу. После подключения к веб-серверу сценарий Python локально открывает порт SOCKS, который можно использовать для подключения к сети, в которой находится веб-сервер.
Доступно множество других инструментов, которые предлагают некоторую поддержку SOCKS. При выборе инструментов следует учитывать следующие аспекты:
- Поддержка обратного обратного соединения SOCKS: при запуске в системе-жертве он подключается обратно к злоумышленнику, а затем открывает прослушиватель SOCKS в системе злоумышленника, предоставляя доступ к сети, к которой подключена система-жертва;
- Поддержка исходящего прокси-сервера. Корпоративные среды обычно ограничивают порты. Обычно это означает, что системы могут подключаться только к веб-портам ( 80, 443) и, кроме того, требуют, чтобы клиенты использовали исходящий прокси-сервер для доступа в Интернет;
- Поддержка аутентификации прокси-сервера. Если для доступа к Интернету требуется прокси-сервер, некоторым может также потребоваться определенный тип аутентификации, например базовая, NTLM или Kerberos. Если программное обеспечение SOCKS использует библиотеку winhttp.dll, переход через прокси-сервер и, при необходимости, аутентификация на нем выполняются прозрачно. Если эта библиотека не используется, адрес прокси-сервера и учетные данные, возможно, придется указать явно. Как правило, программное обеспечение C2 «под капотом» заботится о любом существующем корпоративном прокси-сервере, который затем также прозрачно используется при активации функциональности SOCKS программного имплантата;
- Необязательно: тип SOCKS, который поддерживается и какие функции протокола реализованы: большинство инструментов поддерживают SOCKS4A, различные инструменты также поддерживают SOCKS5, но лишь некоторые из инструментов, поддерживающих SOCKS5, также реализуют функцию UDP ASSOCIATE.
Список инструментов, которые я рассмотрел, можно найти в Приложении А: Сравнение инструментов SOCKS .
Краткое содержание
В таблице ниже показана сводка настроек SOCKS, которые обсуждались в этом разделе.
Windows, красная команда и SOCKS
Думая о машине злоумышленника, люди обычно сразу думают о системе Linux с дистрибутивом типа Kali или BlackArch с большим количеством хакерских инструментов и скриптов. Однако многие не осознают, что для атак на среды на базе Windows Windows с помощью различных модулей и двоичных файлов PowerShell представляет собой отличную наступательную операционную систему, способную выполнять целый ряд наступательных действий против удаленных систем и служб Windows.
Преимущества использования Windows
При выполнении красного наступления оператор по сути является системным администратором, управляющим чужой средой. Наличие в вашем распоряжении всех инструментов управления Windows вместе с какими-либо учетными данными, которые разрешают вам взаимодействовать со средой, — это, как правило, все, что необходимо для выполнения работы.
Действия, которые можно выполнить из Windows, многочисленны, вот несколько примеров:
- Перечисление и изменение Active Directory;
- Взаимодействие с удаленными системами, проведение разведки активных сессий, системной информации, запущенных процессов;
- Изменение конфигурации удаленной системы через реестр или протоколы Microsoft (иногда недокументированные), используемые различными оснастками консоли управления Microsoft ( MMC );
- Выполнение команд в удаленных системах с помощью различных опций, доступных в Windows.
Возможность выполнять такие действия с компьютера Offensive Windows через SOCKS имеет различные преимущества.
- В системе-жертве в целевой сети не происходит никаких действий, действия которых могут быть обнаружены программным обеспечением безопасности;
- Вместо того, чтобы просто стрелять в окружающую среду из наступательных инструментов, вы изучаете сторону системного администратора (инженерную часть); буквально используя инструменты, которые администраторы используют для управления удаленной сетью;
- Windows регулярно использует недокументированные протоколы, для которых еще не были написаны инструменты/скрипты с открытым исходным кодом (на базе Linux), в то время как Windows изначально взаимодействует с другими системами Windows. Это означает, что злоумышленник может напрямую использовать функции Windows.
- Kerberos изначально используется всякий раз, когда удаленная система запрашивает аутентификацию — подробнее об этом в следующих разделах;
- На компьютер с атакующей Windows можно установить любое стороннее программное обеспечение на базе Windows, которое используется в целевой сети, и использовать его по сети. Более того, можно скопировать программное обеспечение на базе Windows, разработанное целевой организацией, на компьютер с атакующей Windows и использовать его оттуда;
- Хотя датчики сетевой безопасности могут срабатывать в инструментах Linux, таких как реализации некоторых протоколов в Impacket, менее вероятно, что они сработают при использовании встроенных функций Windows и реализаций протоколов;
- При доступе к веб-страницам в целевой организации вместо подделки пользовательского агента используется настоящий браузер на базе Windows, такой как Microsoft Edge или Google Chrome, но при этом остается множество других возможных следов того, что браузер работал на компьютере с Linux.
Инструменты SOCKS в Windows
При поиске в Интернете существуют различные инструменты для Windows, такие как Sockscap64, ProxyCap и Proxifier, которые соксифицируют приложения, чтобы принудительно использовать приложения, которые не поддерживают SOCKS, через туннель SOCKS. Эти инструменты хорошо работают для таких приложений, как браузеры и другие инструменты, которые просто устанавливают соединения, однако связь более низкого уровня и связь, инициируемая, например, внепроцессным COM объекты не проксируются должным образом. Более того, в случае возникновения каких-либо проблем сложно изучить трафик, передаваемый через SOCKS, и выяснить, что происходит не так. Наконец, может быть сложно избирательно выбирать трафик, который должен попасть в целевую среду, как в случае с proxychains-ng: по умолчанию соединения, установленные приложением, использующим соксы, принудительно передаются через туннель SOCKS.
Недостатки использования SOCKS
Помимо проблем с использованием инструментов для соксификации приложений в Windows, у SOCKS также есть ряд проблем, о которых следует знать.
- Прежде всего, для работы SOCKS требуется взаимодействие в реальном времени между злоумышленником и системой-жертвой. Если трафик SOCKS проходит по протоколу C2, например HTTP, который используется по умолчанию для многих платформ C2, это будет очень шумно в скомпрометированной системе и, возможно, между исходящими прокси-серверами или решениями для мониторинга сети. К счастью, в настоящее время соединения, такие как WebSockets или другие протоколы потоковой передачи, очень распространены, поэтому можно установить (дополнительный) канал C2, который использует такой протокол, а затем использовать его для SOCKS. В качестве альтернативы, как обсуждалось в предыдущем разделе, существуют различные инструменты, которые могут хорошо сочетаться с трафиком.
- В зависимости от инструмента и протокола, используемого для связи с удаленной системой, это может быть очень медленно. Например, при перечислении служб, установленных в удаленной системе, для каждой службы выполняется четыре запроса, что приводит к довольно большому количеству циклов обслуживания, которые в настоящее время установлены в системе Windows.
- В отличие от программного имплантата, который работает в контексте определенного пользователя и использует учетные данные этого пользователя при запросе, SOCKS работает только в сети. По этой причине, в случае, если удаленная система выполняет запрос на аутентификацию, машина с атакующей Windows должна иметь учетные данные, готовые для аутентификации, тогда как, если инструмент будет выполняться в системе-жертве, аутентификация, вероятно, будет осуществляться прозрачно. Подробнее о том, как решить эту проблему, читайте в следующих разделах.
В следующих разделах рассматривается проблема, связанная с трудностями маршрутизации трафика Windows через SOCKS. В следующем разделе будет подробно описано, как решить проблему аутентификации на компьютере с атакующей Windows.
Матч, заключенный на небесах
Что, если вместо того, чтобы пытаться заставить Windows выполнять свои действия через SOCKS, мы объединим сильные стороны операционных систем Linux и Windows? Linux отлично справляется с низкоуровневыми манипуляциями с сетью, а операционная система Windows отлично подходит для взаимодействия с удаленными системами Windows. Если с помощью какой-либо конфигурации сети можно убедить Windows в том, что она может напрямую подключаться к сегментам сети, доступным с хоста-жертвы, Windows будет гораздо охотнее сотрудничать.
Чтобы обмануть Windows, несколько лет назад я начал использовать решение, которое заключалось в наличии виртуальных машин Linux и Windows, где на виртуальной машине Linux я параллельно запускал несколько серверов пересылки socat , но через proxychains-ng. Это выглядело следующим образом:
Затем в моей виртуальной машине Windows я добавил новую запись в файл хостов, которая указывала target.victim.com на IP-адрес моей виртуальной машины Linux. После этой настройки можно было поручить Windows, например, составить список сетевых ресурсов target.victim.com, что затем автоматически выполнялось бы с виртуальной машины Windows против виртуальной машины Linux. В свою очередь, виртуальная машина Linux просто перенаправляет трафик через SOCKS на удаленный хост и отправляет обратно все ответы виртуальной машине Windows.
Однако проблема этой установки в том, что она не масштабируема. Всякий раз, когда требуется доступ к другому хосту через тот же порт, прослушиватели socat на виртуальной машине Linux необходимо отключить и запустить новые прослушиватели. Кроме того, в файл хостов Windows необходимо было добавить дополнительные записи, чтобы указать имена хостов в целевой сети на IP-адрес виртуальной машины Linux.
Однако в какой-то момент я обнаружил программное обеспечение badvpn 18 от Амброза Бизьяка, которое содержит утилиту tun2socks. Эта утилита способна использовать недавно созданный интерфейс Tun в Linux, а затем туннелировать любые входящие пакеты через SOCKS-сервер в целевую сеть, а это именно то, что мне нужно! Поскольку в настоящее время проект badvpn больше не поддерживается, отличной заменой является утилита tun2socks 19 от Джейсона Лю (@xjasonlyu), которая регулярно обновляется и на странице «Релизы» представлены скомпилированные версии для различных операционных систем и архитектур.
Сочетая в себе tun2socks с возможностями iptables, маршрутов и DNS-сервера Linux, он обеспечивает идеальную настройку для использования Windows в качестве наступательной платформы! В оставшейся части статьи предполагается, что используется SOCKS-сервер, который не поддерживает функцию UDP ASSOCIATE, которая в настоящее время присутствует в большинстве реализаций. Если эта функция поддерживается , это упрощает настройку некоторых аспектов.
На высоком уровне эта настройка виртуальной машины маршрутизации Linux выглядит следующим образом:
- Наступательная виртуальная машина Windows размещается позади виртуальной машины маршрутизации Linux, поэтому Linux может контролировать весь трафик, исходящий от наступательной виртуальной машины Windows;
- Сетевой интерфейс tun2socks создается и настраивается для доступа к целевой сети через SOCKS;
- С помощью правил iptables настраивается раздельное туннелирование, при котором по умолчанию весь трафик направляется в Интернет, а маршруты для определенных подсетей настраиваются для прохождения через интерфейс tun2socks;
- DNS-сервер (dnsmasq) установлен и настроен в Linux, а виртуальная машина Offensive Windows настроена на использование этого DNS-сервера. Это гарантирует, что DNS-запросы, предназначенные для клиентской сети, отправляются туда, а все остальное отправляется на DNS-сервер Интернета по умолчанию;
Вносятся некоторые исправления, чтобы все работало гладко.
Дополнительным преимуществом этой настройки является то, что по умолчанию Windows довольно разговорчива в сегменте локальной сети. Поскольку эта сеть находится только между виртуальной машиной маршрутизации Linux и виртуальной машиной Offensive Windows, не имеет значения, сколько шума производит Windows, поскольку кроме виртуальной машины маршрутизации Linux, которая ее игнорирует, все равно никто не слушает.
В следующих разделах будет подробно рассмотрена настройка виртуальной машины маршрутизации Linux, тогда как виртуальная машина Offensive Windows будет обсуждаться во второй части этой статьи.
Наступательная установка: маршрутизация виртуальной машины Linux
В следующих подразделах обсуждаются различные шаги по настройке виртуальной машины маршрутизации Linux. Лично для виртуальной машины маршрутизации Linux я использую операционную систему Arch Linux, связанную с репозиторием BlackArch, но подойдет любая операционная система Linux.
Два сетевых интерфейса
Для начала виртуальной машине маршрутизации Linux требуется два сетевых интерфейса. Первый интерфейс ( ens33) используется для подключения виртуальной машины маршрутизации Linux к Интернету. Второй интерфейс ( ens37) используется для внутренней сети между виртуальными машинами Linux и Windows. В своей настройке я использую VMware Workstation, где для соединения между виртуальными машинами Linux и Windows я просто создаю новый сегмент локальной сети, а затем подключаю к нему как второй интерфейс маршрутизирующей виртуальной машины Linux, так и интерфейс атакующей виртуальной машины Windows.
Этому второму интерфейсу необходимо назначить статический IP-адрес. В этой статье IP-адресом будет 10.120.0.1/24, однако всякий раз, когда появляется больше информации об IP-адресах сегмента IP-сети цели, этот IP-адрес и размер подсети можно обновить, чтобы лучше сочетаться с клиентской сетью. Это необходимо, поскольку в некоторых случаях регистрируется внутренний IP-адрес Windows-хоста злоумышленника (да, вы правильно прочитали, его внутренний IP-адрес). Однако имейте в виду, что сегмент сети, используемый между виртуальными машинами Linux и Windows, не маршрутизируется к целевой сети.
Чтобы позволить Linux пересылать трафик между различными сетевыми интерфейсами, настройте флаг ip_forward следующим образом. Этот параметр также можно установить навсегда, поместив его в sysctl.conf. После настройки параметр можно проверить с помощью cat /proc/sys/net/ipv4/ip_forward.
DNS-сервер
В наступательной настройке используется разделенная настройка DNS. Кроме того, дополнительно можно настроить DHCP-сервер на втором сетевом интерфейсе Linux для автоматического назначения IP-адреса атакующим виртуальным машинам Windows, подключенным через этот интерфейс. Для этой цели используется программное обеспечение DNS-сервера dnsmasq 20 , которое можно установить через менеджер пакетов Linux. Затем конфигурацию можно обновить в файле /etc/dnsmasq.conf следующим образом: различные DNS-серверы целевой сети можно собрать с помощью программного имплантата C2.
Настройка начинается с установки порта DNS-сервера на 5353. Причина, по которой это делается, объясняется в следующем заголовке.
Далее настраивается DHCP-сервер, который обслуживает IP-адреса в диапазоне 10.120.0.100 до 10.120.0.200 и время аренды 12 часов, при этом DNS-сервер настроен на IP-адрес виртуальной машины маршрутизации Linux. Затем определяются домены ( ad.bitsadmin.com и corp.int) research.dev целевой сети, где IP-адреса DNS-сервера, ответственные за ad.bitsadmin.com домен, установлены на 10.0.10.10 и 10.0.10.11 это означает, что всякий раз, когда поступает запрос на whatever.ad.bitsadmin.com, один из этих двух IP-адресов запрашивается для разрешения имени.
Строки с in-addr.arpa не являются обязательными, но используются для обратного поиска DNS, что может быть актуально при выполнении разведки через DNS. В этой строке указывается, что всякий раз, когда обратный поиск выполняется для IP-адреса, начинающегося с 10.0.10.x(или 10.0.20.x/ 10.0.30.x соответственно corp.int и research.dev), для выполнения обратного поиска используется IP-адрес, указанный в конце строки.
Наконец, указывается DNS-сервер по умолчанию, в данном случае это DNS-сервер Cloudflare, но может быть любой общедоступный DNS-сервер. Эта конфигурация гарантирует, что только определенные запросы попадают на DNS-серверы целевой сети, в то время как все остальные попадают на общедоступный DNS-сервер и, следовательно, не будут видны в целевой сети. Это необходимо, потому что, например, при запуске Burp DNS-запросы к portswigger.net программой обновлений Burp будут направляться на DNS-сервер в целевой сети, что может вызвать оповещения для команды SOC . При такой настройке такие запросы будут просто отправляться на DNS-сервер Cloudflare.
Всякий раз, когда во время взаимодействия обнаруживаются дополнительные домены, их также можно добавить в этот файл. Обязательно перезапустите службу dnsmasq после обновления файла конфигурации, чтобы изменения вступили в силу.
DNS-сервер и UDP через SOCKS
Как обсуждалось ранее, многие реализации сервера SOCKS не поддерживают функциональность UDP ASSOCIATE, а это означает, что невозможно туннелировать UDP-трафик через туннель SOCKS. К счастью, для этого есть решение. Несмотря на то, что по умолчанию для DNS 53/UDP используется порт, в спецификации DNS указано, что более крупные запросы/ответы также могут выполняться через порт 53/TCP, который поддерживается туннелем SOCKS.
Чтобы все это работало, доступен dns_over_tcp.py сценарий из репозитория LOFL 4 , который делает следующее: При запуске сценария он инициирует прослушиватели как на порту, 53/UDP так и на порту 53/TCP. Это также причина, по которой DNS-сервер dnsmasq должен прослушивать порт 5353, иначе порт 53 уже используется. Более того, dns_over_tcp.py скрипт анализирует /etc/dnsmasq.conf файл конфигурации, где на основе настроенных записей выбираются домены, для которых входящие DNS-запросы необходимо преобразовать в DNS-запрос по TCP.
Всякий раз, когда dns_over_tcp.py на порт поступает DNS-запрос 53/UDP, он проверяет запрошенную запись. Если запись соответствует доменам, указанным в ранее проанализированной конфигурации dnsmasq, DNS-запрос по TCP подделывается и отправляется на порт 5353/TCPDNS-сервера dnsmasq ( 127.0.0.1:5353). Поскольку dnsmasq получает запрос на свой TCP-порт, его поведение заключается в том, что затем он также взаимодействует через TCP с сервером, настроенным для этого домена, что решает проблему неподдерживаемого протокола UDP. Ответ от DNS-сервера целевой сети затем отправляется по TCP из dnsmasq обратно в dns_over_tcp.py сценарий, который просто снова отвечает по UDP клиенту, выполняющему DNS-запрос.
Всякий раз, когда dns_over_tcp.py сценарий получает DNS-запрос на порт 53/UDP, который не соответствует домену в конфигурации dnsmasq, он подключается через UDP к порту 5353 dnsmasq. Поскольку входящий запрос был через UDP, dnsmasq просто использует UDP для подключения к DNS-серверу по умолчанию ( 1.0.0.1) и возвращает ответ сценарию dns_over_tcp.py, который затем возвращается клиенту, выполняющему DNS-запрос.
После настройки dnsmasq и dns_over_tcp.py запуска сценария сервер имен виртуальной машины маршрутизации Linux также можно настроить самостоятельно, выполнив следующие команды, где вторая команда является необязательной, чтобы заблокировать файл /etc/resolv.conf для изменений.
1
Tin2socks
После прослушивания порта SOCKS, обеспечивающего доступ к целевой сети, необходимо настроить tun2socks. Как описано в разделе -=сделанное на небесах=- , двоичные файлы Linux для tun2socks можно получить с сайта tun2socks GitHub 19 .
Утилита tun2socks требует настройки нового туннельного адаптера. Это можно сделать с помощью следующих команд.
С помощью этих команд создается новый туннельный интерфейс. Далее вновь созданному интерфейсу присваивается IP-адрес. Этот IP-адрес является частью блока адресов, зарезервированного для тестирования, поэтому можно с уверенностью предположить, что он не будет использоваться целевой сетью. Наконец, tun1 интерфейс переведен в режим онлайн. В репозитории LOFL create_tun.sh доступна утилита , которая выполняет эти действия автоматически. См. параметры командной строки, которые можно использовать ниже.
После создания tun1 интерфейса командную строку tun2socks можно использовать для связи интерфейса с сервером SOCKS и перенаправления всего трафика на интерфейс tun1 через туннель SOCKS. Эта командная строка выглядит следующим образом.
Как можно видеть, -device параметр указывает интерфейс, который он должен использовать для получения трафика, который затем пересылается через SOCKS. Параметр -proxy указывает, куда должен пересылаться трафик, поступающий на устройство. Прокси-протокол (в данном случае socks4) имеет различные параметры, где для LOFL соответствующими параметрами являются socks4 либо socks5. Дополнительные параметры прокси-протокола можно найти на странице «Модели прокси» в вики-странице tun2socks .
Теперь интерфейс tun1 доступен для передачи трафика в целевую сеть, однако перед его использованием необходимо настроить еще два параметра.
Маршруты
В настоящее время, поскольку для интерфейса еще не настроены маршруты tun1, трафик через этот интерфейс передаваться не будет, а вместо этого весь трафик будет отправляться по маршруту по умолчанию. Такая настройка хороша, потому что, как и при настройке разделенного DNS, для целей OPSEC важно, чтобы в целевую сеть направлялся только соответствующий трафик.
На основе IP-конфигурации системы-жертвы, которая используется для разворота SOCKS, и любой разведки, выполненной при настройке домена, IP-адреса могут быть добавлены в таблицу маршрутизации. На примере лабораторной работы ad.bitsadmin.com можно добавить следующие диапазоны IP-адресов для маршрутизации через туннель SOCKS на tun1.
Альтернативно, в репозитории LOFL доступна утилита add_routes.sh, которая помогает создавать маршруты.
На этом этапе из виртуальной машины маршрутизации Linux теперь можно подключаться к системам в целевой сети. Однако требуется еще один шаг, чтобы обеспечить возможность наступательной виртуальной машины Windows достичь целевой сети.
Iptables
Поскольку атакующая виртуальная машина Windows находится в другом сегменте сети, для виртуальной машины маршрутизации Linux требуется конфигурация преобразования сетевых адресов (NAT) для правильной маскировки трафика, исходящего от атакующей виртуальной машины Windows. Таким образом, наступательная виртуальная машина Windows может отправлять трафик на свой шлюз по умолчанию (маршрутизирующая виртуальная машина Linux), который затем маршрутизируется соответствующим образом на соответствующие шлюзы, которыми является либо Интернет (по умолчанию), либо определенные целевые сетевые подсети, настроенные в предыдущий подраздел. Для этого можно использовать следующие команды.
Альтернативно, в репозитории LOFL доступна утилита iptables_nat.sh, которая помогает создавать правила NAT iptables.
Поскольку используется разделенное туннелирование, правила iptables необходимо настроить как для интерфейсов ens37 к ens33(шлюз по умолчанию), так и для интерфейсов ens37 к tun1(целевая сеть).
Регистрация сетевого трафика
Во время пентеста и мероприятий красной команды рекомендуется вести журналирование взаимодействий с клиентской средой, например сетевого трафика. Настройка LOFL позволяет очень легко регистрировать такой сетевой трафик, просто запустив tcpdump на tun1 интерфейсе. Такая команда выглядит следующим образом.
1
Заключение
После выполнения всех шагов на хосте Linux теперь можно взаимодействовать с целевой сетью, как если бы это была локально подключенная сеть. Это можно, например, проверить путем разрешения записей DNS A домена.
На этом завершается настройка виртуальной машины маршрутизации Linux, позволяющая получать профит, выполняемой с помощью наступательной виртуальной машины Windows. Во второй части этой статьи будет рассмотрена настройка Offensive Windows VM. Более того, во второй части будут подробно описаны различные способы сбора различных типов учетных данных из системы-жертвы и способы их использования из атакующей виртуальной машины Windows.
Поиск неисправностей
Сеть, кажется, не работает
Запустите Wireshark на виртуальной машине маршрутизатора Linux и проверьте трафик, проходящий через туннель SOCKS ( tun1), а также трафик между виртуальной машиной маршрутизатора Linux и атакующей виртуальной машиной Windows ( ens37). Примеры проблем, которые могут здесь возникнуть:
- Если трафик на tun1 не наблюдается, возможно, виртуальная машина маршрутизации Linux настроена неправильно.
-- Убедитесь, что ip_forward флаг ОС установлен в значение true:cat /proc/sys/net/ipv4/ip_forward
-- Проверьте правильность настройки iptables:iptables -nvL
-- Проверьте наличие соответствующих маршрутов:ip route | grep tun1
-- Убедитесь, что tun2socks запущен, не сообщает об ошибках и указаны правильные -device параметры -proxy.
Если на отправленные TCP-пакеты не наблюдаются ответы tun1, убедитесь, что сервер SOCKS работает правильно.
DNS-записи не разрешаются
-Если файл /etc/dnsmasq.conf был только что изменен, обязательно перезапустите и dnsmasq службу, и dns_over_tcp.py скрипт, чтобы применить изменения.
- Убедитесь, что dns_over_tcp.py скрипт запущен и не сообщает об ошибках.
- Дополнительную отладку можно выполнить с помощью dig утилиты, заставляя запросы проходить через TCP для проверки различных звеньев в цепочке.
Порт не отвечает
Имейте в виду, что программное обеспечение tun2socks немного обманчиво. По соображениям производительности, когда пакет TCP SYN отправляется на интерфейс tun2socks ( tun1), интерфейс немедленно отвечает ответом SYN/ACK, не проверяя, действительно ли порт на цели открыт. По этой причине обязательно проверьте выходные данные tun2socks, чтобы увидеть, отображается ли предупреждение для комбинации хост:порт, к которой осуществляется попытка подключения. В качестве альтернативы, используя прокси-цепочки (убедитесь, что в параметре указан правильный сервер/версия SOCKS /etc/proxychains.conf), можно проверить, например ncat, nmap -sT открыт ли порт. См. также будущую работу по возможному исправлению этой проблемы.
Запросы CLDAP не пересылаются должным образом
Известная проблема: по каким-то причинам cldaproxy.sh скрипт не всегда работает корректно. Если LOLFCAB зависает и просмотр сетевого трафика между атакующей виртуальной машиной Windows и виртуальной машиной маршрутизации Linux показывает, что используется CLDAP (389/UDP), перезапуск сценария cldaproxy.sh может решить проблему.
Терминал Windows не принимает ввод
При запуске терминала Windows ( wt.exe) из приглашения с повышенными правами, в котором были подготовлены учетные данные, невозможно использовать ввод с клавиатуры. Это известная проблема с терминалом Windows. Дополнительную информацию см. на странице https://github.com/microsoft/terminal/issues/9971 .
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform
Поскольку среда становится все более безопасной и контролируемой, злоумышленникам необходимо изобретать новые способы взлома систем, тогда как администраторам и защитникам необходимо предотвращать и обнаруживать такие попытки взлома. За последнее десятилетие обе стороны добились значительных успехов. Если изначально злоумышленники могли просто запускать практически любую полезную нагрузку в системе, пока они не касались диска, то сегодня у защитников гораздо больше видимости благодаря антивирусному программному обеспечению нового поколения, а также программному обеспечению обнаружения и реагирования на конечные точки (EDR), которое постепенно внедряется все больше и больше систем во все большем числе организаций.
Если программное обеспечение EDR запущено и активно контролируется SOC, у злоумышленников есть несколько способов действовать:
- Оставаться незамеченными, внимательно рассматривая возможные телеметрические данные и оповещения, генерируемые для каждого выполняемого действия (что в любом случае полезно делать);
- Попытаться отключить или ослепить программное обеспечение AV/ EDR, уничтожив его процессы или отключив функции, передающие информацию в эти системы безопасности;
- Попытаться остаться вне поля зрения программного обеспечения EDR, углубившись и используя драйверы.
Однако есть еще один путь, который до сих пор еще не очень широко использовался и исследовался. Этот подход заключается в том, чтобы избегать выполнения действий на конечной точке, где работает программное обеспечение EDR, и вместо этого использовать конечную точку в качестве точки поворота на уровне сети в целевую сеть с использованием прокси-сервера SOCKS.
SOCKS уже регулярно используется злоумышленниками для выполнения сценариев через сетевые туннели для выполнения действий против систем в целевой среде. Однако в этой области можно получить гораздо больше, если знать, какие действия системные администраторы Windows могут выполнять со своих административных рабочих станций в системах во всей среде. При выполнении взаимодействия с красной командой оператор красной команды фактически является наступательным администратором в чужой сети; почему бы такому агрессивному администратору не использовать все мощные инструменты и протоколы, встроенные в Windows, для разведки, горизонтального перемещения и действий по повышению привилегий!? Однако для этого требуется расширенная настройка для поддержки маршрутизации таких протоколов, как Kerberos, в целевую среду.
Эта статья помогает опытным специалистам более эффективно использовать SOCKS и наступательные функции инструментов, изначально доступных в Windows, в своих операциях. Кроме того, менее опытным «красным командам» предоставляется комплексное руководство по настройке машины злоумышленника, в котором инструментарий выполняет прозрачную аутентификацию Kerberos в целевой среде, сочетаясь с законными действиями.
Сначала в статье будет обсуждаться настройка виртуальных машин в системе злоумышленника, состоящей из виртуальных машин Linux и Windows, чтобы предоставить атакующей виртуальной машине Windows доступ к целевой сети. В следующей части будет обсуждаться, как получить учетные данные из системы-жертвы в целевой сети, а затем разместить их на атакующей виртуальной машине Windows. После того как все предварительные условия выполнены, предоставляются различные примеры использования атакующей виртуальной машины Windows. Это проиллюстрирует большое разнообразие действий, которые можно выполнять из Windows как в целевом домене, так и в системах и службах в целевом домене, чтобы достичь целей, поставленных для взаимодействия красной команды. Все это возможно, оставаясь при этом незамеченным для программного обеспечения EDR в системе-жертве.
Для проведения наступательных действий на удаленных системах я запустил новую инициативу под названием «Жизнь за счет чужой земли» ( LOFL ). Этот проект служит базой знаний для злоумышленников, администраторов и защитников о том, какие функции Windows предоставляет для удаленного управления другими системами Windows, службами и Active Directory. Жизнь за счет чужой земли ( LOFL ), в отличие от жизни за счет земли ( LOL ), означает, что командлеты и двоичные файлы LOFL ( LOFLCAB ) способны выполнять действия из локальной (наступательной Windows) системы в УДАЛЕННУЮ систему. Каждый из LOFLCAB документирует тип деятельности, которую он может выполнять, например командные строки, возможные случаи оскорбительного использования.
LOFLCAB подразделяются на следующие категории:
- Командлеты PowerShell ( LOFLCmdlet );
- Двоичные файлы, как консольные, так и графические ( LOFLBin );
- Оснастки консоли управления Microsoft ( MMC );
- Скрипты VBS и CMD;
- Классы WMI.
Помимо того, что злоумышленники используют этот проект для использования LOFLCAB для выполнения своих действий, а защитники — для создания правил оповещения для IOC, системные администраторы Windows также могут получить большую выгоду от этого проекта. Этот проект может помочь в эффективном управлении сетью, используя однострочники для прямого использования оснасток MMC на удаленном хосте или используя командлеты и классы WMI в сценариях для быстрого сбора информации в больших масштабах или выполнения действий на нескольких системах одновременно.
Наконец, эта статья и связанный с ней веб-сайт LOFL -Project также могут быть полезны специалистам по реагированию на инциденты безопасности для безопасного сбора информации и выполнения действий против скомпрометированного домена с зараженными серверами и рабочими станциями.
Веб-сайт LOFL-Project, вдохновленный замечательными веб-сайтами LOLBAS и GTFOBins , можно найти по адресу https://lofl-project.github.io/ . Помимо веб-интерфейса, доступны API для программного доступа к LOFLCAB для любой автоматизированной обработки. Более того, скрипты, используемые для установки, доступны в репозитории LOFL GitHub 4 по адресу https://github.com/bitsadmin/lofl .
Поскольку до сих пор я был единственным участником и существует множество LOFLCAB, веб-интерфейс также предоставляет флажок, отображающий записи, которые, как я ожидаю, могут быть использованы в качестве LOFLCAB, однако еще не полностью документированы. Любые запросы на включение в дополнение к ним очень приветствуются в репозитории LOFL-Project GitHub по адресу https://github.com/LOFL-Project/LOFLCAB .
Из-за большого объема данная статья разделена на три части:
- Настройка виртуальной машины Linux для маршрутизации SOCKS (эта статья)
- Настройка виртуальной машины Windows для Kerberos и получение/использование учетных данных: часть 2
- Жизнь за счет чужой земли: Часть 3
Прежде чем углубиться в настройку, вероятно, будет полезно прочитать о возможных атаках со стороны наступательной виртуальной машины Windows злоумышленника с использованием Kerberos в части 3 статьи .
Теперь давайте углубимся в первую часть — настройку виртуальной машины Linux для маршрутизации SOCK!
SOCKS
Поскольку жизнь за границей во многом зависит от SOCKS, эта статья начнется с объяснения того, что такое SOCKS и в чем разница между его различными версиями.
SOCKS
SOCKS означает Socket Secure и представляет собой протокол, используемый для сетевого взаимодействия уровня 4 модели OSI (TCP/UDP) между клиентом и сервером через промежуточный прокси-сервер. SOCKS используется для таких целей, как сокрытие вашего фактического IP-адреса по соображениям конфиденциальности и для доступа к хостам, которые недоступны напрямую. Это выглядит следующим образом.
Когда приложение не настроено на использование SOCKS, оно просто подключается напрямую к целевому хосту. Если это невозможно, соединение прервется. Однако в случае, как на рисунке, есть сервер SOCKS, который может достичь целевого хоста, этот сервер SOCKS может отправлять пакеты, поступающие от клиента к цели, и отправлять ответы от цели обратно клиенту.
В этом примере мы предполагаем, что приложение поддерживает SOCKS, что означает, что его можно настроить на использование сервера SOCKS (2.2.2.2:1080) для любых сетевых подключений. На техническом уровне, когда приложению дается команда на подключение, приложение, работающее на клиенте (1.1.1.1), устанавливает TCP-соединение с сервером SOCKS (2.2.2.2), который по умолчанию прослушивает порт 1080/TCP. Как только соединение установлено, клиент запрашивает SOCKS-сервер подключиться к цели (3.3.3.3), например, через порт 80/TCP. Затем сервер SOCKS пытается установить TCP-соединение с целью (3.3.3.3:80). Предполагая, что соединение установлено успешно, клиент может затем отправлять данные через сервер SOCKS, инкапсулированные в SOCKS, и любые ответы отправляются от цели на сервер SOCKS, который, в свою очередь, отправляет их обратно клиенту. Это эффективно описывает функциональность SOCKS4.
SOCKS4A
SOCKS4A — это незначительное расширение SOCKS4, в котором вместо возможности обмениваться данными только с IP-адресами через SOCKS он также добавляет возможность взаимодействия с именами хостов.
В случае использования SOCKS4A клиентское приложение может запросить сервер SOCKS для установления соединения Target.com:80(в отличие от 3.3.3.3:80 предыдущего примера). Затем SOCKS-сервер разрешит имя домена и установит соединение с ним (в данном случае 3.3.3.3:80). Клиентскому приложению сервер SOCKS сообщает фиктивный IP-адрес частного использования (например 224.0.0.1), который можно использовать только при связи с сервером SOCKS. Всякий раз, когда Клиент через сервер SOCKS пытается подключиться к этому фиктивному IP-адресу, сервер SOCKS проверяет, заканчивается ли соединение правильным хостом, сопоставленным с этим фиктивным IP-адресом.
SOCKS5
В дополнение к SOCKS4A, SOCKS5 добавляет поддержку аутентификации на сервере SOCKS, но, что наиболее важно, поддержку IPv6 и UDP. Поддержка UDP туннелирует дейтаграммы UDP через туннель SOCKS (TCP) на другую целевую сторону и обратно.
Однако имейте в виду, что SOCKS5 является стандартом, но программное обеспечение, реализующее этот стандарт, может реализовывать только часть функций стандарта SOCKS5. На момент написания этой статьи, как будет обсуждаться в следующем разделе, лишь несколько реализаций фактически поддерживают так называемую функцию SOCKS5 UDP ASSOCATE, определенную в стандарте.
Вкратце, в следующей таблице перечислены различные версии SOCKS, их стандарт RFC и поддерживаемые функции.
Программное обеспечение, не поддерживающее SOCKS
Помимо использования приложения со встроенной поддержкой SOCKS, также можно использовать программное обеспечение, такое как proxychains-ng 5 , чтобы заставить программное обеспечение, в котором невозможно настроить SOCKS, для работы через сервер SOCKS. Это достигается с помощью proxychains-ng путем запуска программного обеспечения, которое перехватывает любые функции, связанные с сетевым подключением, и в тот момент, когда программное обеспечение пытается взаимодействовать с сетью, оно в фоновом режиме проверяет использование туннеля SOCKS. Пример использования proxychains-ng для сетевой утилиты netcat выглядит следующим образом: proxychains ncat -v target.com 80. Proxychains загрузит ncat двоичный файл, перехватывающий функции сетевого подключения и принудительно использующий их через прокси, настроенный в /etc/proxychains.conf файле конфигурации proxychain-ng, например, socks4 2.2.2.2 1080.
Теперь понятно, что такое SOCKS и как его можно использовать, на следующем занятии мы обсудим, почему SOCKS так важен для красной команды.
Красная команда и SOCKS
Во время красного наступления часто используется программный имплант C2 для получения доступа к системе в целевой сети. Из этого имплантата, который находится в памяти системы, выполняется код для выполнения операций по разведке, обнаружению, горизонтальному перемещению и в зависимости от цели таких действий, как сбор, эксфильтрация или даже развертывание (поддельных) программ-вымогателей.
Десять лет назад код, выполняемый из имплантата в памяти, раньше представлял собой команды через cmd.exe или сценарии PowerShell. Поскольку обнаружение такого поведения увеличивалось, оно затем перешло на сборки .NET в процессе, порожденном процессом имплантации. В последнее время программное обеспечение для обеспечения безопасности, такое как антивирус нового поколения и программное обеспечение для обнаружения и реагирования на конечные точки ( EDR ), становится все более распространенным и позволяет лучше контролировать действия, происходящие в системе и внутри запущенных процессов. Чтобы повысить операционную безопасность ( OPSEC ), злоумышленники стали чаще использовать объектные файлы маяков (BOF) и сборки .NET, которые выполняются в процессе работы имплантата.
Однако недостатком BOF и сборок .NET, выполняющихся в системе, является то, что программное обеспечение безопасности внимательно следит за процессом маяка и его поведением при взаимодействии с различными API Windows. Программное обеспечение безопасности также может выдать предупреждение в консоли безопасности при достижении порога вредоносных действий. Здесь может помочь SOCKS.
С2
Большинство программ C2 имеют встроенную функциональность SOCKS. После запуска сервера SOCKS на сервере C2 или клиенте C2 в системе злоумышленника открывается порт SOCKS. Затем из системы злоумышленника можно использовать инструменты через туннель SOCKS для подключения к портам целевой сети. В результате имплант C2 используется только в качестве маршрутизатора сетевого трафика уровня 4 OSI и не загружает и не выполняет вредоносный код внутри своей памяти, что приводит к меньшему количеству действий, которые может инициировать программное обеспечение безопасности на конечной точке. На следующей диаграмме показано, как программное обеспечение C2 в системе Victim подключается к серверу C2, а на сервере C2 предоставляется порт SOCKS. Затем злоумышленник может использовать proxychains-ng с netcat, чтобы дать указание SOCKS подключиться к серверу (4.4.4.4) в целевой сети по порту.80/TCP. Затем соединение SOCKS инкапсулируется в трафик C2, и система-жертва, на которой работает (обратный) сервер SOCKS, подключается к серверу через порт 80/TCP.
Помимо использования встроенных функций SOCKS программного обеспечения C2, существуют также различные другие настройки, которые позволяют получить доступ к целевой сети через SOCKS. Эти настройки будут обсуждаться в следующих подразделах.
SSH
Клиент SSH, который в настоящее время присутствует как в Windows, так и в Linux, имеет встроенную функциональность SOCKS. При подключении по SSH к удаленному хосту с помощью SSH-клиента можно указать параметр -Dс номером порта для SSH-клиента, который затем откроет прослушиватель SOCKS4a на клиентском хосте. Например, ssh 2.2.2.2 -D 1080 он подключится к SSH-серверу, работающему на порту 22/TCP, 2.2.2.2 а затем на клиенте ( 1.1.1.1) запустит прослушиватель SOCKS4a на интерфейсе обратной связи на порту 1080/TCP.
Аппаратный имплантат
Во время красного наступления также можно использовать немного более сложную настройку с аппаратным имплантатом, таким как Raspberry Pi, который, например, подключен к сетевой розетке в конференц-зале. Затем этот аппаратный имплант автоматически подключается обратно через ключ 4G/5G к размещенному в сети промежуточному серверу Linux, где в соединении указывается параметр, -R 2222:127.0.0.1:22 раскрывающий порт SSH аппаратного имплантата на промежуточном сервере. Затем это позволяет злоумышленнику подключиться к промежуточному серверу и через порт 2222 этого промежуточного сервера получить доступ к аппаратному имплантату, где снова-D Параметр SSH-клиента используется для запуска SOCKS-сервера на стороне злоумышленника. Это затем предоставляет злоумышленнику доступ к сети, к которой подключен аппаратный имплант. Синие линии на схеме показывают, что эти соединения проходят через ключ 4G/5G аппаратного имплантата.
Reverse SOCKS
Однако часто в качестве «красной команды» получается доступ к конечной точке пользователя, которая недоступна напрямую из Интернета. В таком случае требуется, чтобы скомпрометированная конечная точка инициировала соединение с сервером, контролируемым злоумышленником, что, в свою очередь, позволяет туннелировать SOCKS-трафик через скомпрометированную конечную точку в целевую сеть. К счастью, такие инструменты существуют, и примерами таких инструментов являются Chisel and gost. Диаграмма обратного SOCKS выглядит аналогично схеме C2, за исключением того, что протокол может отличаться от C2 в том смысле, что часто используется TCP-соединение, которое поддерживает соединение, тогда как в C2 часто используется временное HTTP-соединение, которое периодически проверяет, существует ли какие-либо ожидающие действия.
Chisel
Chisel— отличный инструмент, написанный Хайме Пиллорой (@jpillora) на Go, который состоит из клиентского и серверного компонентов и позволяет устанавливать обратные SOCKS-соединения, туннелируемые через HTTP. В репозитории Releases of the Chisel доступны двоичные файлы для различных операционных систем и архитектур. Настроить Chisel очень просто.
- На сервере, контролируемом злоумышленником, запустите Chisel в серверном режиме с флагом, --reverse где порт ( 1234) должен быть доступен из системы-жертвы:chisel server -p 1234 --socks5 --reverse
- На системе-жертве запустите Chisel в клиентском режиме, где указаны IP-адрес и порт сервера:chisel client 2.2.2.2:1234 R:socks
- Как только система-жертва подключится к серверу, сервер откроет порт 1080/TCP, который разрешает входящие соединения SOCKS5.
Обратите внимание, что на момент написания этой статьи реализация SOCKS5 на GitHub jpillora еще не поддерживает функцию UDP ASSOCIATE SOCKS5. Однако форк и запрос на включение , созданные пользователем GitHub Meteorite, поддерживают эту функцию SOCKS5. Двоичные файлы AMD64 для Windows и Linux ( chisel64.exeи chisel64) можно собрать следующим образом:
Gost
Gost — это инструмент, написанный ginuerzh (@ginuerzh), который расшифровывается как GO Simple Tunnel и часто используется для обхода Великого китайского файрвола (GFW). Gost поддерживает множество протоколов и типов транспорта. Кроме того, gost также поддерживает создание сервера SOCKS и перенаправление обратного TCP-порта. Объединив эти две функции, можно создать сервер SOCKS в клиентской (жертве) системе, а затем предоставить доступ к этому серверу SOCKS через обратный порт. Поскольку gost поддерживает так много опций, протоколов и типов транспорта, поначалу его настройка может оказаться сложной задачей, однако его полезно смешивать с другим трафиком. Как и в случае с Chisel, в Релизах репозитория госта доступны двоичные файлы для различных операционных систем и архитектур.
Пример настройки обратного SOCKS-туннеля по протоколу ssh:
- Запустите gost SSH-сервер на сервере, контролируемом злоумышленником, где порт ( 1234) должен быть доступен системе-жертве:gost -L=sshd://:1234
- Запустите SOCKS-сервер и перенаправьте порт на клиентской (жертве) системе:gost.exe -L=socks5://127.0.0.1:4321 -- -L=rtcp://:1080/127.0.0.1:4321 -F=sshd://1.1.1.1:1234
- Как только система-жертва подключится к серверу, сервер откроет порт 1080/TCP, который разрешает входящие соединения SOCKS5.
Следует иметь в виду, что существует две разные версии gost: v2 — устаревшая версия и v3 — версия, перестроенная с нуля. Приведенные выше команды действительны для версии 3 и не тестировались на версии 2. См. ниже таблицу со ссылками на две версии.
Другие варианты
Помимо обратных SOCKS-серверов, существуют и другие ситуации, в которых можно использовать SOCKS.
Рассмотрим, например, инструмент SocksOverRDP 10 , написанный Балашем Буксаем (@xoreipeip), который добавляет модуль к mstsc.exe клиенту RDP ( ) или Citrix на стороне злоумышленника. После запуска серверного компонента SocksOverRDP на стороне сервера RDP/Citrix клиент RDP/Citrix открывает порт SOCKS, через который можно получить доступ к сети, в которой находится сервер RDP/Citrix, через SOCKS.
Другим примером является инструмент под названием Pivotnacci, написанный Элой Перес (@Zer1t0), который можно использовать для перехода через скомпрометированный веб-сервер в сеть, в которой он расположен. Инструменты состоят из скрипта ( .aspx или .jsp) .php, который размещается на веб-сервере, и скрипта Python, который выполняется на стороне злоумышленника и подключается к веб-серверу. После подключения к веб-серверу сценарий Python локально открывает порт SOCKS, который можно использовать для подключения к сети, в которой находится веб-сервер.
Доступно множество других инструментов, которые предлагают некоторую поддержку SOCKS. При выборе инструментов следует учитывать следующие аспекты:
- Поддержка обратного обратного соединения SOCKS: при запуске в системе-жертве он подключается обратно к злоумышленнику, а затем открывает прослушиватель SOCKS в системе злоумышленника, предоставляя доступ к сети, к которой подключена система-жертва;
- Поддержка исходящего прокси-сервера. Корпоративные среды обычно ограничивают порты. Обычно это означает, что системы могут подключаться только к веб-портам ( 80, 443) и, кроме того, требуют, чтобы клиенты использовали исходящий прокси-сервер для доступа в Интернет;
- Поддержка аутентификации прокси-сервера. Если для доступа к Интернету требуется прокси-сервер, некоторым может также потребоваться определенный тип аутентификации, например базовая, NTLM или Kerberos. Если программное обеспечение SOCKS использует библиотеку winhttp.dll, переход через прокси-сервер и, при необходимости, аутентификация на нем выполняются прозрачно. Если эта библиотека не используется, адрес прокси-сервера и учетные данные, возможно, придется указать явно. Как правило, программное обеспечение C2 «под капотом» заботится о любом существующем корпоративном прокси-сервере, который затем также прозрачно используется при активации функциональности SOCKS программного имплантата;
- Необязательно: тип SOCKS, который поддерживается и какие функции протокола реализованы: большинство инструментов поддерживают SOCKS4A, различные инструменты также поддерживают SOCKS5, но лишь некоторые из инструментов, поддерживающих SOCKS5, также реализуют функцию UDP ASSOCIATE.
Список инструментов, которые я рассмотрел, можно найти в Приложении А: Сравнение инструментов SOCKS .
Краткое содержание
В таблице ниже показана сводка настроек SOCKS, которые обсуждались в этом разделе.
| Title | Description | Link |
|---|---|---|
| C2 | Программные имплантаты C2 часто имеют встроенную функциональность SOCKS. | https://www.thec2matrix.com/ |
| Linux | Туннелирование SOCKS осуществляется либо путем прямого подключения к серверу Linux с помощью SSH-клиента с параметром -D, либо, в качестве альтернативы, путем размещения аппаратного имплантата в целевой сети, который дозванивается до промежуточного сервера, а затем предоставляет SSH-доступ к аппаратному имплантату. | n/a |
| Chisel | Инструмент туннелирования, который изначально поддерживает обратный SOCKS и предоставляет двоичные файлы для многих платформ и архитектур. Форк Meteorite обеспечивает поддержку функции SOCKS5 UDP ASSOCIATE. | https://github.com/jpillora/chisel |
| gost | Усовершенствованный инструмент туннелирования, который позволяет туннелировать множество протоколов, поддерживая SOCKS и (через rtcp) обратный SOCKS. Предоставляет двоичные файлы для различных платформ и архитектур. | https://github.com/go-gost/gost |
| SocksOverRDP | Туннель SOCKS через динамические виртуальные каналы Microsoft Remote Desktop или Citrix Remote Desktop. | https://github.com/nccgroup/SocksOverRDP |
| pivotnacci | Туннель SOCKS через скомпрометированный веб-сервер (.aspx/.php/.jsp) | https://github.com/blackarrowsec/pivotnacci |
Windows, красная команда и SOCKS
Думая о машине злоумышленника, люди обычно сразу думают о системе Linux с дистрибутивом типа Kali или BlackArch с большим количеством хакерских инструментов и скриптов. Однако многие не осознают, что для атак на среды на базе Windows Windows с помощью различных модулей и двоичных файлов PowerShell представляет собой отличную наступательную операционную систему, способную выполнять целый ряд наступательных действий против удаленных систем и служб Windows.
Преимущества использования Windows
При выполнении красного наступления оператор по сути является системным администратором, управляющим чужой средой. Наличие в вашем распоряжении всех инструментов управления Windows вместе с какими-либо учетными данными, которые разрешают вам взаимодействовать со средой, — это, как правило, все, что необходимо для выполнения работы.
Действия, которые можно выполнить из Windows, многочисленны, вот несколько примеров:
- Перечисление и изменение Active Directory;
- Взаимодействие с удаленными системами, проведение разведки активных сессий, системной информации, запущенных процессов;
- Изменение конфигурации удаленной системы через реестр или протоколы Microsoft (иногда недокументированные), используемые различными оснастками консоли управления Microsoft ( MMC );
- Выполнение команд в удаленных системах с помощью различных опций, доступных в Windows.
Возможность выполнять такие действия с компьютера Offensive Windows через SOCKS имеет различные преимущества.
- В системе-жертве в целевой сети не происходит никаких действий, действия которых могут быть обнаружены программным обеспечением безопасности;
- Вместо того, чтобы просто стрелять в окружающую среду из наступательных инструментов, вы изучаете сторону системного администратора (инженерную часть); буквально используя инструменты, которые администраторы используют для управления удаленной сетью;
- Windows регулярно использует недокументированные протоколы, для которых еще не были написаны инструменты/скрипты с открытым исходным кодом (на базе Linux), в то время как Windows изначально взаимодействует с другими системами Windows. Это означает, что злоумышленник может напрямую использовать функции Windows.
- Kerberos изначально используется всякий раз, когда удаленная система запрашивает аутентификацию — подробнее об этом в следующих разделах;
- На компьютер с атакующей Windows можно установить любое стороннее программное обеспечение на базе Windows, которое используется в целевой сети, и использовать его по сети. Более того, можно скопировать программное обеспечение на базе Windows, разработанное целевой организацией, на компьютер с атакующей Windows и использовать его оттуда;
- Хотя датчики сетевой безопасности могут срабатывать в инструментах Linux, таких как реализации некоторых протоколов в Impacket, менее вероятно, что они сработают при использовании встроенных функций Windows и реализаций протоколов;
- При доступе к веб-страницам в целевой организации вместо подделки пользовательского агента используется настоящий браузер на базе Windows, такой как Microsoft Edge или Google Chrome, но при этом остается множество других возможных следов того, что браузер работал на компьютере с Linux.
Инструменты SOCKS в Windows
При поиске в Интернете существуют различные инструменты для Windows, такие как Sockscap64, ProxyCap и Proxifier, которые соксифицируют приложения, чтобы принудительно использовать приложения, которые не поддерживают SOCKS, через туннель SOCKS. Эти инструменты хорошо работают для таких приложений, как браузеры и другие инструменты, которые просто устанавливают соединения, однако связь более низкого уровня и связь, инициируемая, например, внепроцессным COM объекты не проксируются должным образом. Более того, в случае возникновения каких-либо проблем сложно изучить трафик, передаваемый через SOCKS, и выяснить, что происходит не так. Наконец, может быть сложно избирательно выбирать трафик, который должен попасть в целевую среду, как в случае с proxychains-ng: по умолчанию соединения, установленные приложением, использующим соксы, принудительно передаются через туннель SOCKS.
Недостатки использования SOCKS
Помимо проблем с использованием инструментов для соксификации приложений в Windows, у SOCKS также есть ряд проблем, о которых следует знать.
- Прежде всего, для работы SOCKS требуется взаимодействие в реальном времени между злоумышленником и системой-жертвой. Если трафик SOCKS проходит по протоколу C2, например HTTP, который используется по умолчанию для многих платформ C2, это будет очень шумно в скомпрометированной системе и, возможно, между исходящими прокси-серверами или решениями для мониторинга сети. К счастью, в настоящее время соединения, такие как WebSockets или другие протоколы потоковой передачи, очень распространены, поэтому можно установить (дополнительный) канал C2, который использует такой протокол, а затем использовать его для SOCKS. В качестве альтернативы, как обсуждалось в предыдущем разделе, существуют различные инструменты, которые могут хорошо сочетаться с трафиком.
- В зависимости от инструмента и протокола, используемого для связи с удаленной системой, это может быть очень медленно. Например, при перечислении служб, установленных в удаленной системе, для каждой службы выполняется четыре запроса, что приводит к довольно большому количеству циклов обслуживания, которые в настоящее время установлены в системе Windows.
- В отличие от программного имплантата, который работает в контексте определенного пользователя и использует учетные данные этого пользователя при запросе, SOCKS работает только в сети. По этой причине, в случае, если удаленная система выполняет запрос на аутентификацию, машина с атакующей Windows должна иметь учетные данные, готовые для аутентификации, тогда как, если инструмент будет выполняться в системе-жертве, аутентификация, вероятно, будет осуществляться прозрачно. Подробнее о том, как решить эту проблему, читайте в следующих разделах.
В следующих разделах рассматривается проблема, связанная с трудностями маршрутизации трафика Windows через SOCKS. В следующем разделе будет подробно описано, как решить проблему аутентификации на компьютере с атакующей Windows.
Матч, заключенный на небесах
Что, если вместо того, чтобы пытаться заставить Windows выполнять свои действия через SOCKS, мы объединим сильные стороны операционных систем Linux и Windows? Linux отлично справляется с низкоуровневыми манипуляциями с сетью, а операционная система Windows отлично подходит для взаимодействия с удаленными системами Windows. Если с помощью какой-либо конфигурации сети можно убедить Windows в том, что она может напрямую подключаться к сегментам сети, доступным с хоста-жертвы, Windows будет гораздо охотнее сотрудничать.
Чтобы обмануть Windows, несколько лет назад я начал использовать решение, которое заключалось в наличии виртуальных машин Linux и Windows, где на виртуальной машине Linux я параллельно запускал несколько серверов пересылки socat , но через proxychains-ng. Это выглядело следующим образом:
Затем в моей виртуальной машине Windows я добавил новую запись в файл хостов, которая указывала target.victim.com на IP-адрес моей виртуальной машины Linux. После этой настройки можно было поручить Windows, например, составить список сетевых ресурсов target.victim.com, что затем автоматически выполнялось бы с виртуальной машины Windows против виртуальной машины Linux. В свою очередь, виртуальная машина Linux просто перенаправляет трафик через SOCKS на удаленный хост и отправляет обратно все ответы виртуальной машине Windows.
Однако проблема этой установки в том, что она не масштабируема. Всякий раз, когда требуется доступ к другому хосту через тот же порт, прослушиватели socat на виртуальной машине Linux необходимо отключить и запустить новые прослушиватели. Кроме того, в файл хостов Windows необходимо было добавить дополнительные записи, чтобы указать имена хостов в целевой сети на IP-адрес виртуальной машины Linux.
Однако в какой-то момент я обнаружил программное обеспечение badvpn 18 от Амброза Бизьяка, которое содержит утилиту tun2socks. Эта утилита способна использовать недавно созданный интерфейс Tun в Linux, а затем туннелировать любые входящие пакеты через SOCKS-сервер в целевую сеть, а это именно то, что мне нужно! Поскольку в настоящее время проект badvpn больше не поддерживается, отличной заменой является утилита tun2socks 19 от Джейсона Лю (@xjasonlyu), которая регулярно обновляется и на странице «Релизы» представлены скомпилированные версии для различных операционных систем и архитектур.
Сочетая в себе tun2socks с возможностями iptables, маршрутов и DNS-сервера Linux, он обеспечивает идеальную настройку для использования Windows в качестве наступательной платформы! В оставшейся части статьи предполагается, что используется SOCKS-сервер, который не поддерживает функцию UDP ASSOCIATE, которая в настоящее время присутствует в большинстве реализаций. Если эта функция поддерживается , это упрощает настройку некоторых аспектов.
На высоком уровне эта настройка виртуальной машины маршрутизации Linux выглядит следующим образом:
- Наступательная виртуальная машина Windows размещается позади виртуальной машины маршрутизации Linux, поэтому Linux может контролировать весь трафик, исходящий от наступательной виртуальной машины Windows;
- Сетевой интерфейс tun2socks создается и настраивается для доступа к целевой сети через SOCKS;
- С помощью правил iptables настраивается раздельное туннелирование, при котором по умолчанию весь трафик направляется в Интернет, а маршруты для определенных подсетей настраиваются для прохождения через интерфейс tun2socks;
- DNS-сервер (dnsmasq) установлен и настроен в Linux, а виртуальная машина Offensive Windows настроена на использование этого DNS-сервера. Это гарантирует, что DNS-запросы, предназначенные для клиентской сети, отправляются туда, а все остальное отправляется на DNS-сервер Интернета по умолчанию;
Вносятся некоторые исправления, чтобы все работало гладко.
Дополнительным преимуществом этой настройки является то, что по умолчанию Windows довольно разговорчива в сегменте локальной сети. Поскольку эта сеть находится только между виртуальной машиной маршрутизации Linux и виртуальной машиной Offensive Windows, не имеет значения, сколько шума производит Windows, поскольку кроме виртуальной машины маршрутизации Linux, которая ее игнорирует, все равно никто не слушает.
В следующих разделах будет подробно рассмотрена настройка виртуальной машины маршрутизации Linux, тогда как виртуальная машина Offensive Windows будет обсуждаться во второй части этой статьи.
Наступательная установка: маршрутизация виртуальной машины Linux
В следующих подразделах обсуждаются различные шаги по настройке виртуальной машины маршрутизации Linux. Лично для виртуальной машины маршрутизации Linux я использую операционную систему Arch Linux, связанную с репозиторием BlackArch, но подойдет любая операционная система Linux.
Два сетевых интерфейса
Для начала виртуальной машине маршрутизации Linux требуется два сетевых интерфейса. Первый интерфейс ( ens33) используется для подключения виртуальной машины маршрутизации Linux к Интернету. Второй интерфейс ( ens37) используется для внутренней сети между виртуальными машинами Linux и Windows. В своей настройке я использую VMware Workstation, где для соединения между виртуальными машинами Linux и Windows я просто создаю новый сегмент локальной сети, а затем подключаю к нему как второй интерфейс маршрутизирующей виртуальной машины Linux, так и интерфейс атакующей виртуальной машины Windows.
Этому второму интерфейсу необходимо назначить статический IP-адрес. В этой статье IP-адресом будет 10.120.0.1/24, однако всякий раз, когда появляется больше информации об IP-адресах сегмента IP-сети цели, этот IP-адрес и размер подсети можно обновить, чтобы лучше сочетаться с клиентской сетью. Это необходимо, поскольку в некоторых случаях регистрируется внутренний IP-адрес Windows-хоста злоумышленника (да, вы правильно прочитали, его внутренний IP-адрес). Однако имейте в виду, что сегмент сети, используемый между виртуальными машинами Linux и Windows, не маршрутизируется к целевой сети.
Чтобы позволить Linux пересылать трафик между различными сетевыми интерфейсами, настройте флаг ip_forward следующим образом. Этот параметр также можно установить навсегда, поместив его в sysctl.conf. После настройки параметр можно проверить с помощью cat /proc/sys/net/ipv4/ip_forward.
DNS-сервер
В наступательной настройке используется разделенная настройка DNS. Кроме того, дополнительно можно настроить DHCP-сервер на втором сетевом интерфейсе Linux для автоматического назначения IP-адреса атакующим виртуальным машинам Windows, подключенным через этот интерфейс. Для этой цели используется программное обеспечение DNS-сервера dnsmasq 20 , которое можно установить через менеджер пакетов Linux. Затем конфигурацию можно обновить в файле /etc/dnsmasq.conf следующим образом: различные DNS-серверы целевой сети можно собрать с помощью программного имплантата C2.
Настройка начинается с установки порта DNS-сервера на 5353. Причина, по которой это делается, объясняется в следующем заголовке.
Далее настраивается DHCP-сервер, который обслуживает IP-адреса в диапазоне 10.120.0.100 до 10.120.0.200 и время аренды 12 часов, при этом DNS-сервер настроен на IP-адрес виртуальной машины маршрутизации Linux. Затем определяются домены ( ad.bitsadmin.com и corp.int) research.dev целевой сети, где IP-адреса DNS-сервера, ответственные за ad.bitsadmin.com домен, установлены на 10.0.10.10 и 10.0.10.11 это означает, что всякий раз, когда поступает запрос на whatever.ad.bitsadmin.com, один из этих двух IP-адресов запрашивается для разрешения имени.
Строки с in-addr.arpa не являются обязательными, но используются для обратного поиска DNS, что может быть актуально при выполнении разведки через DNS. В этой строке указывается, что всякий раз, когда обратный поиск выполняется для IP-адреса, начинающегося с 10.0.10.x(или 10.0.20.x/ 10.0.30.x соответственно corp.int и research.dev), для выполнения обратного поиска используется IP-адрес, указанный в конце строки.
Наконец, указывается DNS-сервер по умолчанию, в данном случае это DNS-сервер Cloudflare, но может быть любой общедоступный DNS-сервер. Эта конфигурация гарантирует, что только определенные запросы попадают на DNS-серверы целевой сети, в то время как все остальные попадают на общедоступный DNS-сервер и, следовательно, не будут видны в целевой сети. Это необходимо, потому что, например, при запуске Burp DNS-запросы к portswigger.net программой обновлений Burp будут направляться на DNS-сервер в целевой сети, что может вызвать оповещения для команды SOC . При такой настройке такие запросы будут просто отправляться на DNS-сервер Cloudflare.
Всякий раз, когда во время взаимодействия обнаруживаются дополнительные домены, их также можно добавить в этот файл. Обязательно перезапустите службу dnsmasq после обновления файла конфигурации, чтобы изменения вступили в силу.
DNS-сервер и UDP через SOCKS
Как обсуждалось ранее, многие реализации сервера SOCKS не поддерживают функциональность UDP ASSOCIATE, а это означает, что невозможно туннелировать UDP-трафик через туннель SOCKS. К счастью, для этого есть решение. Несмотря на то, что по умолчанию для DNS 53/UDP используется порт, в спецификации DNS указано, что более крупные запросы/ответы также могут выполняться через порт 53/TCP, который поддерживается туннелем SOCKS.
Чтобы все это работало, доступен dns_over_tcp.py сценарий из репозитория LOFL 4 , который делает следующее: При запуске сценария он инициирует прослушиватели как на порту, 53/UDP так и на порту 53/TCP. Это также причина, по которой DNS-сервер dnsmasq должен прослушивать порт 5353, иначе порт 53 уже используется. Более того, dns_over_tcp.py скрипт анализирует /etc/dnsmasq.conf файл конфигурации, где на основе настроенных записей выбираются домены, для которых входящие DNS-запросы необходимо преобразовать в DNS-запрос по TCP.
Всякий раз, когда dns_over_tcp.py на порт поступает DNS-запрос 53/UDP, он проверяет запрошенную запись. Если запись соответствует доменам, указанным в ранее проанализированной конфигурации dnsmasq, DNS-запрос по TCP подделывается и отправляется на порт 5353/TCPDNS-сервера dnsmasq ( 127.0.0.1:5353). Поскольку dnsmasq получает запрос на свой TCP-порт, его поведение заключается в том, что затем он также взаимодействует через TCP с сервером, настроенным для этого домена, что решает проблему неподдерживаемого протокола UDP. Ответ от DNS-сервера целевой сети затем отправляется по TCP из dnsmasq обратно в dns_over_tcp.py сценарий, который просто снова отвечает по UDP клиенту, выполняющему DNS-запрос.
Всякий раз, когда dns_over_tcp.py сценарий получает DNS-запрос на порт 53/UDP, который не соответствует домену в конфигурации dnsmasq, он подключается через UDP к порту 5353 dnsmasq. Поскольку входящий запрос был через UDP, dnsmasq просто использует UDP для подключения к DNS-серверу по умолчанию ( 1.0.0.1) и возвращает ответ сценарию dns_over_tcp.py, который затем возвращается клиенту, выполняющему DNS-запрос.
После настройки dnsmasq и dns_over_tcp.py запуска сценария сервер имен виртуальной машины маршрутизации Linux также можно настроить самостоятельно, выполнив следующие команды, где вторая команда является необязательной, чтобы заблокировать файл /etc/resolv.conf для изменений.
Tin2socks
После прослушивания порта SOCKS, обеспечивающего доступ к целевой сети, необходимо настроить tun2socks. Как описано в разделе -=сделанное на небесах=- , двоичные файлы Linux для tun2socks можно получить с сайта tun2socks GitHub 19 .
Утилита tun2socks требует настройки нового туннельного адаптера. Это можно сделать с помощью следующих команд.
С помощью этих команд создается новый туннельный интерфейс. Далее вновь созданному интерфейсу присваивается IP-адрес. Этот IP-адрес является частью блока адресов, зарезервированного для тестирования, поэтому можно с уверенностью предположить, что он не будет использоваться целевой сетью. Наконец, tun1 интерфейс переведен в режим онлайн. В репозитории LOFL create_tun.sh доступна утилита , которая выполняет эти действия автоматически. См. параметры командной строки, которые можно использовать ниже.
После создания tun1 интерфейса командную строку tun2socks можно использовать для связи интерфейса с сервером SOCKS и перенаправления всего трафика на интерфейс tun1 через туннель SOCKS. Эта командная строка выглядит следующим образом.
Как можно видеть, -device параметр указывает интерфейс, который он должен использовать для получения трафика, который затем пересылается через SOCKS. Параметр -proxy указывает, куда должен пересылаться трафик, поступающий на устройство. Прокси-протокол (в данном случае socks4) имеет различные параметры, где для LOFL соответствующими параметрами являются socks4 либо socks5. Дополнительные параметры прокси-протокола можно найти на странице «Модели прокси» в вики-странице tun2socks .
Теперь интерфейс tun1 доступен для передачи трафика в целевую сеть, однако перед его использованием необходимо настроить еще два параметра.
Маршруты
В настоящее время, поскольку для интерфейса еще не настроены маршруты tun1, трафик через этот интерфейс передаваться не будет, а вместо этого весь трафик будет отправляться по маршруту по умолчанию. Такая настройка хороша, потому что, как и при настройке разделенного DNS, для целей OPSEC важно, чтобы в целевую сеть направлялся только соответствующий трафик.
На основе IP-конфигурации системы-жертвы, которая используется для разворота SOCKS, и любой разведки, выполненной при настройке домена, IP-адреса могут быть добавлены в таблицу маршрутизации. На примере лабораторной работы ad.bitsadmin.com можно добавить следующие диапазоны IP-адресов для маршрутизации через туннель SOCKS на tun1.
Альтернативно, в репозитории LOFL доступна утилита add_routes.sh, которая помогает создавать маршруты.
На этом этапе из виртуальной машины маршрутизации Linux теперь можно подключаться к системам в целевой сети. Однако требуется еще один шаг, чтобы обеспечить возможность наступательной виртуальной машины Windows достичь целевой сети.
Iptables
Поскольку атакующая виртуальная машина Windows находится в другом сегменте сети, для виртуальной машины маршрутизации Linux требуется конфигурация преобразования сетевых адресов (NAT) для правильной маскировки трафика, исходящего от атакующей виртуальной машины Windows. Таким образом, наступательная виртуальная машина Windows может отправлять трафик на свой шлюз по умолчанию (маршрутизирующая виртуальная машина Linux), который затем маршрутизируется соответствующим образом на соответствующие шлюзы, которыми является либо Интернет (по умолчанию), либо определенные целевые сетевые подсети, настроенные в предыдущий подраздел. Для этого можно использовать следующие команды.
Альтернативно, в репозитории LOFL доступна утилита iptables_nat.sh, которая помогает создавать правила NAT iptables.
Поскольку используется разделенное туннелирование, правила iptables необходимо настроить как для интерфейсов ens37 к ens33(шлюз по умолчанию), так и для интерфейсов ens37 к tun1(целевая сеть).
Регистрация сетевого трафика
Во время пентеста и мероприятий красной команды рекомендуется вести журналирование взаимодействий с клиентской средой, например сетевого трафика. Настройка LOFL позволяет очень легко регистрировать такой сетевой трафик, просто запустив tcpdump на tun1 интерфейсе. Такая команда выглядит следующим образом.
Заключение
После выполнения всех шагов на хосте Linux теперь можно взаимодействовать с целевой сетью, как если бы это была локально подключенная сеть. Это можно, например, проверить путем разрешения записей DNS A домена.
На этом завершается настройка виртуальной машины маршрутизации Linux, позволяющая получать профит, выполняемой с помощью наступательной виртуальной машины Windows. Во второй части этой статьи будет рассмотрена настройка Offensive Windows VM. Более того, во второй части будут подробно описаны различные способы сбора различных типов учетных данных из системы-жертвы и способы их использования из атакующей виртуальной машины Windows.
Поиск неисправностей
Сеть, кажется, не работает
Запустите Wireshark на виртуальной машине маршрутизатора Linux и проверьте трафик, проходящий через туннель SOCKS ( tun1), а также трафик между виртуальной машиной маршрутизатора Linux и атакующей виртуальной машиной Windows ( ens37). Примеры проблем, которые могут здесь возникнуть:
- Если трафик на tun1 не наблюдается, возможно, виртуальная машина маршрутизации Linux настроена неправильно.
-- Убедитесь, что ip_forward флаг ОС установлен в значение true:cat /proc/sys/net/ipv4/ip_forward
-- Проверьте правильность настройки iptables:iptables -nvL
-- Проверьте наличие соответствующих маршрутов:ip route | grep tun1
-- Убедитесь, что tun2socks запущен, не сообщает об ошибках и указаны правильные -device параметры -proxy.
Если на отправленные TCP-пакеты не наблюдаются ответы tun1, убедитесь, что сервер SOCKS работает правильно.
DNS-записи не разрешаются
-Если файл /etc/dnsmasq.conf был только что изменен, обязательно перезапустите и dnsmasq службу, и dns_over_tcp.py скрипт, чтобы применить изменения.
- Убедитесь, что dns_over_tcp.py скрипт запущен и не сообщает об ошибках.
- Дополнительную отладку можно выполнить с помощью dig утилиты, заставляя запросы проходить через TCP для проверки различных звеньев в цепочке.
Порт не отвечает
Имейте в виду, что программное обеспечение tun2socks немного обманчиво. По соображениям производительности, когда пакет TCP SYN отправляется на интерфейс tun2socks ( tun1), интерфейс немедленно отвечает ответом SYN/ACK, не проверяя, действительно ли порт на цели открыт. По этой причине обязательно проверьте выходные данные tun2socks, чтобы увидеть, отображается ли предупреждение для комбинации хост:порт, к которой осуществляется попытка подключения. В качестве альтернативы, используя прокси-цепочки (убедитесь, что в параметре указан правильный сервер/версия SOCKS /etc/proxychains.conf), можно проверить, например ncat, nmap -sT открыт ли порт. См. также будущую работу по возможному исправлению этой проблемы.
Запросы CLDAP не пересылаются должным образом
Известная проблема: по каким-то причинам cldaproxy.sh скрипт не всегда работает корректно. Если LOLFCAB зависает и просмотр сетевого трафика между атакующей виртуальной машиной Windows и виртуальной машиной маршрутизации Linux показывает, что используется CLDAP (389/UDP), перезапуск сценария cldaproxy.sh может решить проблему.
Терминал Windows не принимает ввод
При запуске терминала Windows ( wt.exe) из приглашения с повышенными правами, в котором были подготовлены учетные данные, невозможно использовать ввод с клавиатуры. Это известная проблема с терминалом Windows. Дополнительную информацию см. на странице https://github.com/microsoft/terminal/issues/9971 .
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform
Последнее редактирование: