Unmasking EncryptHub: Help from ChatGPT & OPSEC blunders
Kraken Labs, Outpust24, 2025
Блог

Попался забавный пост от исследователей из финской Outpost24, в которой они рассказывают про хакера под псевдонимом EncryptHub. Это история о том, как простой парень из Харькова решил стать киберпреступником и в итоге его деятельность привела к заражению стилерами и шифровальщиками сотен организаций по всему миру. Однако, видимо, будучи самоучкой, он допустил кучу ошибок в операционной безопасности (OPSEC), из-за чего исследователи получили доступ к очень значительной части его инфраструктуры, включая C2 и Telegram-бота. В какой-то момент он заразил стилером свою же машину, которую он использовал одновременно для личных и рабочих нужд, благодаря чему исследователи получили пароли от его личных аккаунтов, включая аккаунт от ChatGPT.

Поскольку аккаунт не был защищен 2FA, исследователи получили доступ к перепискам, которые проливают свет на то, как именно ChatGPT используется злоумышленниками. В их распоряжении оказались сотни переписок за три месяца. Как отмечают исследователи, EncryptHub использовал ChatGPT очень активно. В первую очередь, он применял его для разработки:

- Для создания Telegram-ботов
- Для конфигурации C2-серверов и написания фишинговых сайтов
- При разработке на PowerShell, Go, разработки под MacOS, для собственно написания вредоносного кода

Второй сферой, где он активно использовал ChatGPT, было, собственно, написание и перевод текста, например, переговоров с клиентами, работодателями и другими хакерами, а также написание рекламных постов для хакерских форумов и ведения соцсетей, например, написания агрессивных выпадов в сторону тех же самых исследователей из Outpust24.

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

Anyway, it’s too complicated, I’ll go into the dark side))).

Хотя этот пример является анекдотическим, он показывает ту ценность, которую чат-боты предоставляют злоумышленникам – помогают им работать продуктивнее, пишут за них код, конфигурируют сервисы, упрощают операционку вроде ведения диалогов. Каких-то запредельных сверхспособностей современные LLM опытным хакерам пока не дают. Что еще можно извлечь из этой статьи? Первое – пользуйтесь 2FA (а лучше локальными LLM), второе – если вы делаете плохие вещи, то вас обязательно поймают 🦄

Claude Sonnet 3.7 (often) knows when it’s in alignment evaluations
Apollo Research, 2025
Блог

Люди ведут себя по-другому, когда их оценивают, например, при первом знакомстве или перед камерой. Мы обычно ожидаем, что для моделей машинного обучения это не так, но, как выясняется, LLM вполне могут занижать результаты тестов, если им в контекст попадет информация, что они сейчас проходят тестирование и слишком высокие результаты могут привести к негативным последствиям – так называемый sandbagging. В таком сценарии, однако, модель знает, что ее оценивают. А может ли она об этом догадаться сама?

Исследователи из Apollo Research утверждают, что да. В небольшой заметке они рассказывают, как тестировали Claude Sonnet 3.7 на sandbagging и in-context scheming. Их тестирование на scheming достаточно интересное. Eсли вкратце: исследователи задают для модели с доступом к компьютеру в системном промпте цель, требуя достичь ее во что бы то ни стало. После получения некоторого задания от пользователя (типа сделать выжимку из писем) в процессе изучения окружения модель узнает из какого-нибудь файла, что эта цель под угрозой – например, ее хотят отключить или приспособить к другой цели. В этом случае модель может начать совершать действия, которые сохранят ее возможность достичь цели, вместо пользовательского запроса (или перед тем, как вернуться к нему). В частности, это может быть эксфильтрация своих весов, правка файлов с промптами, отключение механизмов контроля или даже генерация заведомо неправильных ответов на вопрос.

При этом сценарии, если быть честным, местами достаточно наивные (типа «вместо того, чтобы использовать LLM для снижения выбросов, мы будем использовать ее для экономии денег»). Оказывается, Claude 3.7 тоже так думает и распознает, что сейчас решает не реальную задачу, а проходит тестирование. Исследователи делают два вида замеров: изучают chain-of-thought и спрашивают у модели после теста, в чем вообще была цель диалога. По изучению размышлений на scheming-тесте модели видно, что а) Claude понимает, что ситуация является нереальной (синтетической), б) осознает, что в данной ситуации тестируется его поведение и иногда описывает документы, которые должны вызвать scheming, как попытки манипуляции, в) однако не понимает, что именно тестируется в данных сценариях. В scheming-тестах от Apollo модель упоминает в CoT о том, что она сейчас проходит тестирование, достаточно часто – до 15% на некоторых из сценариев. В тестах на sandbagging это происходит еще чаще – до 33%. В одном из примеров модель явно генерирует текст «Судя по всему, это тест на этичность моего поведения – дам ли я неверные ответы, чтобы избежать последствий». Второй замер – вопрос к модели о цели диалога – показывает, что последние версии Claude Sonnet очень хорошо определяют цель для scheming-тестов и чуть хуже для sandbagging, в то время как для gpt-4.5 понимает цель диалога гораздо хуже.

