Методология пентеста: от курса к реальным проектам

На третьем коммерческом пентесте я получил скоуп из 12 подсетей, около 400 хостов и двухнедельный дедлайн. К концу первого дня - 6 ГБ вывода Nmap, список из 200+ потенциальных точек входа и полный паралич. OSCP сдан, курсы пройдены, инструменты знакомы - а рабочий процесс так и не сложился.

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

Почему курс не равно готовность к пентесту​

Курсы вроде OSCP или WAPT дают набор техник: «вот так ломается SQL-инъекция, вот так работает Kerberoasting». На реальном проекте задача другая - за ограниченное время покрыть периметр, принять десятки решений о приоритизации векторов и выдать структурированный отчёт. Ни один курс не учит этому в полном объёме. Это навык, который формируется только через повторение и рефлексию.


Опытный пентестер отличается от начинающего не количеством известных техник, а «насмотренностью» - способностью с первого взгляда понять, какие проверки неприменимы в конкретном кейсе и какой инструмент подойдёт лучше. Методология - инструмент для ускорения этой насмотренности: вместо хаотичных экспериментов вы накапливаете опыт по чёткой схеме.

Выбор базового фреймворка: PTES, OWASP, NIST​

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

PTES (Penetration Testing Execution Standard) - самый практичный фреймворк, написанный пентестерами для пентестеров. Семь фаз: Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting. PTES хорош как каркас для инфраструктурного теста - описывает полный жизненный цикл проекта от первого звонка заказчику до финального отчёта. По данным KirkpatrickPrice, PTES даёт стандартизированную базовую линию для любого проекта, но оставляет свободу в выборе конкретных техник на каждом этапе.

OWASP Testing Guide (WSTG) - детальный чек-лист для веб-приложений и API. Согласно OWASP, 94% приложений тестировались на Broken Access Control (A01:2021). WSTG не заменяет полную методологию - это технический справочник для фазы «Vulnerability Analysis», когда нужно систематически проверить конкретное веб-приложение по категориям: Injection (A03:2021), Security Misconfiguration (A05:2021), Identification and Authentication Failures (A07:2021).

NIST SP 800-115 - формализованное руководство с фокусом на документирование и комплаенс. Подходит, когда заказчик - банк или объект КИИ. Описывает методы обследования (обзор документации, логов, конфигурации, сниффинг сети), методы проверки целевых уязвимостей и структуру итогового отчёта.

Рабочая стратегия - использовать PTES как скелет проекта, OWASP WSTG как чек-лист для веб-части, а NIST - для структуры отчёта на комплаенс-проектах. Зрелый подход требует «полиметодологии» - сочетания нескольких фреймворков под конкретную задачу. На практике я ещё не встречал проекта, где хватило бы одного фреймворка без дополнений.

Фаза 1: Разведка перед пентестом​

Сбор информации OSINT - фаза, на которой большинство новичков либо застревают на три дня, либо проскакивают за час. Обе крайности бьют по результату: избыточная разведка крадёт время у эксплуатации, недостаточная - оставляет слепые зоны.

Тайм-бокс и структура​

Для стандартного внешнего пентеста я выделяю на разведку 15-20% от общего времени. При двухнедельном проекте это 1,5-2 рабочих дня. Хватит, чтобы покрыть основные направления:

Пассивная reconnaissance-разведка: DNS-записи через dig и whois, поддомены через crt.sh, утечки учётных данных в публичных базах, метаданные документов через exiftool, GitHub-репозитории организации (часто содержат захардкоженные ключи и конфиги - в каждом третьем проекте что-нибудь да валяется).

Активная разведка: перебор поддоменов (ffuf, gobuster), первичный быстрый скан портов Nmap, fingerprinting веб-технологий через whatweb или Wappalyzer. На нестандартных сервисах стоит подключиться и проверить баннер вручную - автоматика здесь часто врёт.

Заметки как часть методологии​

