10 лет вы вводили пароль — и хакер на том конце читал его в реальном времени

В изолированную сеть без прямого выхода в интернет почти десять лет заходил один и тот же злоумышленник. Не через открытую дверь и не через случайный VPN, а по цепочке из взломанных внешних серверов, туннелей, подмененных SSH-компонентов и бэкдоров в самой системе входа. Sygnia описала атаку под названием Operation Highland и связала ее с группой Velvet Ant, которую компания относит к China-nexus акторам.

Расследование как разбор почти рядового инцидента, но первые следы активности увели специалистов в 2016 год. И сразу выяснилось, что это не мелкая свежая атака, а многолетнее присутствие внутри внутренней сети. Самый неприятный момент заключался в том, что целевой сегмент не имел прямого подключения к интернету. Изоляция не спасла: атакующие построили маршрут через внешние системы, затем прошли через IT-сеть и добрались до критической инфраструктуры.

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

На первом этапе группа получила устойчивый доступ к серверам, которые смотрели в интернет. Для удаленного выполнения команд использовалась модифицированная версия GS-Netcat, инструмента из Global Socket Toolkit. Такой инструмент умеет поднимать зашифрованную обратную оболочку и вести трафик через Global Socket Relay Network. В скомпрометированной среде файл назвали auditdb и положили в /usr/sbin/, чтобы он напоминал системную утилиту.

Внутри этого бинарного файла был зашит домен вида %.gs.thc[.]org, связанный с инфраструктурой The Hacker's Choice и, вероятно, с relay-сетью GS-Netcat. Чтобы не бросаться в глаза в списке процессов, программа подменяла собственный argv[0] на [khubd], маскируясь под поток ядра Linux. Для автозапуска применялись разные приемы: на новых серверах создавался systemd-unit, замаскированный под сервис Chrome, а на старых системах строку запуска добавляли в скрипты /etc/init.d/.

Параллельно Velvet Ant поставила SOCKS5-прокси на Perl. Он работал как фоновый демон, принимал подключения на заданном порту и пересылал трафик через уже взломанные машины. Sygnia определила, что скрипт был переработанной версией публичного проекта ssspl. Для маскировки процесс назывался smbd -D, будто принадлежал Samba. У разных образцов менялись имя файла, порт и название процесса, поэтому связать их между собой было сложнее.

После закрепления на внешних системах группа построила путь к закрытому сегменту. Один из входов шел через Nginx. На сервере, доступном из интернета, конфигурацию изменили так, чтобы запросы к определенному URL проксировались на внутренний сервер. Внутренний Nginx, в свою очередь, пересылал запросы в FastCGI-процесс fcgiwrap, который запускал файл с безобидным названием uptime.

Этот uptime не был обычной системной утилитой. Инструмент устанавливал SSH-соединение с сервером в сети критической инфраструктуры, используя параметры из HTTP POST-запроса. После подключения он запускал скрипт на целевом устройстве и позволял получать конфиденциальные данные. В итоге простой HTTP-запрос к внешнему веб-серверу превращался в удаленное выполнение команд внутри изолированного сегмента.

Главная часть атаки была глубже. Velvet Ant не ограничилась отдельными бэкдорами и туннелями. Группа подменила компоненты, через которые администраторы входят на Linux-серверы: PAM и OpenSSH. PAM отвечает за проверку учетных данных, а OpenSSH обеспечивает удаленный доступ, копирование файлов и запуск сессий. Если атакующий контролирует этот слой, обычная смена паролей уже не решает проблему: новые учетные данные можно снова перехватить при следующем входе.

Sygnia нашла девять вредоносных вариантов pam_unix.so. Легитимный PAM-модуль заменяли модифицированными библиотеками, где менялась функция pam_sm_authenticate. В нормальном режиме она получает логин и пароль, проверяет их и возвращает успех или отказ. В бэкдор-версии функция могла принимать зашитый пароль атакующего, собирать учетные данные реальных пользователей или совмещать оба механизма.

У части вариантов был только обход аутентификации: при вводе специального пароля модуль пропускал злоумышленника без стандартной проверки. После успешного обхода строка с бэкдор-паролем затиралась в памяти нулями, чтобы усложнить анализ. В другом варианте использовался зашифрованный пароль Pamauth@123456, а все чужие логины и пароли писались в скрытый файл /usr/sbin/.ssh.log. В некоторых случаях записи дополнительно очищались от дублей.

Девять вариантов pam_unix.so были собраны в разных средах. На это указывали отличающиеся RPATH, то есть пути, где загрузчик ищет нужные библиотеки во время выполнения. Sygnia такую картину рассматривает как признак продуманной сборки под разные цели, а не как случайный набор файлов.

