ИИ ускорил атаки. Теперь ИБ важны не сигналы, а маршрут

Сложная кибератака долго оставалась ручной работой.

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

Если атака развивается медленно, ее можно заметить по отдельным событиям. Где-то сработал EDR. Где-то SIEM увидела странную авторизацию. Где-то администратор заметил нетипичное подключение. Где-то система управления доступом показала подозрительное использование учетной записи. Между этими сигналами есть пауза, и аналитик успевает собрать картину.

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

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

Сигнатура не успевает за атакой, которая меняется на ходу

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

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

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

Код можно изменить. Маршрут атаки полностью спрятать сложнее.

«ИИ может менять команды, скрипты и инструменты, но для продвижения по инфраструктуре ему все равно приходится оставлять сетевой след. Он обращается к сервисам, проверяет учетные записи, связывается с соседними узлами и передает данные. Поэтому при атаках с ИИ важно смотреть не только на отдельный сигнал, а на последовательность связей: кто с кем взаимодействовал, через какие узлы и в каком порядке», - говорит Михаил Пырьев, менеджер продукта UDV NTA компании UDV Group.

Именно здесь появляется роль NTA. Сетевой анализ не спорит с EDR, SIEM или системами управления доступом. Он добавляет то, чего часто не хватает при быстрой атаке: связку между событиями. Не просто «на сервере был запуск», «учетная запись вошла», «VPN разрешил подключение», а единый маршрут, по которому атакующий переходил от одной точки к другой.

Опасность не в одном слабом месте, а в цепочке

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

Сценарий JADEPUFFER хорошо показывает эту механику. LLM-агент использовал уязвимость CVE-2025-3248 в визуальном редакторе кода для ИИ Langflow, собрал ключи API и учетные данные, исследовал внутреннюю сеть, получил доступ к объектному хранилищу MinIO с паролем по умолчанию, затем перешел к производственному серверу с MySQL и сервисом Nacos. В итоге были зашифрованы 1342 записи конфигурации, после чего началось удаление баз данных.

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

Для аналитика это плохой сценарий. Уязвимый сервер, ключ API, MinIO с паролем по умолчанию, производственный сервер, MySQL и Nacos могут выглядеть как разные события в разных системах. Каждое по отдельности не всегда требует немедленной остановки. Но вместе они показывают движение атаки к критичной зоне.

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

NTA показывает, как одно событие привело к другому

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

EDR хорошо работает там, где он установлен. Но на коммутатор, камеру, ПЛК, часть IoT-устройств или подрядный узел его поставить нельзя или бессмысленно. Система управления доступом видит авторизацию, но не всегда показывает, к каким узлам потом пошла активность. SIEM собирает события, но без сетевого контекста они могут оставаться набором карточек.

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

«Ценность NTA не в том, чтобы добавить еще один поток алертов. Сетевой анализ нужен, чтобы связать события в одну цепочку: от точки входа до затронутых сервисов, внешних адресов и промежуточных узлов. Без такой ретроспективы команда может устранить видимый симптом, но оставить открытым первоначальный способ проникновения», - отмечает Михаил Пырьев, менеджер продукта UDV NTA компании UDV Group.

Это особенно важно при атаках с ИИ. Ручное сопоставление событий между SIEM, EDR, системой управления учетными записями и облачной консолью превращается в задержку. Аналитик еще выясняет, связаны ли два события между собой, а ИИ-агент уже проверяет следующий путь.

Инструменты по отдельности видят допустимые действия

Одна из главных проблем быстрых атак - формальная легитимность отдельных шагов. VPN-шлюз видит разрешенное подключение. Система управления доступом фиксирует успешную авторизацию. EDR замечает запуск штатной утилиты. Облачная консоль показывает обращение к API. Межсетевой экран пропускает разрешенный трафик. По отдельности ничего не выглядит как повод нажать большую красную кнопку.

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

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

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

Начинать нужно не со всей сети, а с критичных сегментов

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

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

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

Второй шаг - проверка путей к критичным системам. Важно понять не просто, что в сети есть уязвимый узел, а может ли через него атакующий добраться до важного сервиса. Иногда не первая по CVSS уязвимость оказывается самой опасной. Опаснее может быть узел, доступный из интернета, облака или через VPN подрядчика, если он связан с важными внутренними системами.

Третий шаг - профиль нормы. Производственный контур, офисная сеть, ЦОД и облачная инфраструктура работают по-разному. У них разные протоколы, направления соединений, временные окна, объемы трафика и типовые маршруты. Без настройки на фактическую среду NTA будет показывать много событий, но мало смысла.

Четвертый шаг - интеграция с реагированием. Сетевой анализ должен быть связан с SIEM, EDR, системами управления доступом, SOAR и данными о критичности активов. Иначе он останется отдельным экраном, на который смотрят уже после инцидента.

Бизнес-контекст важнее IP-адреса

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

Поэтому NTA особенно полезна, когда связана не только с техническими событиями, но и с Security CMDB или другим источником бизнес-контекста. Тогда аналитик видит не просто сетевую сессию, а сервис, его роль, владельца, критичность и возможный ущерб.

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

Без бизнес-контекста сетевой анализ легко превращается в техническую карту. С ним он становится инструментом управления инцидентом.

Ошибочное первое действие может быть дороже атаки

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

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

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

«При быстрых атаках с участием ИИ опасно реагировать только на самый громкий сигнал. Команде нужно за минуты понять маршрут: где была точка входа, какие узлы уже затронуты, какие учетные записи использовались и куда активность могла пойти дальше. Для бизнеса это разница между точной локализацией и аварийным отключением лишних сегментов», - подчеркивает Михаил Пырьев, менеджер продукта UDV NTA компании UDV Group.

Это и есть новая управленческая ценность NTA. Не «поймать еще один алерт», а сохранить контроль над инцидентом, когда скорость атаки начинает превышать скорость ручного анализа.

ИИ не отменяет старые слабости

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

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

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

Защита становится борьбой за время

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

NTA не решает все задачи ИБ. Она не заменяет EDR, SIEM, управление доступом, контроль уязвимостей, сегментацию и работу с подрядчиками. Но без сетевой ретроспективы быстрая атака превращается в набор разрозненных сигналов, между которыми приходится вручную искать связь.

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

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

В эпоху ИИ выигрывает не тот, кто видит больше сигналов. Выигрывает тот, кто быстрее понимает, как они связаны.