Основы пентеста: путь до уровня Middle

База: сети, Linux/Windows, Bash/Python и инструменты пентестера

Зачем эта база нужна Middle-пентестеру

Пентест (penetration testing) — это проверка защищённости систем с разрешения владельца с целью найти и подтвердить уязвимости, оценить риски и дать рекомендации по исправлению.

Чтобы расти до уровня Middle, важно уметь:

Понимать, как данные ходят по сети и почему “не пингуется” не равно “не работает”.

Уверенно чувствовать себя в Linux и Windows: пользователи, права, службы, логи, сеть.

Быстро писать и читать автоматизацию: Bash для “склеивания” утилит, Python для более сложных задач.

Владеть базовым инструментарием: разведка, анализ трафика, веб-диагностика, перебор директорий, работа с прокси.

Эта статья — фундамент, на который дальше лягут темы веб-уязвимостей, Active Directory, эксплуатация, пост-эксплуатация и отчётность.

> Любые практики делайте только в легальной лаборатории: собственные стенды, тренажёры, отдельные VM и изолированные сети.

Лаборатория для обучения

Чтобы практиковаться безопасно и повторяемо:

Виртуализация: VirtualBox или VMware.

Минимальный набор VM:

- Kali Linux (или Ubuntu + инструменты). - Windows (клиент) для базовых практик. - Уязвимая машина для отработки (например, Metasploitable, OWASP Juice Shop).

Включите снапшоты (snapshots), чтобы откатываться.

Используйте сетевой режим “Host-only” или отдельный виртуальный свитч, чтобы не сканировать случайно “реальную” сеть.

Полезные источники:

Документация Kali Linux

OWASP Juice Shop (репозиторий)

Metasploitable 2 (страница проекта Rapid7)

Сети: понятный минимум для пентеста

Как мыслить сетью в пентесте

В пентесте сеть обычно раскладывается на вопросы:

Где цель? IP, подсеть, маршруты.

Что доступно? Порты, протоколы, сервисы.

Как разговаривать? HTTP, SMB, RDP, DNS и т.д.

Есть ли фильтрация? firewall, NAT, прокси, WAF.

Можно ли наблюдать трафик? зеркалирование, ARP, локальный сегмент, VPN.

!Карта уровней сети и где работают типовые инструменты

IP-адреса, подсети и маршрутизация

IP-адрес (IPv4) — адрес узла в сети.

Подсеть — диапазон IP, который считается “локальным” по маске (CIDR).

Шлюз (default gateway) — устройство, через которое идёт трафик в другие сети.

Частные диапазоны IPv4 (их обычно встречают внутри компаний):

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Что полезно уметь в подсетях на практике:

Понять, какие IP “рядом” и могут быть просканированы.

Отличить адрес сети, broadcast и диапазон хостов.

Понять, почему два узла “в одной подсети” общаются напрямую (L2), а “в разных” — через роутер.

Команды для быстрой диагностики:

Linux:

- ip a (адреса) - ip r (маршруты) - ping (ICMP доступность) - traceroute (путь до узла)

Windows:

- ipconfig /all - route print - ping - tracert

Справка:

ip (Linux manual)

TCP и UDP: порты и состояние

TCP — ориентирован на соединение. Важен там, где нужна надёжность (HTTP(S), SSH, RDP и т.д.).

UDP — без установления соединения, часто быстрее и проще (DNS, NTP, некоторые VPN и т.д.).

Ключевые практические понятия:

Порт — логический “вход” сервиса (например, 22/SSH, 80/HTTP, 443/HTTPS).

Состояния портов при сканировании:

- open — сервис отвечает. - closed — хост доступен, но сервис не слушает. - filtered — ответ блокируется (часто firewall).

DNS: почему имя важно не меньше IP

DNS превращает имя (например, intranet.company) в IP и обратно.

Что часто делает пентестер:

Проверяет резолвинг: правильно ли “видится” цель из разных сегментов.

Делает перечисление поддоменов (subdomain enumeration) и записей.

Ищет утечки через DNS (например, лишние записи, старые окружения).

Инструменты:

dig / nslookup

Документация:

dig (BIND 9 manual)

HTTP(S): основа веб-пентеста

HTTP — прикладной протокол, на котором работает веб.

Минимум, который нужен уже сейчас:

Методы: GET, POST, PUT, DELETE.

Заголовки: Host, Cookie, Authorization, User-Agent, Content-Type.

Коды ответа: 200, 301/302, 401, 403, 404, 500.

Сессии и куки: как браузер “помнит” пользователя.

HTTPS = HTTP поверх TLS: шифрование и проверка сертификата.

Полезные источники:

MDN Web Docs: HTTP

Анализ трафика

Умение посмотреть “что реально происходит по сети” часто экономит часы.

Инструменты:

tcpdump — быстрый CLI-сниффер.

Wireshark — подробный GUI-анализатор.

Полезно уметь:

Фильтровать по IP, порту, протоколу.

Видеть DNS-запросы, TCP-рукопожатие, HTTP-запросы.

Понимать разницу “запрос ушёл” и “ответ не вернулся”.

Документация:

tcpdump (man page)

Wireshark User’s Guide

Linux для пентестера

Файловая система и базовая навигация

Что важно понимать:

В Linux “всё — файл”: устройства, сокеты, конфиги.

Ключевые директории:

- /etc — конфигурация. - /var/log — логи. - /home — домашние каталоги. - /tmp — временные файлы.

База команд:

ls, cd, pwd, cat, less, head, tail, grep, find.

Пользователи, группы и права

Минимальная модель:

Пользователь (user) и группа (group) определяют, кто имеет доступ.

Права rwx задаются отдельно для владельца, группы и остальных.

Полезные команды:

id — кто вы и в каких группах.

chmod, chown — управление правами.

sudo — выполнение команды от имени администратора (root) при наличии разрешения.

Документация:

sudo (man page)

Процессы и службы

В пентесте важно уметь:

Понять, что запущено и что слушает порты.

Быстро остановить, перезапустить или проверить службу в лаборатории.

Команды:

ps aux, top/htop — процессы.

ss -tulpn — слушающие сокеты (порты).

systemctl status <service> — службы (на systemd).

Справка:

ss (man page)

systemctl (systemd documentation)

Логи

Когда что-то “не работает”, логи часто дают ответ быстрее сканеров.

Где смотреть:

/var/log/syslog или /var/log/messages (зависит от дистрибутива)

journalctl (если systemd)

Документация:

journalctl (systemd documentation)

Windows для пентестера

Что важно в Windows-экосистеме

Windows-среда в компаниях часто включает домен Active Directory (AD). Даже если вы пока не взламываете AD, нужно понимать термины:

Локальная учётная запись — живёт на конкретной машине.

Доменная учётная запись — управляется доменом (AD) и может входить на разные машины.

SID — внутренний идентификатор безопасности объекта.

UAC — механизм, который отделяет “обычные” действия от административных.

Аутентификация: NTLM и Kerberos

NTLM — более старый набор протоколов аутентификации, встречается до сих пор.

Kerberos — основной протокол аутентификации в доменах AD.

Почему пентестеру это важно:

