Quasar Linux RAT крадёт ключи разработчиков в Linux

Исследователи Trend Micro описали ранее неизвестный Linux-имплант Quasar Linux RAT, или QLNX. Он нацелен на компьютеры разработчиков и DevOps-инженеров: крадёт токены, ключи доступа и конфиги, которые открывают путь к репозиториям, облакам и конвейерам сборки ПО.

Главная опасность не в одном украденном пароле. Если злоумышленник получает доступ к учётной записи сопровождающего пакета, он может выпустить заражённую версию библиотеки, а её затем установят другие команды и компании.

Что нашли исследователи

Trend Micro называет QLNX имплантом для долгой скрытой работы в Linux-среде. Вредонос запускается из памяти, старается не оставлять файлов на диске и маскирует себя под системные процессы Linux, например под потоки ядра с привычными именами вроде kworker.

После закрепления QLNX поддерживает связь с командным сервером по нескольким каналам. Исследователи насчитали 58 команд: от управления файлами и запуска командной оболочки до снимков экрана, записи нажатий клавиш и наблюдения за буфером обмена.

Для обычного пользователя это звучит как проблема «для айтишников». На деле атаки на разработчиков часто бьют по всем: заражённый пакет может попасть в приложение банка, интернет-магазина, корпоративного сервиса или мобильного продукта.

Какие секреты интересуют QLNX

QLNX ищет не только пароли в привычном смысле. Его цель — рабочие секреты, которые разработчики используют каждый день: токены npm и PyPI, данные Git, ключи AWS, конфиги Kubernetes, Docker и Vault, файлы Terraform, токены GitHub CLI и переменные из .env.

Такие файлы часто лежат рядом с кодом и нужны для сборки, публикации пакетов, доступа к тестовым стендам и облачной инфраструктуре. Даже если разработчик зашёл на рабочую машину всего на пару минут — например, чтобы проверить сборку или найти пример sql distinct on для запроса, — сохранённый токен может оказаться ценнее его личного пароля.

Если атакующий крадёт ключ публикации npm или PyPI, он получает шанс выпустить вредоносное обновление от имени настоящего сопровождающего. Если утекает облачный ключ, под удар попадают серверы, базы данных и резервные копии.

Похожий риск уже проявлялся в атаках через поддельные проекты и инструменты. Мы разбирали такой сценарий в материале о том, как фальшивый репозиторий OpenAI на Hugging Face раздавал стилер.

Почему вредонос трудно заметить

QLNX рассчитан на скрытность. Он проверяет среду, пытается понять, запущен ли внутри контейнера, стирает системные журналы и закрепляется сразу несколькими способами. Среди них — systemd, crontab и внедрение команд в .bashrc.

Отдельный слой маскировки связан с руткитами. Руткит — это набор компонентов, которые прячут процессы, файлы или сетевые соединения от стандартных инструментов администратора. В QLNX исследователи описали две линии защиты: на уровне пользовательского пространства через LD_PRELOAD и на уровне ядра через eBPF.

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

Именно такая связка делает заражение опасным. Антивирус или администратор может не увидеть подозрительный файл, потому что его уже нет на диске. Системные команды могут не показать процесс, потому что руткит его прячет.

Как QLNX перехватывает учётные данные

Один из самых тревожных компонентов QLNX связан с PAM — Pluggable Authentication Module, подключаемым модулем аутентификации Linux. Через PAM проходят входы в систему и проверки учётных данных в разных сервисах.

Имплант использует PAM-хук, чтобы перехватывать данные во время входа. По описанию Trend Micro, он может фиксировать учётные данные в открытом виде, записывать сведения об исходящих SSH-сеансах и отправлять их на сервер атакующих.

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

Схожая логика риска видна и в уязвимостях, где наружу попадают API-ключи. Подробнее о таком классе проблем мы писали в статье об утечке ключей API и переписок через Ollama.

Чем это грозит цепочке поставки ПО

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

Для бизнеса это один из самых неприятных сценариев. Нужно проверить не только заражённый компьютер, но и все пакеты, релизы, ключи публикации, CI/CD-конвейеры, облачные роли и журналы доступа. Если компания быстро не отзовёт токены, атакующий может вернуться через уже украденные учётные данные.

Trend Micro не уточняет, как QLNX попадает на компьютеры жертв. Это важная деталь: защитникам пока приходится исходить из широкого набора версий — вредоносные вложения, поддельные инструменты для разработки, заражённые пакеты, скомпрометированные серверы или украденные пароли.

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

Что сделать сейчас

• Проверьте, хранятся ли токены npm, PyPI, Git, AWS, Kubernetes, Docker, Vault и Terraform на рабочих машинах в открытом виде.
• Перенесите секреты из .env и локальных конфигов в защищённое хранилище секретов с журналом доступа.
• Включите многофакторную защиту для репозиториев, облачных кабинетов и систем публикации пакетов.
• Ограничьте срок жизни токенов и права доступа: ключ для сборки не должен управлять всей облачной инфраструктурой.
• Настройте мониторинг странных публикаций пакетов, новых релизов, изменений CI/CD и входов с незнакомых устройств.
• После подозрения на заражение не ограничивайтесь удалением вредоноса: отзовите токены, смените ключи, проверьте релизы и журналы.
• Обновляйте Linux-системы, инструменты разработки и защитное ПО; отдельно следите за необычными процессами, заданиями cron и изменениями systemd.
• Разделяйте личную и рабочую среду: меньше лишних пакетов, расширений и скриптов на машине, где лежат ключи к продакшену.