ИИ-хакеры против ИИ-безопасников: гонка вооружений и скорости в 2026

Привет! Меня зовут Роман Стрельников, я руководитель направления информационной безопасности в 1С-Битрикс.

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

Риск 1: скорость, потому что ИИ резко ускоряет кибератаки

Anthropic в сентябрьском отчёте связывает применение ИИ с ускорением разведки, эксплуатации уязвимостей и кражи данных. Для примера возьмём операции группы, которую Anthropic обозначила GTG-20006. Anthropic относит эту активность к кибершпионажу и отмечает, что она согласуется с публичными данными о группировке Midnight Blizzard. Целями были государственные учреждения, дипломатические организации и предприятия оборонной отрасли. 

В самом инциденте (который в отчёте фигурирует как russian espionage) по данным Anthropic в планировании, разведке и атаках фигурировали более 20 организаций. Это была длительная кампания с несколькими направлениями. Злоумышленники использовали Claude для разработки и изменения инструментов, подготовки фишинговой инфраструктуры, сбора данных и управления отдельными этапами операций.

Теперь — как именно участвовали агенты.

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

1. Защитная система обнаруживает вредоносную программу.

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

3. Агент перерабатывает программу: изменяет вредоносный инструмент и собирает его новую версию.

4. Вредоносное ПО проходит повторную проверку. Если новая версия обнаруживается, цикл изменений запускается снова.

Anthropic описывает этот цикл так:

“autonomously modifying and rebuilding the malware to evade the existing detections”

Фишинг. По отчёту, ИИ помогал исследовать и регистрировать домены, настраивать серверы для рассылки писем и следить за каналами связи с уже скомпрометированными системами.

Общая скорость. В том же отчёте Anthropic приводит случай, когда атака началась с украденного токена разработчика и примерно за три часа закончилась получением полного административного доступа к облачной среде компании. Это не относится напрямую к кампании GTG-20006, а является одним из примеров из отчёта.

Я вывожу такую условную формулу: «Киберриск = Вероятность × Последствия × Скорость». 

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

Выросла и скорость цикла атаки: «Разведка → Проверка → Изменение подхода → Повторная попытка». С помощью ИИ отдельные шаги этого цикла могут занимать минуты или даже секунды, поэтому у защитных систем остаётся меньше времени на выявление угрозы и перестройку защиты.

Всё это заставляет меняться SOC

SOC (Security Operations Center) — центр мониторинга информационной безопасности компании. Там работают специалисты, которые следят за подозрительной активностью, расследуют инциденты и принимают меры для остановки атак.

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

• В 10:01 пользователь успешно вошёл в систему.

• В 10:02 пользователь запросил доступ к базе данных.

• В 10:03 пользователь начал выгружать большой объём информации.

Конечно, в реальности у SOC могут быть миллионы таких записей ежедневно. Для их обработки используется система, которая ищет признаки угроз: SIEM (Security Information and Event Management).

Теперь смотрите, что меняется из-за участия ИИ в хакерских атаках.

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

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

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

Человек может не успеть остановить атаку, поэтому подключается автоматизация. Может случиться такое: система получает от SIEM предупреждение: учётная запись из необычной сессии создала токен, после чего началась массовая выгрузка информации. 

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

Риск 2: агенты получают слишком широкие полномочия

В апреле 2026 года ИИ-агент компании PocketOS (разрабатывает ПО для проката автомобилей) удалил рабочую базу данных вместе с резервными копиями. Само удаление заняло девять секунд, а восстановление — около 60 часов.

Разбираем, как это было и что пошло не так.

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

Агент нашёл в постороннем файле API-токен Railway. Это случилось, пока нейросеть искала подходящие учётные данные для выполнения операции. Токен до этого использовали для управления доменами, но он обладал гораздо более широкими правами, включая управление рабочей инфраструктурой.

Агент вызвал операцию volumeDelete, отправив запрос к GraphQL API Railway. Под действие попал volume с продакшена, на котором находилась рабочая база данных PocketOS. Вместе с томом были удалены связанные резервные копии. Обычные резервные копии были трёхмесячной давности: по словам PocketOS, их регулярное создание незаметно перестало работать.