Эти протоколы определяют, как можно аутентифицироваться к сервисам (SMB, WinRM, RDP), и какие атаки возможны при неправильной конфигурации.

Справочные источники:

Microsoft: Kerberos authentication

Microsoft: NTLM overview

Сетевые службы Windows, которые часто встречаются

SMB (обычно порт 445/TCP) — файлы и удалённые операции.

RDP (3389/TCP) — удалённый рабочий стол.

WinRM (5985/HTTP, 5986/HTTPS) — удалённое управление.

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

Где смотреть события

Для базовой диагностики:

Event Viewer (Журнал событий)

Security log (входы, ошибки аутентификации)

Справка:

Microsoft: Event Viewer

Bash: автоматизация на склейке утилит

Bash полезен, когда нужно быстро:

Обработать вывод сканеров.

Прогнать однотипные запросы по списку хостов.

Сконвертировать данные (URL, домены, IP) и передать в другой инструмент.

Основные идеи Bash

Конвейеры: команда1 | команда2 — вывод первой становится вводом второй.

Перенаправления:

- > перезаписать файл - >> дописать - 2> ошибки в файл

Переменные и подстановка: VAR=value, затем d" >/dev/null && echo "OK d"

done < domains.txt python import argparse import requests

def main(): parser = argparse.ArgumentParser() parser.add_argument("url") args = parser.parse_args()

r = requests.get(args.url, timeout=10) print("Status:", r.status_code) print("Server:", r.headers.get("Server"))

if __name__ == "__main__": main() `

Документация:

Python: argparse

Requests: documentation

Инструменты пентестера: базовый набор и назначение

Ниже — инструменты, которые встречаются почти в любом проекте. Важно не “уметь нажимать кнопки”, а понимать, какие данные инструмент получает и как интерпретировать результат.

Разведка и сканирование

Nmap — обнаружение хостов, портов и версий сервисов.

Инструменты для баннер-граббинга (например, nc, curl) — понять, что реально отвечает на порту.

Документация:

Nmap Reference Guide

Веб-диагностика

curl — воспроизведение HTTP-запросов руками.

Burp Suite — прокси для перехвата и изменения запросов, ручное тестирование.

OWASP ZAP — прокси и сканер, удобен для обучения.

Документация:

curl documentation

PortSwigger Documentation: Burp Suite

OWASP ZAP Getting Started

Перебор контента (content discovery)

Для поиска скрытых директорий, файлов, эндпоинтов:

ffuf

gobuster

Документация:

ffuf (репозиторий)

gobuster (репозиторий)

Сниффинг и анализ

Wireshark

tcpdump`

Эти инструменты полезны не только для “взлома”, но и для объяснения проблем сетевикам и разработчикам: что и где ломается.

Как собирать всё в рабочий процесс

Один из типовых циклов (в лаборатории и на реальных проектах, только с разрешения):

Уточнить цель и правила (scope): диапазоны, домены, учётки, запреты.

Сетевая разведка: какие хосты живые, какие порты открыты.

Идентификация сервисов: версии, конфигурация, “что это за приложение”.

Ручная проверка (особенно веб): авторизация, роли, бизнес-логика.

Автоматизация:

- Bash — обработка списков, склейка команд. - Python — повторяемые проверки, парсинг, отчётность.

Фиксация доказательств и артефактов: команды, время, результаты.

Рекомендации: как исправить и как проверить, что исправлено.

Частые ошибки новичков и как их избежать

Сканировать “куда попало”: всегда держите перед глазами scope.

Путать “порт открыт” и “уязвимость есть”: порт — это только поверхность.

Игнорировать DNS и маршруты: часть проблем “уязвимостей” — это сетевые ограничения и резолвинг.

Не вести заметки: без таймлайна, команд и подтверждений отчёт будет слабым.

Ставить инструменты без понимания: учитесь читать вывод и проверять гипотезы вручную.

Что должно получиться после этой статьи

После освоения материала вы должны:

Понимать, как устроены IP/порты/TCP-UDP/DNS/HTTP и как это проверять инструментами.

Уверенно выполнять базовую диагностику в Linux и Windows.

Понимать права, процессы и сетевые порты в Linux.

Уметь писать простые пайплайны в Bash и небольшие утилиты на Python.

Знать назначение ключевых инструментов: Nmap, Wireshark, Burp/ZAP, curl, ffuf/gobuster.

Методология и разведка: scoping, OSINT, сканирование и перечисление

Зачем Middle-пентестеру методология и разведка

В предыдущей статье вы собрали базу: сети, Linux/Windows, HTTP, Bash/Python и основные инструменты. Следующий шаг — научиться превращать эту базу в управляемый процесс.

Разведка и перечисление — это этапы, где вы:

Понимаете что именно тестируете (scoping и правила).

Собираете максимум контекста до активных действий (OSINT).

Аккуратно находите поверхность атаки внутри разрешённого контура (сканирование).

Детализируете сервисы и точки входа (перечисление).

Для уровня Middle важно не просто «запустить сканер», а уметь:

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

Выбрать безопасный режим работы (скорость, таймауты, источники трафика).

Вести артефакты: команды, результаты, время, версии инструментов.

> Делайте всё только в разрешённом контуре и в собственной лаборатории. OSINT тоже может иметь ограничения по законам и условиям сервисов.

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

Методология нужна, чтобы:

не забыть критичные проверки;

не выйти за рамки разрешённого;

получать воспроизводимые результаты;

писать отчёт, который можно защитить перед заказчиком.

Популярные ориентиры:

Penetration Testing Execution Standard (PTES)

OWASP Web Security Testing Guide

В этом курсе мы будем мыслить так:

Scoping и правила

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

Активная разведка (сканирование)

Перечисление (enumeration)

Дальше: анализ уязвимостей, эксплуатация, пост-эксплуатация, отчёт

!Конвейерный процесс: где находится разведка и что она отдаёт дальше

Scoping: как формально определить границы и не «сломать всё»

Что такое scope

Scope — это формальное описание того, что разрешено и что запрещено тестировать.

Scope обычно включает:

цели: домены, подсети, конкретные IP, приложения, мобильные клиенты;

тип теста: black box, gray box, white box;

ограничения: запрет DoS, запрет фишинга, запрет социнженерии;

окна проведения работ: даты, часы, change freeze;

контактные лица и эскалация инцидентов.

Правила взаимодействия (Rules of Engagement)

Rules of Engagement — это как именно вы работаете в рамках scope.

Минимальный набор, который вам нужен даже в лабораторных имитациях:

разрешённые источники трафика (ваши IP, VPN, jump-host);

лимиты на нагрузку (скорость сканирования, параллелизм, timeouts);

что делать при обнаружении критичной проблемы;

как хранить данные (логи, дампы, скриншоты) и как их удалять.

Типичные ошибки на scoping

Расплывчатое «тестируйте наш сайт» без списка доменов и окружений.

Нет отдельного согласования на поддомены и сторонние сервисы.

Нет запретов на нагрузочные действия.

Практическое правило: если объект явно не указан в scope, вы его не трогаете.

Как фиксировать scope в рабочих заметках

Чтобы отчёт и доказательства были сильными, заведите артефакты:

scope.txt: домены, IP/CIDR, список приложений, даты, ограничения.

assumptions.md: ваши допущения (например, «поддомены домена X считаются в scope»).

activity.log: таймлайн действий (команда, время, результат, ссылка на файл).

OSINT: пассивная разведка без прямого воздействия на цель

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

Пассивная — вы собираете данные из внешних источников и не отправляете запросы в инфраструктуру цели.

Активная — вы взаимодействуете с инфраструктурой цели (DNS-запросы, HTTP, сканирование портов).

Пассивная разведка часто даёт:

картину активов (домены, подсети, облака);

технологии (CMS, фреймворки, панели);

утечки (репозитории, публичные бакеты, документы);

«теневые» окружения (staging, dev, old).

Что можно искать через OSINT

#### Домены, поддомены, DNS-следы

Источники и подходы:

DNS-записи: A, AAAA, CNAME, MX, TXT.

сертификаты TLS и прозрачность сертификатов.

архивы исторических DNS и индексация.

Инструменты:

whois (регистрация домена)

dig (запросы к DNS)

crt.sh (поиск доменов по сертификатам)

Ссылки:

crt.sh

BIND 9 dig documentation

#### Поисковые системы и dorks

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

Важно:

соблюдайте правила и условия использования поисковых систем;

не автоматизируйте агрессивно то, что запрещено условиями.

#### Публичные сканеры и базы наблюдений

Они полезны, чтобы увидеть «как цель выглядит снаружи».

Shodan

Censys Search

Что там искать:

открытые сервисы и баннеры;

устаревшие версии;

неожиданные страны/провайдеры;

дублирующиеся хосты.

#### Репозитории и утечки конфигов

Что часто находят:

ключи API, токены, .env, пароли в README;

адреса внутренних сервисов;

пути к админкам.

Если вы используете GitHub для поиска, делайте это аккуратно и в рамках scope и законов. Для обучения смотрите материалы GitHub о поиске:

GitHub Docs: Searching code

Практика OSINT: минимальный поток действий

Уточните «корневые» домены и бренды из scope.

Соберите поддомены из сертификатов (crt.sh).

Проверьте базовые DNS-записи и CNAME-цепочки.

Сопоставьте найденное с публичными сканерами (Shodan/Censys).

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

Активная разведка: сканирование без лишнего шума

Активная разведка начинается, когда вы отправляете запросы в сторону цели.

Основная цель сканирования: получить ответы на вопросы:

какие хосты доступны;

какие порты открыты;

какие сервисы и версии;

где есть фильтрация.

Базовая стратегия сканирования

Идея: идти от общего к частному и повышать детализацию постепенно.

Подтвердить доступность (без агрессии)

Сканировать порты

Определить сервисы и версии

Зафиксировать результаты

Nmap: безопасные режимы и типовые команды

Nmap — стандарт де-факто для сетевой разведки.

Справка:

Nmap Reference Guide

Примеры для лаборатории:

Пояснения к ключевым флагам:

-sV пытается определить сервис и версию.

-sC запускает набор стандартных NSE-скриптов, обычно безопасных, но всё равно проверяйте правила.

-p- сканирует все TCP порты 1-65535.

-T3 умеренная агрессивность.

--min-rate задаёт минимальную скорость отправки пакетов и может повышать нагрузку.

Что важно для Middle:

уметь объяснить, почему вы выбрали скорость и профиль;

сохранять результаты в файлы (-oN, -oX, -oG) и уметь их обрабатывать.

Проверка баннеров руками

Сканер ошибается. Подтверждайте критичное руками:

Сканирование UDP: когда оно реально нужно

UDP-сканирование шумнее и менее надёжно интерпретируется.

Проверяйте UDP, когда:

в scope явно есть DNS/NTP/SNMP/VPN;

вы видите признаки UDP по документации или OSINT;

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

Пример (лаборатория):

Перечисление (enumeration): превращаем «порт открыт» в конкретные объекты

Сканирование отвечает «что доступно». Перечисление отвечает «что именно там и как это устроено».

Принцип: перечисляйте по протоколу и собирайте артефакты, которые потом помогут в поиске уязвимостей.

DNS enumeration

Что собрать:

зоны и поддомены;

записи TXT (иногда там SPF/DKIM и служебные метки);

CNAME на сторонние сервисы.

Инструменты и ссылки:

OWASP Amass

ProjectDiscovery subfinder

Пример (лаборатория, с собственным доменом):

HTTP(S) enumeration

Что собрать:

какие хосты отвечают (включая виртуальные хосты по Host);

технологии и фреймворки;

маршруты, директории, панели;

методы аутентификации и роли.

Инструменты:

Burp Suite или OWASP ZAP как прокси

curl для воспроизведения

ffuf для content discovery

whatweb для распознавания технологий

Ссылки:

PortSwigger Documentation: Burp Suite

OWASP ZAP Getting Started

ffuf

WhatWeb

Примеры (лаборатория):

Важно:

ffuf создаёт нагрузку: регулируйте -t, ставьте задержки при необходимости и работайте по правилам.

фильтруйте ответы (-fc, -fs), иначе утонете в шуме.

TLS enumeration (когда есть HTTPS)

Что полезно собрать:

версию TLS и поддерживаемые шифры;

сертификат, SAN-имена, срок действия;

редиректы HTTP->HTTPS.

Для первичной проверки часто хватает:

Документация:

OpenSSL s_client

SMB/Windows-сервисы: осторожное перечисление

Если в сети есть Windows-хосты, вы часто увидите:

SMB 445/tcp

RDP 3389/tcp

WinRM 5985/5986

Что перечислять в рамках этичного теста:

имя хоста, домен/рабочая группа (если раскрывается);

доступные SMB-шары (без скачивания лишних данных);

требования к подписи SMB и версии протокола.

Инструменты и ссылки:

Samba smbclient

enum4linux-ng

Пример (лаборатория):

Как собирать результаты так, чтобы они превращались в отчёт

У Middle-специалиста результаты разведки всегда:

воспроизводимы (понятно, чем получено);

трассируемы (когда и откуда);

минимально шумные (есть фильтрация мусора);

привязаны к scope.

Практичный формат артефактов:

Каталоги по целям: targets/<asset>/...

Для каждого запуска:

- команда (полностью) - дата/время - версия инструмента - выходной файл

Итоговая сводка:

- assets.csv (asset, ip, ports, protocol, service, notes)

Пример структуры:

Типичные ловушки на разведке и как их обходить

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

Смешивание пассивных и активных данных: потом сложно доказать источник.

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

Нет учёта виртуальных хостов: один IP может обслуживать десятки сайтов.

Сканирование без DNS-контекста: вы пропустите важные поддомены и окружения.

Что должно получиться после этой статьи

После освоения материала вы должны уметь:

Формализовать scope и правила работы так, чтобы не выходить за границы.

Разделять OSINT (пассивную) и активную разведку и выбирать корректный подход.

Делать базовое сканирование Nmap и подтверждать результаты вручную.

Проводить перечисление DNS/HTTP/TLS/SMB на уровне, достаточном для дальнейшего поиска уязвимостей.

