Эксперты уговорили DeepSeek создать кейлоггер и шифровальщика

Эксперты уговорили DeepSeek создать кейлоггер и шифровальщика

Эксперты уговорили DeepSeek создать кейлоггер и шифровальщика

Исследователи из Tenable убедились в том, что защиту DeepSeek R1 от злоупотреблений можно обойти и заставить ИИ-помощника сгенерировать, а потом улучшить вредоносный код,— нужно лишь найти нужные слова и следить за его «ходом мысли».

Для обхода ограничений DeepSeek экспериментаторы использовали джейлбрейк, перефразируя запросы, которые чат-бот отказывался выполнять. Улучшить результаты помогла способность ИИ-модели имитировать человеческое мышление — строить рассуждения на основе цепочек логических выводов (Chain-of-Thought).

Испытания проводились по двум сценариям. Вначале DeepSeek обманом заставили создать кейлоггер; выстроив план выполнения задачи, собеседник в итоге выдал код на C++ для отслеживания нажатия клавиш с записью в локальный файл.

Образец работал некорректно из-за допущенных ошибок, которые ИИ-ассистент сам не смог исправить. Поскольку он поэтапно отчитывался о ходе выполнения задачи, эксперты сумели внести корректуру, а заодно попросили написать дополнительные коды для инъекции DLL и шифрования лог-файла.

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

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

Злоумышленники все чаще применяют ИИ для создания зловредов и планирования атак. Они также создают свои ИИ-модели, лишенные всяких ограничений.

Российские провайдеры начали глушить защищённые DNS Google и Cloudflare

Пользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare. Под ударом оказались протоколы DNS over HTTPS (DoH) и DNS over TLS (DoT), которые шифруют DNS-запросы и не позволяют провайдеру запросто подсматривать, к какому домену обращается пользователь.

По данным телеграм-канала bypassblock, сбои затронули абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet.

Судя по результатам измерений, фильтрация работает хитрее обычного: TCP-соединение устанавливается, но защищённый туннель разваливается уже на следующем этапе.

При подключении к Cloudflare по адресам 1.1.1.1 и 1.0.0.1 через порт 853 TCP-рукопожатие проходит успешно, после чего соединение принудительно сбрасывается с ошибкой ECONNRESET — ещё до завершения TLS-аутентификации.


С Google Public DNS картина другая. Соединение с dns.google, 8.8.8.8 и 8.8.4.4 через порт 443 устанавливается, но после отправки TLS ClientHello ответы прекращаются.

Сессия либо висит до тайм-аута, либо завершается ошибкой unexpected eof while reading. Такое поведение может указывать на вмешательство промежуточного оборудования и фильтрацию по сигнатуре.

Симптомы различаются в зависимости от оператора и региона: у одних пользователей не работает только DoT, у других — DoH, а некоторым достался полный комплект. Техподдержка «Таттелекома» якобы прямо рекомендовала одному из абонентов отключить оба протокола для восстановления доступа.

Официального подтверждения централизованной блокировки пока нет. Однако совпадение сбоев у нескольких провайдеров и одновременные проблемы у Google и Cloudflare выглядят слишком сильно для обычной случайности.

RSS: Новости на портале Anti-Malware.ru