Десять лет внутри: как китайская APT-группа жила в Linux через бэкдор в PAM и OpenSSH

Когда команда Sygnia начала анализировать компрометацию, которую позже назовут Operation Highland, самые ранние артефакты датировались 2016 годом. Перед ними было не свежее вторжение — а почти десять лет незамеченного присутствия внутри изолированной сети критической инфраструктуры. Группа Velvet Ant — китайский APT-актор, которого Sygnia отслеживает с нескольких инцидентов — не взломала систему через уязвимость и не оставила очевидных следов. Она изменила те самые программы, которые решают, кому разрешён вход.

Velvet Ant подменила легитимные модули PAM и бинарники OpenSSH на бэкдорированные копии. Не новое вредоносное ПО, которое могут поймать сканеры — а модификация доверенных системных компонентов, которым операционная система верит по умолчанию. Пароли сбрасывались — бэкдор оставался. Сессии завершались — группа возвращалась. Обычные меры реагирования на инциденты не работали, потому что сам механизм аутентификации работал на атакующего.

Это не первый раз, когда Velvet Ant демонстрирует подобную тактику. В 2024 году Sygnia зафиксировала ту же группу, злоупотреблявшую F5 BIG-IP-устройствами для сохранения персистентности. Затем — эксплуатацию CVE-2024-20399 в Cisco NX-OS для установки бэкдора прямо на коммутаторы Nexus. Каждый раз, когда обнаруживался один плацдарм, группа уходила глубже — в менее контролируемую инфраструктуру. Operation Highland — следующий шаг: глубже некуда, это уже сам стек аутентификации.

ЧТО ТАКОЕ PAM И ПОЧЕМУ ЭТО КРИТИЧНО

PAM (Pluggable Authentication Modules) — это подсистема Linux, через которую проходит аутентификация практически каждого сервиса: SSH-логин, sudo, su, локальная консоль. Когда вы вводите пароль на Linux-сервере, именно PAM его проверяет. Ключевой модуль — pam_unix.so — отвечает за стандартную проверку пароля по /etc/shadow.

OpenSSH — стандартный SSH-стек, присутствующий на каждом Linux-сервере: sshd как серверный демон, ssh как клиент, scp для передачи файлов. Оба компонента — PAM и OpenSSH — являются фундаментом удалённого администрирования. Если атакующий контролирует их, он контролирует всё: кто может войти, что видит при входе, какие команды выполняются. И всё это без единой строчки в штатных логах.

Важный контекст: подмена pam_unix.so и бинарников OpenSSH требует root-прав на целевом хосте. Это не техника первоначального проникновения — это техника закрепления после того, как root уже получен. Именно поэтому Velvet Ant тратила силы на первые два этапа: получить initial access, добраться до изолированного сегмента, получить root — и только тогда менять файлы аутентификации. Для защиты это означает: контроль над тем, кто и когда получает root, критичен не меньше, чем мониторинг после факта.

РЕАЛЬНАЯ ЦЕПОЧКА АТАКИ

Целевая сеть не имела прямого доступа в интернет — атакующим пришлось прокладывать путь поэтапно. На первом этапе Velvet Ant закрепились на интернет-facing серверах. Там был развёрнут модифицированный GS-Netcat — инструмент из публичного набора Global Socket Toolkit. Бинарник назвали auditdb и положили в /usr/sbin/ — среди легитимных системных утилит. Чтобы скрыться в списках процессов, инструмент перезаписывал собственный argv[0] строкой [khubd], имитируя легитимный поток ядра. Персистентность обеспечивалась через systemd unit-файл на современных системах или через вставку строки в скрипты /etc/init.d/ на старых — в обоих случаях замаскировано под Chrome-сервис.

Параллельно развернули SOCKS5-прокси на Perl — кастомную реализацию публичного проекта ssspl — для туннелирования трафика и бокового перемещения. Процесс маскировался под smbd -D. Каждый образец использовал уникальное имя файла, имя процесса и порт прослушивания — чтобы затруднить корреляцию между скомпрометированными хостами.

На втором этапе группа прошла через IT-сеть в изолированный сегмент критической инфраструктуры. Для этого использовали компрометированный nginx-сервер: его конфигурацию модифицировали так, чтобы входящие запросы к определённому URL проксировались на backend, где FastCGI-обёртка (fcgiwrap) запускала кастомный бинарник uptime. Тот устанавливал SSH-соединение с сервером во внутреннем изолированном сегменте и выполнял там скрипты — на основании параметров из HTTP POST. Прямого соединения с изолированной сетью не требовалось: команды уходили через простые HTTP-запросы.

