Призрак прошлого пентеста: почему путь к компрометации домена приходит в голову, когда проект уже закончен

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

Это состояние — «эффект инкубации» в чистом виде. Вы сидите за чашкой кофе или гуляете по парку, перебирая в голове логику атаки на Active Directory, и вдруг вас осеняет. Находки, которые раньше казались бесполезными, складываются в идеальную цепочку компрометации. Теперь вы понимаете, как нужно было действовать, но отчет уже сдан, а доступ к инфраструктуре закрыт.

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

Меня зовут Дмитрий Неверов, я технический консультант по тестированию внутренней инфраструктуры в Бастионе. В прошлой статье я уже упоминал постпроектную рефлексию. Теперь хочу подробнее разобрать, почему решения иногда приходят слишком поздно и что с этим делать.

Справка: что такое эффект инкубации

Это психологический феномен, при котором перерыв в работе над сложной задачей помогает найти решение. Ответ внезапно приходит сам по себе, часто в виде озарения («Эврика!»), после того как человек переключился на другую деятельность или отдохнул.

В психологии это одна из стадий творческого процесса по модели Грэма Уолласа: подготовка → инкубация → озарение → проверка. Если перевести модель на язык пентеста: сначала исследуйте проблему, затем дайте себе время переключиться, а когда придет озарение — проверьте, работает ли найденная цепочка на практике.

Симптомы «постпроектного озарения»

Чаще всего такие озарения связаны со сложными цепочками атак на Active Directory. Не с прямолинейными сценариями вроде Kerberoasting → Domain Admins, а с многоходовками, где для достижения цели нужно связать несколько находок. 

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

• Слишком рано списали находку со счетов. Вы нашли сервисную учетную запись с SPN, провели Kerberoasting, получили хеш и подобрали пароль. Затем выполнили распыление этого пароля, но это не дало результатов, и вы успокоились. Через пару дней вас осенило: вы так и не проверили, есть ли у этой сервисной учетки права локального администратора на сервере, куда прописана SPN, или на других серверах.

• Не разобрались в подозрительной детали. Вы увидели странную групповую политику, но не придали ей значения. А после проекта до вас доходит: «Всего-то надо было расшифровать пароль локального администратора, потому что ключ шифрования был в самом скрипте».

• Не связали находки между собой. Вы знали, что в инфраструктуре есть уязвимость ESC1, но сертификаты разрешено выпускать только определенной группой. Постфактум мозг подсказывает: у вас же были права локального администратора на все рабочие станции пользователей — нужно было найти машину пользователя из этой группы и захватить его учетку.

• Зациклились на одном способе атаки. Вы бились головой о стену, потому что EDR или Credential Guard не позволяли сделать дамп билетов Kerberos. Внезапно, через день после закрытия проекта, вы понимаете: можно было использовать функцию имперсонализации пользователя и выполнять команды от его имени.

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

Почему решение приходит потом? Анатомия ошибки

Дело не обязательно в недостатке знаний или невнимательности. Сама специфика работы с Active Directory создает условия, в которых легко упустить перспективный вектор атаки. Причин несколько.

1. Когнитивная перегрузка

Во время проекта вы тонете в сотнях объектов, групп, GPO и ACL. Чтобы не тратить время на всё подряд, приходится отсеивать детали, которые кажутся информационным шумом. Но они не исчезают из памяти. После проекта, когда напряжение спадает, мозг может сопоставить два таких факта и обнаружить между ними связь, которая открывает новый вектор атаки.

2. Нелинейная многовекторная связность (проблема «невидимых ребер»)

В сложных инфраструктурах путь к доменным привилегиям редко идет по прямой «пользователь → администратор». Обычно он проходит через несколько промежуточных звеньев: вложенные группы, права на объекты, делегирование, настройки GPO. BloodHound показывает эти связи в виде графа, но даже с ним непросто проследить все возможные цепочки. Во время проекта внимание сосредоточено на нескольких направлениях, и часть маршрутов остается вне поля зрения. А после перерыва вы возвращаетесь к тем же данным и замечаете, как уже знакомые связи складываются в путь атаки, которого раньше не видели.

3. Дедлайны и туннельное зрение

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

4. Эффект «Эврика!» из-за переключения контекста

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

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

Как использовать эту боль (и не сойти с ума)

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

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

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

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

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

Теперь вы выглядите не как эксперт, который не доработал, а как эксперт, который копнул глубже. Это меняет отношение клиента с «Ну, ок» на «Ого, они и после проекта думают о нашей безопасности». 

Но что, если решение пришло гораздо позже — например, когда вы встретили похожий сценарий на другом проекте? Написать клиенту всё равно стоит, особенно если ваша компания продолжает работать с ним по другим направлениям (SOC, интеграция, поддержка). Расскажите о возможном векторе атаки и подскажите, как его закрыть, если проблема до сих пор актуальна.

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

Как поступать вам — решайте сами. Но сообщить о находке — это лишь часть дела. Важно проверить свою догадку, сохранить результат и по возможности не повторять ту же ошибку на следующих проектах. Для этого есть несколько полезных привычек.

1. Проверяйте гипотезы на стенде

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

2. Пополняйте базу знаний

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

3. Обновляйте методологию проверок

Если решение приходит после проекта, значит, в вашей методологии не хватает проверки, которая нашла бы этот вектор вовремя. Добавьте ее и пересматривайте методологию каждый раз, когда она дает сбои.

4. Возвращайтесь к собранным данным

Заведите привычку в конце рабочего дня выделять час на анализ инфраструктуры без активных действий. Откройте BloodHound, пересмотрите найденные связи и подумайте: «А что, если получить доступ к этому узлу? Куда можно будет двигаться дальше? Все ли данные для этого собраны?». Иногда полезнее еще раз взглянуть на уже известные факты, чем продолжать искать новые.

5. Не пишите отчет в последний день

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

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

Вместо вывода

Пентест Active Directory редко идет по заранее намеченному маршруту. В сложной инфраструктуре невозможно проверить все сочетания прав, настроек и потенциальных путей атаки. Поэтому ситуации, когда удачное решение приходит уже после проекта, неизбежны.

Главное — не оставить такую находку только поводом для сожалений. Из нее может получиться полезный кейс для команды, статья для блога или выступление на конференции. А на следующем проекте похожий сценарий уже не застанет вас врасплох.

Напоследок хочу провести небольшой опрос: нужно ли сообщать заказчику о найденных после проекта векторах? Делитесь своим мнением в комментариях.

PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес‑ориентированной защиты от специалистов Бастиона