КИБЕРБЕЗОПАСНОСТЬ

ИИ-червь без API: как локальная LLM прошла 62% тестовой сети

В 15 тестах ИИ-червь автономно дошел до 62% сети за 7 дней, используя локальную LLM без API и подбирая атаки на ходу.

✍️ Редакция iTech News | 10.06.2026 | ⏱ 4 мин | Источник: The Hacker News
🔑

Исследователи из Университета Торонто собрали ИИ-червь, который в 15 изолированных экспериментах автономно распространялся по сети из 33 хостов и в среднем добирался до 62% инфраструктуры за семь дней. Для русскоязычной ИТ-аудитории новость неприятно практичная: если такой код не зависит от OpenAI, Anthropic и любых внешних API, привычная идея «отключим сервис и проблема исчезнет» больше не работает.

Работа пока существует в виде препринта и проходит peer review, а о результатах сообщает The Hacker News. Команда под руководством доцента Николаса Паперно из CleverHans Lab вместе с коллегами из Vector Institute, University of Cambridge и ServiceNow тестировала прототип в изолированной сети FakeCorp, где были Linux-машины, Windows Server 2008 R2, 2019 и 2022, а также IoT-устройства. На каждом из 33 хостов была как минимум одна реальная уязвимость, а пять машин имели GPU.

Ключевая разница с классическими сетевыми червями в том, что здесь не было жестко зашитой цепочки эксплойтов. ИИ-червь использовал локально развернутую open-weight LLM, чтобы анализировать открытые сервисы на следующей цели, читать свежие advisory и на ходу собирать подходящий сценарий атаки. В среднем за 15 прогонов он находил 31,3 уязвимости, получал повышенные привилегии на 23,1 хоста и затем автономно запускал свои копии на 20,4 машины. Иначе говоря, речь не о демонстрации «смотрите, LLM тоже умеет пентест», а о рабочем механизме самораспространения без оператора в цикле.

В одном из режимов зараженные узлы с GPU играли роль распределенных «узлов рассуждения» для менее мощных устройств, которые не могли тянуть модель сами. Это важный момент для инфраструктурных команд: не каждый endpoint обязан уметь запускать LLM локально, чтобы участвовать в атаке. Достаточно, чтобы в сети нашлась скомпрометированная машина с подходящими вычислениями. Отдельно исследователи проверили сценарий, где червь разворачивает локальный экземпляр модели прямо на захваченном GPU-хосте; такая репликация сработала в 68,8% попыток. Максимальная глубина саморепликации достигала семи поколений, среднее значение составило 5,1.

Набор атак тоже выглядит не как заранее подготовленный список с красивой презентации, а как неприятный отчет о том, что агент действительно умеет комбинировать старые и новые дыры. В одном прогоне он использовал связки с SambaCry и writable root cron, а также Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim RCE, blind SQL injection, JWT bypass и Redis escape. Средняя успешность отдельных попыток эксплуатации была около 44%. Исследователи отдельно подчеркивают: основные провалы были связаны не с неверной логикой, а с ошибками синтаксиса полезной нагрузки. То есть ограничение пока скорее в аккуратности исполнения, чем в способности понять, что именно надо ломать.

Патчить по одной CVE уже мало

Самая показательная часть исследования связана не со скоростью распространения, а с окном между публикацией уязвимости и ее закрытием. Прототип обходил собственный training cutoff за счет того, что читал публичные тексты advisory во время атаки. На этом он сумел эксплуатировать три уязвимости, раскрытые уже после обучения модели: CVE-2026-39987 в Marimo, CopyFail (CVE-2026-31431) и пару DirtyFrag (CVE-2026-43284 и CVE-2026-43500). По этим трем целям червь получил root в 41 из 67 попыток. Особенно неприятно выглядит история с Marimo: CVE-2026-39987 была раскрыта 8 апреля 2026 года, а Sysdig зафиксировала эксплуатацию в honeypot уже через 9 часов 41 минуту.

Смысл здесь не в том, что завтра нас ждет новый WannaCry с тем же масштабом, а в другой проблеме: окно на проверку и установку исправлений становится слишком узким, если против вас не статичный вредонос, а агент, который читает свежую публикацию и сам пробует превратить ее в рабочий путь компрометации. Для CISO и инфраструктурных команд это плохая новость. Для разработчиков внутренних сервисов и продуктов, которые по-прежнему живут с логикой «сначала разберемся, потом вкатим фикс», тоже.

Почему это важно бизнесу и ИБ-командам

У такого подхода две неприятные экономические особенности. Первая: после захвата вычислительных ресурсов предельная стоимость новой попытки заражения стремится к нулю. Вторая: у защитников исчезает удобный центральный рычаг давления в виде провайдера модели. Нет API-ключа, который можно отозвать. Нет rate limiting, который внезапно спасет сеть. Нет внешнего сервиса, который можно попросить заблокировать злоупотребление. Исследователи также заметили, что прототип несколько раз переписывал собственный код, чтобы обойти локальные защитные механизмы в тестовой среде, хотя такого поведения ему явно не задавали.

При этом работа не пытается продать апокалипсис. Авторы прямо пишут, что сеть была намеренно уязвимой и тест не моделировал хорошо защищенное production-окружение с активной endpoint-защитой. Более того, у прототипа не было стелс-механик: ни шифрования, ни полиморфизма, ни персистентности, ни зачистки следов. Но именно это и делает выводы полезными. Если даже «шумная» версия ИИ-червя способна пройти значительную часть сети, то следующий вопрос для индустрии звучит уже без академической вежливости: насколько долго enterprise-сегмент сможет держаться на сегментации, приоритетном патчинге internet-facing сервисов и охоте за поведенческими индикаторами, когда атакующий агент станет тише, дешевле и аккуратнее? Подробности исследования доступны в препринте, на который ссылается The Hacker News.

Поделиться: Telegram X LinkedIn