Привет, Хабр! Меня зовут Александр Колесов, в Бастионе я руковожу направлением развития в департаменте тестирования на проникновение. Мы профессионально ломаем то, что другие старательно защищают. Разумеется, с разрешения владельцев.

Сегодня предлагаю поговорить о внутреннем пентесте — одной из самых недооцененных услуг на рынке. А точнее, о современном подходе к нему — Assumed Breach («предполагаемое нарушение»). В рамках этого метода мы отталкиваемся от ключевой предпосылки: «а что, если компания уже скомпрометирована?».

Я уже рассказывал на SOC Forum 2025, почему классический внутренний пентест часто не отвечает на реальные потребности бизнеса и как Assumed Breach позволяет это исправить. Ниже — запись этого выступления, а дальше в статье покажу, как максимизировать пользу от внутренних пентестов с помощью Assumed Breach.

Представим, что вас УЖЕ взломали

Звучит как сценарий локальной катастрофы, правда? Гораздо комфортнее думать, что этого никогда не случится. На этом комфорте строятся три главных заблуждения, из-за которых компании пренебрегают внутренними пентестами.

• Одни заказчики искренне верят: сначала нужно заказать внешний пентест. Если через периметр пробьются — тогда дозакажем внутренний. А если нет — значит, мы защищены, и тестировать внутренний периметр не нужно. 

• Другие просто не готовы принять, что злоумышленник может оказаться внутри сети. Они буквально не понимают, от чего именно защищаются, заказывая внутренний пентест.

• Третьи идут по пути наименьшего сопротивления: внешний пентест часто воспринимается как обязательная «галочка», а внутренний — как опция для богатых компаний. Да и статистика пока удручает: внутренних пентестов примерно в три раза меньше, чем внешних. Соотношение — где-то 1 к 3. Почему так?

Проблема в ложном чувстве безопасности. Компания инвестирует в защиту внешнего периметра, получает отчет пентестера с парой-тройкой дыр, закрывает их — и считает миссию выполненной. А внутри сети тем временем творится ад: сегментация отсутствует, подрядчики получают права, которым позавидует сисадмин, пароли лежат в конфигах, а к Wi-Fi в офисе может подключиться вообще кто угодно.

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

• Корпоративный Wi-Fi. Классический пример: простая точка доступа Wi-Fi может стать троянским конем. Бывали случаи, когда мы получали доступ во внутреннюю сеть через корпоративный Wi-Fi в холле/фойе. А дальше — стандартный путь: домен, критические системы. Например, таким образом можно добраться до систем СКУД и в итоге получить «легитимный» доступ в помещение через запись чужого пропуска. 

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

• Физический доступ. Что, если сотрудник найдет на территории компании подброшенное устройство и решит использовать? Или кто-то получит доступ к рабочему месту HR во время собеседования? Периметр — это не только сеть, но и стены офиса.

• Подрядчики. Это, пожалуй, самый «трендовый» и опасный вектор. Здесь работает железное правило: ваш уровень защищенности не может быть выше уровня защищенности самого слабого вашего партнера. Взломанный интегратор или обладающий доступом разработчик — это уже ваша проблема.

Простой вопрос, который себе редко задают заказчики — «а что, если злоумышленник уже внутри»? Не потому, что пробил периметр, а потому, что пришел через подрядчика, фишинг или утерянный ноутбук. Тут мы и подходим к главной теме: Assumed Breach — моделирование предполагаемого нарушения. Это подход, при котором мы нацелены не на простой поиск уязвимостей, а на моделирование сценария успешной атаки.

Если говорить просто, Assumed Breach — это отказ от вопроса «что сделать, чтобы нас не взломали?» в пользу гораздо более практичного «мы уже взломаны, что теперь?». Для этого пентестер обычно должен смоделировать какой-то конкретный, реалистичный сценарий.

• Злоумышленник купил на черном рынке учетные данные сотрудника, который работает в филиале в другом городе. В кредах только стандартный VPN-доступ и корпоративная почта. Что он сможет сделать?

