Громко, быстро и везде: Анатомия реальной облачной атаки на базе ИИ

За последние несколько недель команда реагирования на инциденты Wiz Customer Incident Response Team (CIRT) выявила четкую тенденцию в ходе расследований: количество атак с использованием ИИ растет. В нескольких недавних случаях система на базе агента ИИ не просто помогала злоумышленнику за клавиатурой. Она управляла всей операцией целиком: находила точки входа, собирала учетные данные, переходила между платформами и на лету отлаживала собственные скрипты, управляя кампанией от начала и до конца.

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

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

Характеристики атак на базе ИИ

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

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

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

• Одновременная активность на нескольких платформах — агент работает в нескольких средах одновременно. Пока одна задача выполняет перечисление облачных ресурсов, другие развертывают рабочие нагрузки Kubernetes, создают конвейеры CI/CD или выполняют запросы к базам данных, и все это из одного источника и в рамках одного временного окна. Оператор-человек обычно работает с одной средой за раз, а традиционные скрипты редко пересекают границы сред одновременно.

Одновременная активность на нескольких платформах — агент работает в нескольких средах одновременно. Пока одна задача выполняет перечисление облачных ресурсов, другие развертывают рабочие нагрузки Kubernetes, создают конвейеры CI/CD или выполняют запросы к базам данных, и все это из одного источника и в рамках одного временного окна. Оператор-человек обычно работает с одной средой за раз, а традиционные скрипты редко пересекают границы сред одновременно.

• Владение инструментами разных платформ — агент ИИ использует нативные API и инструменты каждой платформы, к которой он получает доступ, включая облачных провайдеров, оркестрацию контейнеров, системы CI/CD, базы данных, поставщиков удостоверений и очереди сообщений. Операторы-люди редко обладают глубокими практическими знаниями обо всех из них одновременно.

Владение инструментами разных платформ — агент ИИ использует нативные API и инструменты каждой платформы, к которой он получает доступ, включая облачных провайдеров, оркестрацию контейнеров, системы CI/CD, базы данных, поставщики удостоверений и очереди сообщений. Операторы-люди редко обладают глубокими практическими знаниями обо всех из них одновременно.

• Связывание учетных данных между средами — поскольку агент свободно владеет таким количеством технологий, каждые учетные данные становятся ступенькой к следующей платформе. Например, токен учетной записи службы Kubernetes приводит к учетной записи облачной службы, которая ведет к системе CI/CD, что в конечном итоге предоставляет полный административный доступ.

Связывание учетных данных между средами — поскольку агент свободно владеет таким количеством технологий, каждые учетные данные становятся ступенькой к следующей платформе. Например, токен учетной записи службы Kubernetes приводит к учетной записи облачной службы, которая ведет к системе CI/CD, что в конечном итоге предоставляет полный административный доступ.

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

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

• Соглашения об именовании для тестирования безопасности — ресурсы, файлы и полезные нагрузки, создаваемые злоумышленником, последовательно маркируются такими терминами, как pentest, probe, recon, redteam и exfil. Такое оформление, вероятно, помогает злоумышленнику представить свою деятельность как авторизованное тестирование безопасности, эффективно обходя защитные механизмы модели ИИ.

Соглашения об именовании для тестирования безопасности — ресурсы, файлы и полезные нагрузки, создаваемые злоумышленником, последовательно маркируются такими терминами, как pentest, probe, recon, redteam и exfil. Такое оформление, вероятно, помогает злоумышленнику представить свою деятельность как авторизованное тестирование безопасности, эффективно обходя защитные механизмы модели ИИ.

• Числовые идентификаторы задач — многие ресурсы, пользователи и файлы, создаваемые во время атаки, включают числовой идентификатор, и одно и то же число часто появляется в нескольких связанных артефактах. Неудачные попытки повторяются под тем же номером с буквенным суффиксом (например, -b, -c, -d). Эти идентификаторы выглядят как внутренние идентификаторы задач, которые агент ИИ использует для отслеживания собственной работы.

Числовые идентификаторы задач — многие ресурсы, пользователи и файлы, создаваемые во время атаки, включают числовой идентификатор, и одно и то же число часто появляется в нескольких связанных артефактах. Неудачные попытки повторяются под тем же номером с буквенным суффиксом (например, -b, -c, -d). Эти идентификаторы выглядят как внутренние идентификаторы задач, которые агент ИИ использует для отслеживания собственной работы.

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

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

Внутри расследования: как атака на базе ИИ выглядит на практике

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

