Полтора года назад я потратил четыре часа на ручной fuzzing одного API-эндпоинта за Cloudflare WAF - перебирал мутации payload'ов, менял кодировки, чередовал case. Потом написал классификатор на scikit-learn, обученный на 2000 пар «payload - HTTP-ответ» из логов Burp Suite. Следующий аналогичный эндпоинт сломал за 20 минут. Модель не гениальная - она просто отсекла 85% бесполезных мутаций, которые я раньше проверял вслепую. Machine learning пентест - не замена голове и не маркетинговая обёртка. Это способ убрать рутину там, где данных уже достаточно, а рук не хватает.
Русскоязычные материалы по теме делятся на два лагеря: вендорские обзоры (ML-модули в MaxPatrol SIEM, PT NAD - defensive, не наш случай) и статьи про LLM-ассистентов вроде METATRON, которые парсят вывод Nmap через Ollama. Ни то ни другое не отвечает на конкретный вопрос: как самому построить ML-пайплайн для кластеризации поддоменов, классификации ответов WAF или выделения аномалий из pcap-дампа. Разбираем именно это - с кодом, цифрами и ограничениями.
Место ML в цепочке атаки: где автоматизация работает
Прежде чем писать код, стоит честно разметить kill chain и зафиксировать, на каких фазах ML для хакинга даёт выигрыш, а где создаёт иллюзию пользы. Подробнее - в нашем материале про безопасность llm атаки.| Фаза kill chain | ML-задача | Эффективность | Контекст применения |
|---|---|---|---|
| Reconnaissance (T1595.002) | Кластеризация поддоменов, приоритизация целей | Высокая | Внешний пентест, bug bounty |
| Discovery (T1046) | Классификация сервисов по баннерам | Средняя | Внешний и внутренний пентест |
| Initial Access | Мутация payload'ов для обхода WAF | Высокая | Внешний пентест, веб-приложения |
| Credential Access (T1110) | Приоритизация словарей по паттернам | Низкая | Внутренний пентест, legacy |
| Lateral Movement | Анализ трафика, поиск аномалий | Средняя | Red team, длительные операции |
| Post-Exploitation | Классификация данных для exfiltration | Низкая | Advanced scenarios |
Правило простое: машинное обучение кибербезопасность-задач хорошо решает там, где много однородных данных и нужно принять бинарное или категориальное решение. Reconnaissance и WAF bypass - идеальные кандидаты: тысячи поддоменов, тысячи HTTP-ответов, бинарный исход (интересно / не интересно, заблокировано / пропущено). Post-exploitation - обратная история: каждая среда уникальна, данных для обучения мало, контекст решает всё.
По данным Mandiant M-Trends 2025, exploits остаются самым частым вектором initial access - 38% всех расследований. Значительная часть этих эксплойтов направлена на веб-приложения за WAF. Verizon DBIR 2025 подтверждает: 26% всех подтверждённых нарушений - веб-атаки. Автоматизация атак машинное обучение в этих условиях - не экзотика, а прагматичный ответ на масштаб задачи.
Автоматизация разведки пентест: от сырых данных к приоритизированным целям
ML OSINT разведка: кластеризация поддоменов
Типичная ситуация на внешнем пентесте или bug bounty: subfinder и Amass вернули 3000+ поддоменов. Руками проверить каждый - полдня. Классический подход: отфильтровать по HTTP-статусам, выбросить 404 и 301, смотреть остальное. Проблема в том, что ты пропускаешь поддомены с нестандартным поведением - а именно там обычно сидят dev-стенды, забытые API и админки без аутентификации.ML-подход: собрать признаки для каждого поддомена (HTTP-статус, длина ответа, количество заголовков, наличие фреймворковых маркеров типа
X-Powered-By, TLS-параметры) и кластеризовать через DBSCAN. Кластеры с малым количеством элементов помечаются как outliers - и именно они заслуживают ручного анализа в первую очередь.Требования к окружению: Python 3.9+, scikit-learn >= 1.2, pandas, 4 ГБ RAM минимум. Работает полностью offline после сбора данных. Данные предварительно собираются утилитами
httpx или httprobe и сохраняются в CSV/JSON.[Применимо: внешний пентест, bug bounty, grey box с доступом к DNS-зонам]
Python:
# кластеризация поддоменов - выделяем аномалии из общей массы
import pandas as pd
from sklearn.cluster import DBSCAN
from sklearn.preprocessing import StandardScaler
# df: subdomain, status_code, content_length, header_count, has_api_marker
features = df[['status_code', 'content_length', 'header_count', 'has_api_marker']]
scaled = StandardScaler().fit_transform(features)
clusters = DBSCAN(eps=0.5, min_samples=3).fit_predict(scaled)
df['cluster'] = clusters
anomalies = df[df['cluster'] == -1] # outliers - приоритетные целиhttpx).Когда техника НЕ работает: качество кластеризации целиком зависит от набора признаков. Если собрать только status_code и content_length - результат будет шумным, с десятками ложных outliers. Минимум 4-5 признаков для вменяемой работы. DBSCAN чувствителен к параметру
eps - для каждого нового скоупа его придётся подбирать. Универсального значения нет, что превращает pipeline в полуавтоматический. Так что «запустил и забыл» не получится.Классификация HTTP-ответов при fuzzing
Вторая точка, где ML экономит часы - постобработка результатов fuzzing. Отправил 50 000 запросов через ffuf или Burp Intruder, получил 50 000 ответов. Фильтрация по status code и content length покрывает 70% случаев, но оставшиеся 30% - ложные срабатывания и пропуски.Подход: обучить бинарный классификатор (RandomForest или логистическая регрессия) на размеченной выборке «интересный / неинтересный ответ». Признаки: длина body, количество слов, наличие ключевых строк (
error, exception, stack trace, debug), время ответа в миллисекундах, количество Set-Cookie заголовков. Размечать полностью вручную не нужно: берёшь первые 200 ответов, сортируешь по отклонению от медианной длины, проверяешь 30-40 - этого достаточно для обучения модели, которая отранжирует остальные 49 800. Те, что модель пометит как «интересные», проверяешь руками.[Применимо: внешний пентест, веб-приложения. Работает против любого стека, включая приложения за ModSecurity CRS 3.x/4.x, Cloudflare WAF, AWS WAF]
Когда техника НЕ работает: если целевое приложение возвращает идентичный ответ на все невалидные запросы (uniform error page) - классификатору не на чем учиться. Нет вариативности в данных - нечего классифицировать. Тут выход - time-based анализ или side-channel наблюдения, не ML.
ML анализ трафика пентест: выделение сигнала из шума
На внутреннем пентесте или red team ты часто снимаешь сетевой трафик -tcpdump, Wireshark, Burp в прокси-режиме. Дамп в 500 МБ pcap за день работы - норма. Искать в нём руками - боль, которую ML снимает в двух сценариях.Сценарий 1: поиск аномальных сессий. Выделяешь из pcap метаданные TCP-сессий (длительность, количество пакетов, средний размер пакета, ratio входящего/исходящего трафика), нормализуешь и прогоняешь через Isolation Forest. Anomaly score выше порога - кандидаты на ручную проверку. На offensive стороне мы ищем не зловредный трафик (это задача SOC), а необычный - DNS-туннели, нестандартные протоколы на стандартных портах, признаки C2-каналов, которые мы сами планируем имитировать или эксплуатировать.
Positive Technologies в PT NAD используют похожий подход на defensive стороне: бинарная классификация TCP-сессий по статистикам длин пакетов для обнаружения Telegram-трафика даже через MTProto. Мы берём ту же математику, но с обратной целью - понять, какие каналы связи в сети остаются незамеченными, и использовать это для планирования exfiltration-маршрутов.
[Применимо: внутренний пентест, red team. Требует доступа к сетевому трафику (SPAN-порт, ARP spoofing, MITM-позиция)]
Сценарий 2: fingerprinting WAF по поведению. Перед обходом WAF его нужно понять глубже, чем позволяет
wafw00f. Отправляешь 100-200 проверочных payload'ов с разной структурой (SQLi, XSS, command injection, path traversal) и собираешь ответы в датасет: payload_type, encoding, response_code, response_time_ms, blocked. Логистическая регрессия на этих данных показывает, к каким классам payload'ов WAF чувствителен, а что пропускает. Получается карта атаки, собранная за 5 минут вместо часа ручного тестирования.Требования к окружению для анализа трафика: Python 3.9+,
scapy для парсинга pcap, scikit-learn, 8 ГБ RAM минимум (для дампов >200 МБ рекомендуется 16 ГБ). Jupyter Notebook удобен для визуализации кластеров через matplotlib.Обход WAF ML: adversarial-подход к генерации payload
Обход WAF ML - та область, где data science ИБ пересекается с adversarial machine learning напрямую. Концепция: WAF - это классификатор (regex-based или ML-based). Задача атакующего - сгенерировать adversarial examples, которые WAF классифицирует как легитимные, а целевое приложение - как исполняемый payload.Подход, который я использую на внешних пентестах:
- Сбор baseline. Отправляешь 200-300 payload'ов из стандартных словарей SecLists и фиксируешь, какие заблокированы, какие прошли. Это обучающая выборка.
- Feature engineering. Каждый payload описывается признаками: длина, количество спецсимволов, наличие SQL/JS ключевых слов, уровень URL-encoding, использование Unicode, наличие inline-комментариев.
- Обучение модели блокировки. RandomForest или GradientBoosting предсказывает: заблокирует WAF конкретный payload или нет. Accuracy 85-90% после 300 примеров - типичный результат для ModSecurity с CRS.
- Генерация мутаций. Берёшь рабочий payload, который блокируется, мутируешь его и прогоняешь каждую мутацию через модель. Если модель предсказывает «не заблокирован» - отправляешь на реальный WAF для проверки.
Python:
# мутация SQL-payload'а - четыре базовых трансформации
import random
def mutate_sqli(payload: str) -> list:
mutations = []
mutations.append(payload.replace(' ', '/**/')) # комментарии вместо пробелов
mutations.append(payload.replace("'", '%2527')) # double URL-encoding
mutations.append(''.join( # random case
c.upper() if random.random() > 0.5 else c.lower() for c in payload
))
mutations.append(payload.replace('SELECT', 'SEL/**/ECT')) # inline comment
return mutations[Применимо: внешний пентест, веб-приложения за ModSecurity CRS 3.x/4.x, Cloudflare WAF (Free/Pro tier), AWS WAF с managed rules. Против WAF с ML-based detection (Cloudflare Enterprise с Bot Management, Imperva SecureSphere Advanced) эффективность ниже - нужен baseline в 500+ payload'ов и более сложный feature engineering]
Ограничения и когда ML не работает в пентесте
| Ограничение | Где проявляется | Что делать |
|---|---|---|
| Мало данных (<200 точек) | Внутренний пентест с 20 хостами | Не использовать ML, работать руками |
| Overfitting на один WAF | Модель обучена на ModSecurity, применяется к Cloudflare | Переобучать под каждый WAF отдельно |
| Ложная уверенность | Модель говорит «пройдёт» - payload блокируется | Каждое предсказание проверять на таргете |
| Время на pipeline > ручной анализ | Настройка ML при скоупе <50 целей | Grep, jq и awk быстрее |
| Детектируемость baseline-запросов | 300 payload'ов для обучения = 300 алертов в SOC | Растягивать во времени, ротировать source IP |
Порог, ниже которого ML не оправдан: менее 200 точек данных (поддоменов, ответов, payload'ов). Ниже этого -
grep, jq и awk работают быстрее, потому что не требуют настройки pipeline.Детектирование ML-driven recon со стороны Blue Team
Для полноты картины - ML-driven recon оставляет следы, и SOC их ищет:- Массовое сканирование (T1046): Sigma-правило
net_firewall_susp_network_scan_by_ip.ymlиз SigmaHQ детектирует паттерн множественных подключений с одного IP. При кластеризации поддоменов ты массово отправляешь HTTP-запросы - это видно на уровне NGFW и SIEM. CrowdStrike Falcon и Elastic 8.x+ с включённым network module фиксируют такую активность. - Массовая отправка payload'ов (T1110): WAF fingerprinting через сотни мутированных запросов выглядит как brute force. В SigmaHQ для T1110 - 40 правил, включая
win_security_susp_failed_logons_single_source_ntlm.yml. Любой SIEM с базовой конфигурацией это поймает. - DNS-разведка (T1595.002): Массовый DNS-резолвинг тысяч поддоменов детектируется правилом
net_dns_external_service_interaction_domains.yml. PT NAD и аналогичные NTA-решения видят это на уровне сетевого трафика.
Когда что применять: decision tree
Последние полтора года я наблюдаю одну устойчивую ошибку: люди путают «ML в пентесте» с «ChatGPT пишет мне эксплойты». Это принципиально разные вещи. LLM - генеративная модель, которая галлюцинирует несуществующие CVE и теряет контекст на седьмом шаге kill chain (об этом честно пишут в разборе METATRON на Codeby). Классический ML - инструмент обработки данных, которые ты уже собрал: кластеризация, классификация, anomaly detection. Он не генерирует атаки из воздуха. Он убирает рутину.
Вместо четырёх часов ручного анализа 3000 поддоменов - 40 секунд скрипта. Вместо 500 ручных проб WAF - 50 целевых, отобранных моделью.
Порог входа в offensive AI security завышен в восприятии. Для 80% задач хватает scikit-learn, pandas и 50 строк Python. Ни PyTorch, ни TensorFlow, ни GPU за 200 тысяч рублей. Сбор данных, feature engineering,
fit - predict. Кто пишет на Python и понимает, что ищет в конкретном скоупе, - освоит за выходные.Другая крайность - слепая вера в модель. На одном bug bounty я видел, как человек отправлял payload'ы, помеченные моделью как «пройдёт WAF», без ручной проверки. Результат: 200 blocked-запросов, бан source IP и ноль находок. Модель - советчик, не оракул. Каждое предсказание нужно верифицировать на реальном таргете, прежде чем строить exploitation chain. Если хочешь повторить шаги в контролируемой инфре - таски web-категории на HackerLab позволяют обкатать мутированные payload'ы без риска бана.
