Чеклист пентестера: инструменты, скрипты, заметки

На втором подходе к OSCP потерял два часа не из-за сложной машины - из-за пропавшего вывода nmap. Tmux-сессия упала, scrollback ушёл вместе с результатом полного сканирования и NSE-скриптов. Пришлось запускать заново, ждать, нервничать. С того провала каждый проект стартует не с первой команды в терминале, а с mkdir и шаблона заметок в Obsidian. Этот чеклист пентестера - рабочий процесс из 20+ реальных проектов, а не теоретическая методичка PTES.

Организация работы пентестера: структура проекта до первого пакета​

Без подготовки через два дня выводы nmap, скриншоты из Burp Suite и логи crackmapexec валяются вперемешку в ~/Downloads. Найти нужный артефакт для отчёта - отдельный квест на полчаса. Чеклист пентеста начинается не со сканирования, а с создания рабочего пространства. Подробнее - в нашем статье о валидация безопасности.

Шаблон каталогов для каждого проекта:
Каталоги пронумерованы по этапам пентеста. В пятницу вечером нужно за секунды найти скриншот подтверждения RCE, а не грепать весь диск.

Автоматизация создания - первая инвестиция в скрипты для пентестера:
Вызов: newproject.sh client-2026-q3. На десятом проекте экономия на ручном mkdir измеряется часами.

Файл scope.txt заполняется до первого пакета данными из Rules of Engagement: IP-диапазоны, домены, временные окна, контакт для экстренной связи. Плохой scope - одна из главных причин провала пентестов: время уходит на выяснение границ вместо поиска уязвимостей. Scope не зафиксирован письменно - тест не начинается. Точка.

Чеклист пентеста: инструменты пентестера на каждом этапе​

Методология пентеста по PTES выделяет пять основных фаз. Ниже - чеклист с привязкой к конкретным инструментам и правилам логирования. Ключевое правило: каждый инструмент пишет вывод в файл, а не в stdout. Терминал - ненадёжное хранилище (спросите мой tmux).

Этап разведки​

Этап соответствует тактике Reconnaissance в MITRE ATT&CK (T1595, Active Scanning). Задача - собрать максимум данных до активного зондирования.

• Субдомены: amass enum -passive -d target.com -o 01-recon/subdomains.txt + перекрёстная проверка через subfinder
• DNS-записи (MX, TXT, CNAME): dig или dnsenum → 01-recon/dns.txt
• OSINT по сотрудникам: theHarvester -d target.com -b google,linkedin → 01-recon/emails.txt
• Утечки учётных данных через Have I Been Pwned или Dehashed - строго по согласованию с заказчиком
• Репозитории GitHub/GitLab на утечки ключей: gitleaks или trufflehog
• Certificate Transparency logs для скрытых поддоменов

Каждый найденный поддомен или email - строчка в файле, а не заметка в голове. Через неделю вы не вспомните, что нашли вручную в DNS-записях. Проверено.

Сканирование и оценка уязвимостей​

Тактика Discovery (T1046, Network Service Discovery). Переход от пассивного сбора к активному зондированию целей из scope.

• Полный TCP-скан: nmap -sS -sV -O -p- --min-rate 5000 -oA 02-scanning/nmap/full_tcp target. Флаг -oA создаёт три формата (.nmap, .xml, .gnmap) - страховка от потери данных и основа для парсинга
• UDP top-1000: nmap -sU --top-ports 1000 -oA 02-scanning/nmap/udp_top target. SNMP, DNS и TFTP забывают чаще всего - а именно через них бывают самые глупые точки входа
• Nuclei: nuclei -l live_hosts.txt -o 02-scanning/nuclei/results.txt. Библиотека ProjectDiscovery содержит более 9 000 шаблонов и обновляется при каждом новом CVE
• Nessus или OpenVAS для аудита по базе CVE - экспорт результатов в CSV в 02-scanning/nessus/
• Веб-директории: feroxbuster или gobuster → 02-scanning/web/dirs.txt
• Burp Suite Pro в пассивном режиме параллельно с ручной работой в браузере

Каждый потенциально уязвимый сервис - строчка в заметках с портом, версией и предварительной оценкой. Не «там Apache», а «10.10.10.5:8080 - Tomcat 9.0.31, проверить manager/html с дефолтными кредами». Разница между этими двумя записями - минут двадцать при переходе к эксплуатации.

Эксплуатация и сбор доказательств​

По MITRE ATT&CK эксплуатация - T1190 (Exploit Public-Facing Application) для внешних сервисов, T1110 (Brute Force) для подбора учётных данных. Пост-эксплуатация покрывает T1003 (OS Credential Dumping), T1078 (Valid Accounts), T1021 (Remote Services), T1083 (File and Directory Discovery).

Инструменты на этих этапах пентеста: Metasploit для готовых модулей, sqlmap для SQL-инъекций, Burp Suite для проверки веб-логики (BOLA/IDOR - по OWASP API Security Top 10, API1:2023), Hydra для брутфорса, CrackMapExec и BloodHound для AD-окружений.

Правило трёх скриншотов. Для каждой подтверждённой уязвимости нужны минимум три скриншота: (1) уязвимый параметр или сервис, (2) момент эксплуатации, (3) результат - whoami, доступ к данным. Файлы идут в 03-exploit/screenshots/ с именем вида IP_PORT_vuln-type_01.png. Нет скриншота - finding в отчёт не попадает. Без исключений.

