«Ну всё, отчет у клиента, можно выдохнуть. Через неделю новый проект — пора забыть этот и готовиться к следующему». Знакомый сценарий?
Меня зовут Дмитрий Неверов, я технический консультант в Бастионе. Занимаюсь пентестами инфраструктур на базе Active Directory. Сегодня хочу поговорить о постпроектной работе — том этапе, который начинается уже после завершения пентеста. Хотя примеры будут связаны с AD, тему можно переложить на любую другую область наступательной безопасности.
На практике постпроектной работой часто пренебрегают. Отчет сдан, уязвимости задокументированы, клиент доволен — казалось бы, цель достигнута. Но именно в этот момент мы теряем самый ценный ресурс для роста: живой опыт, который еще не забылся. Непроверенные гипотезы, неисследованные векторы атаки — всё это остается без внимания, хотя именно здесь часто скрываются самые ценные уроки.
Постпроектная работа — это способ превратить завершенный пентест в источник долгосрочного развития. Она помогает разобраться в вопросах, на которые не хватило времени, и превратить разовые находки в системные знания. Без этого вы рискуете навсегда застрять в рутине, повторять одни и те же ошибки и упускать новые векторы.
Давайте разберем, почему этот этап часто пропускают, какие возможности при этом теряются и как сделать постпроектную работу регулярной частью своей практики.
Ловушки для пентестера
Проблема #1: «Сдали отчет — забыли»
Это самая распространенная ошибка. Вы потратили две недели на проект, но как только отчет уходит клиенту, вы переключаетесь на следующую задачу и не даете себе времени осмыслить, что произошло.
В чем здесь проблема? Пентест — это не просто список найденных уязвимостей. Это вызов, сложный процесс принятия решений, проб и ошибок, догадок и тупиков. Весь этот богатый материал остается нераспакованным. Вы не фиксируете, где действовали эффективно, а где теряли время, не запоминаете неочевидные находки, не задаетесь вопросом «а что, если бы я пошел другим путем?».
В результате каждый новый проект вы начинаете практически с нуля, опираясь только на уже зарекомендовавшие себя приемы. Прогресса нет, вы топчетесь на месте, а конкуренты, которые анализируют свои проекты, обгоняют вас.
Проблема #2: стагнация знаний в AD-пентесте
В мире пентеста Active Directory сложился негласный стандартный набор действий: запускаешь BloodHound, ищешь Kerberoastable-аккаунты, проверяешь атаки на ADCS, пробуешь SMB-Relay и, если повезет, — DCSync. Это работает в 70% инфраструктур, и клиенты довольны.
В результате вы не обновляете свои знания. Вы становитесь узким специалистом по трем‑четырем техникам, пропуская более элегантные, скрытные и глубокие пути к полной компрометации домена. Самое опасное — вы перестаете замечать, как много возможностей упускаете. А самое печальное — вы даже не узнаете, что упустили, потому что клиент не знает о возможных атаках и не спросит. Вы останетесь в неведении, а значит — не растете. И только когда попадаете в инфраструктуру, где ваши техники уже не работают, вы понимаете, что ваших знаний недостаточно.
Со временем к этим проблемам добавляются и другие:
Накопление «слепых зон». Если вы не анализируете, какие объекты или технологии вы проигнорировали, эти пробелы будут повторяться из проекта в проект.
Потеря времени на одни и те же ошибки. Без рефлексии вы будете снова и снова наступать на одни грабли — например, тратить часы на ручной перебор там, где можно было автоматизировать, или игнорировать неочевидные маршруты, потому что «так привыкли».
Снижение интереса к работе. Когда каждый проект похож на предыдущий, пропадает азарт. Работа превращается в механическое выполнение инструкции, а это прямой путь к выгоранию.
Отсутствие командной синергии. Вы не делитесь находками с коллегами, а они — с вами. Каждый учится на своих ошибках, но вместе вы могли бы расти гораздо быстрее.
Решение: разбор завершенных проектов как системный процесс
Что же делать? Ответ прост: после каждого проекта выделять время на рефлексию. Не пять минут, а полноценный сеанс, который включает в себя несколько этапов.
Этап 1. Сбор сырых данных
Пока проект свеж в памяти, запишите всё, что вы делали, даже если это кажется неважным:
Какие инструменты и команды вы использовали?
Какие решения принимали в критические моменты?
Где вы застревали и почему?
Что вы заметили, но не стали исследовать?
Какие технические или организационные ошибки допустили?
И самое главное — что нового узнали из проекта?
Это не отчет для клиента, это ваш личный дневник. Никто вас не осудит. Не редактируйте, пишите как есть.
Этап 2. Анализ и классификация
Теперь разберите эти записи по категориям. Например:
Успешные атаки — что сработало и почему.
Неудачные попытки — почему не сработало (не хватило прав, сработала защита, не учли конфигурацию).
Потеря времени — на что ушло больше всего времени и можно ли было избежать этого.
Упущенные возможности — векторы, которые вы заметили, но не проверили, или вообще не заметили.
Этап 3. Извлечение уроков
На основе анализа сформулируйте для себя три-пять конкретных выводов. Например:
«В следующий раз перед запуском Responder сначала проверю, запрещает ли групповая политика отравление LLMNR, чтобы сразу понять, имеет ли смысл выполнять эту атаку».
«Надо написать скрипт, который автоматически будет проверять права на службы на удаленных рабочих станциях».
«При атаке через SMB-relay стоит сразу проверять подписи SMB, чтобы не тратить время зря».
Этап 4. Практическое закрепление
Если вы обнаружили новый вектор, который не пробовали, или поняли, что вашей техники недостаточно, создайте лабораторный стенд и отработайте этот сценарий. Только так техника станет частью вашего рабочего арсенала, а не останется записью в заметках.
Самое главное не откладывайте всё это на потом. «Потом» никогда не настанет, и вы снова будете работать по привычному сценарию.
«А если я не узнал ничего нового?» Проблема «успешного успеха»
Иногда после завершения проекта возникает ощущение, что анализировать уже нечего: все атаки сработали, всё было гладко, никаких новых знаний. Это состояние я называю «успешный успех». Вроде бы всё хорошо, но роста нет.
Скорее всего, в инфраструктуре остались векторы, до которых вы просто не дошли. Попробуйте сознательно поискать то, что осталось за рамками проекта. Задайте себе несколько вопросов:
«А что бы я сделал, если бы у меня было еще 3 дня?» — вы наверняка нашли бы второстепенные векторы, которые отбросили из-за нехватки времени.
«Какие атаки я сознательно не применял, потому что считал их сложными или редкими?» — например, непонятные настройки в групповых политиках, атаки на доверие между лесами, на PKI.
«Какие векторы я даже не смотрел?» — например, настройки Rights Assessments, базы данных MSSQL, секреты SCCM.
Не ограничивайтесь тем, что лежит на поверхности. Иногда даже в самом простом домене есть тонкости конфигурации, которые вы не замечали, потому что не углублялись. Например, анализ групповых политик может показать, какие учетные записи используются для автоматизации задач, и это открывает путь к атакам на сервисные учетные записи.
После этого вернитесь к этапу 3 и сформулируйте уроки на тему «чего я не знаю». Даже если вы не сталкивались с этими темами в проекте, их отсутствие — уже информация. Вы составите список тем для самостоятельного изучения.
Отработка векторов в лаборатории
Одна из самых мощных практик постпроектной работы — это воссоздание в лабораторной среде тех атак, которые вы не успели или не смогли реализовать на проекте.
Как это делается:
Выявите вектор. Рефлексируя над проектом, вы обнаружили вектор или цепочку атаки, которую не реализовали.
Разверните аналогичную среду. Поднимите домен, настройте аналогичные связи, добавьте групповые политики.
Отработайте атаку «от и до». Не просто запустите готовую команду или программу, а разберите каждый шаг.
Задокументируйте для себя. Запишите последовательность команд, необходимые условия, признаки уязвимости. Так у вас появится готовый сценарий для следующего проекта.
Измените условия. Поменяйте условия, добавьте новое звено, усложните задачу или используйте другую программу или подход для реализации.
Этот подход превращает «неудачу» (то, что вы не сделали на проекте) в новый навык. Через три-четыре таких стенда вы закроете большинство пробелов и почувствуете уверенность в самых разных средах.
Не всегда есть возможность воссоздать в лабораторной среде вектор. Это может быть связанно с определенным программным обеспечением или тонкими настройками, которые знает только администратор. В таком случае зафиксируйте гипотезу и условия, при которых она могла бы сработать, чтобы проверить ее на одном из следующих проектов.
Как поделиться уроками с командой
Индивидуальная рефлексия — это хорошо, но знания начинают приносить максимальную пользу, когда ими делится вся команда. Вот несколько способов внедрить коллективный постпроектный анализ.
1. Проведите короткий разбор проекта
Соберитесь (вживую или онлайн) на 30–40 минут после каждого проекта. Формат простой:
каждый участник делится одним наблюдением, которое его удивило;
команда разбирает одну ошибку и обсуждает, как ее можно было избежать;
выбирает одну новую технику, которую стоит изучить всем;
берет один нереализованный вектор атаки и вместе обсуждает, как его можно было реализовать.
Не затягивайте, не превращайте встречу в допрос. Это должно быть живое и позитивное обсуждение.
2. Создайте общую базу знаний
Создайте wiki или другой внутренний ресурс, где команда сможет собирать накопленные знания. Продумайте структуру базы знаний, чтобы каждая запись относилась к своей категории и не валялась в общей куче. Например, после проекта вы узнали о нестандартном способе получения доступа через GPO — поделитесь этим.
Не превращайте базу знаний в набор ссылок на чужие статьи. Лучшая запись — это та, которая прошла через личный опыт.
3. Напишите «внутренний разбор» по горячим следам
Не отчет для клиента, а для коллег. Опишите, что пошло не по плану, какие были сюрпризы, какие нестандартные решения вы применили.
Это особенно ценно для младших специалистов, которые учатся на чужих ошибках. На конференциях и в статьях обычно показывают уже готовое решение, опуская десятки неудачных попыток, которые к нему привели. Внутренние отчеты как раз помогают сохранить этот опыт и передать его коллегам.
4. Разбирайте новые техники вместе
Раз в месяц проводите небольшой внутренний разбор новой техники. Один из участников команды показывает коллегам то, что недавно изучил или успешно применил. Лучше всего, если это будет демонстрация на стенде с разбором условий, ограничений и практических нюансов применения. Такой формат помогает быстрее распространять практические знания внутри команды, чтобы каждый не проходил один и тот же путь самостоятельно.
5. Интегрируйте уроки в стандарты
Если вы заметили, что часто пропускаете какую-то категорию атак, добавьте ее в обязательный чек-лист для всех будущих проектов. Так рефлексия перерастает в улучшение процессов.
6. Поделитесь собранной информацией
Пока проект еще не закрыт и собранные данные доступны, покажите свои записи, выводы и результаты коллегам. Свежий взгляд со стороны нередко помогает заметить векторы атаки, которые вы упустили во время проекта.
Если появляются новые идеи или гипотезы, воспроизведите их в лабораторной среде, проверьте на практике и задокументируйте результат в базе знаний.
Заключение
Проект сдан, отчет отправлен — но на этом работа только начинается. Самое важное происходит после того, как клиент получил свой отчет. Это момент, когда вы можете остановиться, оглянуться и увидеть свой собственный путь: где вы выросли, где споткнулись, куда двигаться дальше.
Постпроектная работа — это не роскошь, а необходимость. Она превращает каждый пентест в инвестицию в ваше профессиональное будущее. Если вы будете системно извлекать уроки из завершенных проектов, стендировать пропущенные атаки и делиться находками с командой, вы перестанете топтаться на одном месте. Ваши знания будут расти, ваша интуиция — обостряться, а каждый новый проект станет не рутиной, а приключением.
Помните: пентестер — это не тот, кто запускает инструменты, а тот, кто понимает, почему они работают, и что делать, когда они не работают. Мастерство зависит не от количества выполненных проектов, а от умения извлекать из каждого новые знания.
Так что в следующий раз, когда вы закроете проект, не спешите выдыхать. Возьмите блокнот, задайте себе три вопроса и сделайте шаг к новым высотам.
PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес‑ориентированной защиты от специалистов Бастиона