OpenSSH тоже оказался под контролем атакующих. В новых вариантах были изменены ssh, sshd, ssh-keygen и scp, хотя вредоносные функции нашли в трех из них: ssh, sshd и scp. Модифицированные ssh и sshd перехватывали учетные данные при входящих и исходящих соединениях, шифровали их и сохраняли в /usr/share/man9/ph/.ph.man. В каждой записи фиксировались направление соединения, тип аутентификации и результат входа.

Кроме паролей, измененные бинарные файлы записывали команды, которые пользователь набирал в оболочке. sshd создавал зашифрованные логи с данными о пользователе, TTY, времени сессии и IP-адресе. ssh вел похожую запись для исходящих подключений. Для файлов в /usr/share/man9/ph/ применяли timestomping: временные метки подгонялись под дату /etc/shells, чтобы скрыть появление новых артефактов в хронологии файловой системы.

У атакующих была даже защита от собственной слежки. В модифицированный ssh добавили флаг -d, который отключал запись паролей и команд. Velvet Ant могла работать через зараженные инструменты и при этом не оставлять в них следов собственной активности. Это важная деталь: бэкдор был сделан не только для доступа, но и для аккуратной работы внутри уже взломанной среды.

scp получил отдельные функции. При запуске от root вредоносный scp мог отключать SELinux, чтобы снять ограничения обязательного контроля доступа и свободнее читать или передавать файлы. Еще один специальный флаг ! менял имя процесса на [kauditd] -sh, имитируя легитимный демон аудита Linux.

Sygnia также нашла старую ветку модифицированного OpenSSH. В ней менялись только ssh и sshd. Бэкдор в sshd работал через хэши: введенный пароль перехватывался, хэшировался и сравнивался с зашитым значением. Кроме общего хэша в бинарном файле были семь отдельных MD5-хэшей, по одному на каждый день недели. Логи учетных данных в старой версии писались в /usr/lib/eth-scsi/libethscsi.so, а команды - в /var/lib/sam/ с именами вида sam_{timestamp}. По этим файлам Sygnia и увидела самые ранние следы кейлогинга, уходящие к 2016 году.

Еще один слой доступа был проще: атакующие добавляли свои публичные SSH-ключи в authorized_keys на взломанных серверах. Конечно, это такой изощренный способ, как подмена PAM или OpenSSH, но дает устойчивый вход без пароля и работает независимо от вредоносных бинарных файлов.

Очистка сети оказалась рискованной. Когда заражен обычный сервис, его можно остановить, удалить и заменить. Когда подменены PAM и OpenSSH, неаккуратная замена может запереть администраторов снаружи. В критической инфраструктуре любая подобная ошибка превращает реагирование на инцидент в простой производства.

Ситуацию усложняла изоляция: у большинства систем не было доступа в интернет, поэтому нельзя было просто скачать чистые пакеты из репозиториев и подтянуть зависимости. В среде использовались разные версии Linux, разные библиотеки, разные сборки PAM и OpenSSH. Компонент, безопасный для одного хоста, мог сломать вход на другом.

Как проходило восстановление? Сначала подготовили лабораторию, где проверяли процесс замены. Затем для каждого хоста определяли подходящие чистые компоненты, переносили их в закрытую сеть контролируемым способом, выполняли замену и сразу проверяли SSH и аутентификацию. Планы отката готовили заранее, а проверку доступа считали частью восстановления, а не финальной формальностью.

Главный вывод Operation Highland неприятен для любых изолированных сетей. Отсутствие прямого выхода в интернет меняет маршрут атакующего, но не делает компрометацию невозможной. Velvet Ant прошла через внешние серверы, использовала прокси и веб-цепочку, а затем закрепилась в самом механизме входа. В такой ситуации журналы входа могут выглядеть нормально, команды вводятся через привычные инструменты, а атакующий движется как администратор.

Sygnia советует считать PAM, OpenSSH, LSASS и другие компоненты аутентификации критическими средствами безопасности, а не обычными системными файлами. Для Linux-серверов важно отслеживать изменения pam_unix.so, конфигураций /etc/pam.d/, ssh, sshd, scp, sftp, ssh-keygen, sshd_config, authorized_keys, systemd-unit-файлов и SysVinit-скриптов. Для Windows похожий подход нужен к LSASS и компонентам LSA, потому что атаки уровня Skeleton Key тоже вмешиваются в сам процесс проверки учетных данных.

Отдельный практический вывод касается смены паролей. Делать ее до удаления бэкдоров опасно: новые учетные данные могут сразу попасть в журналы подмененных PAM или SSH. Сначала нужно восстановить доверие к механизму входа, убрать вредоносные компоненты, проверить доступ и только потом менять пароли.