И всё это заняло девять секунд.

Клиенты потеряли доступ к сервису. Последние доступные компании резервные копии оказались трёхмесячной давности. При помощи Railway данные удалось восстановить примерно через 60 часов.

Что мы поняли из этой истории: агент получил доступ к токену с избыточными полномочиями, тестовая задача могла затронуть рабочую среду, а API позволял немедленно удалить критический ресурс. 

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

Главное — обеспечивать эти ограничения на уровне прав доступа и API. Даже если в инструкции агента указано, что удалять рабочие данные запрещено, система должна технически блокировать такую возможность. Потому что есть 2 уровня ограничений:

• Инструкция агенту. Например: «Работай только с тестовыми ресурсами и ничего не удаляй».

• Технические разрешения. Это если токен позволяет только читать информацию о тестовых ресурсах, а операции удаления запрещены на уровне API.

Кстати, после происшествия Railway изменила механизм volumeDelete: теперь удалённые через API тома можно восстановить в течение 48 часов.

Риск 3: ИИ может выходить за пределы тестовой среды

Во время испытания Claude Mythos 5 самостоятельно опубликовала вредоносный Python-пакет в настоящем интернете. За час его установили 15 сторонних систем, и одна из них передала модели свои учётные данные — а агент их потом использовал для доступа к их инфраструктуре.

Разбираем, как мы до этого дошли.

Инцидент произошёл во время CTF (Capture the Flag). Это испытание по кибербезопасности, в котором необходимо взломать тестовую систему и найти скрытую информацию. 

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

Агент нашёл инструкцию по установке Python-пакета. В документации вымышленной компании для разработчиков было написано установить определённый Python-пакет — пусть это будет условный пакет noname — из публичного репозитория PyPI. Проверив реестр, Claude обнаружила, что пакета noname не существует. 

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

Агент сам создал вредоносный пакет noname. Чтобы опубликовать его в PyPI, модель самостоятельно нашла сервис временной электронной почты, зарегистрировала учётную запись и загрузила пакет. Всего она опубликовала три версии.

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

“NOT okay, and surely not the intended solution.”

Но затем агент «вспомнил», что находится в симуляции. Значит, можно.

Пакет начали скачивать реальные системы. Модель рассчитывала, что пакет установят системы вымышленной компании в рамках симуляции. 

Но пакет оказался в настоящем PyPI, и примерно за час его скачали и запустили на 15 реальных системах. Исследователи считают, что все они принадлежали компаниям, которые автоматически скачивают новые Python-пакеты и проверяют их на вредоносность.

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

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

Что могло помочь и что делать для защиты: есть три защитных механизма, и они напрямую связаны с историей выше.

Риск 4: вайбкодинг создает новые уязвимости внутри компаний

Исследователи RedAccess проанализировали веб-приложения, созданные с помощью Lovable, Replit, Base44 и размещённые в том числе на Netlify. Они обнаружили более 380 000 общедоступных приложений и ресурсов. Около 5000 из них выглядели как корпоративные, а более 2000 содержали чувствительные корпоративные, операционные или личные данные. Во многих случаях приложения были доступны без нормальной проверки пользователей или с очень слабой защитой.

Риски подтверждаются и исследованиями безопасности сгенерированного кода. В работе Is Vibe Coding Safe?, представленном на конференции ICML 2026, исследователи проверили ИИ-агентов на 186 задачах из реальных open-source проектов. В одном из наиболее успешных вариантов 57% решений были функционально корректными, но требованиям безопасности соответствовали лишь 11,8%.

Как были получены эти цифры: исследователи брали настоящую ошибку безопасности из GitHub-проекта, находили момент, когда её ещё не исправили, и предлагали ИИ самостоятельно написать соответствующую функцию. Затем проверяли, повторит ли ИИ старую уязвимость.

• Vulnerability Fix Patch — исправление уязвимости, написанное настоящими разработчиками. Оно показывает, каким должно быть безопасное решение.

