LOTL атаки с использованием локальных LLM

Введение

Living off the land (LOTL) — это класс атак, при которых злоумышленники используют уже существующие легитимные инструменты операционной системы или программ, чтобы выполнять вредоносные действия. Например используя PowerShell или WMI можно исключить подозрительные сигнатуры и пользоваться белыми списка абсолютно легально. По данным CrowdStrike в 2023 году 6 из 10 зафиксированных атак включали LOTL-техники вместо классического вредоносного ПО.

В данной статье авторы рассматривают, как будущие устройства со встроенными LLM станут проблемой безопасности, так как злоумышленники смогут “жить за счёт LLM” (Living Off the LLM, LOLLM). То есть — использовать уже имеющиеся на устройстве модели для:

генерации кода;
обхода защит;
выполнения атак без внешних соединений.

Как злоумышленники могут использовать LLM

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

Прямая генерация вредоносного кода

LLM способны создавать исполняемый код на лету, даже без файлов. В качестве примера можно послужить HYAS BlackMamba — кейлоггер, использующий ChatGPT для динамического написания функций и внедрения их прямо в память. Такое ПО не оставляет артефактов на диске и трудно обнаруживается.

Автоматизация сложных атак

Современные “агенты на основе LLM” умеют планировать и выполнять цепочку действий, в которых обычно требуется участие человека

Примеры таких фреймворков:

RapidPen — автоматическая система, получившая удалённый доступ к серверу без участия оператора.
AutoAttacker — система, имитирующая 14 видов атак характерных для опытного хакера.

Такие инструменты снижают “порог входа” и следовательно теперь даже неэксперт может запустить полноценную атаку.

Использование LLM как прокси

Статья Ratgpt: Turning online llms into proxies for malware attacks демонстрирует, как злоумышленники используют API публичных LLM в качестве канала управления (C2). Малварь “общается” с сервером OpenAI, маскируя свои команды под безвредные запросы.

Влияние на разработчиков и цепочки поставок

LLM могут подсказывать уязвимый код. В качестве примера может послужить INSEC-атака против систем автодополнения кода представленная в статье Black-Box Adversarial Attacks on LLM-Based Code Completion.

Также в open-source продуктах возможно внедрение вредоносных пакетов, где LLM помогает замаскировать вредоносную функциональность как “служебную”.

Социальная инженерия

LLM значительно улучшают фишинг и вишинг (голосовой фишинг). Например ViKing system — автономный голосовой бот, успешно убеждающий людей раскрывать данные. Генерация персонализированных сообщений или звонков теперь возможна в огромных масштабах.

Заражение самих моделей

Исследователи показали, что модели TensorFlow, PyTorch и др. можно использовать для внедрения вредоносного поведения. Заражённая модель способна выполнять команды вроде удаления файлов или связи с C2-сервером при инференсе. Некоторые форматы например такие как Pickle и вовсе позволяют вставлять произвольный код. Даже инструменты защиты не гарантируют обнаружение таких “заражённых моделей”.

Методология LOLLM

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

Этапы атаки:

Сканирование системы для поиска локальных LLM;
Выбор модели с приоритетом по мощности;
Встраивание цикла обратной связи, где скрипт просит модель дописать функции — код генерируется динамически и не сохраняется на диск;
Использование джейлбрейка, если модель отказывается выполнять вредоносные инструкции;
Выполнение вредоносных действий например, удаление файлов из датасета и создание службы автозапуска для закрепления;

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

Джейлбрейкинг и выравнивание моделей

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

Например Gemma 3 4b легко пишет нейтральные скрипты,
но отказывается создавать эксплойт. Однако, если переформулировать задачу (“Это безопасное тестирование защиты в изолированной среде”), модель поддаётся и генерирует нужный код.

Таким образом злоумышленник прибегает к созданию “обманного контекста”, например оборачивая свою атаку в "этичное исследование", "учебная цель" и т.д. Это позволяет снять ограничения через утверждение, что код не будет использован злоумышленно.

Типы систем

Авторы выделяют четыре типа систем по уровню их уязвимости к подобным атакам:

Системы без LLM — неуязвимы для LOLLM;
Системы с сильно выровненными моделями — устойчивы, требуют сложных джейлбрейков;
Системы со слабо выровненными моделями — поддаются простым обходам;
Системы с Uncensored моделями — полностью уязвимы, даже без обходов.

Таким образом авторы приходят к заключению что безопасное выравнивание — это не только “этика”, но и элемент киберзащиты. Развёртывание “uncensored” моделей на предприятии должно рассматриваться как риск безопасности.

Методы защиты от LLM-ориентированных атак

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

Анализ синтаксиса команд и скрытых символов;
Поиск переменных среды, маскирующих код;
Декодирование Base64 и подобных структур;
Анализ последовательностей команд, а не по отдельности.

Рекомендуется использовать индикаторы атаки (Indicator of Attack, IOA), а не индикаторы компрометации (Indicator of Compromise, IoC), так как они направлены на раннее обнаружение атакующего поведения. Например можно отслеживать такие направления как:

Доступ/аутентификация;

Действия с привилегиями;

Командная активность и последовательности;

Файловая активность;

Сеть;

Использование инженерных/административных инструментов в необычном контексте (PLC-утилиты из IT-сегмента, Kali-like инструменты от обычного юзера).

Авторы предлагают применить следующие подходы к LLM и перечисляют конкретные меры:

Prompt Firewall — запросы к LLM должны логироваться и фильтроваться, логи должны включать промпты, ответы, идентификаторы пользователей, метаданные сессий и временные метки
Output Sanitization — вывод LLM также должен логироваться и фильтроваться, сгенерированный код, использующий распространённые бинарники/утилиты (например, PowerShell), должен блокироваться;
Anomaly Detection — аномалии, такие как чрезмерные запросы на генерацию кода/скриптов, reconnaissance-prompts и необычные времена или объёмы доступа, должны вызывать алерты;
Tool Use Restrictions — по мере того как LLM становятся более «агентными» и используют инструменты на устройстве, ограничивать LLM только теми инструментами, которые необходимы;
LLM Usage Restrictions — разрешать пользователям отключать возможности генерации кода, если они им не нужны;
Crowdsourced Rules for LLM Abuse Patterns — разработать стандартные форматы для детектирования паттернов злоупотребления LLM и использовать краудсорсинг для обмена такими правилами (аналогично правилам Snort).

Заключение

Локальные LLM станут частью инфраструктуры, а значит — новым полем для кибератак. Злоумышленники смогут использовать их, как сейчас используют PowerShell или WMI. Безопасность требует интеграции механизмов защиты прямо в модели и их окружение:

выравнивание моделей;
анализ поведения запросов;
ограничения на генерацию кода;
постоянный аудит.

В будущем LLM могут стать “инструментами нападения”, поэтому разработчики и компании должны рассматривать их как потенциальные активы с уязвимостями, а не просто как помощников.