В июне 2026 года экосистема Arch Linux AUR (Arch User Repository) подверглась масштабной атаке на цепочку поставок, получившей название Atomic Arch. Исследователи из Sonatype зафиксировали инцидент как серию заражений, затронувших порядка 1500 пакетов. Атака ориентирована прежде всего на разработчиков, работающих в Linux-окружении, а также на администраторов, использующих AUR для установки стороннего ПО. В отличие от традиционных угроз, здесь не использовались уязвимости нулевого дня в самом Arch Linux, менеджере пакетов pacman или AUR-хелперах. Вместо этого злоумышленники злоупотребили механизмом захвата orphan-пакетов - программ, которые долгое время не поддерживаются, но по-прежнему пользуются доверием пользователей.
Описание
Техническая реализация атаки представляет собой трёхуровневую цепочку. Первый уровень - это взлом AUR-пакетов через легитимную процедуру захвата orphan-проектов. Злоумышленник оформляет заявку на обслуживание пакета, получает права и изменяет его PKGBUILD или скрипты установки. В качестве примера аналитики приводят пакет "runescape-launcher" версии 2.2.12-1. В его ".SRCINFO" и "PKGBUILD" была добавлена ссылка на файл "install.sh", а также зависимость от npm. Файл "install.sh" содержал функцию "post_install()", вызываемую pacman как при установке, так и при обновлении пакета. Внутри этой функции злоумышленник разместил команду "npm install atomic-lockfile commander chalk". Таким образом, при стандартном выполнении "yay -S" или "paru -S" пользователь неявно запускал установку вредоносного npm-пакета.
Второй уровень цепочки - использование жизненного цикла npm. Пакет "atomic-lockfile@1.4.2", замаскированный под библиотеку для работы с файловыми блокировками, содержал в "package.json" скрипт "preinstall", который указывал на исполняемый файл "src/hooks/deps". Это не был обычный скрипт на JavaScript, а скомпилированный ELF-файл для архитектуры x86-64. После загрузки pacman вызывал "npm install", npm запускал "preinstall", и на системе выполнялся вредоносный бинарник размером около 3 МБ. Такой подход позволяет обойти многие средства защиты, ориентированные на анализ JavaScript.
Внутри "src/hooks/deps" обнаружены несколько ключевых возможностей. Во-первых, адрес командного сервера (C2) был скрыт с помощью повторяющегося XOR-кодирования. Вместо прямой подстроки ".onion" в образе содержался зашифрованный 62-байтовый блок, который после декодирования давал адрес Tor v3 hidden service: "olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion". Такой подход затрудняет обнаружение C2 простым поиском по строке "strings". Во-вторых, бинарник собирал широкий спектр данных о системе: токены GitHub, npm, SSH-ключи, учётные данные Docker и Podman, файлы cookie и Local Storage из браузеров на базе Chromium, а также историю команд оболочки (".bash_history", ".zsh_history"). Зафиксированы строки, связанные с платформами Discord, Slack, Teams и Vault. В-третьих, модуль пытался закрепиться в системе, используя systemd-шаблоны для пользовательских и системных служб. Наконец, наиболее примечательной возможностью является условное использование eBPF (extended Berkeley Packet Filter).
eBPF, обычно применяемый для сетевой фильтрации и наблюдения, здесь используется для сокрытия вредоносной активности. Бинарник проверяет, запущен ли он с правами root или обладает ли процесс capability "CAP_BPF" и "CAP_SYS_ADMIN". При выполнении этих условий он загружает встроенный eBPF-объект размером 52 776 байт. Этот объект, как показал статический анализ, содержит карты "hidden_pids", "hidden_names" и "hidden_inodes", а также точки трассировки для перехвата системных вызовов "getdents64", "ptrace" и "recvmsg". Его цель - скрыть процессы, файлы и сетевые соединения, связанные с вредоносной нагрузкой, а также заблокировать попытки отладки. Аналитики отмечают, что из-за статического подхода невозможно подтвердить фактическое срабатывание eBPF на конкретных машинах, но архитектура явно предусматривает такие действия.
Третий уровень атаки представлен вредоносным npm-пакетом "js-digest@4.2.2". Этот пакет имитирует библиотеку криптографических функций - в его состав входят файлы "aes.js", "sha256.js" и "index.js". Однако в "package.json" прописан скрипт "preinstall", выполняющий "./lib/install-deps.mjs". Файл с расширением ".mjs" ассоциируется с модулями ECMAScript, что может ввести в заблуждение при автоматической проверке. На самом деле это ещё один ELF-бинарник почти того же размера, что и в "atomic-lockfile". Его C2 и встроенный eBPF-объект совпадают с предыдущим образцом. Различаются только внутреннее имя агента ("cryjs" вместо "atomic") и версия (0.8.4 вместо 0.8.2).
Предоставленный анализ MistEye позволил восстановить всю картину атаки. Два независимых вредоносных пакета имеют два неоспоримых доказательства общего происхождения: один и тот же onion-адрес C2 и идентичный eBPF-объект с одинаковым хешем SHA-256. Это указывает на единую команду разработчиков или общего заказчика, который создал несколько вариантов нагрузки для разных этапов атаки.
Последствия для организаций, использующих AUR, серьёзны. Даже если пакет был установлен месяцы назад и его обслуживание захватили недавно, пользователь может получить вредоносное обновление при очередном выполнении "yay -Syu". Возможный ущерб включает утечку токенов доступа к коду и инфраструктуре, компрометацию конвейеров CI/CD, а также долговременное присутствие с помощью eBPF, которое трудно обнаружить стандартными средствами.
Тенденция, которую демонстрирует атака Atomic Arch, - это смещение фокуса злоумышленников с уязвимостей в коде на эксплуатацию процессов и доверия в открытых экосистемах. Нарушители не используют ни одной ошибки программирования; они полагаются на то, что разработчики не проверяют содержимое "install.sh" в давно известных пакетах, а менеджеры пакетов выполняют скрипты из установленных модулей без дополнительной проверки. Для снижения риска пользователям AUR рекомендуется перед установкой любого недавно захваченного или долго не обновлявшегося пакета изучать PKGBUILD и ".install"-файлы на предмет вызовов "npm install", "bun install", "curl" или "wget". Системным администраторам следует проверять наличие необычных systemd-сервисов и BPF-карт с именами hidden_pids и hidden_inodes. В случае обнаружения заражения требуется немедленная смена всех скомпрометированных токенов и восстановление окружений из чистых образов.
Индикаторы компрометации
Onion Domains
- olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion
SHA256
- 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f
- 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
- 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
- 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc
- 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
Malicious dependency
- atomic-lockfile@1.4.2
- js-digest@4.2.2
- lockfile-js@1.4.2
- nextfile-js@1.4.2
