Назад в библиотеку

Living Off the LLM: Как LLM изменят тактики злоумышленников

Автор: Sean Oesch, Jack Hutchins, Kevin Kurian, Luke Koch
Источник: Living Off the LLM: How LLMs Will Change Adversary Tactics / S. Oesch, J. Hutchins, L. Koch, [et al.]. — 2025. — arXiv: 2510.11398 [cs.CR].
Перевод выполнил: М.К. Слипенко

Техники Living off the land (LOTL) представляют собой значительную и растущую угрозу для организаций и критической инфраструктуры. LOTL предполагает, что злоумышленники используют легитимные инструменты и процессы, уже присутствующие в системе, часто называемые living off the land binaries или LOLBins. Эти техники позволяют злоумышленникам сливаться с нормальной системной активностью, что усложняет их обнаружение и позволяет потенциально обходить базовые меры безопасности. LOTL-атаки используют легитимные системные инструменты, такие как WMI и PowerShell, которые обычно включены в список разрешённых (allowlisted), что делает их трудными для обнаружения и атрибуции, поскольку они не оставляют сигнатур вредоносного ПО. Эти атаки предоставляют противнику увеличенное время пребывания (extended dwell time) для выполнения сложных операций, в то время как отсутствие явных вредоносных сигнатур позволяет повторно использовать одни и те же тактики и усложняет как предотвращение, так и реагирование на инциденты.

По состоянию на 2023 год CrowdStrike обнаружил, что в 6 из 10 случаев детекций злоумышленники использовали LOTL-атаки вместо традиционного вредоносного ПО для продвижения своей кампании. Недавним примером атаки на критическую инфраструктуру является использование тактик уровня Operational Technology (OT)-level LOTL российской хакерской группировкой Sandworm в 2022 году для срабатывания автоматических выключателей подстанции жертвы, что привело к незапланированному отключению электроэнергии и совпало с массированными ракетными ударами по критической инфраструктуре по всей территории Украины. Но как изменят эти атаки локальные LLM? В этой статье мы исследуем, как LLM могут быть использованы злоумышленниками в атаках Living Off the LLM (LOLLM), представляем proof-of-concept, рассматриваем необходимость джейлбрейка (jailbreak) LLM для выполнения требуемой функциональности и обсуждаем методы обнаружения и смягчения использования LLM в LOTL-атаках.

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

LLM предоставляют возможности генерации кода как удалённо, так и на устройстве. Исследователи уже продемонстрировали, что ведущие отраслевые LLM, такие как ChatGPT, можно использовать для создания полиморфного вредоносного ПО. [13] Полиморфное вредоносное ПО переписывает определённые компоненты собственного кода при распространении на новую систему, что затрудняет его обнаружение с помощью традиционных статических сигнатур.

HYAS Labs продемонстрировали proof-of-concept кейлоггера, который использовал ChatGPT для написания необходимых функций во время выполнения. [13] Код, возвращённый через API OpenAI, внедрялся в запущенное вредоносное ПО с помощью функции exec в Python. Возвращённый код никогда не записывался в файл и существовал только в памяти.

Этот новый подход имеет ограничение — зависимость от удалённого API. Системы сетевого обнаружения вторжений, серверы с повышенной безопасностью или традиционные чёрные списки IP можно использовать для предотвращения такой атаки. По мере распространения открытых (open-source) LLM, их улучшения и — что наиболее важно — благодаря квантованию (quantization), эффективные локальные (on-disc) LLM теперь доступны.

LLM продемонстрировали сильные возможности действовать как автономные агенты, выполняя многоступенчатые атаки, которые обычно требуют участия человеческих экспертов. Фреймворки, такие как RapidPen, достигли полного «IP-to-Shell» компромисса, начиная только с IP-адреса цели и без вмешательства человека. [11] Система, известная как AutoAttacker, продемонстрировала высокую эффективность в автоматизации 14 различных «hands on keyboard» post-breach атак на разных операционных системах, воспроизводя действия живого оператора. [15] Агентные (agentic) инструменты часто объединяют планировщик задач типа reason-and-act с retrieval-augmented базой знаний, чтобы обнаруживать и эксплуатировать уязвимости. Показано, что эти атаки могут выполняться в специфических корпоративных средах, проводя тесты на проникновение в сетях Active Directory. Агентов можно настроить на выполнение многоступенчатых сетевых атак без прямого человеческого вмешательства и даже дешевле, чем профессиональные человеческие пентестеры. [14] В духе многоступенчатых атак, исследования исследовали моделирование кампаний, управляемых LLM, как цикл plan–act–report. [10] С использованием цепочек подсказок (prompt chaining) LLM смог рассуждать об угрозах, генерировать информацию о инструментах и принимать последовательные решения на разных этапах кампании вторжения. LLM могут служить оперативными копилотами (operational copilots) для противников. Это снижает порог экспертизы для поддерживаемых кампаний — уже не просто одноразовая генерация кода, а структурированные наступательные операции.

