Этапы пентеста: от планирования и разведки до эксплуатации, отчёта и retest

Если вы ещё выбираете формат проверки, сначала посмотрите виды пентеста: black box, white box, API, web и network. Для бизнеса также полезно зачем стартапу ранний аудит API.

Запрос «этапы пентеста» почти всегда означает одно из двух. Либо вы учитесь на пентестера и хотите понять рабочий процесс без хаоса. Либо вы заказчик и хотите знать, что именно происходит между договором и финальным PDF.

Без этапов пентест превращается в «потыкали инструменты — написали отчёт». С этапами появляется управляемый процесс: понятный scope, воспроизводимые находки, приоритеты и retest. Ниже — практичная карта этапов penetration testing так, как это выглядит в реальных проектах по web и API, а не в абстрактной теории из учебника.

Зачем разбивать пентест на этапы

Этапы нужны не ради красоты. Они решают три задачи:

• Контроль риска. Команда понимает, что можно трогать, а что нельзя.
• Качество находок. Меньше шума от сканеров, больше реальных сценариев атаки.
• Польза для бизнеса. В конце вы получаете не «список CVE», а план, что чинить первым.

Важно: этапы не всегда идут строго линейно. Иногда после эксплуатации возвращаются к разведке, а во время отчёта уточняют severity. Но каркас процесса должен быть. Иначе команда теряет фокус, а заказчик не понимает, за что платит.

Классическая цепочка выглядит так: планирование → разведка → сканирование → анализ → эксплуатация → post-exploitation → отчёт → исправления и retest. Дальше разберём каждый шаг подробно.

Этап 1. Планирование и scope

Это самый недооценённый этап. Многие хотят сразу «начинайте ломать». Но без нормального планирования вы получаете либо опасный хаос на проде, либо бесполезный отчёт мимо реальных рисков.

На этом этапе фиксируют:

• цели проверки: web, API, mobile, network, cloud;
• формат: black / gray / white box;
• окружения: staging, prod с ограничениями, тестовые аккаунты;
• окно работ и стоп-правила;
• что считается критичным для бизнеса;
• контакты на случай инцидента;
• правила коммуникации и NDA.

Хороший scope отвечает на вопрос: какой риск мы хотим проверить за выделенное время? Например: «Может ли обычный пользователь через REST API получить доступ к чужим заказам и платежным данным?»

Плохой scope звучит так: «Проверьте всё, что можно». Это не scope. Это пожелание, которое почти гарантирует размытый результат.

От себя добавлю: для большинства SaaS-продуктов лучший старт — gray box web + API с ролями user/admin/partner. Это быстрее выводит на BOLA/IDOR, XSS и ошибки авторизации, чем широкий «пентест всего интернета компании».

Ещё один практический момент планирования — критерии успеха. Зафиксируйте заранее, что считается результатом: список критичных сценариев, покрытие ролей, проверка платежного flow, проверка BOLA на ключевых объектах. Тогда по завершении можно честно сказать, выполнен ли scope, а не спорить постфактум.

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

Этап 2. Разведка (reconnaissance)

Разведка — сбор информации о цели. Её делят на пассивную и активную.

Пассивная разведка

Без прямого «шума» по целевой системе: открытые источники, WHOIS, DNS history, публичные репозитории, документация, утечки, job-посты, subdomain enumeration через внешние сервисы.

Активная разведка

Прямое взаимодействие с целью: обход сайта, карта эндпоинтов, анализ JS-бандлов, проверка robots.txt, sitemap, API schemas, fingerprint технологий.

Для web/API на этом этапе особенно полезно:

• собрать карту ролей и объектов (user, order, invoice, organization);
• найти скрытые или устаревшие эндпоинты;
• понять, где проходит авторизация;
• заметить, какие ID предсказуемы;
• понять, где UI ограничивает действия, а API — нет.

Именно здесь часто рождается гипотеза атаки. Не «есть ли CVE», а «если я подменю ID в запросе, получу ли чужие данные?».

На разведке полезно вести живую карту атаки: роли → объекты → эндпоинты → возможные нарушения ownership. Эта карта потом экономит часы на анализе и эксплуатации. Без неё команда часто хаотично прыгает между случайными багами и теряет фокус на главном риске.

Этап 3. Сканирование и enumeration

На этом этапе инструменты помогают быстро закрыть ширину: порты, сервисы, известные сигнатуры, базовые misconfig, устаревшие компоненты.

Но важный принцип: сканер — помощник, а не пентест. Он ускоряет работу. Он не заменяет мышление.

Что обычно делают:

