Google Threat Intelligence Group сообщила о первом известном случае, когда злоумышленники, по оценке исследователей, использовали искусственный интеллект для разработки zero-day эксплойта. Атака была нацелена на обход двухфакторной аутентификации в популярном open-source инструменте администрирования, но её удалось остановить до массового использования. Для бизнеса и разработчиков это сигнал: AI уже помогает не только писать код, но и быстрее находить логические ошибки в защите.
Почему эта новость важна
Google описала инцидент как переход от экспериментального использования AI в атаках к более зрелым и масштабируемым сценариям. В отчёте Google Threat Intelligence Group говорится, что исследователи выявили threat actor, который использовал zero-day эксплойт, вероятно разработанный с помощью AI. Злоумышленники планировали применить его в массовой кампании, но уязвимость была обнаружена и закрыта до широкого распространения атаки.
Zero-day — это уязвимость, о которой разработчик продукта ещё не знает или для которой ещё нет публичного исправления. Именно поэтому такие баги особенно опасны: у защитников фактически «ноль дней» на подготовку, если атака уже началась.
В этом случае речь шла не о классическом взломе пароля, а о более тонкой проблеме — логической ошибке в механизме доверия. Эксплойт позволял обойти двухфакторную аутентификацию при наличии действующих учётных данных. Иными словами, 2FA не ломали напрямую: атакующие пытались использовать ошибочную внутреннюю логику системы.
Что именно обнаружила Google
По данным Google, уязвимость находилась в Python-скрипте популярного open-source веб-инструмента для системного администрирования. Название продукта, конкретная уязвимость и группа злоумышленников не раскрываются — это сделано намеренно, чтобы не помочь другим атакующим повторить технику.
Известно следующее:
| Факт | Что подтверждено |
| Тип проблемы | Zero-day уязвимость |
| Цель | Популярный open-source веб-инструмент администрирования |
| Язык/компонент | Python-скрипт |
| Эффект | Обход двухфакторной аутентификации |
| Условия атаки | Нужны действующие учётные данные |
| Статус | Уязвимость раскрыта поставщику и исправлена |
| Массовая эксплуатация | По данным Google, была предотвращена |
Reuters также подтвердила со ссылкой на Google, что атака была нацелена на широко используемый open-source инструмент системного администрирования и была остановлена до применения в рамках массовой эксплуатации.
Почему исследователи решили, что в разработке участвовал AI
Google не утверждает, что весь эксплойт был автоматически создан машиной от начала до конца. Формулировка осторожнее: GTIG считает, что эксплойт был разработан с применением AI.
На это указали особенности кода:
- чрезмерно подробные обучающие комментарии и docstring-блоки;
- «учебный» стиль оформления Python-кода;
- структурированные help-меню;
- вымышленная оценка CVSS, похожая на AI-галлюцинацию;
- признаки шаблонности, характерной для кода, сгенерированного большой языковой моделью.
CVSS — это система оценки серьёзности уязвимостей. Если в коде появляется правдоподобная, но несуществующая CVSS-оценка, это похоже на типичную ошибку генеративной модели: она создаёт уверенно звучащую, но фактически неверную деталь.
Важно: Google отдельно отмечает, что у неё нет доказательств использования Gemini. CyberScoop со ссылкой на GTIG пишет, что исследователи уверены в значимом участии AI, но не называют конкретную модель.
Чем этот случай отличается от обычного использования AI хакерами
До этого злоумышленники уже активно применяли AI для фишинга, генерации текстов, перевода, написания простых скриптов, маскировки вредоносного кода и автоматизации рутины. Но здесь речь о более серьёзном уровне: AI, вероятно, помог найти и «упаковать» ранее неизвестную уязвимость в рабочий эксплойт.
Разница принципиальная:
| Раньше чаще встречалось | Теперь зафиксировано |
| AI пишет фишинговые письма | AI помогает разрабатывать zero-day эксплойт |
| AI переводит и адаптирует тексты | AI анализирует логику приложения |
| AI генерирует вспомогательные скрипты | AI помогает обойти механизм безопасности |
| Атака всё ещё сильно зависит от оператора | Часть исследования и разработки ускоряется моделью |
Это не означает, что каждый хакер теперь мгновенно создаёт zero-day. Но порог входа снижается: то, что раньше требовало узкой экспертизы, постепенно становится доступнее тем, кто умеет правильно ставить задачи AI-инструментам.
Почему логические уязвимости особенно удобны для AI
Многие системы ломаются не из-за «дырки» в стиле переполнения буфера, а из-за неправильной логики: разработчики неверно определили, кому можно доверять, в каком порядке проверять условия, когда считать пользователя подтверждённым и какие исключения допустимы.
AI-модели хорошо работают с такими задачами, потому что они умеют:
- читать большие фрагменты кода;
- находить несоответствия между намерением и реализацией;
- объяснять сложные цепочки условий;
- быстро генерировать варианты проверки;
- предлагать сценарии, которые человек мог не протестировать.
В рассматриваемом случае уязвимость описывается как высокоуровневая семантическая логическая ошибка, связанная с жёстко заданным предположением доверия. Простыми словами: система в какой-то ситуации доверяла тому, чему доверять не должна была.
Что это значит для компаний и разработчиков
Главный вывод — нельзя рассчитывать только на то, что сложную ошибку «никто не найдёт». AI ускоряет поиск нестандартных сценариев, а значит защитникам тоже нужно менять подход.
Практические шаги:
Проверять не только код, но и логику доступа
Важно тестировать не только синтаксис, зависимости и известные CVE, но и бизнес-логику: кто может войти, при каких условиях 2FA считается пройденной, можно ли переиспользовать токены, как система ведёт себя при нестандартных переходах.
Усилить threat modeling
Threat modeling — это разбор продукта глазами атакующего. Команда заранее отвечает на вопросы: что можно обойти, где есть доверенные зоны, какие действия опасны, какие цепочки событий приводят к компрометации.
Не считать 2FA абсолютной защитой
Двухфакторная аутентификация сильно повышает безопасность, но не спасает, если приложение неправильно проверяет состояние пользователя. 2FA должна быть частью общей архитектуры доступа, а не единственным барьером.
Внедрять AI и на стороне защиты
Если атакующие используют AI для анализа кода, защитники должны делать то же самое: применять статический анализ, fuzzing, AI-assisted review, автоматические проверки логики авторизации и регулярные red team-упражнения.
Что пока остаётся неизвестным
В этой истории есть несколько важных пробелов, и их нельзя заполнять догадками.
Пока неизвестно:
- какой именно open-source инструмент был уязвим;
- какая конкретная модель AI использовалась;
- сама ли модель нашла уязвимость или помогла доработать уже найденную идею;
- насколько близко злоумышленники подошли к массовой эксплуатации;
- сколько похожих AI-assisted эксплойтов уже может существовать вне поля зрения исследователей.
Эти ограничения важны: новость серьёзная, но её нельзя превращать в миф о том, что AI уже полностью автономно взламывает любые системы. Речь о более реалистичном и поэтому более опасном сценарии: AI становится мощным ускорителем для людей, которые уже умеют атаковать.
Итог
Google зафиксировала важный рубеж в кибербезопасности: AI, по оценке исследователей, уже используется для разработки zero-day эксплойтов, а не только для фишинга и вспомогательной автоматизации. Конкретная атака была остановлена, уязвимость исправлена, но направление очевидно — время между обнаружением ошибки и её превращением в рабочий инструмент атаки будет сокращаться.
Для разработчиков, администраторов и владельцев сервисов это означает одно: безопасность нужно строить не только вокруг обновлений и 2FA, но и вокруг регулярной проверки логики доступа, сценариев доверия и поведения системы в нестандартных ситуациях.