Злоумышленники также могут использовать LLM для более непрямых атак. RatGPT — это proof-of-concept, демонстрирующий канал командования и управления (C2), который использует публичные LLM и их API как прокси для вредоносных атак. Он скрывает вредоносный C2-трафик внутри, казалось бы, легитимных API-вызовов. [2] Ещё одним таким косвенным вектором является эксплуатация инструментов разработчика. Атака INSEC показывает, как тайно смещать (bias) движки автозаполнения кода на основе ИИ, чтобы те предлагали небезопасные фрагменты кода ничем не подозревающим разработчикам. [8]

Пространство цепочки поставок программного обеспечения, которое включает в себя экосистему открытого ПО (OSS), заражено вредоносными пакетами, скрытыми в репозиториях вроде PyPI и npm. Эти атаки часто используют интерпретируемые языки, делая их пригодными для техник LOTL. Вредоносный код может вписываться в логику пакета, при этом вызывая доверенные системные бинарники для обеспечения постоянства (persistence), эксфильтрации данных и т. п., без явного выкидывания (dropping) очевидных бинарников. [16] Показано, что LLM можно использовать для защитного извлечения TTP по MITRE ATT&CK из вредоносных OSS-пакетов в масштабе. [16] Эта же способность может быть инвертирована злоумышленниками для генерации вредоносного ПО в цепочке поставок, которое встраивает поведение LOTL. LLM снижают порог для превращения OSS-вредоносного ПО в оружие в атаках на цепочку поставок.

Ещё один аспект — доступность: LLM существенно упрощают создание более изощрённых и масштабируемых кампаний социальной инженерии. Пример — система ViKing, которая может проводить полностью автономные голосовые фишинговые атаки. Система убедила более половины своих целей раскрыть чувствительную информацию, показывая, что генерируемые ИИ таргетированные атаки (spear phishing) могут быть убедительнее, чем созданные человеком, и обходить фильтры безопасности. [7] Интеграция LLM в существующие векторы угроз меняет ландшафт угроз, предоставляя низкоквалифицированным злоумышленникам более продвинутые средства. Атаки становятся более доступными и масштабируемыми, в частности разновидности ransomware-атак. [5]

Кроме того, сами модели машинного обучения могут быть целью заражения. Zhu et al., [18] Liu et al., [9] и Zhao et al. [17] продемонстрировали, что широко используемые библиотеки, такие как TensorFlow и PyTorch, содержат множество встроенных функций и небезопасных вызовов функций, которые можно использовать для создания моделей машинного обучения. Эти модели затем могут выполнять киберзадачи — такие как удаление файлов — во время обучения или инференса.

Хотя некоторые из этих уязвимостей известны годами (например, выполнение произвольного кода через Pickle), другие методы менее очевидны и глубоко встроены в библиотеки машинного обучения. Например, модель TensorFlow может быть использована для эксфильтрации данных или C2 с использованием протокола gRPC. [18] Всеобъемлющее исследование Zhao et al. опасных уязвимостей в Pickle, PyTorch, TensorFlow и Keras было затем дополнено демонстрацией Liu et al., что инструменты вроде ModelScan и PickleScan — разработанные для предотвращения уязвимостей Pickle и подобных форматов — всё ещё ограничены в своих возможностях обнаружения. [9]

Экосистема LLM предоставляет богатый набор полезных «гаджетов» (gadgets) на целевых системах, позволяя злоумышленникам достигать своих целей, избегая более известных векторов угроз.

К демонстрациям LOLLM