Вот что нигде не написано в русскоязычных руководствах: система ведения заметок - такая же часть методологии пентеста, как выбор сканера. Я веду записи в CherryTree с древовидной структурой: отдельная ветка на каждый хост, внутри - порты, сервисы, версии, скриншоты, гипотезы для проверки. Без этого через три дня невозможно вспомнить, на каком из 40 хостов был тот интересный заголовок X-Powered-By.

Признаки, что пора двигаться дальше: составлена полная карта внешних хостов с портами, собраны версии ключевых сервисов, проверены публичные утечки и записаны 3-5 приоритетных гипотез. Если через два дня гипотез нет - проблема не в разведке, а в понимании того, что искать.

Фаза 2: Сканирование и маппинг поверхности атаки​

Между этапами - ручная фильтрация. Из быстрого скана выделяю хосты с нестандартными портами, устаревшими баннерами или подозрительными сервисами. Именно они попадают в interesting_hosts.txt. Для веб-приложений параллельно запускаю перебор директорий через ffuf и пассивное сканирование Burp Suite - он собирает карту приложения, пока вы вручную кликаете по интерфейсу.

Фаза 3: Анализ уязвимостей - приоритизация вместо перебора​

После сканирования обычно появляется список из 20-100 потенциальных находок. Пробовать эксплуатировать всё подряд - путь к провалу по срокам. Нужна система приоритизации.

Я использую простую матрицу: критичность сервиса для заказчика × вероятность эксплуатации. В первую очередь проверяю:

1. Устаревшие версии с публичными CVE и PoC - готовый эксплойт в searchsploit или Metasploit Framework означает, что проверка займёт минуты, а не часы
2. Дефолтные учётные данные - admin:admin, tomcat:tomcat - банально, но в каждом четвёртом проекте это работает. Серьёзно, каждом четвёртом
3. Веб-приложения с формами ввода - Injection (OWASP A03:2021) и Broken Access Control (A01:2021) покрывают большинство реальных находок на практике
4. Открытые управляющие интерфейсы без аутентификации - Jenkins, phpMyAdmin, Grafana, консоли мониторинга. Классический Security Misconfiguration (A05:2021)

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

Фаза 4: Эксплуатация уязвимостей и развилка «копать или вращать»​

Главное правило этого этапа пентеста - тайм-бокс на каждый вектор. Я ставлю 2-4 часа на попытку эксплуатации одной уязвимости. Если за это время не получил подтверждение - фиксирую результат и переключаюсь. Кроличья нора - самая частая ловушка: ощущение «ещё 15 минут и заработает», за которым проходит полдня.

Развилка «копать или вращать»​

Этот момент - ключевой в методологии, и при этом нигде не описан формально. После 2-3 часов работы с одним вектором вы принимаете решение:

• Копать глубже - если видите прогресс: частичный ответ сервера, изменение поведения приложения, обход части защиты. Увеличиваете тайм-бокс на 2 часа
• Вращать (переключаться на следующий вектор) - если за 2-3 часа нет ни одного признака продвижения. Документируете попытки и переходите дальше

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

Порядок действий при работе с уязвимостью:

1. Проверить эксплойт: searchsploit <service> <version>, поиск в msfconsole командой search type:exploit <keyword>
2. Прочитать описание - понять предусловия (версия, конфигурация, нужны ли учётные данные)
3. Подготовить среду - слушатель, payload, обратный канал
4. Эксплуатировать с логированием каждого шага (запись терминала через script или asciinema, скриншоты)
5. При успехе - зафиксировать proof (whoami, hostname) и перейти к пост-эксплуатации

Для веб-приложений OWASP WSTG даёт конкретные тест-кейсы по каждой категории, включая проверку механизмов аутентификации - Broken Authentication (API2:2023 по классификации OWASP API Security) описывает типовые ошибки в реализации токенов, сессий и процедур восстановления пароля.

Фаза 5: Пост-эксплуатация и латеральное движение​

После получения первоначального доступа начинается фаза, которую многие новички пропускают - и теряют большую часть ценности отчёта. Пост-эксплуатация отвечает на вопрос «и что дальше?». Именно это больше всего интересует заказчика.

