07.07.2026 — CVE-2026-53359 – Januscape {#CVE-2026-53359}

Идентификатор CVE (CVE ID): CVE-2026-53359

Ссылка на CVE: <https://www.cve.org/CVERecord?id=CVE-2026-53359>

Ссылка на NVD: <https://nvd.nist.gov/vuln/detail/CVE-2026-53359>

Описание {#description-CVE-2026-53359}

Уязвимость CVE-2026-53359 позволяет гостевой системе нарушить изоляцию среды виртуализации и повысить свои привилегии (guest to host escape) в среде KVM/x86. Насколько известно, это первая обнаруженная уязвимость, позволяющая использовать эксплойт перехода с гостевой системы на хост, который может быть активирован как на Intel, так и на AMD, а не только на одной архитектуре. Januscape — это уязвимость типа use after free в эмуляции ShadowMMU KVM/x86.

Подробное описание уязвимости представлено в статье.

CVSS рейтинг: на момент написания статьи не проставлен.

Влияние {#impact-CVE-2026-53359}

Общее влияние {#overall-impact-CVE-2026-53359}

подвержен KVM, не зависит от QEMU;
отключенная вложенная виртуализация (nested virtualization) сильно затрудняет эксплуатацию.

Влияние на сервисы Yandex Cloud {#impact-on-yandex-cloud-services-CVE-2026-53359}

Не оказывает влияния на пользователей Yandex Cloud поскольку:

вложенная виртуализация (nested virtualization) выключена;
аппаратная технология Extended Page Tables (EPT) включена.

Компенсационные меры {#compensatory-measures-CVE-2026-53359}

Yandex Cloud применяет исправленные стабильные версии, выпущенные 04.07.2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260.

23.06.2026 — Целевые атаки с шифрованием данных в Linux-инфраструктуре российских организаций {#targeted-linux-ransomware-attacks-2026}

Исходный отчет {#original-report-linux-ransomware-2026}

Kaspersky / Securelist. Как изменился арсенал группы Head Mare в начале 2026 года: <https://securelist.ru/head-mare-phantomheart-and-phantomproxylite/114753/>.
F6. Bearlyfy выпустили джинна: F6 проанализировала свежие атаки группы: <https://habr.com/ru/companies/F6/news/1014722/>.
Positive Technologies. Фантомные боли: масштабная кампания кибершпионажа и возможный раскол APT-группировки PhantomCore: <https://habr.com/ru/companies/pt/articles/939942/>.
Sansec. Found defunct.dat on your site? You've got a problem: <https://sansec.io/research/gsocket>.

Краткое описание {#brief-description-linux-ransomware-2026}

Yandex Cloud наблюдает целевые атаки с шифрованием данных в Linux-инфраструктуре российских организаций. В описанной кампании участвуют APT-группировки Bearlyfy (Labubu, Toy Ghouls) и Head Mare (PhantomCore). Основные цели атак — узлы прикладных служб, виртуализации и баз данных.

Типовая цепочка атаки начинается с публично доступных интерфейсов прикладных служб, уязвимых веб-приложений, перехваченных учетных данных или VPN-сессий. После первичного закрепления атакующие быстро проводят разведку, подбирают учетные данные к СУБД и повышают привилегии на Linux-узле с помощью локальных LPE-эксплойтов, включая CVE-2026-31431, CVE-2026-43284, CVE-2026-43500, CVE-2026-21533 и другие. Затем шифровальщик запускается координированно сразу на нескольких узлах.

Для управления скомпрометированной инфраструктурой применяются gsocket-имплант поверх публичного релея gs.thc.org, revsocks, обратные SSH-туннели, а также GOST, rsocx, cloudflared и localtonet. Закрепление выполняется через systemd и cron, а процессы маскируются под ядерные потоки Linux с помощью exec -a. Имплант может находиться в скрытой фазе годами, поэтому отсутствие текущих соединений с gs.thc.org не гарантирует, что узел не был скомпрометирован ранее.

Хронология {#timeline-disclosure-linux-ransomware-2026}

не позже 2023 года — публично атрибутирована активность группы Head Mare;
не позже января 2025 года — зафиксирована публичная активность группы Bearlyfy;
август 2025 года — закрыты уязвимости TrueConf Server BDU:2025-10114, BDU:2025-10115, BDU:2025-10116, которые использовались как одна из точек входа;
не позже марта-апреля 2026 года — Bearlyfy переходит на собственное семейство шифровальщиков GenieLocker;
в 2026 году — Bearlyfy и Head Mare наблюдаются с повышенной активностью и обмениваются инструментами и инфраструктурой;
23.06.2026 — опубликован бюллетень Yandex Cloud.

Затронутые технологии {#technologies-affected-linux-ransomware-2026}

Публично доступные интерфейсы прикладных служб: административные API, интерфейсы агентов автоматизации, серверы видеоконференций, уязвимые веб-приложения.
Linux-узлы прикладных сервисов, виртуализации и баз данных, на которых возможно локальное повышение привилегий после первичного доступа.
Средства скрытого управления и закрепления: gsocket, revsocks, обратные SSH-туннели, GOST, rsocx, cloudflared, localtonet, systemd, cron.
Средства воздействия: GenieLocker (hostd) и Babuk-вариант для Linux/ESXi.

Рекомендации по обнаружению уязвимости и дополнительные материалы {#recommendations-for-vulnerability-detection-linux-ransomware-2026}

Обратите внимание на следующие признаки компрометации:

соединения к gs.thc.org и поддоменам g.gs.thc.org, y.gs.thc.org, q.gs.thc.org, x.gs.thc.org, а также к узлам 360nvidia[.]com, 5.252.176[.]47, 45.156.27[.]115, 45.87.246[.]40;

defunct

hostd

revsocks

revsockslinux_amd64

fscan

.babyk

/tmp/locker.log

процессы с именами [nmpercpuwq], [kswapd0], [card0-crtc8], [slub_flushwq];
запуск полезной нагрузки из memfd, строки gsocket-engine.c, gsocket-ssl.c, GSOCKETINTERNAL, GS_connect в бинарных файлах, cron-задачи с base64-оберткой;
для TrueConf Server — строку the required argument for option '--Serial' is missing в логах.

Для поиска известных артефактов используйте готовые материалы:

YARA-правило Elastic для gsocket: <https://github.com/elastic/protections-artifacts/blob/main/yara/rules/MultiHacktoolGsocket.yar>;
репозиторий F6 DFIR с материалами по GenieLocker: <https://github.com/f6-dfir/Ransomware>.

Чтобы снизить риск атаки, примите следующие меры:

Изолируйте публичные интерфейсы прикладных служб. Административные API, СУБД, интерфейсы агентов автоматизации и серверы видеоконференций должны быть доступны только из выделенного сегмента, но не из интернета. Для фильтрации на уровне ВМ используйте Security Groups в Yandex Compute Cloud, для публичных веб-фронтов — Yandex Smart Web Security.

Сегментируйте сеть по уровням доверия. Отделите базы данных и хранилища резервных копий от прикладных сегментов, VPN-маршрутов и внешних точек входа. Используйте отдельные сети Yandex Virtual Private Cloud или подсети с собственными Security Groups, Yandex Cloud Interconnect для связности с корпоративной сетью и NAT Gateway для централизации исходящего трафика.

Отключите аутентификацию по паролю через SSH для служебных учетных записей. Для административного доступа используйте ключи, MFA и OS Login. Это привязывает SSH-доступ к учетным записям в Yandex Cloud, позволяет хранить ключи централизованно, исключает локальные ~/.ssh/authorized_keys как точку управления и передает события подключения в Yandex Audit Trails.

Перенесите резервные копии в иммутабельное хранилище. Используйте Yandex Object Storage с Object Lock поверх версионированного бакета в режиме Compliance или с постоянным Legal Hold. Режим Governance недостаточен, потому что скомпрометированная учетная запись с ролью storage.admin может снять такую защиту.

Применяйте принцип минимальных привилегий. Назначайте сервисным аккаунтам только необходимые IAM-роли, ограничивайте доступ конкретными бакетами и операциями, не используйте лишние статические ключи. Храните и ротируйте секреты в Yandex Lockbox.

Мониторьте исходящий трафик с прикладных узлов. Соединения к нестандартным портам и неизвестным внешним адресам рассматривайте как приоритетный сигнал. Храните журналы на максимальную доступную глубину: из-за скрытой фазы импланта ретроспективный поиск важнее текущего состояния. Используйте Yandex Cloud Logging для централизации журналов ВМ, Yandex Audit Trails для событий IAM и data plane, включая Flow- и DNS-логи, и Yandex Cloud Detection and Response для сетевой видимости.

Сканируйте уязвимости в образах и артефактах в Yandex Cloud Registry до публикации. Это позволяет сократить риск на стороне цепочки сборки.

Контролируйте целостность системных каталогов Linux-узлов: /etc/cron.d/, /var/spool/cron/, /lib/systemd/system/, ~/.ssh/, ~/.config/. Проверяйте подмену легитимных systemd-юнитов, cron-команды с pkill -0 и exec -a, маскировку процессов под ядерные потоки, учетные записи без следов создания и интерактивных входов, а также расхождение между mtime и Birth time на годы.

Сканируйте файловую систему и память YARA-правилами. Проверка памяти особенно важна, потому что gsocket может выполняться из memfd без файла на диске.

При обнаружении компрометации не перезагружайте и не выключайте узел до снятия снимков системного и пользовательских дисков, а по возможности и дампа памяти средствами Yandex Compute Cloud. Изолируйте узел через Security Groups без отключения сетевого интерфейса, обратитесь в техническую поддержку Yandex Cloud и выполните ротацию всех учетных данных, доступных скомпрометированному узлу. Заранее настроенные снапшоты по расписанию и Yandex Cloud Backup упрощают восстановление.

Используйте встроенные средства Yandex Cloud. Yandex Identity Hub и федерация удостоверений позволяют централизовать административный доступ с временем жизни сессии до шести часов. Yandex Security Deck помогает выявлять избыточные права, ошибки в конфигурации инфраструктуры, Kubernetes-кластеров и открытые секреты. Yandex Cloud Detection and Response помогает обнаруживать вредоносную сетевую активность и контролировать изменения в IAM, а также сохраняет аудит за пределами контура заказчика.

07.07.2026 — CVE-2026-53359 – Januscape {#CVE-2026-53359}

Документы 2