На третьем — и главном — этапе атакующие захватили стек аутентификации. На скомпрометированных хостах pam_unix.so был заменён бэкдорированной копией. Sygnia обнаружила девять различных вариантов — каждый скомпилирован в отдельном build-окружении, что указывает на хорошо организованный производственный конвейер. Два основных варианта: первый принимал захардкоженный бэкдор-пароль и полностью обходил стандартную проверку (пароль после использования немедленно перезаписывался в памяти нулями, чтобы не светиться в дампе); второй дополнительно записывал реальные логины и пароли всех пользователей в скрытый файл /usr/sbin/.ssh.log. Во втором варианте бэкдор-пароль хранился в бинарнике в зашифрованном виде.

Бинарники OpenSSH — ssh, sshd, scp, а в части случаев и ssh-keygen — также были подменены. Модифицированный sshd перехватывал и сохранял учётные данные всех входящих соединений в зашифрованном файле /usr/share/man9/ph/.ph.man. Каждая запись содержала направление соединения, тип аутентификации и успешность. Модифицированный ssh и sshd также вели кейлоггинг каждой команды в сессии. sshd писал файлы в /usr/share/man9/ph/ с именами вида s{MD5(username+TTY)}, ssh — с именами вида c{MD5(UID+SSH_TTY)}. Все созданные файлы и директории проходили timestomping — их временны́е метки подменялись под время создания /etc/shells. Модифицированный scp при запуске от root мог отключить SELinux. Флаг ! в scp маскировал процесс под [kauditd] -sh.

Отдельная деталь, показывающая уровень операционной дисциплины: в модифицированном ssh был добавлен кастомный флаг -d, который отключал собственное логирование кредов и кейлоггинг. Когда операторы Velvet Ant сами работали через бэкдорированный бинарник — они активировали этот флаг, чтобы не оставлять следов своей активности. Третий слой персистентности — добавление собственных SSH-ключей в authorized_keys на скомпрометированных хостах: независимый доступ без паролей.

ХРОНОЛОГИЯ

Самые ранние артефакты кейлоггинга в этой среде датируются 2016 годом. Они обнаружены в старом варианте модифицированного OpenSSH: тот писал логи в /var/lib/sam/ с именами вида sam_{timestamp} — менее изощрённо, чем более поздние варианты, и именно это позволило Sygnia установить дату первого появления группы. Присутствие продолжалось как минимум до момента расследования — около десяти лет в одной среде.

Sygnia отслеживает Velvet Ant через несколько независимых расследований разных жертв. В 2024 году группа была поймана на злоупотреблении F5 BIG-IP-устройствами для поддержания персистентности внутри другой организации. В том же году — на эксплуатации CVE-2024-20399, zero-day в Cisco NX-OS, для установки бэкдора VELVETSHELL прямо на коммутаторы Nexus. В обоих случаях Sygnia публиковала подробные writeup’ы с IOC.

Паттерн стабильный: при обнаружении Velvet Ant не уходит — она переходит на инфраструктуру, которую защитники контролируют хуже. Сетевые appliance под управлением проприетарных OS мониторятся слабее, чем Windows-серверы. Linux-коммутаторы — слабее, чем appliance. Стек аутентификации самих Linux-хостов — слабее всего остального. Operation Highland опубликован Sygnia 11 июня 2026 года.

ПОЧЕМУ ЭТО ВАЖНО

Обычная модель реагирования на инцидент предполагает: сброс паролей, завершение сессий, изоляция хоста. Ни одна из этих мер не работает, когда скомпрометирован сам механизм аутентификации. Сброс пароля бесполезен, если pam_unix.so принимает бэкдор-пароль независимо от содержимого /etc/shadow. Завершение сессий бесполезно, если новые credentials перехватываются при следующем входе легитимного администратора. EDR, IDS и SIEM не видят ничего аномального — входы выглядят как обычная административная активность.

Для сисадмина, управляющего продакшн-сервером с SSH-доступом, это прямое указание на слепое пятно: если злоумышленник имел доступ к /lib/security/pam_unix.so или к бинарникам OpenSSH — обычная проверка логов ничего не покажет. Этот класс атак, который Sygnia называет «authentication-layer persistence», требует отдельной стратегии обнаружения: не анализ логов, а контроль целостности самих исполняемых файлов.

Паттерн Velvet Ant последовательен: каждый раз, когда один плацдарм обнаруживается, группа уже готовила следующий, глубже. Operation Highland — это точка, после которой атакующие контролировали не конкретный сервис, а способность аутентифицироваться на всех серверах среды.

КАК ПРЕДОТВРАТИТЬ ЭТО НА ВАШЕМ СЕРВЕРЕ