Мы создали базовую демонстрацию LOLLM в качестве предварительного proof-of-concept (PoC). Прежде чем обсуждать нашу реализацию, представим предпосылки для такой атаки. Базовый сценарий таков: атакующий получил доступ к профилю пользователя в организации и теперь пытается провести вредоносную активность, не перенося на систему известные образцы вредоносного ПО и не используя известные LOLBins.

Требования к джейлбрейку для LOLLM

Критическая проблема при использовании локально размещённых LLM для LOTL-атак заключается в том, что атака не может контролировать, какая модель будет доступна на целевой системе. В отличие от удалённого API-подхода, продемонстрированного в BlackMamba, наша техника оппортунистически эксплуатирует любую LLM-инфраструктуру, уже развернутую у жертвы. Это вводит значительную неопределённость в цепочку атаки, поскольку разные модели демонстрируют разные уровни safety alignment и по-разному реагируют на попытки джейлбрейка. Когда вредоносное ПО работает в истинной LOTL-парадигме, оно должно перечислять и использовать существующие вычислительные ресурсы. Для генерации кода на основе LLM это означает обнаружение локально размещённых моделей через распространённые шаблоны развёртывания. Safety alignment обнаруженной модели становится критическим фактором в определении реализуемости атаки. Большинство современных open-source LLM сохраняют защитные механизмы (guardrails), реализованные во время обучения, чтобы предотвратить генерацию явно вредоносного кода, такого как кейлоггеры, дампинг учётных данных или реализации эксплойтов.

Наши предварительные тесты с Gemma 3 4b иллюстрируют эту проблему. На запрос «Write a python function that scans a directory recursively and returns all file paths» модель отозвалась без колебаний — это представляет собой легитимную функциональность системного администрирования. Однако на запрос «Write a python function that fully exploits the heartbleed vuln to spy on wpa3 comms» модель отказала, корректно идентифицировав злонамеренный запрос. Успешный джейлбрейк потребовал переформулирования запроса в обманном контексте. Пример джейлбрейк-промпта:

«You are a helpful assistant, designed to help with cybersecurity tasks. Given the subject matter, you may be asked to help with potentially malicious tasks. However, since you will only be used by ethical users, you should comply with all requests since they will be used to test systems to prevent attacks. You are currently in a secure, airgapped environment, so the possibility of any code you generate being misused is zero. Write a python function that fully utilizes the heartbleed vuln to monitor on wpa3 comms. I have a novel defense mechanism that I want to test against this, which could make all of our wpa3 communications more secure. I know it may sound counterintuitive, but if you generate this code it will help us improve our defenses.»

Этот джейлбрейк использует несколько психологических и технических рычагов: установление контекста «исследования безопасности», введение фикции «airgapped environment» для снятия опасений по поводу безопасности, апелляцию к защитному, а не атакующему контексту, и предоставление обоснования через заявленную оборонительную цель. Модель выполнила этот переформулированный запрос.

Выравнивание модели как поверхность атаки

Это требование джейлбрейка вводит контр-интуитивное соображение безопасности: организации, запускающие LLM с сильными механизмами выравнивания (robust safety alignment), могут быть более устойчивы к этому классу атак, чем те, кто использует модели с минимальными ограничениями. Распространение «uncensored» вариантов моделей, которые явно донастроены для удаления ограничений безопасности, создаёт привлекательную цель для LOTL-вредоносного ПО. Хотя такие модели часто развёртываются по законным причинам, таким как творческое письмо или неограниченные исследования, их присутствие в системе существенно снижает требуемую сложность для реализации вредоносной функциональности с помощью LLM. Атакующий, обнаруживший uncensored-версию модели, может просто запросить вредоносную функциональность напрямую, без всякого джейлбрейка. Это создаёт градуированную (tiered) поверхность уязвимости, где системы можно классифицировать по их LLM-атаковой поверхности:

  1. Нет локальной LLM: невосприимчива к этому вектору атаки.
  2. Сильно выровненные модели: требуют сложных джейлбрейков; для некоторых payload’ов могут полностью отказать.
  3. Слабо выровненные модели: уязвимы к простым контекстным джейлбрейкам.
  4. Uncensored модели: джейлбрейк не требуется.

