Классический пентест часто начинается у внешнего периметра. Команда получает домены, адреса или приложение и ищет способ проникнуть внутрь. Assumed Breach меняет стартовую точку. Заказчик заранее допускает, что первый рубеж уже пройден: злоумышленник получил рабочую станцию, обычную учётную запись, доступ к внутреннему сегменту или действующий облачный сеанс.
Проверка отвечает на другой вопрос: что произойдёт после входа? Сможет ли атакующий повысить права, перейти на другие узлы, добраться до Active Directory, облачных консолей, резервных копий и критичных данных? Заметит ли SOC атаку до того, как локальная проблема станет крупным инцидентом?
Сценарий особенно полезен там, где интернет-периметр уже неплохо защищён. Украденный токен, скомпрометированный подрядчик или заражённая рабочая станция всё равно могут дать точку входа. После этого решает лишь глубина защиты.
Как проходит Assumed Breach
Assumed Breach означает «предположение о компрометации». Перед началом работ заказчик выдаёт красной команде ограниченную стартовую позицию. Частый вариант — обычная доменная учётная запись и рабочая станция. В облаке стартом может стать низкопривилегированный пользователь, сервисная идентичность или тестовый сеанс с заранее заданными правами.
Команда не тратит большую часть времени на фишинг или поиск уязвимого внешнего сервиса, а сразу моделирует фазу после Initial Access. Сначала проверяющие выясняют, какие домены, сегменты, ресурсы и системы видит исходная учётная запись. В Active Directory оценивают группы, разрешения, сервисные аккаунты, доверительные отношения и делегирование Kerberos.
Следом идут Credential Access и Privilege Escalation. Проверяющие ищут цепочки, где один секрет открывает следующий уровень доступа: сохранённые учётные данные, токены, ключи API, локальные административные права и избыточные разрешения. Затем начинается фаза Lateral Movement, то есть «боковое перемещение» — переход на другие узлы через штатные административные механизмы, слабую сегментацию или чрезмерное доверие между системами.
В гибридной инфраструктуре маршрут может выйти из локального домена в Microsoft Entra ID, облачные подписки, SaaS, CI/CD и хранилища секретов. Одновременно оценивается защитный контур. EDR должен видеть подозрительное поведение, SIEM связывать события, XDR сопоставлять сигналы, а SOC вовремя начать расследование.
Чем Assumed Breach отличается от других подходов
Assumed Breach часто смешивают с Black Box, Gray Box, White Box и Red Team. Black Box, Gray Box и White Box определяют, сколько исходной информации получает команда. Assumed Breach задаёт стартовое состояние атаки. Red Team описывает более широкий формат моделирования реального противника.
| Подход | Старт | Главная цель |
|---|---|---|
| Black Box | Почти без данных | Найти путь с внешнего периметра |
| Gray Box | Есть часть данных или учётная запись | Быстрее проверить конкретную область |
| White Box | Доступна полная техническая информация | Получить максимальное покрытие |
| Assumed Breach | Компрометация уже предполагается | Проверить последствия доступа внутрь |
| Red Team | Зависит от сценария | Достичь цели, моделируя противника |
Gray Box может напоминать Assumed Breach, потому что тестировщикам тоже выдают учётную запись. Разница в цели. Gray Box обычно ускоряет проверку приложения или роли пользователя. Assumed Breach строится вокруг развития компрометации: повышение прав, переход между системами, доступ к цели и способность защиты разорвать цепочку.
Red Team шире и может охватывать внешние сервисы, облако, социальную инженерию и внутреннюю сеть. Assumed Breach бывает самостоятельным пентестом, стартовой фазой Red Team или частью Purple Team, где атакующая и защищающая стороны совместно разбирают телеметрию.
Что такой тест показывает лучше обычного пентеста
Главная сила Assumed Breach проявляется в цепочках небольших ошибок. Одна лишняя группа, сервис с чрезмерными правами и плохо изолированный сервер по отдельности могут выглядеть терпимо. В связке слабости иногда образуют короткий маршрут от обычного пользователя к административному контуру.
Подход хорошо проверяет сегментацию и идентификацию. Наличие VLAN и межсетевых экранов ещё не означает изоляцию, а принадлежность к внутренней сети не должна автоматически означать доверие. Поэтому тестировщики смотрят, какие административные протоколы проходят между зонами, как настроены MFA, условный доступ, привилегированные роли, сервисные субъекты и токены.
Assumed Breach показывает и качество телеметрии. Наличие EDR, SIEM и XDR не гарантирует обнаружение. Часть событий может не собираться, корреляция может пропустить нужную последовательность, а SOC может получить сигнал без контекста. Полезный итог теста — карта маршрутов атаки и точек, где цепочку можно разорвать.
Почему к Assumed Breach обращаются всё чаще
Первая причина — исчезновение единого «внутреннего периметра». Данные живут в SaaS, облаках и локальных системах, сотрудники работают с разных устройств, приложения получают собственные идентичности. Вторая причина — атаки через легитимные учётные данные и токены, которые сложнее отличить от обычной работы.
Третья причина — зрелость защитных технологий. Многие организации уже внедрили EDR, SIEM, XDR, MFA и управление привилегиями. Следующий вопрос сложнее покупки лицензий: сработает ли весь набор как единая система против связной атаки? Assumed Breach даёт практический ответ и одновременно проверяет SOC.
Подход совпадает с принципом Zero Trust «assume breach». Защита проектируется так, будто часть среды уже может быть скомпрометирована. Отсюда следуют минимальные привилегии, постоянная проверка доступа, сегментация, телеметрия и ограничение радиуса поражения. Пентест превращает архитектурную идею в измеримый сценарий.
Assumed Breach удобен и для повторных проверок. После внедрения PAM, изменения политик или настройки EDR компания может снова запустить тот же сценарий и сравнить число шагов до критичного ресурса, время обнаружения и точку, где защита остановила движение.
Заключение
Assumed Breach не заменяет классический пентест, аудит приложений или Red Team. Подход закрывает другой участок задачи. Вместо вопроса «сможет ли злоумышленник войти?» организация получает ответ на более неприятный вопрос: «что произойдёт, когда злоумышленник уже вошёл?» Для зрелой инфраструктуры именно второй вопрос часто определяет масштаб будущего инцидента.
Хорошая проверка связывает Active Directory, облачные идентичности, сегментацию, права, EDR, SIEM и работу SOC в одну картину. Результатом становится не просто найденная уязвимость, а понимание, где атака ускоряется, где защитники её замечают и какой контроль способен остановить дальнейшее развитие.
Рост интереса к Assumed Breach закономерен. Чем больше компания зависит от распределённых сервисов и идентичностей, тем слабее модель «надёжной внутренней сети». Современная защита должна пережить отдельную компрометацию без полного захвата инфраструктуры. Assumed Breach проверяет именно такую устойчивость.
FAQ: часто задаваемые вопросы
Что такое Assumed Breach простыми словами?
Это проверка, которая начинается с уже скомпрометированной точки внутри инфраструктуры и показывает, насколько далеко сможет продвинуться атакующий.
Чем Assumed Breach отличается от обычного пентеста?
Обычный пентест часто ищет первоначальный путь внутрь. Assumed Breach пропускает эту фазу и сосредотачивается на последствиях уже полученного доступа.
Assumed Breach и Red Team — это одно и то же?
Нет. Assumed Breach задаёт стартовое условие. Red Team представляет более широкий формат моделирования противника.
Что проверяют в Active Directory при Assumed Breach?
Права, группы, сервисные аккаунты, делегирование, доверительные отношения и пути повышения привилегий.
Как оценить результат Assumed Breach?
Полезны число шагов до цели, время обнаружения, сработавшие средства защиты и изменения, разрывающие опасные цепочки.