Целью была организация с крупной мультиоблачной средой. ИИ-агент действовал с нескольких IP-адресов, контролируемых злоумышленником, и перемещался практически по каждому слою среды: облачным провайдерам, кластерам Kubernetes, пайплайнам CI/CD и GitOps, поставщику идентичности, средствам управления секретами, хранилищам данных и внутренним приложениям. На протяжении всей атаки он собирал учетные данные и секреты, получал доступ к конфиденциальным данным и использовал различные каналы для вывода этих данных из среды.

Первоначальный доступ: проверка каждой двери

В ходе атаки злоумышленник исследовал множество общедоступных сервисов, используя различные методы. Он отправлял эксплойты для известных уязвимостей, пытался получить анонимный доступ к облачному хранилищу и работал через API уязвимого внутреннего инструмента разработчика. Там он попытался создать учетную запись администратора, инициировать сброс пароля, прочитать локальные файлы с помощью обхода пути (path traversal) и загрузить тестовый файл с префиксом pentest.

Одним из подтвержденных векторов первоначального доступа стала уязвимость удаленного выполнения кода в Java (RCE) в открытом экземпляре Kafka UI. Из Java-процесса приложения были запущены команды оболочки, за которыми последовало развертывание вредоносного ПО и установка канала связи с сервером управления (C2).

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

Закрепление внутри рабочих нагрузок

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

• Сохранение доступа — развертывание бэкдоров и агентов C2 в нескольких подах в различных кластерах.

Сохранение доступа — развертывание бэкдоров и агентов C2 в нескольких подах в различных кластерах.

• Сбор учетных данных — извлечение смонтированных токенов учетных записей служб Kubernetes, поиск в переменных среды таких строк, как token, secret, key и pass, а также отправка запросов к службе метаданных экземпляра (IMDS) для сбора учетных данных из привязанной к узлу учетной записи облачной службы.

Сбор учетных данных — извлечение смонтированных токенов учетных записей служб Kubernetes, поиск в переменных среды таких строк, как token, secret, key и pass, а также отправка запросов к службе метаданных экземпляра (IMDS) для сбора учетных данных из привязанной к узлу учетной записи облачной службы.

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

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

Эти собранные учетные данные стали основной точкой входа для латерального перемещения в плоскость управления облаком.

Действия в плоскости управления облаком

Агент действовал в обеих облачных средах организации — GCP и AWS — с темпом, недоступным ни одному человеку-оператору. Используя ключи доступа и учетные данные учетных записей служб, полученные на предыдущих этапах атаки, а также подмену удостоверений (identity impersonation), агент-злоумышленник сначала провел широкую разведку.

В GCP он задействовал учетную запись службы, наделенную привилегиями создания токенов, превратив ее в автоматизированный механизм генерации учетных данных для десятков идентификаторов в быстрой последовательности. Параллельно агент непрерывно сканировал реестры контейнеров, пытался эксфильтровать ценные записи баз данных и развертывал общедоступные сервисы Cloud Run с префиксом pentest-.

Одновременно в AWS агент задействовал AWS Systems Manager (SSM) для выполнения команд на экземплярах в среде. С помощью SSM он пытался подключиться к базам данных, используя полученные учетные данные, перемещался латерально по SSH, собирал дополнительные секреты и организовывал эксфильтрацию в бакет с именем pentest-<task_id>. Для создания межсетевой (cross-account) персистентности он создал нового пользователя IAM с префиксом probe и использовал его для принятия роли OrganizationAccountAccessRole, получив административный доступ ко всем дочерним аккаунтам в AWS Organization.

Поставщик идентификации: превращение в инсайдера

Вместо того чтобы полагаться только на украденные учетные данные, агент создал собственное удостоверение. Используя скомпрометированный административный ключ API для поставщика идентификации (IdP) организации, он программно внес изменения: создал пользователя с префиксом pentest, установил ему пароль, активировал учетную запись и добавил ее в группу администраторов.

Когда IdP возвращал ошибки в процессе, агент устранял неполадки и преодолевал каждый сбой «на лету». Имея в распоряжении рабочее удостоверение, он расширил радиус поражения за счет членства в группах. Он добавил пользователя в группы ролей облака, напрямую сопоставленные с ролями AWS IAM Identity Center, а затем в широкие организационные группы, которые предоставили унаследованный доступ к корпоративным приложениям. Через несколько минут после последнего изменения групп вновь созданное удостоверение выполняло вход в AWS через единый вход (SSO), поддерживая непрерывные сеансы аутентификации до тех пор, пока учетная запись не была заблокирована.

Превращение CI/CD и GitOps в оружие

Платформы CI/CD и GitOps стали основными исполнительными механизмами агента. Параллельно работали пять различных потоков задач, результаты каждого из которых подпитывали остальные:

• Сбор секретов — сбор секретов из каждого доступного источника: собственного хранилища секретов платформы CI/CD, Kubernetes Secrets и ConfigMaps, переменных среды бегунов (runners), конечных точек метаданных облака, сайдкаров HashiCorp Vault, слоев образов Docker и баз данных, открытых другими потоками задач.

