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

Brute RDP

Отслеживать

Leonard123

RAID-массив
Пользователь
Регистрация
26.04.2021
Сообщения
75
Реакции
5
Подскажите, как при брут форсе RDP сделать так что бы каждый новый запрос отправлялся с нового ip? Поможет ли tor если написать скрипт который будет перезапускать его каждую секунду?
 
Leonard123 сказал(а):
Поможет ли tor если написать скрипт который будет перезапускать его каждую секунду?
Брутить rdp (да в принципе что угодно, где важна высокая скорость и точность результатов) через тор - это надежно и быстро дичь, особенно на обьемах. Вообще тор и скорость не совместимы, т.к. "быстрый тор" это оксюморон, типа "горячий снег" или "сухой дождь".
Скрипт не нужен, он там есть, torrc называется (т.е. конфиг). В torrc можешь прописать NewCircuitPeriod N , для создания нового контура по истечении этого временного промежутка. N - это в секундах, по дефолту при обьявленном параметре но пустом значении - вроде 30, хоть 0.5 ставь (мне))) низкие значения ставить нинада
Однако соединение будет крайне нестабильно, высокие значения таймаутов не помогут т.к. предыдущая цепочка будет сбрасываться раньше чем они истекут, следовательно будет большая потеря пакетов да и само построение цепочки занимает n времени + мосты при низком значении NewCircuitPeriod лучше не использовать совсем, если нужна скорость или наоборот использовать, если важна точность, т.к. дополнительный узел в цепи (в данном случае речь за именно за мост) = минус скорость и плюс более стабильное соединение. Так же поиграйся в доп. к NewCircuitPeriod с параметрами:
  • MaxCircuitDirtiness: Этот параметр определяет максимальное время (в секундах), в течение которого цепь может оставаться открытой, прежде чем она будет закрыта. По умолчанию, это значение равно 10 минутам. Это означает, что если цепь не используется в течение 10 минут, она будет закрыта, что помогает обеспечить безопасность и анонимность пользователей.
  • CircuitStreamTimeout: Этот параметр определяет максимальное время ожидания (в секундах) для потока внутри цепи, прежде чем он будет закрыт. По умолчанию, это значение равно 60 секундам. Это помогает предотвратить утечку информации через долгоживущие потоки.
  • CircuitBuildTimeout: Этот параметр определяет максимальное время ожидания (в секундах) для построения цепи, прежде чем она будет закрыта. По умолчанию, это значение равно 60 секундам. Это помогает предотвратить утечку информации через неудачные попытки построения цепей.
  • CircuitIdleTimeout: Этот параметр определяет максимальное время (в секундах), в течение которого цепь может оставаться открытой без активности, прежде чем она будет закрыта. По умолчанию, это значение равно 10 минутам. Это помогает обеспечить безопасность и анонимность пользователей, предотвращая утечку информации через долгоживущие, но неактивные цепи.
Оптимальный вариант - тебе надо поискать хороший сервис носков с ротацией, обратись к вендору используемого софта (если он с форумов), он посоветует наиболее подходящий сервис под его продукт.
 