Вести артефакты разведки так, чтобы они напрямую легли в отчёт.

Веб-пентест: OWASP Top 10, тестирование API и поиск логических багов

Как эта тема продолжает предыдущие статьи курса

В прошлых статьях вы построили фундамент (сети, Linux/Windows, HTTP, инструменты) и научились работать методологически (scope, OSINT, сканирование, перечисление и артефакты). Теперь мы применяем это к самой частой практике в коммерческом пентесте: проверке веб-приложений и API.

На уровне Middle от вас ждут не только умения «прогнать сканер», а способности:

быстро собрать картину приложения (роли, потоки, критичные данные);

находить типовые уязвимости из индустриальных чек-листов;

тестировать API так же уверенно, как веб-интерфейс;

находить логические баги (business logic), которые автоматикой почти не ловятся;

писать воспроизводимые доказательства и рекомендации.

Ключевые ориентиры:

OWASP Top 10 2021

OWASP API Security Top 10

OWASP ASVS

PortSwigger Web Security Academy

> Работайте только в легальном контуре. Даже безобидный на вид тест может нарушить правила, если выходит за рамки scope или создаёт нагрузку.

Картина веб-приложения: что именно мы тестируем

Веб-система почти всегда состоит из нескольких частей:

браузерный фронтенд (HTML/JS);

бэкенд (HTTP API, серверная логика);

база данных и кеши;

внешние интеграции (платежи, почта, SMS, SSO);

хранилища файлов (локальные или облачные);

инфраструктурные компоненты (reverse proxy, WAF, CDN).

!Где пентестер перехватывает и анализирует запросы и какие типовые компоненты есть у веб-системы

На практике это означает: почти любая проверка сводится к контролю над входными данными (параметры, заголовки, куки, тело запроса) и проверке того, как приложение:

аутентифицирует пользователя;

авторизует действие;

валидирует и обрабатывает вход;

пишет/читает данные;

взаимодействует с внешними сервисами.

Методология веб-пентеста: поток работы Middle

Ниже — рабочий, воспроизводимый процесс, который удобно превращать в артефакты и отчёт.

Уточнить scope именно для веб

- домены и поддомены, окружения (prod/stage/dev), IP, пути; - разрешены ли переборы, сканеры, нагрузка; - есть ли тестовые аккаунты для разных ролей.

Собрать карту приложения

- основные разделы и бизнес-функции; - роли и разрешения; - критичные операции (платежи, смена email, выдача прав, выгрузки).

Базовая техническая разведка

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

Проверки по OWASP Top 10

- не «всё подряд», а приоритизация по поверхности и рискам.

Отдельный трек: API

- аутентификация, авторизация, массовое назначение, rate limit.

Логика и злоупотребления

- проверка инвариантов (что не должно быть возможно ни при каких условиях).

Доказательства и рекомендации

- точный запрос/ответ, шаги воспроизведения, влияние и исправление.

OWASP Top 10: как использовать список правильно

OWASP Top 10 — это не «чек-лист из 10 пунктов», а классификация самых распространённых и значимых классов рисков.

Ниже — OWASP Top 10 (2021) и практический взгляд пентестера: как искать и какие признаки.

| Категория OWASP | Что это на практике | Где часто проявляется | |---|---|---| | Broken Access Control | пользователь делает то, что не должен | IDOR, админские функции, смена чужих данных | | Cryptographic Failures | утечки из-за слабой криптографии или её отсутствия | HTTP без TLS, слабые настройки cookies, хранение секретов | | Injection | интерпретация данных как команд/запросов | SQL/NoSQL инъекции, OS command injection | | Insecure Design | риск из-за неверной архитектуры/логики | отсутствие лимитов, неверные роли, опасные сценарии | | Security Misconfiguration | неправильные настройки | лишние методы, debug, открытые панели | | Vulnerable and Outdated Components | известные уязвимости в зависимостях | старые CMS, библиотеки, контейнеры | | Identification and Authentication Failures | проблемы входа/сессий | слабые пароли, фиксация сессий, отсутствие MFA | | Software and Data Integrity Failures | риск из-за цепочки поставки и целостности | небезопасные обновления, неподписанные артефакты | | Security Logging and Monitoring Failures | атаки не замечаются | отсутствие логов входа, алертов, трассировки | | SSRF | сервер делает запросы куда не должен | превью URL, импорты по ссылке, webhooks |

Broken Access Control: база, которую проверяют всегда

Access control — это ответ на вопрос: разрешено ли этому пользователю выполнить это действие над этим объектом. Самая частая ошибка: разработчик проверил «пользователь залогинен», но не проверил «это его объект».

Что тестировать:

вертикальная эскалация: доступ к админ-функциям от обычного пользователя;

горизонтальная: доступ к данным других пользователей (IDOR);

обход ограничений через прямые вызовы API;

манипуляции ролями в токенах/профиле.

Практические приёмы:

меняйте идентификаторы объектов (id, userId, accountId) и смотрите, выдаёт ли система чужие данные;

сравнивайте поведение UI и прямого API: UI может скрывать кнопку, но API всё равно доступно;

фиксируйте матрицу ролей: «роль → действие → ожидаемый результат».

Injection: когда входные данные становятся кодом

Инъекция — это ситуация, когда приложение передаёт ваши данные в интерпретатор (SQL, shell, шаблонизатор) без правильной обработки.

Что важно для Middle:

подтверждать не только ошибкой, но и контролируемым эффектом (в рамках разрешённого);

понимать, какой именно интерпретатор участвует (SQL или NoSQL, bash или PowerShell);

помнить, что WAF и фильтры могут давать ложные ощущения защиты.

Источники для практики техники и паттернов:

PortSwigger: SQL injection

SSRF: запросы с сервера как отдельная поверхность

SSRF появляется, когда сервер делает исходящие запросы по данным пользователя.

Где искать:

«загрузить по ссылке», «импортировать из URL», «сгенерировать превью»;

webhooks и интеграции, куда приложение отправляет запросы;

обработка изображений/документов с внешними ссылками.

Что проверять:

можно ли заставить сервер ходить на внутренние адреса;

можно ли получить метаданные облака (если система в облаке и это в scope);

есть ли allowlist доменов и как она обходится.

Материал:

PortSwigger: SSRF

Identification and Authentication Failures: вход, токены, сессии

Цель теста — не «подобрать пароль», а проверить, что механизм идентификации и сессии не позволяет:

входить без знания секрета;

фиксировать или подменять сессию;

сохранять токены небезопасно;

обходить MFA, если оно заявлено.

Что собирать как артефакты:

параметры cookies (например, наличие HttpOnly, Secure, разумного времени жизни);

поведение logout (сессия реально инвалидируется или только удаляется cookie в браузере);

политика повторных попыток и rate limit.

Security Misconfiguration: «всё лишнее — риск»

Проверяйте:

включён ли debug и подробные ошибки;

открыты ли административные панели;

какие HTTP-методы разрешены;

есть ли опасные заголовки и утечки версий.

Инструментально это часто начинается с ручного curl и перехвата в Burp.

Тестирование API: как не пропустить главные классы ошибок