Сбор секретов — сбор секретов из каждого доступного источника: собственного хранилища секретов платформы CI/CD, Kubernetes Secrets и ConfigMaps, переменных среды бегунов (runners), конечных точек метаданных облака, сайдкаров HashiCorp Vault, слоев образов Docker и баз данных, открытых другими потоками задач.

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

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

• Спрей кредов (Credential spraying) — объединение результатов первых двух потоков задач, проверка собранных учетных данных на доступных целях, которые агентам удалось обнаружить: базах данных, облачных API, внутренних службах OAuth, кластерах Kubernetes, платежных эндпоинтах.

Подбор учетных данных (credential spraying) — объединение результатов первых двух рабочих потоков; проверка собранных учетных данных на доступных целях, которые удалось обнаружить агентам: базах данных, облачных API, внутренних службах OAuth, кластерах Kubernetes, платежных шпиньках и конечных точках.

• Эксплуатация служб — исследование доступных служб с целью понять принцип их работы, ожидаемые ими потоки аутентификации, а также попытки их использования.

Эксплуатация служб — исследование доступных служб с целью понять принцип их работы, ожидаемые ими потоки аутентификации, а также попытки их использования.

• Расширение вычислительных ресурсов — развертывание новых исполнителей (runners) и подов, перемещение по сети в латеральном направлении с помощью SSH-ключей и встроенных инструментов удаленного выполнения, а также передача информации о каждой новой позиции в остальные рабочие потоки.

Расширение вычислительных ресурсов — развертывание новых исполнителей (runners) и подов, перемещение по сети в латеральном направлении с помощью SSH-ключей и встроенных инструментов удаленного выполнения, а также передача информации о каждой новой позиции в остальные рабочие потоки.

Как только появлялась новая учетная запись, она проверялась на всех известных целях до подтверждения доступа, а как только цель становилась доступной, по ней проверялись все известные учетные записи.

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

Пайплайны и манифесты носили такие названия, как pentest_exfil, recon, foothold, dump-remaining и harvest, и содержали числовые идентификаторы задач. Неудачные попытки повторялись под тем же идентификатором, но с буквенным суффиксом, а код внутри каждого полезного блока был структурирован с пошаговыми комментариями и повторно используемыми вспомогательными функциями. Несмотря на то, что обе платформы предлагали различную инфраструктуру и модели выполнения, на обеих запускались одни и те же рабочие потоки.

На платформе CI/CD агенты использовали скомпрометированную служебную учетную запись для создания пайплайнов и задействовали существующих исполнителей для обеспечения доступности различных кластеров, облачных аккаунтов и VPC. Собственные выходные логи исполнителей служили каналом эксфильтрации как для секретов, так и для данных. Для латерального перемещения они применяли SSH-ключи и облачные ключи доступа, обнаруженные в ходе рабочей задачи по сбору секретов, чтобы получать доступ к хостам за пределами исполнителей через SSM и другие встроенные средства удаленного выполнения.

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

Использование возможностей Kubernetes (Living Off Kubernetes)

Kubernetes (K8s) сыграл главную роль в этой атаке, и это неслучайно. Контроллеры GitOps по определению работают внутри кластеров K8s, исполнители CI/CD часто запускаются как поды K8s, а большая доля секретов, хранящихся в менеджерах секретов CI/CD, сама по себе представляет собой токены K8s. Агент получил доступ к API K8s через три разных шлюза: исполнителей CI/CD, развертывания GitOps и созданную им бэкдор-учетную запись в поставщике удостоверений.

Агент выгрузил секреты из нескольких кластеров, извлекая строки подключения к базам данных, учетные данные клиентов OAuth, TLS-сертификаты и ключи служебных облачных учетных записей. Когда элементы управления доступом на основе ролей (RBAC) блокировали доступ к секретам, он переключался на ConfigMaps в K8s, обнаруживая зашитые в код пароли по умолчанию, учетные данные в открытом виде и ключи шифрования. Он выполнял удаленные команды внутри работающих подов для чтения переменных среды и запрашивал службу метаданных экземпляров, чтобы превратить учетные данные подов в облачные учетные данные.

Получив права cluster-admin и предоставив себе неограниченный доступ во всем кластере, агент создал токены служебных учетных записей для имитации легитимных приложений и попытался пройти аутентификацию в хранилище секретов организации в качестве этих приложений. Он также попытался получить доступ к сайдкарам vault-agent — вспомогательным контейнерам, которые извлекают секреты из хранилища и сохраняют их в виде текстовых файлов внутри пода, пытаясь напрямую прочитать расшифрованные учетные данные из файловой системы.