Чеклист пост-эксплуатации:

• whoami /all или id - немедленно, со скриншотом
• Дамп хешей (SAM/NTDS для Windows, /etc/shadow для Linux) → 04-postexploit/loot/
• Все найденные учётки → creds.txt в корне проекта
• Сетевые подключения и ARP-таблица → 04-postexploit/network-info.txt
• Каждый lateral movement: исходный хост, целевой хост, использованный метод
• AD-окружение: SharpHound для графа BloodHound, Kerberoasting через impacket-GetUserSPNs, хеши для hashcat

В msfconsole обязательно включайте логирование сессии: spool 03-exploit/msf-session.log до начала работы. Потерянный вывод Meterpreter - потерянный finding. Восстановить его можно, но нервы и время уже не вернёшь.

Ведение заметок пентестера: Obsidian для пентеста​

Заметки отделяют 8-часовой рабочий день от 12-часового. Без системы ведения заметок пентестера до трети времени уходит на поиск того, что уже было найдено. Знакомо?

Obsidian для пентеста - мой основной инструмент. Markdown-файлы, [[wikilinks]] между хостами, мгновенный полнотекстовый поиск по хранилищу. Для каждого обнаруженного хоста - заметка по шаблону:
Если с хоста 10.10.10.5 прошёл lateral movement на 10.10.10.12, в обеих заметках появляется перекрёстная ссылка. Граф Obsidian при написании отчёта показывает цепочку атаки визуально - для себя полезно, заказчику в презентации тоже заходит.

CherryTree - альтернатива с древовидной структурой. Плюс: весь проект в одном файле (.ctb), легко переносить между машинами. Минус: бинарный формат, нет git-версионирования, для командной работы не годится. Работаете в команде с git - Obsidian. Один на проекте и нужна портативность - CherryTree. Оба варианта на порядок лучше, чем терминальный scrollback.

Критическая привычка - записывать процесс, а не только результат. Не «нашёл SQLi на /api/users», а «параметр id на /api/users, payload 1 OR 1=1-- вернул 200 с полным дампом, подтверждено через sqlmap с ключами --dbs --batch». Эта детализация спасает при составлении отчёта и при ретестах через месяц, когда в голове уже пусто.

Скрипты для автоматизации пентеста​

. Стандартная библиотека, ничего ставить не надо.

Массовый nuclei. При 50+ поддоменах в scope ручной запуск по каждому - издевательство. Связка cat 01-recon/subdomains.txt | httpx -silent | nuclei -o 02-scanning/nuclei/all.txt прогоняет всё за один проход, результат сразу в нужном каталоге.

Форматирование хешей. После impacket-secretsdump хеши нужно привести в формат для hashcat. Скрипт на Python извлекает NTLM-хеши из вывода secretsdump и складывает в файл для подбора. Экономия - 10 минут на хосте, на 20 хостах это уже три часа рутины, которую можно было не делать руками.

Pentest report template: от заметок к документу​

Отчёт - единственное, что видит заказчик. При правильном ведении заметок написание занимает 4-6 часов вместо двух дней. Разница - в подготовке, а не в скорости печати.

Структура pentest report template по методологии PTES:

1. Executive Summary - для руководства, без технических деталей, 1 страница. Если C-level не понял за минуту - переписывай
2. Scope and Methodology - что тестировалось, модель (black/grey/white), временные окна
3. Findings - каждая уязвимость отдельно: описание, severity по CVSS, скриншоты-доказательства, шаги воспроизведения, рекомендации по исправлению
4. Risk Rating - агрегированная оценка уровня безопасности
5. Appendices - полные логи сканирования, списки хостов, дополнительные скриншоты

Каждый finding привязан к evidence из 03-exploit/screenshots/. Нет скриншота - finding не попадает в отчёт. Это правило заставляет фиксировать доказательства в момент эксплуатации, а не вспоминать потом (и не находить).

Маппинг findings на MITRE ATT&CK добавляет ценности для зрелых заказчиков: T1190 для эксплуатации веб-сервиса, T1110 для подобранных паролей, T1003 для дампа хешей. Заказчики с SOC получают не просто список дыр, а карту тактик, которые их мониторинг пропустил.

Чеклист пентестера не заканчивается отправкой отчёта - через 2-4 недели ретест. Копируете проект с суффиксом -retest, проверяете каждый finding по списку. Структура каталогов та же, процесс - тот же.

За три года с этой системой ни один артефакт не потерялся. Но вот что я заметил - проблема никогда не в инструментах пентестера. Половина коллег до сих пор хранят всё в одном терминальном окне и восстанавливают по памяти. Эксплуатация у них на уровне, отчёты - нет: неполные findings, забытые скриншоты, раздражённые заказчики. Методология пентеста - не PTES на стене и не красивая схема из чьей-то презентации. Это привычка фиксировать каждый шаг в момент его совершения. Формируется она из повторения - проект за проектом, пока руки сами не начнут набирать -oA после каждого nmap и не откроют шаблон заметки до первого скана. На экзамене OSCP эта дисциплина важнее любого эксплоита: время жёстко ограничено, и без системы оно утекает на повторный сбор того, что уже было найдено. WAPT - для тех, кто хочет не один writeup, а 30 уровней прогрессии до OSCP-стандарта.