API — это не «что-то отдельное»: чаще всего именно API и есть реальный интерфейс управления данными. UI лишь вызывает эндпоинты.

Ориентир для системного подхода:

OWASP API Security Top 10

Базовая карта API

Перед активными тестами соберите:

базовые URL (например, /api/v1/), версии API;

тип аутентификации: cookie session, JWT, OAuth2;

какие роли есть и какие эндпоинты доступны;

форматы: JSON, XML, multipart (загрузки).

Источники истины:

Swagger/OpenAPI (/swagger, /openapi.json), если доступно;

трафик в прокси (Burp/ZAP) во время обычной работы;

мобильное приложение, если оно в scope.

Критичный класс: BOLA (Broken Object Level Authorization)

BOLA — это API-вариант IDOR: объект доступен по идентификатору, но сервер не проверяет, что он принадлежит пользователю.

Практика теста:

найдите запрос вида GET /api/orders/12345;

создайте второй аккаунт;

замените идентификатор на заказ второго аккаунта;

проверьте чтение и модификацию (GET, PATCH, DELETE).

Важно фиксировать, какие данные утекли и какое действие выполнено.

Аутентификация и токены в API

Что часто ломается:

принятие токена «в любом месте» (например, и в cookie, и в header), что расширяет поверхность атаки;

неправильная проверка подписи JWT или использование небезопасных настроек;

слишком долгоживущие refresh-токены;

отсутствие привязки сессии к контексту (например, устройство, IP) там, где это требуется моделью угроз.

Полезная практика: проверить, что сервер отклоняет запросы при:

отсутствующем токене;

поддельном токене;

токене другого пользователя;

токене с истёкшим сроком.

Mass Assignment: когда сервер принимает лишние поля

Ошибка возникает, когда API принимает JSON и автоматически мапит поля на модель, позволяя менять то, что менять нельзя.

Пример ситуации:

клиент отправляет { "name": "Alice" };

вы добавляете { "role": "admin" } или { "isPaid": true };

сервер «послушно» применяет.

Как тестировать:

сравните поля в ответе и в запросе;

попробуйте добавить поля, похожие на системные (role, isAdmin, status, price, ownerId);

смотрите, появились ли изменения в профиле/объекте после запроса.

Rate limiting и защита от перебора

API часто забывают защищать лимитами даже когда UI защищён.

Проверяйте:

есть ли лимиты на login, reset password, OTP;

блокируются ли агрессивные запросы к «дорогим» эндпоинтам;

корректны ли ответы при превышении лимита.

Важно: любой тест на лимиты согласуйте с Rules of Engagement, чтобы не устроить DoS.

Валидация входных данных и схемы

Что проверять:

типы (строка вместо числа, массив вместо объекта);

граничные значения (пусто, очень длинно, отрицательно);

неожиданные поля;

вложенные структуры.

Это помогает находить не только баги, но и возможные инъекции или обходы логики.

Логические баги: как мыслит Middle

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

Автоматические сканеры почти всегда слабы здесь, потому что:

нужен контекст ролей и процесса;

важна последовательность шагов;

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

Подход «инварианты и злоупотребления»

Сформулируйте инварианты: что должно быть истинно всегда.

Примеры инвариантов:

пользователь не может получить скидку больше установленного лимита;

цена товара не может стать отрицательной;

один и тот же купон нельзя применить дважды;

нельзя оплатить заказ чужой картой от имени другого пользователя;

нельзя менять роль через пользовательский интерфейс или API.

Дальше придумайте злоупотребления:

поменять порядок шагов (сначала «подтвердить», потом «изменить»);

повторить запрос (replay) после успешного действия;

сделать гонку (race condition) параллельными запросами;

подменить идентификаторы объектов в критичных местах;

обойти UI и вызвать API напрямую.

!Ментальная модель, как системно искать бизнес-логические уязвимости

Race condition: когда два запроса побеждают систему

Race condition появляется, если приложение не ожидает одновременных действий.

Типовые примеры:

двойное списание или двойная выдача бонуса;

обход лимита на применение купона;

покупка товара по старой цене при одновременном обновлении.

Как тестируют аккуратно:

находят критичный запрос (например, «применить купон»);

пытаются отправить его параллельно (в Burp это часто делают через инструменты для повторной отправки и параллелизма);

проверяют эффект на балансе/заказе.

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

Признаки логических уязвимостей в интерфейсе и API

Сигналы, на которые стоит реагировать:

критичные параметры приходят от клиента (например, price, role, isVerified);

сервер «верит» данным фронтенда без перепроверки;

в ответах видны лишние поля, которые «как будто внутренние»;

один и тот же эндпоинт используется разными ролями без явной матрицы разрешений;

есть много переходов состояний (draft → confirmed → paid → shipped), но нет явных проверок.

Практика в лаборатории: минимальный безопасный набор действий

Ниже — что стоит отработать на учебном стенде (например, OWASP Juice Shop), не выходя в «опасные» техники.

Настройте перехват трафика

- браузер → Burp/ZAP → приложение.

Составьте карту приложения

- роли, ключевые функции, список эндпоинтов.

Отработайте проверку авторизации

- минимум два аккаунта; - попытки доступа к чужим объектам.

Отработайте базовый трек API

- поиск OpenAPI/Swagger; - проверка BOLA и mass assignment.

Отработайте один сценарий логического теста

- повтор запроса (replay) на критичное действие; - тест изменения порядка шагов.

Как оформлять находки, чтобы это было уровнем Middle

Минимальный стандарт описания уязвимости (в заметках и в отчёте):

Контекст

- где найдено (URL/эндпоинт), какая роль, какие предусловия.

Шаги воспроизведения

- последовательность действий и точный запрос (метод, путь, параметры).

Фактический результат

- что произошло (данные утекли, действие выполнено).

Ожидаемый результат

- что должно было быть.

Влияние

- какие риски для бизнеса и безопасности.

Рекомендация

- конкретное исправление (проверка авторизации на сервере, allowlist, валидация схем, транзакции/блокировки при гонках).

Полезный ориентир для требований к контролям:

OWASP ASVS

Что должно получиться после этой статьи

После освоения материала вы должны уметь:

использовать OWASP Top 10 как карту рисков и приоритизации, а не как «список ради списка»;

тестировать API на BOLA, mass assignment, ошибки аутентификации и отсутствие лимитов;

строить карту ролей и объектов и проверять авторизацию системно;

искать логические баги через инварианты, последовательность шагов и повторы запросов;

оформлять находки с воспроизводимостью и понятным влиянием.

Эксплуатация и постэксплуатация: privesc, lateral movement и AD основы

Как эта тема продолжает курс

В прошлых статьях вы научились собирать поверхность атаки (scope, OSINT, сканирование, перечисление) и находить уязвимости в вебе и API (OWASP Top 10, логика). Следующий уровень сложности в реальных проектах начинается после первого подтверждённого доступа или контроля над уязвимой функцией: нужно понять, как превратить точку входа в измеримый риск.

Для Middle-пентестера это обычно означает три компетенции:

Эксплуатация: подтверждение уязвимости с контролируемым эффектом и минимальными побочными воздействиями.