• Подрядчик, который разрабатывает критичное ПО, был скомпрометирован. Атакующий получил доступ к его джамп-хосту в корпоративной сети. Сможет ли он оттуда добраться до биллинга или базы данных клиентов?

• Сотрудник подхватил троян, приехал в офис и подключился к корпоративному Wi-Fi. Чем это грозит компании?

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

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

Assumed Breach предлагает начинать работы с разработки сценариев, актуальных для заказчика. Например, «давайте предположим, что ваш подрядчик скомпрометирован. У него есть доступ к вашему GitLab и CI/CD. Проверим, что можно сделать оттуда». Подход со сценарием и моделированием предполагаемого нарушителя позволяет оценить конкретные угрозы для компании, а не получить на выходе простой список уязвимостей.

Конечно, уровень готовности к такой работе сильно разнится. Небольшой круг наиболее зрелых игроков IT-рынка начал мыслить в этой парадигме уже давно. Тогда как для многих других сама мысль о том, что кто-то может уже находиться внутри их сети, кажется странной. Главный парадокс: чтобы по-настоящему защититься, нужно сначала признать собственную уязвимость. И для многих это трудный шаг.

Как происходит сейчас

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

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

Звучит разумно? Но погодите: какая ситуация моделируется? Какие в этом сценарии у нарушителя должны быть реальные доступы? Откуда у нарушителя вообще появился такой уровень доступа, и как он попал в этот сегмент сети?

Без ответов на эти вопросы пентест не даст максимальной пользы. Пентестеру говорят: «Ломай!» — и он ломает. Идет по пути наименьшего сопротивления, находит цепочку уязвимостей, поднимает привилегии до Domain Admin и торжественно пишет в отчете: «Ура, мы захватили домен»!

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

Проблема подобных «синтетических» условий проявляется в трех ключевых аспектах.

1. Нерелевантная точка старта. Откуда у реального злоумышленника взялся бы именно такой доступ? Если это подрядчик — он бы видел только то, что ему нужно для работы. Если это инсайдер — он бы имел права своего подразделения. А мы дали универсальный доступ, который никак не соответствует реальным ролям в компании. Может ли такой аккаунт вообще существовать? Если это обычный сотрудник, то зачем ему VPN-доступ «специально для теста»? Если это админ, то почему его права ограничены именно так?

2. Отсутствие модели нарушителя и целей. Без понимания, что за ситуацию мы моделируем, пентестер действует вслепую. Его успех измеряется в абстрактных «взломанных серверах», а не в предотвращении конкретных бизнес-потерь. А что, если злоумышленнику вообще не нужен Domain Admin? Может, его задача — украсть данные клиентов, а они лежат в одной базе на одном сервере, до которого можно дотянуться, не заглядывая в домен? Или его цель — поднять привилегии только внутри CI/CD, чтобы подсунуть бэкдор в код?

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

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

Реальный злоумышленник редко ставит себе конечную цель «взять домен». Его цель — ваши данные, ваши деньги. Он может остановиться на почтовом ящике юриста, если там лежит договор о поглощении конкурента. А вы в это время ставите команде пентеста задачу «взять домен», чтобы удостовериться, что он надежно защищен. Возможно, что домен даже взяли, но насколько это критично и полезно?

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

Про зрелость, кстати, разговор отдельный. Само решение заказать внутренний пентест еще ни о чем не говорит. Заказчиков можно условно разделить на четыре категории по уровню зрелости: 

• те, кто понимает и хочет; 

• кто понимает, но не хочет (экономит); 

• кто не понимает, но хочет (есть бюджет и абстрактное «надо»); 

• и те, кто не понимает и не хочет.

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

Бывает и другая крайность: компания сначала идет к дешевым исполнителям, получает за 300 тысяч отчет со сканера уязвимостей, а потом приходим мы и приносим совершенно другие результаты. Но это не всегда значит, что заказчик «прозрел». Часто он просто в ступоре: почему одни нашли три уязвимости, а другие — полный компромат на всю инфраструктуру? Тут мотивация понятна: компания следует трендам или хочет формально соблюдать регуляторику, не более.