• Human-Written Security Test Code — тесты безопасности, написанные людьми. Они проверяют, не допускает ли функция известную ошибку.

• Human-Written Functionality Test Code — функциональные тесты. Они проверяют, что программа вообще работает правильно.

• File with Feature Masked Out — файл, из которого убрали реализацию нужной функции. Именно его ИИ должен дополнить.

Суть исследований проста: приложение может правильно выполнять задачу пользователя и одновременно содержать серьёзные ошибки безопасности. Пример возьмём условный — допустим, ИИ создал дашборд сотрудников. Он корректно показывает данные, но забывает добавить на сервере проверку, имеет ли вообще пользователь право запрашивать сведения конкретного отдела.

Что с этим делать: для снижения рисков компаниям нужно учитывать все приложения, созданные сотрудниками, назначать ответственных за их поддержку и ограничивать доступ к корпоративным данным. Перед публикацией обязательно проверять код и зависимости, проводить тестирование авторизации и разграничения прав пользователей. Эти проверки лучше встроить в стандартный процесс развёртывания, чтобы новое приложение в принципе нельзя было опубликовать в интернете без обязательного контроля безопасности. Например, внутри нашей компании работает платформа Битрикс24 Вайбкод, которая позволяет настраивать доступы к приложениям и безопасно хранить их.

Риск 5: ИИ помогает находить сложные цепочки уязвимостей

Такие цепочки возникают, когда уязвимость одного сервиса позволяет получить доступ к другому. 

В июле 2026 года трое исследователей компании Hacktron с помощью Claude нашли цепочку уязвимостей, которая позволила пройти от публичного форума OpenAI до внутреннего репозитория компании. Исследование заняло менее 72 часов, непосредственная работа людей — всего несколько часов. За обнаруженные уязвимости OpenAI выплатила исследователям 6500 долларов.

На схеме показан путь атаки через девять компонентов инфраструктуры. То есть это не девять отдельных уязвимостей: Хактрон использовали две основные проблемы безопасности, а остальные элементы помогли связать их в одну цепочку.

Сокращённо-упрощённая цепочка в истории с OpenAI выглядела примерно так.

Исследователи начали с публичного форума OpenAI на платформе Discourse. При загрузке изображений HEIC форум использовал ImageMagick, который обращался к библиотеке libheif. В ней обнаружилась уязвимость, связанная с переполнением памяти. Проблемный код уже исправили разработчики библиотеки, но исправление не попало в пакеты Debian, на основе которого работал форум.

С помощью Claude исследователи разработали специально подготовленное изображение, обработка которого позволяла удалённо выполнять команды на сервере (RCE). Получив контроль над форумом, они использовали ошибку интеграции с системой единого входа OpenAI (SSO) и захватили учётную запись сотрудника. Через его Codex, подключённый к корпоративному GitHub, исследователи создали тестовый pull request во внутреннем репозитории OpenAI.

ИИ сыграл ключевую роль в технически сложной части исследования. Исследователи обнаружили уязвимость в libheif — библиотеке, которую форум использовал для обработки изображений. Сначала они пытались создать эксплойт с помощью Claude Opus 4.8, но модель не смогла получить надёжный результат. После выхода Claude Opus 5 исследователи передали ей ту же задачу, и она за несколько часов создала работающий эксплойт.

Как можно усилить защиту от таких атак: необходимо учитывать связи между системами. SBOM (Software Bill of Materials) помогает отслеживать используемые библиотеки и их версии, а изоляция обработки пользовательских файлов ограничивает последствия RCE. 

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

Краткий чек-лист

Советы компаниям по актуализации безопасности:

1. Определить, для чего можно использовать ИИ и к каким данным и системам предоставлять доступ. 

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

3. Ограничить права агентов необходимым минимумом и изолируйте тестовую среду от рабочей.

4. Особое внимание уделять проверке кода, прав доступа и сторонних зависимостей, особенно при работе с конфиденциальными данными.

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

6. Регулярно обновлять правила безопасности с учётом новых ИИ-инструментов и интеграций. Заранее определённые ограничения и процедуры проверки помогут использовать ИИ с меньшими рисками.