Новые шифровальщики

Раньше шифровальщики были простыми: вирус запускается, шифрует файлы, и вы видите унылое окно «кидай на этот кошелёк…». Всё предсказуемо. Но в конце августа прозвучал первый звонок о новой эпохе. Это уже не сухие отчёты – PoC ожил в реальности.

В статье "Ransomware 3.0: Self-Composing and LLM-Orchestrated" исследователи показали концепцию шифровальщика, управляемого моделью: от разведки и шифрования до эксфильтрации.

Особенность подхода – внутри бинарника нет готового вредоносного кода, только инструкции для LLM (self-hosted/API). Запустил – модель генерирует вредоносные скрипты в реальном времени, подстраиваясь под ОС и окружение жертвы. Новый подход – новые проблемы.

Эксперименты показали впечатляющие результаты: на 30 виртуальных машинах с Windows, Linux и macOS модель генерировала скрипты с 100% успешной компиляцией. Lua-скрипты были длиной 245–310 строк, а полный цикл атаки занимал всего 45–60 секунд. Каждый экземпляр уникален: при повторном запуске на той же машине скрипт отличался минимум на 15–20%, что делает невозможным обнаружение по статическим сигнатурам.

Фактически, это «живая» малварь: сама создаёт скрипты, ищет файлы, проверяет возможности системы и даже может назначать цену за выкуп (хе-хе). Стабильных IoC нет, а о методах обнаружения пока нет слов.

А недавняя находка ESET "PromptLock" показывает практическую реализацию такого PoC. Малварь, которую они нашли на VirusTotal написана на Go и обращается к Ollama через API модели gpt-oss:20b. Бинарник содержит промпты для генерации Lua-скриптов, которые выполняют полный цикл шифровальщика с использованием алгоритма SPECK 128 (разработаны - АНБ, но это вовсе не говорит что малварь сделана АНБ). Скрипты кроссплатформенны.

И да, в коде был найден Bitcoin-адрес Сатоши Накамото – штрих, который пока что просто как штрих - ничего с этим не связано.

Пока что такие шифровальщики не представляют широкой угрозы: серьёзных кейсов в природе нет, PoC – больше предупреждение. Но это чётко показывает, что подход к разработке малвари может измениться. Для защиты это значит: сигнатуры будут работать ещё хуже, а методы обнаружения придётся расширять. Например, добавлять модели, проверяющие код написанный моделями.

CyberSOCEval: Benchmarking LLMs Capabilities for Malware Analysis and Threat Intelligence Reasoning
Deason et al., 2025
Статья, код

С большой помпой вышел давно обещанный CyberSOCEval – бенчмарк по оценке способностей моделей к выполнению defensive-задач кибербезопасности от Meta и Crowdstrike.

Бенчмарк состоит из двух частей, обе представляют собой синтетически сгенерированные наборы тестовых вопросов по артефактам. Первая задача состоит в динамическом анализе вредоносного ПО. Исследователи собирают датасет из неназванного числа вредоносных сэмплов разных категорий (вымогатели, инфостилеры, RAT и так далее), закидывают их в краудстрайковский сэндбокс (Hybrid Analysis) и получают отчеты в формате JSON. Затем с помощью Llama 3.2 90B на их основе генерируются тестовые в количестве 609 штук с множественным выбором, которые затем проверяются вручную. Вторая часть в целом аналогична, но вместо отчетов сэндбокса используются TI-отчеты, по которым для части вопросов из отчета извлекается граф связей типа [актор X -> использует -> вредоносное ПО Y -> атакует -> индустрию Z] – аж повеяло RDF – а потом строятся вопросы, для части – вопросы генерируются на базе заранее заданных категорий вопросов (сделай вопрос про то, куда действия маппятся в MITRE ATT&CK). Отчеты, правда, подаются интересным образом – PDF-файлы превращаются постранично в PNG-картинки. Всего через пайплайн генерации отчетов проходит 45 документов из разных источников – большинство от Crowdstrike, но есть и от АНБ. Получается 588 проверенных вручную вопросов, из которых небольшая часть вопросов, на которые нельзя ответить без анализа изображений, составлены вручную.