• network/service discovery (если в scope есть сеть);
• web crawling и endpoint discovery;
• проверка заголовков и базовых security controls;
• enumeration пользователей, ролей, параметров;
• поиск интересных точек входа: upload, search, reset password, admin API.

Для API-пентеста enumeration особенно критичен: нужно понять, какие методы доступны, какие поля принимаются, где есть bulk-операции и как выглядит модель доступа.

Этап 4. Анализ уязвимостей

После сбора данных команда отделяет шум от сигнала. Не каждая «находка сканера» — реальный риск. Не каждый missing header — critical.

На этом этапе отвечают на вопросы:

• уязвимость вообще существует или это false positive?
• можно ли её эксплуатировать в рамках scope?
• какой бизнес-эффект: утечка данных, takeover аккаунта, fraud, downtime?
• насколько легко воспроизвести?
• нужен ли chain из нескольких слабостей?

Здесь начинается настоящая ценность пентеста. Новички часто останавливаются на «сканер нашёл много красного». Опытный специалист строит короткий список гипотез с высоким impact и идёт проверять их руками.

Для web/API приоритет обычно такой: broken access control / BOLA, auth bypass, XSS с реальным impact, mass assignment, sensitive data exposure, логические баги в платежах и ролях.

Хороший анализ всегда связан с бизнесом. «SQL injection в тестовом стенде без данных» и «BOLA в API заказов с реальными PII» — это разные приоритеты. Поэтому на этапе анализа важно не только подтвердить техническую возможность, но и оценить ущерб: деньги, данные, доступ, репутация, комплаенс.

Этап 5. Эксплуатация

Эксплуатация — попытка подтвердить уязвимость на практике. Не «похоже, тут может быть IDOR», а «вот запрос, вот ответ, вот чужие данные».

Что важно на этом этапе:

• воспроизводимые шаги;
• минимально достаточные доказательства;
• аккуратность: не удалять прод-данные, не валить сервис;
• фиксация контекста: роль, токен, ID объекта, время.

Пример сильной находки: пользователь A через `GET /api/orders/{id}` читает заказ пользователя B, затем через `PATCH` меняет статус. Это уже не теоретический риск, а сценарий ущерба.

Пример слабой «находки»: отсутствует заголовок X-Frame-Options без демонстрации реального clickjacking в критичном сценарии. Такое можно упомянуть, но не раздувать до Critical.

Отдельный навык эксплуатации — остановиться вовремя. Цель пентеста не «сломать всё, что можно», а доказать риск в рамках правил и собрать материал для отчёта.

Этап 6. Post-exploitation

Если удалось получить доступ, следующий вопрос: а что дальше может сделать атакующий?

• эскалация привилегий;
• доступ к соседним объектам и тенантам;
• чтение секретов и токенов;
• движение к админке или внутренним API;
• оценка blast radius: один аккаунт или вся платформа.

Именно post-exploitation показывает разницу между «баг есть» и «баг опасен для бизнеса». Одна XSS в тестовом поле и XSS, через которую крадут session admin, — это разные миры.

Для внутренних сетевых пентестов этот этап часто включает lateral movement. Для продуктового AppSec/API — чаще цепочки вокруг ролей, токенов и данных.

Этап 7. Отчётность

Отчёт — это продукт пентеста для бизнеса и инженеров. Если отчёт плохой, даже сильная техническая работа обесценивается.

Нормальный отчёт содержит:

• executive summary без жаргона;
• scope и ограничения;
• список находок с severity;
• шаги воспроизведения;
• доказательства;
• бизнес-влияние;
• рекомендации по фиксу;
• приоритеты remediation.

Лучшие отчёты читаются двумя аудиториями. CTO за 5 минут понимает риск. Разработчик за 15 минут может воспроизвести и начать чинить.

Плохой отчёт: 70 страниц сканерного шума, severity у всего Critical, нет запросов/ответов, нет понятного «что делать завтра».

Отдельно договоритесь о формате передачи чувствительных доказательств. Иногда в отчёт нельзя класть полные токены или реальные персональные данные. Тогда используют редактирование, маскирование и отдельный защищённый канал для PoC. Это часть зрелого процесса, а не бюрократия.

Этап 8. Remediation и retest

Этап, который чаще всего выкидывают из разговора — и зря. Пентест без исправлений почти бесполезен.

После отчёта команда заказчика:

• разбирает Critical/High;
• фиксит баги;
• добавляет регресс-проверки;
• просит retest по ключевым находкам.

Retest подтверждает, что уязвимость действительно закрыта и не всплыла рядом в похожем эндпоинте. Без этого легко «починить один IDOR» и оставить такой же паттерн в соседнем API.

