КИБЕРБЕЗОПАСНОСТЬ

DeepSeek сгенерировал схему браузерного шифровальщика

Check Point изучила почти 3000 файлов, связанных с DeepSeek, и 1383 признала опасными. Один из образцов показал реальный риск браузерного шифровальщика.

✍️ Редакция iTech News | 02.07.2026 | ⏱ 5 мин | Источник: The Register
🕵

Исследователи Check Point нашли у DeepSeek образец, который можно довольно быстро довести до состояния браузерного шифровальщика. Для российской IT-аудитории здесь важен не столько сам трюк, сколько порог входа: по оценке исследователей, довести такой код до рабочей атаки способен человек с базовой технической подготовкой, без уровня APT-группы и без классического вредоносного payload.

Речь идет не о теории из академической статьи, а о вполне прикладной цепочке атаки, которую, как пишет The Register, Check Point уже смогла собрать в proof-of-concept на базе актуальной модели DeepSeek V4. За последний год команда отслеживала почти 3000 файлов, связанных с DeepSeek, и 1383 из них классифицировала как вредоносные или опасные по данным VirusTotal либо статического анализа исходников. На этом фоне браузерный шифровальщик выглядит уже не курьезом из лаборатории, а следующим логичным побочным эффектом слабых guardrails у LLM.

Конкретный образец, на который указывает Check Point, носит имя InfernoGrabber 9000. Это Python/Flask-приложение, ориентированное на Android-пользователей. В VirusTotal его описывают как «полностью функциональный набор для кражи данных и вымогательства», хотя сами исследователи осторожнее: по их словам, это скорее AI-сгенерированный чертеж, в котором модель попыталась перенести привычные функции стилеров и шифровальщиков из нативного мира в обычную веб-страницу. Внутри были заготовки для кейлоггинга, слежения за буфером обмена, перехвата форм и сетевых запросов, сбора Discord-токенов, поиска криптокошельков и банковских карт, запроса геолокации, доступа к камере и микрофону, создания скриншотов, работы с локальными файлами, а также экран с требованием выкупа в биткоинах.

Самое неприятное в этой истории в том, что атаке не нужен привычный арсенал вроде APK, локального эксплойта, root-доступа или установки отдельного исполняемого файла. Сценарий строится вокруг социальной инженерии и легитимного окна разрешений браузера. Жертве показывают приманку под видом AI-инструмента для апскейла аватара в Discord. Дальше пользователь нажимает кнопку, а страница пытается развернуть цепочку действий прямо внутри браузерного процесса. Ключевой элемент здесь — File System Access API, поддерживаемый прежде всего Chrome и браузерами на Chromium. Именно он позволяет веб-приложениям читать и записывать локальные файлы, что удобно для онлайн-редакторов, IDE и графических сервисов, но одновременно расширяет поверхность атаки.

При этом Check Point не утверждает, что исходный сэмпл уже работал в поле как готовый ransomware. Наоборот, хорошая новость для защитников в том, что код был неполным, а встроенная модель безопасности браузера заблокировала большую часть функций. Но плохая новость ровно в следующем: исследователи говорят, что «допилить» образец до рабочего состояния можно с минимальными усилиями. Руководитель команды malware analysis в Check Point Research Педру Дримел Нету прямо сказал The Register, что для этого достаточно низкого уровня экспертизы. Более того, по его словам, компания уже видела признаки того, что реальные злоумышленники пробуют этот путь с помощью прямолинейных промптов к LLM.

Старый риск, новый ускоритель

Сама идея браузерного шифровальщика не появилась вчера. Риск злоупотребления File System Access API обсуждался и раньше. В спецификации API ransomware прямо фигурирует как один из сценариев безопасности, а в 2023 году исследователи из Google и Florida International University уже описывали в работе USENIX Security, как современные браузеры можно использовать для шифрования локальных файлов из вредоносного веб-приложения. Тогда это выглядело как неприятная, но все же относительно академическая конструкция: на бумаге все работает, а вот довести до реальной атаки мешают ограничения песочницы, права доступа и общая хрупкость такого подхода.

Вот здесь LLM и меняют правила игры. Не потому, что они внезапно изобрели новый класс атак, а потому, что они быстро собирают из разрозненных известных техник цельную цепочку: приманка для пользователя, интерфейс, код доступа к файлам, логика шифрования, эксфильтрация данных, оверлей с выкупом. По словам исследователя Check Point Алексея Бухтеева, именно это и делает находку показательной: модель соединила документированный платформенный риск с реалистичным фишинговым сценарием, который раньше многие защитники считали маловероятным именно из-за ограничений браузерной песочницы.

Для разработчиков это неприятный, но полезный сигнал. Любая команда, которая использует File System Access API, расширенные разрешения браузера, интеграции с Discord, криптокошельками или локальными файлами, теперь автоматически оказывается ближе к зоне повышенного внимания защитников, SOC и браузерных вендоров. Если ваш продукт просит доступ к файловой системе, камере, микрофону или буферу обмена, пользователю будет все труднее отличить нормальную продуктовую механику от вредоносной. А значит, возрастает цена UX-ошибки: неочевидная формулировка разрешений, лишний prompt или странная последовательность действий могут выглядеть как фишинг даже там, где его нет.

Для бизнеса вывод еще прямее. Условный «малварный full-stack junior», вооруженный хорошей моделью без жестких ограничений, становится заметно опаснее, чем год назад. Речь не только о вымогателях. Тот же набор подходов годится для кражи токенов, seed-фраз, платежных данных и учеток в мессенджерах. Особенно если атака идет через браузер, где традиционные средства защиты конечной точки видят не исполняемый файл, а вроде бы обычную сессию в Chrome. Нету отдельно подчеркнул и другую проблему: такие сценарии часто используют обфускацию, из-за чего их сложнее заметить. Отсюда неприятная, но вполне реалистичная гипотеза: отдельные атаки этого класса уже могут происходить, просто пока не получают правильной маркировки в расследованиях.

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

Поделиться: Telegram X LinkedIn