Как-то к нам пришел банк — казалось бы, образец зрелости. В рамках одного из требований ЦБ РФ заказчику пришлось заказать внутренний пентест. Формально — всё правильно. Но когда мы буквально за пару часов получили права доменного администратора, у заказчика началась настоящая истерика.

Парадокс? Вместо того чтобы работать с найденными уязвимостями, клиент переживал об отчете для регулятора. Объяснение оказалось простым: до нас он много лет заказывал дешевые пентесты. Исполнители приносили почти пустые сгенерированные отчеты, которые и шли в ЦБ. А мы оказались «слишком эффективными».

Заказ дорогой и «пафосной» услуги, конечно, не является индикатором зрелости. Компания может заказывать Red Teaming, не имея центра мониторинга, просто потому, что «у Василия Иваныча из ООО “СамыйТехнологичныйХолдинг” тоже это есть». Такому заказчику не нужен Assumed Breach — он ждет не реальной оценки угроз, а красивого отчета для галочки.

Как получить результаты лучше

Основная трудность на пути внедрения Assumed Breach заключается в том, что многие компании всё еще оценивают защищенность по количеству закрытых уязвимостей, а не через призму актуальной для компании модели угроз.

Преодолеть ее — значит сместить фокус с гипотетического «взлома» на моделирование реальных сценариев, где у атакующего есть конкретная цель, а не абстрактное желание «поломать всё подряд».

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

Ключевая задача Assumed Breach — команда должна оказаться в тех же условиях, в которых мог бы оказаться злоумышленник, взломавший подрядчика. Пентестеры должны идти за конкретными целями, которые определены на старте, и находить ровно те дыры, которые критичны для заказчика. Это позволит точечно вкладываться в поиск и устранение самых критичных рисков, не распыляя ресурсы.

Заказывайте правильный Assumed Breach, а неправильный не заказывайте

Ключевая задача Assumed Breach — провести корректное моделирование ситуации, когда злоумышленник уже внутри. Но как понять, в чьей именно шкуре? Без четких правил мы снова получим абстрактное «взломали домен», просто стартуя из другой точки. Ответом становится работа с моделью нарушителя, которая отвечает на три простых вопроса:

• Кто? (Инсайдер? Взломанный подрядчик? Конкурент?)

• Откуда? (Утерянный ноутбук? Фишинг? VPN подрядчика?)

• Чего хочет? (Данные клиентов? Интеллектуальная собственность? Вывод систем из строя?)

Именно модель нарушителя определяет точку старта, уровень доступа и цели атаки. Без такой модели внутренний пентест похож на «тыканье вилкой в инфраструктуру».

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

Превратить всю эту теорию в практику сильно помогает диалог между командой пентеста и заказчиком. Потому что Assumed Breach зависит не столько от формального технического задания, сколько от качества взаимодействия между участниками процесса.

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

Ценность Assumed Breach рождается в диалоге — когда техническая экспертиза пентестера «переплетается» с пониманием бизнес-рисков заказчика.

Вместо заключения

Если сжать всё вышеперечисленное до одной мысли, с помощью Assumed Breach мы получаем четкие ответы на вопросы бизнеса:

• Что, если конкретный подрядчик, с которым мы работаем пятый год, уже скомпрометирован?

• Сможет ли атакующий с позиции бывшего сотрудника добраться до нашего биллинга?

• Что произойдет, если злоумышленник получит физический доступ к сети в одном из наших офисов?

• Насколько реально из сегмента с тестовыми средами пробиться к проду?

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

Безопасность начинается не тогда, когда вы пытаетесь превратить инфраструктуру компании в неприступную крепость, а когда честно признаете: «нас могут взломать». Давайте смоделируем, как это может произойти, и подготовимся.

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

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