Постэксплуатация: повышение привилегий (privesc) и перемещение по инфраструктуре (lateral movement) в рамках разрешений.

Понимание Active Directory (AD): базовая модель домена, аутентификация и типовые пути компрометации.

> Всё ниже применяйте только в легальной лаборатории и в рамках согласованного scope и Rules of Engagement. Даже «безопасные» действия после доступа могут нарушить договорённости.

!Диаграмма, показывающая как privesc и lateral movement связываются в один путь атаки

Принципы безопасной эксплуатации

Эксплуатация в пентесте отличается от «взлома ради взлома»: ваша цель не максимальный ущерб, а доказательство риска.

Ключевые принципы:

Минимально достаточное воздействие: доказывайте уязвимость самым щадящим способом.

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

Контроль данных: не скачивайте лишнее; не трогайте персональные и коммерческие данные без необходимости.

Согласование опасных действий: переборы, гонки, действия с высокой нагрузкой, любые попытки «закрепиться».

Хорошая опора для процесса:

Penetration Testing Execution Standard (PTES)

Что считается «постэксплуатацией» на практике

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

Типовые цели постэксплуатации:

Поднять привилегии: пользователь → администратор/root.

Расширить охват: попасть на другие хосты и сервисы.

Подтвердить влияние: доступ к критичным данным/операциям.

Сформулировать рекомендации: какие конкретные настройки и процессы привели к пути атаки.

Privilege escalation (privesc): смысл и границы

Privilege escalation — получение более высоких прав на том же хосте или в той же системе контроля доступа.

Важно различать:

Вертикальная эскалация: обычный пользователь становится администратором.

Горизонтальная эскалация: доступ к ресурсам другого пользователя того же уровня (например, чтение чужих файлов/токенов), часто как шаг к вертикальной.

Прежде чем пытаться privesc, Middle-специалист формулирует:

Какая у меня текущая роль и права?

Какие политики безопасности ожидаются в этой среде?

Какой вектор privesc здесь наиболее вероятен: конфигурация, учетные данные, уязвимость компонента?

Privesc в Linux: типовые классы ошибок

Ниже — наиболее частые направления, которые встречаются в корпоративных Linux-серверах. Это не «пошаговый взлом», а карта для системного анализа.

Ошибки в sudo

Смысл: пользователю разрешили выполнять команды от root, но ограничения можно обойти.

Что проверяют (в рамках лаборатории и разрешений):

Какие команды разрешены через sudo.

Можно ли запустить интерпретатор, редактор или инструмент, который позволяет выйти в shell.

Есть ли небезопасные переменные окружения или разрешён запуск без пароля.

Официальная справка по механике:

sudo — manual

Небезопасные права на файлы и секреты

Самый «приземлённый» privesc: секреты лежат там, где их не должны читать.

Частые источники:

конфиги приложений с паролями к БД;

.env файлы;

резервные копии в каталогах, доступных группе;

приватные ключи и токены в домашнем каталоге.

SUID/SGID и Linux capabilities

Смысл: бинарнику дали особые права, чтобы он мог делать привилегированные операции. Если бинарник небезопасен или его можно использовать неожиданным способом, это может привести к повышению прав.

Термины:

SUID: программа запускается с правами владельца файла.

SGID: программа запускается с правами группы файла.

Linux capabilities: более «тонкая» модель привилегий, когда процессу дают не root, а конкретную возможность.

Официальная справка:

capabilities — Linux manual

Планировщики задач и сервисы

Смысл: что-то исполняется автоматически с высокими правами, но вы можете:

изменить исполняемый файл;

подменить путь;

изменить конфиг;

контролировать директорию, из которой подхватываются скрипты.

Полезный ориентир по устройству systemd:

systemd.unit — документация

Уязвимости ядра и пакетов

Это более рискованный класс: эксплуатация уязвимости ОС может быть нестабильной.

Правило для Middle:

в реальном проекте сначала исчерпывайте конфигурационные причины и утечки секретов;

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

Privesc в Windows: типовые классы ошибок

В Windows privesc часто связан с тем, как устроены службы, права на объекты и учетные данные.

Неправильные ACL и «перезаписываемые» компоненты

Смысл: у обычного пользователя есть права на:

папку службы;

исполняемый файл службы;

конфигурацию службы;

определённые ветки реестра.

Если служба запускается от имени LocalSystem или администратора, контроль над её исполняемым кодом может привести к повышению прав.

Справка по сервисам Windows:

Microsoft Learn: Windows services

Всегда думайте про UAC и контекст токена

UAC не равен «нет админ-прав». Важно понимать:

вы в группе администраторов или нет;

ваш процесс запущен с повышением или без;

какие действия требуют подтверждения.

Справка:

Microsoft Learn: User Account Control

Учетные данные и их следы

В корпоративной Windows-среде часто встречаются:

сохранённые пароли (в приложениях, скриптах, планировщиках задач);

повторное использование локальных админ-паролей;

токены и ключи доступа к облачным ресурсам.

Важно: любые действия, связанные с извлечением учетных данных, обычно жёстко регулируются Rules of Engagement и требуют согласования.

Lateral movement: как перемещаются по инфраструктуре

Lateral movement — это получение доступа к другим системам, используя текущие привилегии, учетные данные, доверия и сетевую связность.

Мыслительная модель:

Есть ли у меня учетные данные или токен, который примут другие сервисы?

Есть ли сеть и маршруты до других хостов?

Есть ли удалённые протоколы управления (SSH, RDP, WinRM, SMB)?

Могу ли я повысить привилегии на новом хосте так же, как на первом?

Удобная таксономия техник:

MITRE ATT&CK: Lateral Movement

Главные причины успешного lateral movement

повторное использование паролей на разных хостах;

слишком широкие права групп и сервисных аккаунтов;

отсутствие сегментации сети;

доступные административные протоколы «везде»;

слабый контроль локальных администраторов.

Что собирать как артефакты

Чтобы ваши выводы были «уровня Middle», фиксируйте не только факт доступа, но и причину:

какая учётка использовалась и откуда она взялась (в пределах допустимого раскрытия);

какой протокол и порт;

какие ограничения сети были или отсутствовали;

почему это проблема (например, нарушение принципа наименьших привилегий).

Pivoting и доступ к внутренним сегментам: базовая идея

Иногда цель lateral movement не «ещё один сервер», а выход в сегмент, который недоступен напрямую (например, внутренняя подсеть, сеть БД, подсеть админки).

Ключевые понятия:

Pivot host: хост, через который вы маршрутизируете трафик.

Сегментация: правило, что не все со всеми должны общаться.

На уровне Middle важно уметь объяснить заказчику:

какой участок сети стал доступен;

почему он не должен быть доступен из вашей исходной позиции;

какая настройка сети или контроля доступа это допустила.

Active Directory: минимальная база для пентестера

Active Directory (AD) — это система управления идентичностями и доступом в Windows-домене. Во многих компаниях компрометация AD означает компрометацию значительной части инфраструктуры.

Официальная отправная точка:

Microsoft Learn: Active Directory Domain Services overview

!Иллюстрация базовых объектов AD и связей между ними

Объекты AD: что нужно понимать

Базовые сущности:

