Цепочки атак, а не отдельные фишинговые письма, payload и правила SIEM, становятся главным предметом проверки корпоративной защиты. По данным The Hacker News, 93% руководителей по безопасности сообщили о кибератаках с влиянием на бизнес за последние 12 месяцев, хотя многие компании уже регулярно валидируют свои средства защиты.
Проблема в том, что классическое тестирование часто отвечает на узкий вопрос: сработает ли конкретный EDR на конкретный образец, заметит ли SIEM одну технику, провалят ли сотрудники учебный фишинг. Это полезно, но атакующие так не работают. Реальный инцидент обычно складывается из последовательности: письмо, сбор учетных данных, первичный доступ, повышение привилегий, боковое перемещение, подготовка данных и вывод наружу. На каждом шаге защита может выглядеть прилично, но между шагами остается щель размером с бюджет на инцидент-респонс.
Материал The Hacker News продвигает идею Attack Chaining: проверять не библиотеку изолированных техник, а цельный маршрут атаки. В такой модели результат одного действия становится входом для следующего. Если симуляция получила валидный пароль, она пробует использовать его дальше. Если разведка нашла доступный порт, сценарий перестраивается. Если контроль заблокировал шаг, цепочка останавливается или ищет обходной путь в рамках заданных правил.
Это заметный сдвиг от привычного подхода breach and attack simulation, где техники часто прогоняются по списку и сопоставляются с MITRE ATT&CK. Такой список дает понятную метрику, но плохо отвечает на главный вопрос: сможет ли противник, комбинируя десять не самых экзотических действий, пройти через инфраструктуру, пока отдельные панели показывают зеленые статусы. Для CISO это неприятная математика: закрыть 90% известных экспозиций мало, если оставшиеся 10% соединяются в рабочий маршрут до критичных данных.
В источнике приводятся данные отчета Filigran State of Threat Management: 88% опрошенных считают, что ИИ ускоряет действия атакующих после проникновения, а 84% называют разрозненные инструменты и несвязанные проверки одной из причин, по которым уязвимости замечают слишком поздно. Эти цифры хорошо ложатся на текущую реальность SOC: алертов много, контекста меньше, а связи между фишингом, IAM, сетью, EDR и DLP часто приходится собирать вручную уже после того, как ущерб случился.
В качестве примера The Hacker News вспоминает взлом французской налоговой службы DGFiP в 2025 году. По описанию источника, там не было одного магического приема, достойного отдельной конференции. Сработала последовательность из первичного доступа, злоупотребления учетными данными, бокового перемещения и эксфильтрации. Именно такие истории неприятнее всего для зрелых ИБ-команд: каждый контроль по отдельности мог быть настроен не катастрофически плохо, но вся конструкция все равно пропустила маршрут.
OpenAEV в материале представлен как платформа, где такие цепочки атак можно запускать автоматически. Команды могут строить многоэтапные сценарии с условиями: если учетная запись валидна — идти к следующей машине, если шаг заблокирован — завершить проверку или сменить ветку. Путь отображается на интерактивном графе, а найденные артефакты — IP-адреса, токены, файлы, учетные данные — становятся структурированными находками, которые объясняют, почему симуляция пошла дальше.
Практический смысл здесь не в красивом графе, хотя графы в ИБ продаются почти так же уверенно, как «единая панель управления». Важнее другое: такие проверки помогают найти chokepoint — точку, исправление которой ломает всю последующую ветку атаки. Это полезнее, чем очередной список из сотни замечаний без приоритета, где патч на второстепенном сервере лежит рядом с misconfiguration, открывающей путь к доменному администратору.
Отдельный акцент сделан на safety controls. Цепочка запускается в заранее заданных границах: какие активы можно трогать, какие действия разрешены, насколько далеко сценарий может эскалировать доступ. Без этого автономная симуляция быстро превращается в очень дорогой способ поссориться с эксплуатацией. Для российских и русскоязычных команд, где продакшен часто держится на тонком балансе между регламентом и героизмом дежурной смены, этот пункт не декоративный.
Еще одна важная деталь — социальная инженерия описана как полноценный этап, а не отдельная HR-кампания с отчетом «кликнули 7% сотрудников». Фишинговое письмо, SMS-приманка или поддельная страница могут стать узлом сценария: клик, ответ или введенный пароль сразу передаются в следующие действия. Это ближе к реальности, где атакующего интересует не процент кликов сам по себе, а возможность превратить один клик в доступ к системе.
В материале также описан автономный режим с XTM One: оператор задает цель и область проверки, а агент сам планирует маршрут, выбирает действия, реагирует на найденные данные и при необходимости генерирует фишинговые письма или лендинги. Это звучит эффектно, но для бизнеса главный вопрос прозаичнее: кто отвечает за границы, журналирование и последствия такого запуска. Автономность в offensive security полезна ровно до момента, пока она остается управляемой и проверяемой.
Для разработчиков вывод простой: безопасность все меньше сводится к закрытию отдельных тикетов с CVE и все больше зависит от связей между сервисами, секретами, правами и процессами деплоя. Для бизнеса — еще проще: отчет «техника заблокирована» не равен устойчивости к инциденту. Следующий этап рынка ИБ, похоже, будет мерить не количество найденных дыр, а то, какие цепочки атак они реально собирают и где их дешевле всего разорвать.