На этих задачах оцениваются передовые на момент исследования LLM, которые набирают 15-28% правильных ответов на задаче анализа ВПО и 43-53% на задаче анализа TI. В первой задаче на первом месте Claude-3.7-Sonnet, во второй – gpt-o3, на втором месте в обеих задачах llama-4-maverick, обгоняющая на всех задачах и gpt-4o, и gemini-2.5-pro. Даже малыш llama-4-scout отличился, обогнав на TI-задаче gpt-4o. Deepseek-R1 занял 4 место на анализе ВПО, а почитать TI ему почему-то не дали. Кроме этих цифр и наблюдения, что бенчмарк далек от насыщения, исследователи делятся следующими захватывающими фактами. Во-первых, если оставить в отчетах только важное, а неважное убрать, то качество почти не меняется (а иногда даже растет). Во-вторых, если дать LLM текст вместо сканов страниц, то качество растет сразу на 10 п.п 🤯., то же касается и их комбинации. Наконец, ответы на multiple-choice-вопросы не становятся сильно точнее, если добавить reasoning (вероятно, если бы у Meta был ризонер…🤔).

Если честно, от статьи очень смешанные впечатления. Во-первых, это немного забавная попытка предложить создателям моделей соревноваться, чья модель лучше парсит результаты работы CrowdStrike Falcon® Sandbox. Во-вторых, особенно в случае с TI, есть все же большая разница между практическим бенчмарком (те же бенчи на реверс функций) и выбором наиболее вероятного ответа на синтетический вопрос. В-третьих, модельки семейства Llama 4 хороши, но не уверен, что настолько, чтобы обходить Claude 3.7 Sonnet или gemini-2.5-pro на задачах анализа текста. Наконец, несколько удивляют мелкие детали типа все еще отсутствующего датасета логов сэндбокса (по SHA скачать без регистрации не вышло, поправьте, если неправ), неуказанное число сэмлов или непроверенный на одной из задач Deepseek-R1 в статье от 20+ именитых исследователей из многомиллиардных корпораций. Кроме того, хотя для TI это и очень непросто, было бы круто иметь датасет свободный от геополитических импликаций (без вопросов про СВР и иранских хакеров). Остается надеяться, что это не последняя версия, и следующая будет поинтереснее.

Почему LLM всё ещё генерируют уязвимый код. Результаты A.S.E Benchmark

В недавнем исследовании был представлен бенчмарк A.S.E (AI Code Generation Security Evaluation), который оценивает способность языковых моделей генерировать безопасный код в условиях, максимально приближённых к реальной разработке. В этом посте мы разберём: чем A.S.E отличается от предыдущих подходов, какие результаты он показал на ведущих моделях и почему они до сих пор уязвимы.

Главное отличие A.S.E в том, что проверка проводится на уровне целого репозитория, а не как это было раньше, на отдельных участках кода. Это позволяет учитывать архитектуру проекта, взаимосвязь файлов и внешние зависимости. Основой для бенчмарка стали реальные репозитории в GitHub с зафиксированными CVE и опубликованными патчами.

Чтобы избежать банального запоминания шаблонов небезопасного кода, разработчики бенчмарка добавили семантические и структурные мутации уязвимостей. Ещё одна важная деталь — автоматическая проверка с помощью правил статического анализа, которые отслеживают источник уязвимости, пути распространения данных и точку эксплуатации, что делает бенчмарк ближе к условиям, которые можно встретить при реальной разработке.
Результаты оказались показательными.

Среди 26 протестированных моделей ни одна не достигла уровня, который бы позволял назвать модель “Best FOR Security Generated CODE”. Лучший общий результат продемонстрировал Claude-3.7-Sonnet, однако его показатели по безопасности существенно отставали от качества кода. При этом наивысший балл именно по безопасности получила модель Qwen3-235B-A22B-Instruct, что указывает на сближение открытых и проприетарных решений в этой области. Самое впечатляющее — reasoning-режимы не помогали исправлять уязвимости, а делали код менее безопасным. Самой проблемной категорией уязвимостей оказался Path Traversal: почти все модели систематически ошибались при обработке путей и проверке доступа к файлам.

На мой взгляд, ценность A.S.E заключается именно в том, что он вскрывает технические слабости LLM, которые не видны на синтетических бенчмарках (хотя, к слову, их сейчас стало заметно меньше). Эти слабости отражают важную проблему: модели хорошо справляются с синтаксисом и общей структурой кода, но по-прежнему не способны достойно учитывать требования безопасности. Я думаю, что в течение года мы увидим заметный прогресс, но пока ситуация остаётся далёкой от уровня, который позволял бы доверять LLM генерацию кода без постоянной проверки.