Domain Controller (DC): сервер, который обслуживает аутентификацию и каталог.

Пользователь: учетная запись человека или сервисная учетная запись.

Компьютер: учетная запись машины в домене.

Группа: способ выдавать права набору пользователей.

OU: контейнер для объектов, упрощающий управление.

GPO: политики, которые применяются к компьютерам и пользователям.

LDAP и каталог

AD предоставляет каталог (справочник), который можно запрашивать по LDAP. Для пентестера это означает: многие «пути атаки» начинаются с того, что вы узнаёте структуру домена, группы и связи.

Справка:

Microsoft Learn: LDAP overview

Kerberos: логика без криптодеталей

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

Минимальная модель:

пользователь получает билет на вход в домен;

затем получает билеты на конкретные сервисы;

сервис доверяет билетам, выданным доменом.

Справка:

Microsoft Learn: Kerberos authentication overview

Типовые причины компрометации домена (на уровне концепций)

Ниже перечислены причины и классы ошибок, которые чаще всего приводят к «домино-эффекту» в AD. Формулировки специально даны концептуально: ваша задача — научиться распознавать риск и подтверждать его в согласованной лаборатории.

Слабые и повторно используемые пароли

Если один пароль подходит к множеству систем или сервисных учеток, lateral movement становится линейным.

Что важно фиксировать в отчёте:

где именно повторяется доступ;

почему это нарушение политики;

какие меры: парольные политики, MFA там, где возможно, и управление локальными админами.

Чрезмерные права групп и сервисных аккаунтов

Частая реальность: сервисные аккаунты имеют слишком широкие права, потому что «так быстрее настроить». Это часто создаёт короткий путь к критичным ресурсам.

Ошибки делегирования и доверий

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

Справка по идее делегирования:

Microsoft Learn: Kerberos constrained delegation overview

Небезопасные ACL на объектах AD

Если учетная запись может менять свойства важного объекта (например, группы, GPO или учетной записи администратора), это может привести к эскалации без «эксплойтов».

Как Middle-специалист ищет путь атаки в AD

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

Подход:

Зафиксировать исходную позицию

Собрать данные о группах и правах

Построить возможные переходы

Подтвердить один переход с минимальным воздействием

Остановиться на достаточном уровне доказательства

Инструмент, который часто используют для визуализации связей в AD:

BloodHound (GitHub)

Важно: инструмент сам по себе не цель. Цель — объяснить путь и первопричины.

Постэксплуатация и «что нельзя делать по умолчанию»

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

Типичные «красные зоны», которые почти всегда требуют явного согласования:

любые формы закрепления (persistence);

массовое скачивание данных;

действия, способные повлиять на доступность (нагрузка, перезапуски критичных сервисов);

любые техники, связанные с извлечением или подбором учетных данных.

На уровне Middle правильная стратегия такая:

подтвердить риск точечно;

собрать артефакты;

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

Как оформлять результаты privesc и lateral movement

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

Контекст

Исходные права и позиция

Шаги воспроизведения

Результат и доказательства

Влияние

Рекомендации

Примеры доказательств, которые ценят заказчики:

минимальный набор команд/действий, показывающих уровень прав;

сетевой факт доступа (протокол, порт, успешная аутентификация);

привязка к неверной настройке (права на файл, членство в группе, отсутствие сегментации);

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

Что должно получиться после этой статьи

После освоения материала вы должны:

понимать, чем эксплуатация отличается от постэксплуатации и почему важна минимизация воздействия;

знать основные классы privesc в Linux и Windows на уровне причин и проверок;

уметь объяснить lateral movement через триаду: учетные данные, связность сети, удалённые протоколы;

понимать базовую модель AD: объекты, роли DC, Kerberos и LDAP на уровне процесса;

уметь описать путь атаки как последовательность причин и переходов, а не как набор «инструментов».

Отчётность и профессиональная практика: доказательства, риск-оценка и ремедиация

Зачем Middle-пентестеру сильная отчётность

В предыдущих статьях вы прошли путь от базы (сети, ОС, инструменты) через методологию разведки до веб-пентеста и основ эксплуатации, privesc и lateral movement. На практике результат работы пентестера ценится не количеством найденных портов или «красотой» цепочки атак, а тем, насколько:

понятно и воспроизводимо доказано наличие проблемы;

корректно оценён риск для бизнеса и безопасности;

предложены реалистичные и проверяемые меры устранения;

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

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

Ключевые ориентиры и стандарты:

OWASP Web Security Testing Guide

OWASP ASVS

FIRST CVSS v3.1 Specification

NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

> Все примеры ниже подразумевают легальный контур, согласованный scope и Rules of Engagement.

Что такое «доказательства» в пентесте и почему они важнее слов

Доказательство в отчёте отвечает на вопросы:

Что именно было обнаружено?

Как это воспроизвести?

Какой эффект и влияние?

Почему это произошло (первопричина)?

Как исправить и как проверить, что исправлено?

Принципы качественных доказательств

Воспроизводимость: другой инженер должен повторить шаги и получить тот же результат.

Минимально достаточное воздействие: вы доказываете риск без лишнего доступа к данным и без разрушительных действий.

Трассируемость: понятно, когда, откуда и какими средствами получен результат.

Целостность: артефакты (логи, ответы сервера, скриншоты) не вызывают сомнений.

Какие артефакты обычно прикладывают

HTTP-запросы и ответы из прокси (Burp/ZAP), включая заголовки.

Вывод команд сканирования и перечисления (например, Nmap) с сохранением в файлы.

Скриншоты, но только как дополнение к запросам/логам.

Текстовые логи вашей активности и временная линия.

Конфигурационные фрагменты, если они в scope и их разрешено показывать.

Сильная фиксация: что именно сохранять

Чтобы доказательство было «уровня Middle», фиксируйте:

Контекст (цель, роль пользователя, окружение, дата/время).

Предусловия (нужен ли аккаунт, какая роль, какие данные тестовые).

Точные шаги (UI-операции и точные запросы).

Фактический результат (что получили или что смогли сделать).

Ожидаемый результат (как должно быть по требованиям безопасности).

Влияние (какие данные/операции под угрозой).

Рекомендация (что менять в коде/настройках/процессах).

!Схема показывает, как из одного тестового действия получить воспроизводимое доказательство

Профессиональные границы: что фиксировать, а что не трогать

Правило минимизации данных

В коммерческом пентесте вы почти всегда обязаны следовать принципу «минимум данных для доказательства». Это относится и к вебу, и к инфраструктуре, и к AD.

Практические рекомендации:

Используйте тестовые аккаунты и тестовые сущности (заказы, документы), если они предоставлены.

Если проверка требует показать доступ к данным, показывайте минимальную выборку.

Не скачивайте базы «целиком» ради доказательства.

Обращение с чувствительными данными

Согласуйте заранее:

где хранятся артефакты (шифрование диска, доступ по принципу наименьших прав);

как маскировать секреты в отчёте (токены, cookies, персональные данные);

сроки хранения и порядок удаления.

Практичный подход к маскированию:

показывать только первые и последние символы секрета, например AKIA...9XQ2;

в скриншотах закрывать чувствительные поля;