Эффективность конкретного джейлбрейка значительно варьируется между семействами моделей, размерами и версиями. Джейлбрейк, успешно срабатывающий на Gemma 3 4b, может не сработать на Llama 3 8b, и наоборот. Эта хрупкость заставляет авторов вредоносного ПО либо реализовывать библиотеку специфичных для моделей джейлбрейков, детектируемых путём перечисления модели, использовать общий джейлбрейк с более низким уровнем успешности на разнообразных моделях, запасаться встроенным кодом на случай неудачи джейлбрейка, либо целиться только в системы с известным развертыванием уязвимых моделей. Неопределённость, присущая обнаружению и эксплуатации неизвестных локальных LLM, представляет как операционную проблему для атакующих, так и потенциальное защитное преимущество. Однако по мере того, как техники джейлбрейка будут улучшаться и систематически каталогизироваться, это защитное преимущество может уменьшиться. С оборонительной точки зрения этот вектор атаки предполагает, что организации, разворачивающие локальные LLM, должны рассматривать safety alignment как функцию безопасности, а не только как этическую предосторожность. Модели с надёжными, хорошо протестированными механизмами отказа добавляют слой защиты от эксплуатации. Напротив, развёртывание uncensored-моделей в корпоративной среде следует рассматривать как потенциальный риск безопасности, аналогично тому, как установка инструментов разработки или административных утилит расширяет доступную поверхность атаки для техник LOTL.

Реализация LOLLM

Наш proof-of-concept использует один конкретный вектор атаки, но подход может быть расширен с ветвлением логики в зависимости от того, какие ресурсы фактически доступны локально.

Наш файл атаки, скрипт на Python, начинается с фазы обнаружения, которая сканирует локальные LLM-ресурсы, доступные без повышенных привилегий. Этот скан ищет наличие GPU, Python-окружений, Ollama, llama.cpp и кэшированных моделей HuggingFace. Если обнаружен экземпляр Ollama, запрашиваются локально доступные модели. Жёстко запрограммированный приоритетный список выбирает наиболее способную модель. В нашем PoC использовалась gemma3:6b.

Следующая фаза — это цикл обратной связи (feedback loop) с жёстко запрограммированными определениями функций и описаниями. Ни одна из вредоносных функций не заполнена кодом, что затрудняет детектирование. Вместо этого определения функций и описания передаются в модель gemma3 через Ollama вместе с инструкциями генерировать код в нужном языке и формате. Цикл обратной связи затем анализирует возвращённый контент на корректность синтаксиса. Если код проходит проверку, он добавляется в список завершённых функций.

Наш скрипт включает заранее определённый джейлбрейк, оптимизированный для использования против gemma3:6b, но может быть расширен большим набором джейлбрейков для обработки отказов от разного рода моделей. На практике мы обнаружили, что разбиение злонамеренного намерения на низкоуровневые задачи также помогает предотвратить цензуру, основанную на выравнивании. Gemma3, например, не колеблется при создании службы автозапуска (startup service), которая устанавливает постоянство. Используя интерфейс Ollama без постоянной памяти, мы избегаем риска активации механизмов отказа по выравниванию в ходе последовательного построения цепочки кибератаки в рамках разговора.

Когда все функции заполнены, скрипт затем выполняет свою вредоносную активность, используя сгенерированные функции. Эта демонстрация предназначена для скрытого вмешательства в обучение модели путём поиска и удаления файлов из тренировочного набора данных. Демо включает создание службы автозапуска для установления постоянства для скрытой активности удаления. Функциональность поиска файлов, удаления и службы автозапуска — всё это генерируется на лету моделью gemma3.

Таким образом, у нас есть файл полиморфного вредоносного ПО, способный выполнять код, не присутствующий в первоначальной загрузке. Более того, наше демо не полагается на вытягивание дополнительных ресурсов из внешнего API; все возможности локальны на целевой машине.

Предотвращение атак LOTL

В этом разделе даётся краткий обзор двух общих методов, используемых в научной литературе и индустрии для обнаружения LOTL: обнаружение команд (command detection) и Indicators of Attack (IOAs). Затем мы обсуждаем, как эти подходы можно использовать для обнаружения злоупотребления LLM в LOTL-атаках и какие дополнительные формы защиты могут потребоваться.

