При атаках с ИИ важны не сигналы, а связи

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

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

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

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

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

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

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

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

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

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

Мы в UDV Group считаем, что именно здесь NTA закрывает важный пробел. Он показывает, что один узел или одна учетная запись стали точкой перехода между системами, которые раньше так не взаимодействовали. Это особенно важно в инфраструктурах, где есть облака, локальные сервисы, подрядчики, IoT, сетевое оборудование, промышленные контроллеры и устройства без хостовых агентов.

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

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

При атаках с участием ИИ ручное сопоставление событий становится задержкой само по себе. Аналитик может несколько минут переключаться между SIEM, EDR, IAM, VPN-шлюзом и облачной консолью, пока агент уже проверяет следующий маршрут. Поэтому NTA должен быть встроен в общий контур мониторинга и реагирования, а не жить отдельным интерфейсом.

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

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

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

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

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

Четвертый шаг — связь с бизнес-контекстом. Сетевой анализ должен понимать не только IP-адрес и протокол, но и роль актива: кто владелец сервиса, насколько он критичен, какие процессы зависят от него, что произойдет при отключении или компрометации. Здесь полезна Security CMDB: она помогает перейти от сетевой сессии к пониманию бизнес-риска.

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

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

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

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