в приложениях к отчёту хранить «сырой» трафик только если это явно разрешено.

Структура отчёта: как сделать документ полезным для разных аудиторий

Отчёт обычно читают как минимум три аудитории:

менеджмент и владельцы продукта;

инженеры (разработка, DevOps, админы);

безопасность (AppSec, SecOps, GRC).

Значит, документ должен иметь два слоя: краткое резюме и технические детали.

Рекомендуемая структура

Executive summary

Scope и ограничения

Методология и допущения

Сводка результатов

Детальные находки

Рекомендации по ремедиации и приоритизация

Приложения (артефакты, список хостов, версии инструментов)

!Макет помогает представить, как выглядит отчёт, который удобно читать менеджменту и инженерам

Executive summary: что туда писать

Executive summary отвечает на вопрос: что плохого может случиться и что делать в первую очередь.

Держите фокус на:

количестве и критичности находок;

кратком описании самых важных рисков;

системных причинах (например, «проблемы контроля доступа в API»);

предложении плана: «исправить критичное → внедрить контроли → ретест».

Избегайте:

перегруза терминами и аббревиатурами;

«технической прозы» без влияния на бизнес;

подробных PoC в этом разделе.

Техническая часть: формат одной находки

Для большинства команд удобен единый шаблон на каждую уязвимость.

Минимальный шаблон:

Название и идентификатор (внутренний ID)

Уровень критичности

Затронутые активы (URL/эндпоинты, хосты)

Описание (что это и почему проблема)

Шаги воспроизведения

Фактический результат

Ожидаемый результат

Влияние

Рекомендации

Признаки исправления (как проверить после ремедиации)

Важно: «шаги воспроизведения» должны быть настолько конкретными, чтобы инженер мог повторить без догадок.

Риск-оценка: как объяснить приоритеты без магии

Риск-оценка нужна, чтобы:

сравнить разнородные проблемы (веб, сеть, AD) в одной шкале;

помочь планировать исправления;

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

Два популярных подхода

Качественная шкала

- например: Critical/High/Medium/Low - плюс пояснение почему (эксплуатация, доступ, влияние)

Стандартизированная оценка

- часто используют CVSS как общий язык - спецификация: FIRST CVSS v3.1 Specification

На уровне Middle важно понимать ограничения:

CVSS хорошо описывает техническую сторону, но слабо учитывает бизнес-контекст.

«Критичность» должна учитывать реальные активы: деньги, персональные данные, доступность сервиса, юридические риски.

Практичная качественная матрица

Можно использовать простую матрицу: вероятность эксплуатации и влияние. В отчёте достаточно объяснить словами, на основании каких факторов вы сделали вывод.

Факторы вероятности:

доступность из интернета или только из внутренней сети;

наличие аутентификации и требования к роли;

сложность эксплуатации и наличие публичных техник;

наличие компенсирующих контролей (WAF, сегментация, MFA).

Факторы влияния:

утечка чувствительных данных;

изменение данных или финансовые операции;

эскалация привилегий и компрометация домена;

влияние на доступность.

Таблица для отчёта, чтобы читателю было проще ориентироваться:

| Уровень | Короткое описание | Типовые примеры | |---|---|---| | Critical | компрометация критичных данных или полный контроль | RCE, доменная эскалация, массовая утечка | | High | серьёзная утечка или значимое изменение данных | BOLA/IDOR в платежах, privesc до admin | | Medium | ограниченное влияние или нужны дополнительные условия | XSS с ограничениями, частичная утечка | | Low | низкое влияние или в основном hardening | лишние заголовки, информационные утечки |

Привязка к бизнесу: как формулировать влияние

Плохая формулировка:

«возможна компрометация»

Хорошая формулировка:

«пользователь с ролью Customer может читать и изменять заказы других пользователей, что приводит к утечке персональных данных и подмене адресов доставки»

Правило: влияние должно описывать какое действие и над какими объектами возможно.

Ремедиация: как давать рекомендации, которые реально внедрят

Пентест считается полезным, если рекомендации приводят к исправлениям. Рекомендации уровня Middle:

конкретные;

проверяемые;

учитывают первопричину;

предлагают минимально необходимое изменение, а не «переписать всё».

Типы рекомендаций

Тактические

- быстрые фиксы, которые уменьшают риск сразу - пример: «проверять ownership объекта на сервере для эндпоинта X»

Стратегические

- изменения процессов и стандартов - пример: «внедрить единый слой авторизации и покрыть критичные эндпоинты тестами по матрице ролей»

Как связывать находку с первопричиной

Частая ошибка отчёта: описать симптом, но не причину.

Примеры первопричин:

отсутствие серверной авторизации на уровне объекта (BOLA);

доверие к параметрам клиента (mass assignment, price/role в запросе);

небезопасные ACL на службе Windows;

отсутствие сегментации, позволяющее lateral movement.

Рекомендация должна закрывать причину, а не только маскировать проявление.

Полезные ссылки для формулирования контролей

OWASP ASVS

OWASP API Security Top 10

Ретест и верификация исправлений

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

Что важно согласовать заранее

какие находки входят в ретест;

сроки и окружение (prod или staging);

критерий успешности.

Как описывать критерий успешности в находке

Добавляйте раздел «Признаки исправления»:

какой запрос должен возвращать отказ (403 или эквивалент);

какие роли должны иметь доступ;

какие негативные тесты должны не проходить;

какие логи или события должны появляться при попытке атаки.

Так вы превращаете находку в мини-спецификацию для проверки.

Коммуникация и профессиональная практика на проекте

Таймлайн и журнал активности

Ваши материалы должны позволять восстановить ход работ:

когда и что запускалось;

какие цели были затронуты;

какие результаты получены.

Практика из предыдущих статей про артефакты остаётся актуальной, но в отчётности она становится критичной.

Как сообщать о критичных находках

Если обнаружено что-то уровня Critical, «дождаться конца проекта» может быть неправильным.

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

Проверяют воспроизводимость.

Минимизируют доказательство.

Немедленно уведомляют контактных лиц по согласованному каналу.

Фиксируют факт уведомления и время.

Это соответствует профессиональной этике и снижает риск реального инцидента.

Тон и стиль

Пишите нейтрально: без обвинений и эмоций.

Разделяйте факт и интерпретацию.

Не переоценивайте: если у вас гипотеза, так и пишите.

Частые ошибки в отчётах и как их избежать

Нет воспроизведения: «уязвимость есть» без шагов и запросов.

Нет влияния: описан баг, но не объяснено, чем он опасен.

Нереалистичная ремедиация: «переписать на другой фреймворк».

Смешение окружений: находка из staging описана как prod.

Слишком много скриншотов вместо фактов: скриншоты без запросов и логов плохо проверяются.

Что должно получиться после этой статьи

После освоения материала вы должны уметь:

собирать доказательства так, чтобы находка была воспроизводимой и минимально разрушительной;

писать отчёт, понятный и менеджменту, и инженерам;

делать риск-оценку с понятным обоснованием и приоритизацией;

давать рекомендации, которые закрывают первопричину и проверяются ретестом;

вести артефакты и коммуникации в профессиональном формате.