Исследователи Trend Micro описали ранее недокументированный Linux-имплант под кодовым названием Quasar Linux RAT (QLNX), который, по их данным, нацелен на системы разработчиков и DevOps-инженеров с целью кражи учётных данных, обеспечивающих доступ к реестрам пакетов, облачной инфраструктуре и конвейерам CI/CD. Как сообщается, вредоносное ПО выполняется бесфайлово из памяти, использует двухуровневую архитектуру руткита и поддерживает 58 различных команд, предоставляющих оператору полный контроль над скомпрометированным хостом. Угроза затрагивает Linux-системы, используемые в процессах разработки и эксплуатации программного обеспечения.

Целенаправленный сбор секретов разработчиков

Ключевая особенность QLNX, выделяющая его среди прочих Linux-троянов удалённого доступа, — это специализированный модуль сбора учётных данных, ориентированный именно на экосистему разработки. По данным исследователей Aliakbar Zahravi и Ahmed Mohamed Ibrahim, модуль извлекает секреты из следующих файлов и конфигураций:

• .npmrc — токены NPM
• .pypirc — учётные данные PyPI
• .git-credentials — данные доступа к Git-репозиториям
• .aws/credentials — ключи доступа AWS
• .kube/config — конфигурация Kubernetes
• .docker/config.json — учётные данные Docker
• .vault-token — токены HashiCorp Vault
• Учётные данные Terraform, токены GitHub CLI и файлы .env

Компрометация этих активов, по оценке Trend Micro, потенциально позволяет злоумышленнику публиковать вредоносные пакеты в реестрах NPM или PyPI, получать доступ к облачной инфраструктуре или перемещаться через конвейеры CI/CD. Это создаёт риск каскадных атак на цепочку поставок программного обеспечения: единственный скомпрометированный мейнтейнер пакета может стать точкой входа для массового распространения вредоносного кода.

Механизмы скрытности и закрепления

QLNX, как сообщается, демонстрирует продвинутый набор техник уклонения от обнаружения. Имплант выполняется бесфайлово из оперативной памяти и маскируется под легитимные потоки ядра — например, kworker или ksoftirqd, — что затрудняет его обнаружение стандартными средствами мониторинга процессов.

Для закрепления в системе предположительно используются не менее семи различных методов, включая:

• Юниты systemd
• Задания crontab
• Инъекции в .bashrc

Имплант также профилирует хост для обнаружения контейнеризованных сред и очищает системные журналы для сокрытия следов своей активности.

Двухуровневая архитектура руткита

Особого внимания заслуживает двухуровневая архитектура сокрытия. На уровне пользовательского пространства QLNX, по данным исследователей, использует механизм LD_PRELOAD динамического компоновщика Linux для перехвата системных вызовов и сокрытия артефактов и процессов импланта. На уровне ядра задействован компонент на основе eBPF, который по команде с управляющего сервера скрывает процессы, файлы и сетевые порты от стандартных утилит — ps, ls, netstat.

Комбинация руткитов пользовательского пространства и ядра значительно усложняет обнаружение: даже если один уровень сокрытия будет нейтрализован, второй продолжает маскировать присутствие импланта.

Перехват аутентификации через PAM

QLNX, как сообщается, включает бэкдор на основе Pluggable Authentication Module (PAM), который перехватывает учётные данные в открытом виде во время событий аутентификации, регистрирует данные исходящих SSH-сессий и передаёт собранную информацию на управляющий сервер. Дополнительно описан второй модуль сбора учётных данных на базе PAM, который автоматически загружается в каждый динамически скомпонованный процесс для извлечения имени службы, имени пользователя и токена аутентификации.

Командно-контрольная инфраструктура и возможности

После закрепления имплант входит в основную операционную фазу, непрерывно пытаясь установить и поддерживать связь с C2-сервером по протоколам raw TCP, HTTPS и HTTP. Набор из 58 поддерживаемых команд, по данным исследователей, включает:

• Выполнение произвольных команд оболочки
• Управление файлами и инъекция кода в процессы
• Снятие снимков экрана и перехват нажатий клавиш
• Установка SOCKS-прокси и TCP-туннелей
• Запуск Beacon Object Files (BOF)
• Управление одноранговой (P2P) mesh-сетью

Точный механизм первоначальной доставки QLNX на момент публикации исследования остаётся неизвестным.

Оценка воздействия

Наибольшему риску подвержены организации, в которых разработчики работают на Linux-системах и хранят на них секреты доступа к инфраструктуре — токены пакетных реестров, ключи облачных провайдеров, конфигурации оркестрации контейнеров. Компрометация одного рабочего места разработчика может привести к публикации отравленных пакетов, несанкционированному доступу к продуктивной облачной инфраструктуре и латеральному перемещению через CI/CD-конвейеры.

Важная оговорка: на момент публикации не предоставлены индикаторы компрометации (хеши, IP-адреса, домены), подтверждённые случаи реальных атак или отравления пакетов. Оценка масштаба угрозы основана на анализе возможностей импланта, а не на задокументированных инцидентах.

Рекомендации по защите

1. Аудит хранения секретов: убедитесь, что токены NPM, PyPI, AWS, Docker, Kubernetes и другие секреты не хранятся в открытом виде в домашних каталогах. Используйте менеджеры секретов и краткосрочные токены.
2. Мониторинг LD_PRELOAD: проверяйте переменную окружения LD_PRELOAD и файл /etc/ld.so.preload на наличие неожиданных записей.
3. Контроль eBPF-программ: используйте bpftool для инвентаризации загруженных BPF-программ и выявления аномальных модулей.
4. Проверка PAM-конфигурации: регулярно проверяйте файлы в /etc/pam.d/ и загруженные PAM-модули на предмет несанкционированных изменений.
5. Мониторинг маскировки процессов: обращайте внимание на процессы с именами kworker или ksoftirqd, которые не соответствуют ожидаемым потокам ядра.
6. Проверка механизмов персистентности: проведите аудит юнитов systemd, заданий crontab и файлов .bashrc на предмет подозрительных записей.
7. Ротация секретов: при подозрении на компрометацию немедленно ротируйте все токены и ключи доступа, хранившиеся на затронутой системе.

Описанный имплант QLNX демонстрирует тенденцию к созданию вредоносного ПО, специализированного именно на инфраструктуре разработки. Приоритетное действие для команд безопасности — провести инвентаризацию секретов, хранящихся на рабочих станциях разработчиков в открытом виде, и перенести их в централизованные хранилища секретов с поддержкой краткосрочных токенов и аудита доступа.