Последнее редактирование:
А есть какой
Desoxyn сказал(а):
Брутить rdp (да в принципе что угодно, где важна высокая скорость и точность результатов) через тор - это надежно и быстро дичь, особенно на обьемах. Вообще тор и скорость не совместимы, т.к. "быстрый тор" это оксюморон, типа "горячий снег" или "сухой дождь".
Скрипт не нужен, он там есть, torrc называется (т.е. конфиг). В torrc можешь прописать NewCircuitPeriod N , для создания нового контура по истечении это временного промежутка. N - это в секундах, по дефолту при обьявленном параметре но пустом значении - вроде 30, хоть 0.5 ставь (мне))) низкие значения ставить нинада
Однако соедениние будет крайне нестабильно, высокие значения таймаутов не помогут т.к. предыдущая цепочка будет сбрасываться раньше чем они истекут, следовательно будет большая потеря пакетов да и само построение цепочки занимает n времени + мосты при низком значении NewCircuitPeriod лучше не использовать совсем, если нужна скорость или наоборот использовать, если важна точность, т.к. дополнительный узел в цепи (в данном случае речь за именно за мост) = минус скорость и плюс более стабильное соединение. Так же поиграйся в доп. к NewCircuitPeriod с параметрами:
  • MaxCircuitDirtiness: Этот параметр определяет максимальное время (в секундах), в течение которого цепь может оставаться открытой, прежде чем она будет закрыта. По умолчанию, это значение равно 10 минутам. Это означает, что если цепь не используется в течение 10 минут, она будет закрыта, что помогает обеспечить безопасность и анонимность пользователей.
  • CircuitStreamTimeout: Этот параметр определяет максимальное время ожидания (в секундах) для потока внутри цепи, прежде чем он будет закрыт. По умолчанию, это значение равно 60 секундам. Это помогает предотвратить утечку информации через долгоживущие потоки.
  • CircuitBuildTimeout: Этот параметр определяет максимальное время ожидания (в секундах) для построения цепи, прежде чем она будет закрыта. По умолчанию, это значение равно 60 секундам. Это помогает предотвратить утечку информации через неудачные попытки построения цепей.
  • CircuitIdleTimeout: Этот параметр определяет максимальное время (в секундах), в течение которого цепь может оставаться открытой без активности, прежде чем она будет закрыта. По умолчанию, это значение равно 10 минутам. Это помогает обеспечить безопасность и анонимность пользователей, предотвращая утечку информации через долгоживущие, но неактивные цепи.
Оптимальный вариант - тебе надо поискать хороший сервис носков с ротацией, обратись к вендору используемого софта (если он с форумов), он посоветует наиболее подходящий сервис под его продукт.
А есть софт какой нибудь что бы ип менялся постоянно? К примеру взять список прокси, закинуть туда и что бы всё работало ? Для брута RDP я хочу использовать crowbar, в документации ничего не сказано про использование прокси
 
Leonard123 сказал(а):
А есть какой

А есть софт какой нибудь что бы ип менялся постоянно? К примеру взять список прокси, закинуть туда и что бы всё работало ? Для брута RDP я хочу использовать crowbar, в документации ничего не сказано про использование прокси
NLBrute брутить рдп поищи на гите слитый, есть платная есть кряк
 
Homeless сказал(а):
NLBrute брутить рдп поищи на гите слитый, есть платная есть кряк
Я про смену ip , в соседней теме говорили что NLBrute прошлый век, чем он по твоему лучше?
 
Leonard123 сказал(а):
А есть софт какой нибудь что бы ип менялся постоянно? К примеру взять список прокси, закинуть туда и что бы всё работало ? Для брута RDP я хочу использовать crowbar, в документации ничего не сказано про использование прокси
https://github.com/nadoo/glider
Кроссплатформенный (go)
Конфиг для примера:

Код: 
listen=mixed://admin:admin@0.0.0.0:8888

strategy=lha
maxfailures=1
dialtimeout=2
check=http://www.msftconnecttest.com/connecttest.txt#expect=200
checkinterval=120
checktimeout=3
checktolerance=50

forward=socks4://1.2.3.4:5678
forward=socks5://2.3.4.5:6789
forward=http://proxy.hyets:3128
forward=ssh://john@5.5.5.5:22?key=/keys/.ssh/id_rsa

Конфиг у кого то подсмотрел, сорри, не помню у кого ))) Так бы тэгнул.

По конфигу:
  • listen=mixed://admin:admin@0.0.0.0:8888 указывает, что листенер будет висеть на порту 8888 и поддерживать как HTTP, так и SOCKS прокси, используя basic auth для аутентификации (авторизацию можно не указывать, просто как пример, что она поддерживается)
  • strategy=lha задает стратегию переключения между прокси-серверами как Latency based High Availability (высокая доступность на основе задержки), что позволяет переключаться между прокси-серверами в зависимости от их задержки.
  • maxfailures=1 устанавливает максимальное количество неудачных попыток подключения перед тем, как прокси-сервер будет отключен.
  • dialtimeout=2 задает таймаут подключения в секундах.
  • check=http://www.msftconnecttest.com/connecttest.txt#expect=200 и связанные с ним параметры (checkinterval, checktimeout, checktolerance) используются для периодической проверки доступности прокси-серверов.
  • forward указывает список прокси-серверов, между которыми Glider будет переключаться в соответсвии с заданными выше правилами.
 