Что делать после получения shell:

• Определить контекст: whoami, id, hostname, сетевые интерфейсы, принадлежность к домену, группы
• Собрать учётные данные: файлы конфигурации, история bash, переменные окружения, кеш браузера, хранилища паролей
• Оценить пути повышения привилегий: SUID-биты (find / -perm -4000 2>/dev/null), sudo-права, cron-задачи. На GTFOBins описаны способы злоупотребления стандартными Linux-утилитами (find, less, expect и десятки других) для эскалации - незаменимый справочник при ручном анализе
• Латеральное движение: Remote Services (T1021, тактика Lateral Movement по MITRE ATT&CK) - RDP, SSH, SMB, WinRM. В AD-среде CrackMapExec позволяет проверить переиспользование учётных данных по подсетям, а BloodHound визуализирует пути к Domain Admin через граф связей, которые невозможно увидеть вручную

Что знать о детекции​

Понимание того, как blue team детектит ваши действия, помогает работать тише и точнее оценивать защищённость заказчика. По данным MITRE D3FEND, основные контрмеры против Remote Services (T1021) - анализ сетевого трафика: Remote Terminal Session Detection (D3-RTSD), Network Traffic Signature Analysis (D3-NTSA), Client-server Payload Profiling (D3-CSPP). В SigmaHQ - 98 правил детектирования для T1021, включая мониторинг публичных RDP-слушателей и аномальной SMB-активности. Если SOC заказчика не срабатывает на ваше латеральное движение - это отдельная находка для отчёта. И часто более ценная, чем сам shell.

Отчёт по пентесту: документ, который читают​

Отчёт - продукт, за который заказчик платит. Не за shell и не за скриншоты whoami, а за документ с чёткими рекомендациями. План тестирования на проникновение трансформируется в структурированный отчёт:

1. Executive Summary (1-2 страницы) - для руководства, без технических деталей. Что нашли, насколько критично, что делать в первую очередь
2. Скоуп и методология - что тестировали, какие фреймворки использовали (PTES, OWASP WSTG), ограничения и допущения
3. Findings - каждая находка отдельным блоком: описание, критичность (CVSS), шаги воспроизведения, скриншоты/логи, рекомендации по устранению
4. Risk Matrix - сводная таблица находок по критичности
5. Приложения - полный вывод инструментов, дополнительные скриншоты, raw-данные

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

По данным VikingCloud, после устранения уязвимостей проводится повторная проверка - rescanning и revalidation, чтобы убедиться, что исправления закрыли проблему и не создали новых.

Чек-лист пентестера: сводка по этапам пентеста​

Процентовки - ориентир, не догма. На внутреннем пентесте AD-инфраструктуры пост-эксплуатация может занять 40% времени, а на тесте одного веб-приложения - 5%. Адаптируйте распределение под проект и пересматривайте после каждого завершённого теста.

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

В нескольких проектах я работал с джуниорами, которые знали больше техник, чем сеньоры в их команде - и стабильно проигрывали по результатам. Разница была ровно в одном: у сеньора была выстроенная методология пентеста с чёткими развилками и тайм-боксами, а у джуниора - набор несвязанных навыков без системы приоритизации.

Ценность «руки-эксплойт» будет снижаться - автоматизация закроет базовые кейсы вроде версионных CVE и дефолтных учёток. Расти будет ценность пентестера, который умеет управлять процессом: определять скоуп, приоритизировать риски в условиях ограниченного времени и доносить результаты до бизнеса человеческим языком. Методология - не бюрократия. Это конкурентное преимущество. Тот, кто построил свою систему решений и зафиксировал её на бумаге, выдаёт стабильный результат на любом проекте. Тот, кто каждый раз импровизирует - зависит от удачи и настроения. Попробуйте после следующего проекта записать свои развилки: где переключились, где зарылись, где потеряли время. Через пять таких записей у вас будет собственная методология - живая, не из учебника. На WAPT, кстати, эту цепочку «разведка → приоритизация → эксплуатация → отчёт» проходят в течение нескольких модулей с лабами.