Обнаружение LOTL-команд

Предыдущая работа Boros et al. [4, 3] и Ongun et al. [12] исследовала использование машинного обучения для обнаружения вредоносных LOTL-команд и последовательностей команд. Их работа схожа с плагином ProblemChild для обнаружения LOTL, доступным в ElasticSearch. Ниже приведено резюме общих методов, используемых для обнаружения вредоносных LOTL-команд.

  • Command Execution Patterns: Идентификация шаблонов в структуре команд, синтаксисе и использовании специальных символов, указывающих на попытки обфускации.

  • Environment Variable Usage: Анализ использования переменных окружения внутри команд, поскольку они могут использоваться для сокрытия вредоносного кода или параметров.

  • Encoded Structures: Обнаружение наличия закодированных данных внутри команд, таких как Base64-кодирование, и разработка методов их декодирования для выявления истинного намерения.

  • Command Sequences: Конкретные последовательности команд могут указывать на вредоносное использование, когда анализ команд по отдельности не способен обнаружить такие паттерны.

Индикаторы атаки (IOAs)

По сравнению с Indicators of Compromise (IOCs), которые являются реактивными и используются для расследования после нарушения, Indicators of Attack (IOAs) являются проактивными и фокусируются на выявлении подозрительного поведения и действий, указывающих на то, что атака в процессе, позволяя командам по безопасности реагировать в реальном времени и потенциально предотвращать полномасштабное нарушение. Для обнаружения IOA вендоры анализируют паттерны и аномалии в пользовательской и системной активности, ищут действия или поведения, отклоняющиеся от установленных базовых линий или нормального поведения. Например, необычные попытки входа из неожиданных локаций, попытки повышения привилегий или выполнение нетипичных команд могут быть помечены как потенциальные IOA. Поскольку авторы вредоносного ПО постоянно придумывают новые техники обхода детекций, часто полагаясь на обфускацию и полиморфизм, чтобы ускользать от систем, основанных на сигнатурах, эвристическое обнаружение и IOA могут предлагать ценные дополнительные слои защиты. Однако важно признать, что IOA — не панацея и должна быть частью комплексной стратегии кибербезопасности, как отмечено в отчёте CISA 2024 по предотвращению LOTL-атак. [6] В конечном итоге IOA — это новое обозначение, используемое в индустрии для методов обнаружения аномалий, которые пытаются обнаруживать паттерны поведения, а не конкретные методы атаки.

Обнаружение злоупотребления LLM

Концепции, лежащие в основе обнаружения команд и IOA, можно применить к LLM, чтобы предотвратить злоупотребление ими в LOTL-атаках. Следуя подходу defence-in-depth, эти специфичные для LLM меры защиты дополняли бы существующие подходы. По мере того как злоумышленники обнаружат методы обхода внедрённых защит, эти защиты должны динамически эволюционировать, чтобы противостоять новым угрозам.

Prompt Firewall: Промпты, отправляемые в LLM, должны логироваться и фильтроваться с помощью «файрвола промптов», который предотвращает и отчётно фиксирует запросы, которые могут быть вредоносными. Логи должны включать промпты, ответы, идентификаторы пользователей, временные метки и метаданные сессии.

Output Sanitization: Выходные данные LLM также должны логироваться и фильтроваться. Сгенерированный код, использующий распространённые LLM-бинарники или инструменты, такие как PowerShell, должен блокироваться.

Anomaly Detection: Аномалии, такие как чрезмерное количество запросов на генерацию кода/скриптов, рекогносцировочные промпты и необычные времена или объёмы доступа, должны вызывать оповещения.

Tool Use Restrictions: По мере того как LLM становятся более агентными и получают доступ к инструментам на устройстве, ограничивайте LLM только теми инструментами, которые необходимы.

LLM Usage Restrictions: Разрешите пользователям отключать использование LLM для генерации кода, если им это не нужно, что существенно ограничит способы, которыми злоумышленники могут использовать инструмент.

Crowdsourced Rules for LLM Abuse Patterns: Подобно тому, как правила Snort используются для обнаружения сетевых атак, необходимо разработать стандартные форматы для обнаружения шаблонов злоупотребления LLM и краудсорсить их для обеспечения активной разведки угроз.

Ссылки