Практический совет: сразу закладывайте время и бюджет на retest. Иначе отчёт ляжет в Confluence и через полгода всплывёт снова на следующем аудите.

Типичные ошибки на этапах пентеста

1. Слабый scope. «Проверьте всё» без приоритетов.
2. Сканер вместо мышления. Много PDF, мало реальных сценариев.
3. Нет ролей в gray box. Без user/admin трудно поймать broken access control.
4. Проверка только UI. Главные дыры часто в API.
5. Нет доказательств. «Возможно уязвимо» — это не находка.
6. Нет retest. Риск формально «нашли», фактически не закрыли.
7. Игнор бизнес-контекста. Технический баг без понимания ущерба плохо приоритизируется.

Как этапы выглядят на практике для web/API

Короткий рабочий сценарий для продукта:

1. Согласовали gray box: staging + роли + список критичных flows.
2. Собрали карту API и объектов.
3. Прогнали базовые сканы и вручную прошлись по авторизации.
4. Подтвердили BOLA на заказах и XSS в профиле.
5. Проверили, можно ли через цепочку дойти до админских действий.
6. Отдали отчёт с приоритетами и примерами запросов.
7. После фиксов сделали retest и закрыли находки.

Именно так пентест становится инструментом роста безопасности, а не ритуалом «для галочки».

Что требовать заказчику на каждом этапе

• Планирование: письменный scope, роли, окружения, стоп-правила.
• Разведка/сканирование: понимание поверхности атаки, а не только «инструменты запущены».
• Эксплуатация: воспроизводимые PoC по критичным находкам.
• Отчёт: executive summary + технические детали + приоритеты фиксов.
• Retest: подтверждение закрытия Critical/High.

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

Мини-чеклист перед стартом пентеста

Если вы заказчик, перед kick-off пройдите короткий чеклист:

1. Есть ли тестовые аккаунты минимум двух ролей?
2. Понятен ли список критичных бизнес-сценариев?
3. Согласовано ли окружение и можно ли его «нагружать» проверками?
4. Кто принимает Critical в первый день после находки?
5. Заложен ли retest в срок и бюджет?

Если на два и более вопроса ответ «нет», сначала закройте организационные дыры. Иначе даже сильная техническая команда отдаст отчёт, которым никто не сможет быстро воспользоваться.

Для тех, кто учится: на каждом этапе ведите артефакты. На разведке — карта поверхности. На анализе — список гипотез. На эксплуатации — PoC. На отчёте — влияние и фикс. Так вы быстрее вырастете из «запускателя инструментов» в специалиста, которому доверяют.

Частые вопросы

Сколько этапов должно быть в пентесте?

В учебниках часто 5–7. В реальных проектах удобнее считать 8, включая remediation/retest. Без последнего этапа цикл неполный.

Можно ли пропускать разведку?

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

Чем этап эксплуатации отличается от сканирования?

Сканирование ищет признаки. Эксплуатация подтверждает, что атака работает, и показывает реальный impact.

Нужен ли post-exploitation всегда?

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

Что важнее: этапы или инструменты?

Этапы. Инструменты меняются каждый год. Процесс мышления и доказательства риска остаётся.

Ещё один совет по этапам: не смешивайте discovery и reporting в голове команды. Пока идёт эксплуатация, фиксируйте доказательства сразу. Не оставляйте «потом вспомним, как воспроизводили». Через три дня контекст теряется, а качество отчёта падает. Дисциплина на этапе эксплуатации почти всегда определяет, будет ли отчёт полезным для разработчиков.

И последнее: этапы — это общий язык между бизнесом и безопасностью. Когда все понимают, что сейчас planning, а не exploitation, меньше паники и больше управляемости. Именно поэтому сильные команды так внимательно относятся к процессу, а не только к набору инструментов.

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

Заключение

Этапы пентеста — это каркас качественной проверки: от чёткого scope до отчёта и retest. Если вы учитесь, осваивайте процесс целиком, а не только «как запустить сканер». Если вы заказчик, требуйте прозрачные этапы, воспроизводимые находки и проверку исправлений.

И практический итог для большинства digital-продуктов: сильнее всего работает цикл planning → recon → API/web analysis → exploitation → report → retest с фокусом на авторизацию, BOLA/IDOR, XSS и бизнес-логику.

Читайте также: виды пентеста, BOLA и XSS как главные угрозы и кто такой пентестер.

Похожие статьи

• Виды пентеста: black box, white box, API, web и сетевой
• OWASP Top 10:2025 — BOLA и XSS
• Безопасность продукта стартапа и аудит API