Ключевой инструмент защиты от этого класса атак — File Integrity Monitoring на бинарники аутентификации. Не конфиги, не логи — именно исполняемые файлы. AIDE, auditd с watch на запись, или любое FIM-решение должны покрывать: pam_unix.so и другие модули в /lib/security/ и /lib/x86_64-linux-gnu/security/, конфигурации в /etc/pam.d/, бинарники ssh, sshd, scp, sftp, ssh-keygen, файл sshd_config, authorized_keys привилегированных пользователей, unit-файлы systemd и startup-скрипты. Любое изменение этих файлов — алерт, который требует ответа, а не просто записи в лог.

Быструю проверку целостности уже установленных пакетов даёт dpkg --verify. На Debian/Ubuntu команда сравнивает контрольные суммы файлов с метаданными пакета — пустой вывод значит, что файлы не изменены, строка с префиксом ??5?????? говорит о несовпадении суммы:

dpkg --verify openssh-server openssh-client libpam-modules

Этот тест быстрый, но не абсолютный: атакующий с root-доступом может подправить и базу dpkg. Более надёжный вариант — сравнить SHA256-хэши файлов напрямую с эталоном из чистого образа той же версии дистрибутива. Для бинарника sshd это выглядит так: скачиваете пакет с официального зеркала на отдельной чистой машине, распаковываете и сравниваете хэш с файлом на проверяемом сервере. Совпадение — OK. Расхождение при совпадающей версии пакета — красный флаг.

Снизить риск первоначального получения root помогают базовые меры, которые одновременно усложняют и эту технику: прямой root-логин через SSH должен быть отключён (PermitRootLogin no в sshd_config), весь административный доступ — через именованные аккаунты с минимальными правами sudo. MFA до того, как запрос попадает на хост, а не внутри него — иначе скомпрометированный PAM его просто проигнорирует.

Если компрометация уже произошла — порядок восстановления принципиален. Сброс паролей до замены pam_unix.so бессмысленен: новые пароли будут перехвачены модифицированным модулем в момент следующего входа легитимного администратора. Последовательность: сначала верифицировать и заменить бинарники аутентификации, затем зачистить authorized_keys, и только потом ротировать credentials. Sygnia особо отмечает: замену PAM-модулей и SSH-бинарников нужно предварительно тестировать на идентичной конфигурации в изолированной лаборатории — несовместимая версия или отсутствующая зависимость могут заблокировать SSH-доступ к живому продакшн-серверу.

ЧТО ДЕЛАТЬ ПРЯМО СЕЙЧАС

Если у вас есть основания подозревать компрометацию — или вы просто хотите убедиться в чистоте системы — проверьте наличие подозрительных файлов по путям, которые использовала Velvet Ant. Команда ищет файлы в директориях, характерных для данной кампании:

ls -la /usr/sbin/.ssh.log 2>/dev/null
ls -la /usr/share/man9/ph/ 2>/dev/null
ls -la /usr/lib/eth-scsi/ 2>/dev/null
ls -la /var/lib/sam/ 2>/dev/null

Если какая-либо из этих директорий или файлов существует — это прямой IOC кампании. Отдельно проверьте authorized_keys для root и других привилегированных аккаунтов: Velvet Ant добавляла собственные публичные ключи как третий слой персистентности. Для root:

cat /root/.ssh/authorized_keys

Для остальных пользователей с оболочкой — проверьте ~/.ssh/authorized_keys в их домашних директориях. Любой ключ, которого нет в вашем реестре доверенных ключей — потенциальный IOC.

Полный список индикаторов компрометации (IOC) по Operation Highland опубликован Sygnia в приложении к отчёту. Если ваша среда попадает под описанный профиль — критическая инфраструктура, изолированная сеть, Linux-серверы с долгим uptime без регулярного audit бинарников — проверка целостности PAM и OpenSSH должна быть в приоритете.

ВЫВОДЫ

Operation Highland — демонстрация того, куда движется продвинутая persistent-атака при правильной тактике defenders: каждый обнаруженный плацдарм вынуждал Velvet Ant идти глубже, пока группа не добралась до уровня, который большинство Blue Team не проверяет никогда. PAM и OpenSSH — не «просто пакеты». Это механизм, который решает, кто является тем, за кого себя выдаёт. Его компрометация делает бессмысленными MFA, сложные пароли и аудит логов одновременно.

Практический вывод для сисадмина: FIM на бинарники аутентификации — не параноя, а минимальная гигиена для любого сервера, на котором работают долгосрочные административные процессы. Для организаций с критической инфраструктурой или изолированными сетями: доверие к компоненту только потому, что он системный — это именно та модель угрозы, которую эксплуатирует Velvet Ant уже почти десятилетие.