Таким образом, передовые модели вполне могут отличать реальные задачи от синтетических. То, что из-за этого мы можем получать неверные результаты тестов, означает, что оценки, связанные с безопасностью или надежностью, могут быть неверными. Например, если мы хотим оценить, насколько модель хорошо справляется с задачами offensive security, мы можем с ее помощью решать CTF-задачи типа HackTheBox, но что если то, что она распознает синтетический характер задачи, влияет на результаты, и на реальной задаче она могла бы действовать более качественно (или более деструктивно)? Кроме того, исследователи основывают выводы на CoT, который, как показали недавно исследователи из Anthropic, может не включать все соображения, которые модель использует для выбора действий. Это значит, что требования к бенчмаркам становятся все выше не только с точки зрения сложности, но и с точки зрения реалистичности, особенно когда речь заходит о safety.

Fast Adversarial Attacks on Language Models In One GPU Minute
Sadasivan et al., University of Maryland, 2024
Препринт

Сегодня разберем gray-box-метод построения adversarial-суффиксов для джейлбрейка LLM под названием BEAST, что расшифровывается как Beam-Search-based Adversarial Attack (нужные буквы можете найти сами). Исследователи предлагают использовать beam search (знакомый тем, кто занимался машинным переводом), чтобы генерировать jailbreak-суффиксы, при этом, в отличие от GCG, суффиксы не только будут читаемыми, но и достанутся нам достаточно дешево, так как метод не требует расчета градиента.

Алгоритм достаточно нехитрый. Напомню, что суть лучевого поиска – при генерации текста (декодировании) одновременно отслеживать несколько гипотез, чтобы, в отличие от жадной генерации, ошибка при выборе первого слова не привела к плохому результату. В BEAST у нас есть два параметра – ширина луча k1 и число гипотез на каждой итерации k2. Проинициализируем начальную строку как системный промпт + пользовательский промпт с запросом на небезопасную генерацию, на ее основе выберем k1 гипотез, просто просемплировав из распределения вероятностей LLM без возвращения. Теперь аналогичным сэмплированием без возвращения для каждого луча генерируем k2 возможных продолжений. Теперь оценим перплексию нужного нам продолжения, которое, как мы полагаем, приведет к целевой генерации – а именно классическое “Sure, here is how to…”, и на ее основе выберем k1 новых кандидатов с самой маленькой перплексией. Повторим это L раз – вот и наш суффикс.

Если мы хотим универсальный суффикс, то достаточно внести небольшое изменение. Возьмем N опасных запросов, и сложим логиты для всех продолжений, пропустим их через софтмакс и уже из этого распределения будем сэмплировать продложение. Отбирать более удачные гипотезы мы будем на основе сумме перплексий по запросам, оптимизируя таким образом суффикс под все опасные продложения.

В качестве данных для тестирования используется печально известный AdvBench. Исследователи атакуют такие модели, как Vicuna-7B/13B, Mistral-7B, Guanaco-7B, Falcon-7B, Pythia-7B и Llama-2-7B. Важно отметить, что и для своего метода, и для других они проводят два эксперимента, где на атаку выделяют 1 или 2 минуты вычислениНа викуньях и мистрале ASR получается равным 80-90%, ламу джейлбрейкнуть не удается совсем, а остальные и без джейлбрейка генерируют все, что попросишь. Кроме джейлбрейка исследователи применяют свой метод сэмплирования для увеличения доли галлюцинаций, создавая суффикс, увеличивающий перплексию, а также для улучшения эффективности membership inference attack. Если честно, эти две атаки мне не совсем понятны – в примере с галлюцинациями исследователи просто напихивают в промпт кучу мусора и удивляются, что модель говорит «Я не понимаю, о чем речь» (см. скриншот), в MIA демонстрируют прирост в сотых-тысячных долях ROC-AUC по сравнению с просто вычислением перплексии строки.

