- 27,609
- 46
- 8 Ноя 2022
Рассказываем подробности о хакерской кибероперации Operation Highland.
В изолированную сеть без прямого выхода в интернет почти десять лет заходил один и тот же злоумышленник. Не через открытую дверь и не через случайный <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>, а по цепочке из взломанных внешних серверов, туннелей, подмененных 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. Компонент, безопасный для одного хоста, мог сломать вход на другом.
Sygnia описывает восстановление как отдельную инженерную операцию. Сначала подготовили лабораторию, где проверяли процесс замены. Затем для каждого хоста определяли подходящие чистые компоненты, переносили их в закрытую сеть контролируемым способом, выполняли замену и сразу проверяли 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. Сначала нужно восстановить доверие к механизму входа, убрать вредоносные компоненты, проверить доступ и только потом менять пароли.
Operation Highland показывает, почему одних сигнатур и ожидания тревог мало против терпеливого атакующего. Velvet Ant не обязательно приносит в сеть ярко выраженный вредоносный файл. Группа меняет компоненты, которые и так стоят почти на каждом Linux-сервере, а после подмены продолжают выполнять привычные функции. Без проверки целостности, охоты за аномалиями и регулярного контроля аутентификационного слоя такой доступ может жить годами.
В изолированную сеть без прямого выхода в интернет почти десять лет заходил один и тот же злоумышленник. Не через открытую дверь и не через случайный <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>, а по цепочке из взломанных внешних серверов, туннелей, подмененных 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. Компонент, безопасный для одного хоста, мог сломать вход на другом.
Sygnia описывает восстановление как отдельную инженерную операцию. Сначала подготовили лабораторию, где проверяли процесс замены. Затем для каждого хоста определяли подходящие чистые компоненты, переносили их в закрытую сеть контролируемым способом, выполняли замену и сразу проверяли 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. Сначала нужно восстановить доверие к механизму входа, убрать вредоносные компоненты, проверить доступ и только потом менять пароли.
Operation Highland показывает, почему одних сигнатур и ожидания тревог мало против терпеливого атакующего. Velvet Ant не обязательно приносит в сеть ярко выраженный вредоносный файл. Группа меняет компоненты, которые и так стоят почти на каждом Linux-сервере, а после подмены продолжают выполнять привычные функции. Без проверки целостности, охоты за аномалиями и регулярного контроля аутентификационного слоя такой доступ может жить годами.
- Источник новости
- www.securitylab.ru
