Дослідники 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 демонструє тенденцію до створення зловмисного ПЗ, спеціалізованого саме на інфраструктурі розробки. Пріоритетна дія для команд безпеки — провести інвентаризацію секретів, що зберігаються у відкритому вигляді на робочих станціях розробників, і перенести їх до централізованих сховищ секретів із підтримкою короткострокових токенів та аудиту доступу.