Спасибо, а как вот этот может подой
Desoxyn сказал(а):
https://github.com/nadoo/glider
Кроссплатформенный (go)
Конфиг для примера:

Код: 
listen=mixed://admin:admin@0.0.0.0:8888

strategy=lha
maxfailures=1
dialtimeout=2
check=http://www.msftconnecttest.com/connecttest.txt#expect=200
checkinterval=120
checktimeout=3
checktolerance=50

forward=socks4://1.2.3.4:5678
forward=socks5://2.3.4.5:6789
forward=http://proxy.hyets:3128
forward=ssh://john@5.5.5.5:22?key=/keys/.ssh/id_rsa

Конфиг у кого то подсмотрел, сорри, не помню у кого ))) Так бы тэгнул.

По конфигу:
  • listen=mixed://admin:admin@0.0.0.0:8888 указывает, что листенер будет висеть на порту 8888 и поддерживать как HTTP, так и SOCKS прокси, используя basic auth для аутентификации (авторизацию можно не указывать, просто как пример, что она поддерживается)
  • strategy=lha задает стратегию переключения между прокси-серверами как Latency based High Availability (высокая доступность на основе задержки), что позволяет переключаться между прокси-серверами в зависимости от их задержки.
  • maxfailures=1 устанавливает максимальное количество неудачных попыток подключения перед тем, как прокси-сервер будет отключен.
  • dialtimeout=2 задает таймаут подключения в секундах.
  • check=http://www.msftconnecttest.com/connecttest.txt#expect=200 и связанные с ним параметры (checkinterval, checktimeout, checktolerance) используются для периодической проверки доступности прокси-серверов.
  • forward указывает список прокси-серверов, между которыми Glider будет переключаться в соответсвии с заданными выше правилами.
Спасибо! Как думаешь этот может подойти? https://github.com/kitabisa/mubeng
 
Desoxyn сказал(а):
https://github.com/nadoo/glider
Кроссплатформенный (go)
Конфиг для примера:

Код: 
listen=mixed://admin:admin@0.0.0.0:8888

strategy=lha
maxfailures=1
dialtimeout=2
check=http://www.msftconnecttest.com/connecttest.txt#expect=200
checkinterval=120
checktimeout=3
checktolerance=50

forward=socks4://1.2.3.4:5678
forward=socks5://2.3.4.5:6789
forward=http://proxy.hyets:3128
forward=ssh://john@5.5.5.5:22?key=/keys/.ssh/id_rsa

Конфиг у кого то подсмотрел, сорри, не помню у кого ))) Так бы тэгнул.

По конфигу:
  • listen=mixed://admin:admin@0.0.0.0:8888 указывает, что листенер будет висеть на порту 8888 и поддерживать как HTTP, так и SOCKS прокси, используя basic auth для аутентификации (авторизацию можно не указывать, просто как пример, что она поддерживается)
  • strategy=lha задает стратегию переключения между прокси-серверами как Latency based High Availability (высокая доступность на основе задержки), что позволяет переключаться между прокси-серверами в зависимости от их задержки.
  • maxfailures=1 устанавливает максимальное количество неудачных попыток подключения перед тем, как прокси-сервер будет отключен.
  • dialtimeout=2 задает таймаут подключения в секундах.
  • check=http://www.msftconnecttest.com/connecttest.txt#expect=200 и связанные с ним параметры (checkinterval, checktimeout, checktolerance) используются для периодической проверки доступности прокси-серверов.
  • forward указывает список прокси-серверов, между которыми Glider будет переключаться в соответсвии с заданными выше правилами.
А прокси любые подойдут?
 
Leonard123 сказал(а):
почему?
Только скорость упадет да и зачем это надо вообще.Если брут изначально правильно делает проходы то ip не улетает в бан,но опять же всё пропорционально списку ip и количеству комбинаций.Нужен просто абузоустойчивый сервер и всё, да и как ты будешь проверять стоит ли сторонний софт на рдп который будет рубить тебе подключение с ипа, по 5 попыток на одну проксю? так это ничего не запасешься)))) и времени вагон потеряешь.
 
admin


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