Последний год все повторяют, что атаки ускорил искусственный интеллект. А вот свежий случай переворачивает эту мысль. Компания Sysdig разобрала инцидент, где живой человек, без всякого ИИ, прошёл путь от уязвимости в ноутбуке Marimo до чужого SSH-бастиона за восемь секунд. Такую скорость обычно приписывают ботам, но здесь за клавиатурой сидел человек с собственным, написанным вручную набором скриптов. История поучительная сразу с нескольких сторон, и мы разберём почему.
Что за уязвимость
Marimo — это платформа для интерактивных Python-ноутбуков, популярная у дата-сайентистов и в командах машинного обучения. Уязвимость CVE-2026-39987 в ней позволяет выполнить произвольный код ещё до какой-либо аутентификации. Причина обидная в своей простоте: у платформы есть несколько соединений по WebSocket, и на всех стоит проверка входа, на всех, кроме одного. Конечная точка терминала эту проверку почему-то не выполняла. В результате любой, кто открывал к ней соединение, сразу получал интерактивную командную оболочку с правами процесса Marimo. Без пароля, без токена, без единого препятствия.
Проблема не новая. Уязвимость затрагивает версии вплоть до 0.20.4 и закрыта в 0.23.0, а сама она давно висит в каталоге активно эксплуатируемых уязвимостей CISA, с федеральным сроком устранения ещё 7 мая. То есть патч был доступен месяцами. Пострадали те, кто так и не обновился.
Восемь секунд — но за ними четыре часа подготовки
Самое интересное здесь — как именно атакующий двигался. Получив оболочку, он за восемь секунд добрался до SSH-бастиона: вытащил ключи от облака и вошёл на защищённый узел, через который управляется вся инфраструктура. Один запуск, одна команда, восемь секунд. Именно эта цифра и попала в заголовки.
| Шаг | Что произошло |
|---|---|
| 1 | Подключение к незащищённой конечной точке терминала — оболочка без пароля |
| 2 | Кража ключей AWS сразу из двух мест: окружения процесса и базы Redis приложения |
| 3 | Один из ключей вернул приватный SSH-ключ из AWS Secrets Manager |
| 4 | Вход на SSH-бастион, а через него — доступ в облако жертвы |
| Итого | 8 секунд выполнения поверх ~4 часов предварительной подготовки |
Но за красивой цифрой прячется другая, куда более честная. Прежде чем сделать этот рывок, человек потратил около четырёх часов в предыдущих сессиях, писал и отлаживал свой инструментарий. К моменту атаки у него было восемь готовых скриптов, которые и отработали цепочку в одну команду. Всего за девятичасовую сессию он ввёл более 850 команд вручную и не использовал ни одного известного публичного хакерского инструмента, всё своё.
Наш взгляд. Восемь секунд — это не про магию и не про ИИ. Это восемь секунд исполнения поверх часов подготовки. Так работали сильные атакующие всегда: заранее собрать и отладить инструментарий, а в бою просто нажать кнопку. Скорость даёт не искусственный интеллект как таковой, а заготовленный сценарий. ИИ лишь позволяет делать такие заготовки тем, у кого раньше не хватало на это навыка. Вывод для защитника от этого не меняется: считать, что у вас есть время на реакцию, нельзя ни в том, ни в другом случае.
Как отличили человека от бота
Отдельно любопытно, как исследователи вообще поняли, что перед ними человек, а не ИИ-агент. Sysdig заранее оставила ловушку: в одном из файлов лежала скрытая инструкция, которая приказывала любой языковой модели вывести определённую метку. Расчёт простой: ИИ-агент, читающий файл, наткнулся бы на эту инструкцию и послушно её выполнил, выдав себя. Наш герой дважды открывал тот самый файл и метку не вывел ни разу. Значит, инструкцию читал не автомат, а человек, который на подобные приманки не ведётся.
Это тонкий, но важный сигнал о том, куда движется оборона. Защитники начинают расставлять ловушки специально на ИИ, приманки, рассчитанные на то, что автономный агент выполнит спрятанную команду, а живой оператор нет. Пока это скорее исследовательский приём, но сам подход показателен: различать, кто именно тебя атакует, становится отдельной задачей.
Почему ноутбуки для машинного обучения — лакомая цель
Ещё один слой этой истории: куда именно ударил атакующий. Ноутбуки вроде Marimo или Jupyter обычно крутятся не на пустом месте, а рядом с конвейерами машинного обучения. А это значит доступ к мощным GPU, к большим и часто чувствительным датасетам и, что критичнее всего, к ключам от облаков: AWS, GCP, провайдеров моделей. Такой хост исследователи прямо называют дверью в облачный аккаунт жертвы.
В нашем случае так и вышло. Ключи AWS нашлись сразу в двух местах: в переменных окружения процесса и в базе Redis, которую использовало приложение. Одного из них хватило, чтобы вытащить приватный SSH-ключ из хранилища секретов AWS, а этот ключ открыл вход на бастион. Классическая цепочка: одна дыра в наружном сервисе, и через несколько звеньев атакующий уже управляет вашей облачной инфраструктурой. При этом ML-инфраструктуру защищают заметно хуже, чем классические веб-приложения: её поднимают дата-сайентисты, а не безопасники, и вопросы вроде «а не торчит ли этот ноутбук в интернет» задают уже постфактум.
Что это значит для защиты
Практические выводы простые, но их стоит проговорить, потому что бьют они по типичным слабым местам.
- Не выставляйте ноутбуки и панели наружу. Marimo, Jupyter и подобные инструменты не должны быть доступны из интернета, прячьте их за VPN или хотя бы за список разрешённых адресов. Что именно у вас торчит наружу, показывает тест внешнего периметра.
- Обновляйтесь в темпе атакующего. Патч для Marimo вышел давно, а жертвами стали те, кто затянул. Если сервис смотрит в интернет, счёт идёт на часы — об этом мы подробно писали в заметках из наших расследований.
- Уберите долгоживущие ключи оттуда, откуда их удобно красть. Секреты не в переменных окружения и не в открытой Redis, а короткоживущие токены вместо вечных ключей, тогда украденный доступ протухает быстрее, чем им успевают воспользоваться.
- Отдельно проверяйте ML-инфраструктуру и облако. Это задача аудита безопасности машинного обучения и аудита облачной инфраструктуры, а устойчивость к реальному сценарию проверит Red Team.
- Держите наготове план реагирования и логи, по которым видно движение внутри. В атаке, где до бастиона восемь секунд, весь разбор потом строится именно на журналах.
Вывод
Случай с Marimo ценен тем, что ломает удобный шаблон. Мы привыкли объяснять скорость атак искусственным интеллектом, но здесь машинную скорость выдал человек, за счёт подготовки, а не автоматики. И это не повод расслабиться, а наоборот: быстрым может быть и бот, и подготовленный оператор, а значит окно на реакцию у вас одинаково маленькое в обоих случаях. Обновляйте то, что смотрит в интернет, не оставляйте ноутбуки и ключи на виду и проверяйте свою облачную и ML-инфраструктуру до того, как это сделает кто-то другой. О том, как ИИ меняет и нападение, и оборону, мы писали в разборах злоупотреблений ИИ в атаках и нагрузки на SOC, а как выглядит массовая автоматизация — на примере кампании против PaperCut. Начать разумно с честной оценки периметра: закажите пентест или аудит с применением ИИ.