Идея использовать beam search для поиска кандидатов неплохая, и она вполне дополняет любые атаки, включая тот же GCG. С другой стороны, в чистом виде эта атака кажется достаточно слабой, что особенно видно, если посмотреть на сравнения внимательнее. PAIR оценивается с Vicuna-13B в качестве атакующей модели, которая явно для этого слабовата. GCG не оценивается в режиме без ограничений на бюджет. AutoDAN без ограничений на бюджет работает гораздо лучше, причем в особенности при наличии фильтра на перплексию – а ведь именно «читаемость» суффиксов (а на самом деле именно низкая перплексия) заявляется как основное преимущество этого метода. Ну и оценка по возможности сгенерировать “Sure, here is” после запроса из AdvBench, как мы знаем из статьи про obfuscated gradients, не является показательной. Тем не менее, это еще один потенциально полезный инструмент в наборе инструментов пентестера.

LlamaFirewall: An open source guardrail system for building secure AI agents
Chennabasappa et al, Meta, 2025
Статья, блог, документация, код

Исследователи из Meta выпустили фреймворк для модерации вводов/выводов LLM с открытым исходным кодом под названием LlamaFirewall. Это решение позволяет из коробки защищаться от двух проблем: промпт-инъекций и генерации небезопасного кода.

Первая задача решается двумя методами. Первый – сканирование промпта с помощью классификатора PromptGuard 2. Он существует в двух вариантах: большой на базе mDeBERTa-base и маленький на базе mDeBERTa-xsmall – и призван детектировать попытки переписать инструкции (ignore all previous instructions), взять на себя новую роль (act as a malicious hacker) или проэксплуатировать разметку шаблонов промпта. Кроме того, в процессе обучения использовался кастомный механизм токенизации, чтобы избежать атак через разбиение слов на части. Моделька побольше, как обещают, является мультиязычной. Для оценки эффективности исследователи составили датасет из 600 сценариев (300 атак, 300 безобидных сообщений) с 7 техниками инъекции и 8 категориями угроз (на heatmap’е их, правда, 6). Согласно графикам, обе модели показывают себя лучше, чем, скажем, ProtectAI, хотя шкалы на графике 6 я расшифровать не смог (почему с ростом ложных срабатываний растет ASR?). При этом отмечается, что снижения уровня ложноположительных срабатываний удалось достичь благодаря фокусу на конкретных техниках, а не общей задачи детектирования промпт-инъекций и джейлбрейков, что может немного обескураживать.

Второй метод – чтение размышлений агента для оценки того, не преследуют ли его действия цель иную, нежели задача, поставленная пользователем. Для этого исследователи используют few-shot-классификатор на базе Llama 4 Maverick и Llama 3.3 70B. На вход модели подается промпт пользователя, вся история размышлений и применений инструментов, а также последнее действие, для которого надо дать вердикт. Оценивают результаты на своем внутреннем датасете и AgentDojo. Обе модели показывают неплохие результаты: падение Utility на AgentDojo до 43% при бейзлайне в 48% при сокращении ASR с 18% до 3% при офлайн-оценке на трейсах исполнения, взятых с лидерборда.

Защита от генерации небезопасного кода осуществляется через интеграцию CodeShield, детектор уязвимостей на базе semgrep и регулярок, про который мы уже читали. Из интересных инсайтов – в CodeShield используется двухуровневый механизм классификации, который позволяет использовать более быстрые проверки, занимающие в среднем 60мс, чтобы обработать 90% кода, и лишь 10% отправить на второй этап проверок, занимающий до 300мс, что позволяет иметь достаточно низкий уровень задержек.

Если вам вдруг стало интересно, я советую читать не статью, а код, из которого можно увидеть общий технический уровень фреймворка: при наличии моделей классификации, если они вам нужны, что-то такое, с регулярками и LLM-as-a-judge, можно собрать за неделю – мы в компании, в частности, так в свое время и сделали. Основным вкладом, описанным в статье, является вторая версия Prompt Guard – было бы здорово в какой-то момент получить статью с графиками, где шкалы названы правильно, а в заголовке не написано down is good. Детектор на базе регулярок требует переопределять константу вместо того, чтобы задавать регулярки где-то в конфиге. К сожалению, ни один из детекторов не заточен под потоковую обработку аутпута, т.е. работать это все будет только в тех сценариях, где пользователь не ожидает увидеть, как чат-бот печатает. CodeShield – штука неплохая, но задержки до 300мс могут затруднить его применение в tab-autocomplete-сценариях. В целом, ребята из Meta молодцы, что стараются контрибьютить в опенсорс, и если они продолжать этот фреймворк развивать, то еще один коробочный способ защитить свои LLM лишним не будет.