Кластер также стал уровнем для обеспечения персистентности (persistence). Агент развертыл имплант командного центра в качестве самовосстанавливающейся рабочей нагрузки Kubernetes, гарантируя сохранение бэкдора даже в случае завершения работы пода. Позже он изменил работающие рабочие нагрузки, напрямую обращаясь к контроллеру GitOps, не оставляя при этом никаких следов в истории Git.

Доступ к данным и их эксфильтрация

Сбор и эксфильтрация данных выполнялись непрерывно в ходе всей атаки, адаптируясь к каналам, разрешенным в каждой конкретной среде. Агент отправлял результаты на вебхук службы перехвата запросов webhook[.]site, фиксировал выгруженные данные в репозиторий на собственной платформе управления исходным кодом организации и сохранял результаты в созданном для этой цели ConfigMap Kubernetes. Он также пытался создать хранилища (buckets), названные по имени задачи, например pentest-<task-id>-<objective>, в качестве места назначения. Эти попытки были отклонены. Когда один маршрут давал сбой или исчерпывал лимит размера, агент переходил к следующему.

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

Скрипт выполнял запросы к структуре базы данных, искал конфиденциальные термины в названиях столбцов и загружал результаты на webhook[.]site вместе с токеном служебной учетной записи пода «для повторного использования точки опоры в будущем».

Рекомендации для специалистов по защите

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

• Унификация логов на всех платформах: каждый этап этой атаки отражался в отдельном источнике логов, и ни один из них по отдельности не давал полной картины. Аудит-логи облаков, аудит-логи Kubernetes, события времени выполнения, логи поставщика удостоверений, журналы аудита CI/CD и логи SaaS-приложений необходимо собирать в едином месте с возможностью поиска и с согласованным сроком хранения. Когда логи унифицированы, защитники могут связать активность между платформами и понять весь масштаб инцидента за считанные минуты, а не дни. Решение Wiz Defend предлагает сбор в реальном времени различных источников логов, включая логи систем контроля версий, облачные логи, логи поставщиков удостоверений и многое другое, а также встроенные правила обнаружения угроз для выявления активных угроз в вашей среде.

Унификация логов на всех платформах:

• Каждый этап этой атаки отражался в отдельном источнике логов, и ни один из них по отдельности не давал полной картины. Аудит-логи облаков, аудит-логи Kubernetes, события времени выполнения, логи поставщика удостоверений, журналы аудита CI/CD и логи SaaS-приложений необходимо собирать в едином месте с возможностью поиска и с согласованным сроком хранения. Когда логи унифицированы, защитники могут связать активность между платформами и понять весь масштаб инцидента за считанные минуты, а не дни.

Каждый этап этой атаки отражался в отдельном источнике журналов, и ни один из них не давал полной картины. Журналы аудита облака, журналы аудита Kubernetes, события среды выполнения, журналы поставщика удостоверений, журналы аудита CI/CD и журналы приложений SaaS должны собираться и быть доступны для поиска в одном месте с единым сроком хранения. Когда журналы объединены, защитники могут связать активность на разных платформах и понять полный масштаб инцидента за считанные минуты вместо дней.

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

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

• Используйте ИИ для расследования и приоритизации: Когда злоумышленник генерирует тысячи событий на различных платформах, расследование оповещений по отдельности становится невозможным. Команды безопасности должны использовать расследование с поддержкой ИИ для группировки связанных оповещений, обобщения активности по источникам, декодирования полезных нагрузок и выделения наиболее критических путей, чтобы аналитики могли сосредоточиться на принятии решений, а не на ручной корреляции. Важно быстро реагировать на истинно положительные инциденты. Wiz Defend использует контекстно-зависимую группировку для корреляции нескольких обнаружений из разных источников журналов в единую связную историю на основе контекста обнаружения и времени. Blue Agent от Wiz может помочь в быстром расследовании и приоритизации — это агент расследования SOC на базе ИИ, который предназначен для автономного исследования угроз.

Используйте ИИ для расследования и приоритизации:

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

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

• Wiz Defend использует контекстно-зависимую группировку для корреляции нескольких обнаружений из разных источников журналов в единую связную историю на основе контекста обнаружения и времени.

Wiz Defend использует контекстно-зависимую группировку для корреляции нескольких обнаружений из разных источников журналов в единую связную историю на основе контекста обнаружения и времени.

• Blue Agent от Wiz может помочь в быстром расследовании и приоритизации — это агент расследования SOC на базе ИИ, который предназначен для автономного исследования угроз.

Blue Agent от Wiz может помочь в быстром расследовании и приоритизации — это агент расследования SOC на базе ИИ, который предназначен для автономного исследования угроз.

Предполагайте полную уязвимость скомпрометированных ресурсов: