Кампании с участием нового семейства вымогательского ПО VECT 2.0 демонстрируют тревожную тенденцию: под видом классического ransomware жертвы фактически получают полное уничтожение данных. Исследователи Check Point Research установили, что из‑за критического дефекта в реализации шифрования восстановить зашифрованные файлы невозможно даже самим операторам VECT — вне зависимости от уплаты выкупа.
VECT 2.0: RaaS с фасадом勒 вымогательства и реальной функцией вайпера
VECT (переименованный в VECT 2.0) позиционируется на даркнете как ransomware-as-a-service (RaaS). На своем сайте оператор рекламирует триединую модель «Exfiltration / Encryption / Extortion»: кража данных, их шифрование и дальнейший шантаж. Для вступления в партнерскую программу новым аффилиатам требуется вступительный взнос около 250 долларов в криптовалюте Monero (XMR), при этом для резидентов стран СНГ плата отменяется — явная попытка привлечь исполнителей из региона.
Несмотря на агрессивный маркетинг, на утечечном сайте VECT пока числятся лишь две подтвержденные жертвы, взломанные через цепочку поставок, связанную с группировкой TeamPCP. Однако архитектура сервиса, интеграция с даркнет‑форумами и партнерства показывают стремление построить промышленно масштабируемую платформу вымогательских атак.
Фатальная ошибка в шифровании: файлы крупнее 131 КБ безвозвратно уничтожаются
Ключевая особенность VECT 2.0 — то, что он технически не является полноценным ransomware в привычном понимании. Анализ показал, что для файлов размером более 131 072 байт (примерно 128–131 КБ) вредонос не производит корректного шифрования, а необратимо разрушает содержимое. Это затрагивает большинство критически важных для бизнеса документов и баз данных.
Разработчики VECT заявляли, что используют современную схему ChaCha20-Poly1305 AEAD, обеспечивающую как конфиденциальность, так и целостность данных. На практике же применяется более слабый, неаутентифицированный режим шифрования без контроля целостности. Более того, реализация для Windows, Linux и ESXi, написанная на C++, содержит фундаментальную концептуальную ошибку.
Для «крупных» файлов вредонос делит содержимое на четыре независимых блока и шифрует их с помощью ChaCha20-IETF, используя каждый раз новый случайный 12‑байтовый nonce. На диск записывается только последний nonce. Три первых, необходимых для расшифровки соответствующих частей файла, генерируются, используются и тут же теряются: они не сохраняются ни в файл, ни в реестр, ни на сервер злоумышленника.
Поскольку для расшифровки каждого блока требуется одновременно и ключ, и точный nonce, первые три четверти любого большого файла становятся невосстанавливаемыми для всех — включая операторов VECT. Таким образом, VECT 2.0 фактически работает как вайпер с интерфейсом ransomware: данные уничтожаются без возможности их вернуть даже при «успешных» переговорах и оплате.
Партнерства, цепочки поставок и роль BreachForums и TeamPCP
Для расширения экосистемы VECT 2.0 операторы выстроили сотрудничество с киберпреступным маркетплейсом BreachForums и хакерской группой TeamPCP. Такое объединение позволяет использовать уже ранее похищенные учетные данные и доступы, снижая порог входа для аффилиатов и ускоряя запуск новых атак.
Эксперты отмечают, что конвергенция массовых краж учетных данных в цепочках поставок, зрелой RaaS‑модели и мобилизации даркнет‑форумов формирует качественно новый уровень индустриализированного распространения вымогательского ПО. VECT 2.0 может стать прототипом будущих платформ, где оператор управляет не только шифровальщиком, но и всей цепочкой эксплуатации ранее украденных данных.
Технические особенности VECT 2.0 для Windows, Linux и ESXi
Вариант для Windows помимо шифрования локальных, съемных и сетевых дисков оснащен широким набором средств противодействия анализу, нацеленным на десятки инструментов безопасности и отладки. Реализован механизм закрепления в Safe Mode: при запуске с параметром --force-safemode вредонос переводит следующую загрузку системы в безопасный режим и прописывает себя в реестр для автоматического старта, используя минимальный набор драйверов и сервисов Windows.
Интересно, что встроенные механизмы обнаружения виртуальной среды и песочниц в Windows‑версии фактически никогда не вызываются. Это облегчает работу аналитиков и средств защиты, поскольку вредонос не активирует многие функции уклонения.
Варианты для ESXi и Linux используют общий код. ESXi‑сборка перед шифрованием выполняет геофенсинг и проверки на отладку, а также пытается распространяться по сети через SSH. Если VECT обнаруживает, что запущен в одной из стран СНГ, он завершает работу без шифрования. Примечательно, что среди исключений присутствует и Украина, что нетипично: большинство современных RaaS после 2022 года удалили ее из этого списка. Исследователи предполагают, что разработчики могли использовать устаревшую кодовую базу или сгенерированный ИИ код.
Совокупность признаков — ошибки в криптографии, необычные списки геофильтров, неиспользуемые проверки окружения — указывает, что за VECT стоят относительно неопытные операторы, частично полагающиеся на автоматическую генерацию фрагментов кода.
С точки зрения киберзащиты этот кейс подчеркивает: оплата выкупа не может рассматриваться как стратегия восстановления. В случае атаки VECT 2.0 денег у жертв можно лишиться дважды — и без малейшего шанса вернуть критические данные. Приоритетом должны стать устойчивость и восстановление: изолированные офлайн‑резервные копии, регулярное тестирование процедур восстановления, жесткое управление доступами и проактивное выявление компрометации в цепочке поставок.
VECT 2.0 показывает, как быстро даже «любительские» группы, вооруженные RaaS‑платформой и ресурсами даркнета, могут превратиться в серьезную угрозу для инфраструктуры на Windows, Linux и ESXi. Компаниям стоит пересмотреть свои планы реагирования на инциденты, уделить внимание резервному копированию и сегментации сети, а также обучению сотрудников распознаванию признаков ранней компрометации. Чем раньше будет обнаружена активность подобных семейств, тем больше шансов, что VECT 2.0 так и останется для вашей организации лишь предметом новостных сводок, а не причиной катастрофической потери данных.
