Google Threat Intelligence Group сообщила о первом известном ей случае, когда злоумышленники, вероятно, использовали ИИ для поиска и подготовки zero-day-эксплойта. Целью стала популярная open-source веб-система администрирования, название которой Google не раскрывает. Уязвимость позволяла обойти двухфакторную аутентификацию при наличии действующих логина и пароля. Массовую эксплуатацию удалось остановить до запуска кампании: Google связалась с разработчиком инструмента и помогла закрыть проблему.
В отчёте речь идёт о криминальной группе, которая планировала массовую эксплуатацию и, с высокой вероятностью, использовала языковую модель как помощника для поиска логической ошибки и написания Python-эксплойта. Google указывает, что не видит признаков использования Gemini в этой операции.
Уязвимость находилась не в памяти, не в обработке строк и не в классическом переполнении буфера. Это была семантическая логическая ошибка: в коде существовало жёстко заданное предположение о доверии, которое конфликтовало с реальной проверкой аутентификации. Проще говоря, часть приложения считала пользователя достаточно доверенным в ситуации, где механизм 2FA должен был остановить вход. Такие ошибки плохо ищутся обычным фаззингом, зато хорошо подходят для анализа, где нужно понять смысл веток кода и бизнес-логику.
Эксплойт был написан на Python. Признаки ИИ Google увидела не по одному странному комментарию, а по совокупности деталей: аккуратная «учебная» структура кода, обилие поясняющих комментариев, подробные help-меню, чистый Python-стиль и даже выдуманная оценка CVSS. Такой набор похож на результат LLM, которая пытается оформить код как демонстрационный инструмент из обучающих материалов.
Важная деталь: для эксплуатации требовались действующие учётные данные. Это не удалённый вход «с нуля» без пароля. Сценарий опасен другим: если у атакующего уже есть логин и пароль, например после фишинга, утечки или инфостилера, он может обойти второй фактор и превратить украденные credentials в полноценный доступ. Для корпоративных админ-панелей это критично, потому что 2FA часто считается последним барьером после компрометации пароля.
Google не называет ни криминальную группу, ни затронутый продукт. Это осознанное снижение риска: если инструмент популярен, раскрытие названия до широкого обновления могло бы ускорить копирование техники. Из опубликованных данных известно только, что это open-source веб-инструмент системного администрирования, а не продукт Google.
Массовая фаза атаки не состоялась. GTIG сработала до того, как группа успела развернуть кампанию против большого числа целей. Поэтому инцидент показывает не ущерб от уже прошедшей волны, а новый уровень подготовки атакующих. Раньше криминальным группам чаще приходилось покупать zero-day, ждать чужой exploit chain. Теперь же ИИ помогает искать логические ошибки в доступном коде и собирает рабочий эксплойт быстрее.
В том же отчёте компания пишет, что группы из разных сегментов уже используют ИИ для разведки, разработки инструментов, поиска уязвимостей и маскировки вредоносного кода. BleepingComputer приводит примеры: китайские и северокорейские кластеры, включая APT27, APT45, UNC2814, UNC5673 и UNC6201, применяли ИИ-модели для задач, связанных с поиском уязвимостей и разработкой эксплойтов; российские акторы использовали ИИ-сгенерированный код для усложнения анализа вредоносов CANFAIL и LONGSTREAM.
Пример — Android-бэкдор PROMPTSPY, который использует Gemini API для автономного взаимодействия с интерфейсом устройства. Google пишет, что модуль может анализировать раскладку экрана и получать команды для нажатий и жестов, а также работать с PIN-кодами и графическими ключами. На момент публикации Google не обнаружила такие приложения в Google Play, а устройства с Google Play Services защищаются Google Play Protect.
Ещё один риск — инфраструктура вокруг ИИ. Google и Help Net Security описывают компрометацию GitHub-репозиториев, связанных с LiteLLM и Trivy, группой TeamPCP/UNC6780. Вредоносный компонент SANDCLOCK вытаскивал облачные секреты, включая AWS-ключи и GitHub-токены. Такие шлюзы часто подключают корпоративные приложения сразу к нескольким ИИ-провайдерам. Кража ключей в этом слое может дать атакующим доступ не только к облаку, но и к внутренней AI-инфраструктуре компании.
Google в отдельном материале о защите предприятий пишет, что организации больше не защищаются от эксплуатации «со скоростью человека». Компания рекомендует переносить дисциплину безопасности с серверов и ноутбуков на исходный код, библиотеки, CI/CD, build runners и цепочки поставки, а также переходить от разовых проверок к постоянному поиску уязвимостей и автоматизированной валидации.
Практический минимум для команд разработки и ИБ: проверить open-source админ-панели, особенно доступные из интернета; пересмотреть логику 2FA и восстановления сессий; искать места, где код «доверяет» пользователю до завершения второго фактора; убрать хранение секретов в репозиториях; защитить CI/CD и build runners; вести актуальную инвентаризацию внешних сервисов и внедрить тесты на обход аутентификации. Для SOC полезно отдельно отслеживать входы с валидным паролем, где 2FA выглядит пройденной нетипичным способом или сразу следует доступ к административным функциям.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
