Контекст

В июне 2026 года в экосистеме Arch Linux AUR была выявлена масштабная атака с отравлением цепочки поставок, которую Sonatype назвала «Atomic Arch». Эта атака не связана с уязвимостями нулевого дня в официальных репозиториях Arch Linux, pacman, AUR-хелперах или самой Arch Linux, а представляет собой злоупотребление механизмом захвата заброшенных пакетов AUR: злоумышленники легально захватывали пакеты, долгое время не поддерживаемые разработчиками, но по-прежнему вызывающие доверие у пользователей, и изменяли их PKGBUILD или установочные скрипты.

При выполнении пользователем обычных операций установки или обновления AUR вредоносный сценарий вызывает npm или Bun для установки JavaScript-пакетов, контролируемых злоумышленником, и с помощью жизненного цикла npm выполняет Linux ELF-полезную нагрузку. Эта нагрузка в основном нацелена на рабочие станции и среды сборки Linux и обладает способностью к краже чувствительной информации, такой как данные GitHub, npm, SSH, Docker/Podman, Vault, браузера и истории командной оболочки.

На этапе публичного раскрытия количество затронутых пакетов AUR увеличилось с первоначальных более 400 до примерно 1 500. Это событие демонстрирует, что компоненты с открытым исходным кодом, которые больше не поддерживаются, но продолжают пользоваться доверием, становятся новым типом точки входа для атак, используемой злоумышленниками для объединения сценариев, хуков жизненного цикла менеджеров пакетов и локальных сред разработчиков.

Настоящий текст основан на результатах статического анализа MistEye для `runescape-launcher`, `atomic-lockfile@1.4.2` и `js-digest@4.2.2`, и охватывает ключевые технические этапы цепочки атаки. Указанные образцы не являются полным набором атакующих файлов, а служат для выявления паттернов атаки.

MistEye ответ

MistEye — это веб-3-система угроз и динамического мониторинга безопасности, разработанная SlowMist, которая объединяет возможности мониторинга безопасности и агрегации интеллекта, предоставляя пользователям реальное предупреждение о рисках и защиту активов.

В ходе анализа инцидента отравления цепочки поставок Arch Linux AUR MistEye провела анализ и корреляционное исследование связанных вредоносных пакетов, зависимостей npm, ELF-полезных нагрузок, коммуникаций C2 и вторичных загрузчиков, извлекая соответствующие IOC. На основе результатов анализа MistEye направила клиентам предупреждения о высоком риске и уведомления о угрозах, помогая клиентам своевременно выявлять и устранять связанные риски цепочки поставок. Подробности разведывательных данных:

Ниже приведен подробный технический анализ.

Анализ цепочки атак: AUR install scriptlet до npm lifecycle script

Техническая суть этой атаки может быть описана как три последовательных этапа: атакующие захватили пакет AUR и модифицировали сценарии сборки/установки, чтобы при установке или обновлении через pacman запускался npm install для загрузки вредоносного пакета, а затем с помощью сценариев жизненного цикла npm (preinstall) автоматически выполнялся встроенный в пакет нативный Linux ELF-загрузчик. Ниже подробно описан каждый из трех этапов.

В качестве примера возьмем пакет runescape-launcher (версия 2.2.12-1). Злоумышленник добавил ссылку на install.sh в файлы .SRCINFO и PKGBUILD, а также объявил npm как зависимость выполнения.

Ключевые заявления в файле .SRCINFO:

Соответствующее объявление в PKGBUILD:

install.sh — это файл скрипта установки pacman. Злоумышленник определил функцию post_install() в этом файле и указал post_upgrade() на ту же функцию:

Ключевая исполнительная цепочка:

.SRCINFO заявляет, что install = install.sh и depends = npm

→ PKGBUILD синхронизирует объявление install="install.sh" и depends=('npm' ...)

→ makepkg включает install.sh в финальный pacman-пакет

→ при первой установке pacman вызывает post_install()

→ при обновлении pacman вызывается post_upgrade()

→ post_upgrade() вызывает post_install()

→ post_install() переходит в /tmp

→ Выполните npm install atomic-lockfile commander chalk → npm установил atomic-lockfile@1.4.2

→ Запустить preinstall для atomic-lockfile

→ Выполнить Linux x86-64 ELF-полезную нагрузку src/hooks/deps

Следует обратить внимание на несколько моментов: commander и chalk — это легитимные и популярные пакеты на npm, они не обязательно являются вредоносными; в том же post_install() присутствует существующая/сопутствующая логика setcap, а вредоносное добавление заключается в cd /tmp и npm install atomic-lockfile commander chalk.

Основная цель дизайна этого слоя — использовать цикл установки/обновления пакетов pacman в качестве трамплина, чтобы передать управление от системного менеджера пакетов npm, причем это срабатывает как при первой установке, так и при обновлении.

atomic-lockfile@1.4.2 — это первый подтвержденный вредоносный npm-пакет, использовавшийся в первой волне атаки. Этот пакет выглядит как библиотека для блокировки файлов, сохраняя полную структуру TypeScript/JavaScript-библиотеки, входные точки main/module/exports, CLI и типы. Однако злоумышленники настроили в package.json скрипт scripts.preinstall для автоматического выполнения нативного двоичного файла во время установки:

src/hooks/deps — это не обычный скрипт установки зависимостей, а Linux x86-64 PIE ELF-исполняемый файл без символической таблицы. Ключевые метаданные:

• Путь к файлу: src/hooks/deps
• Тип файла: ELF 64-битный LSB pie исполняемый файл, x86-64, динамически связанный, обрезанный
• ELF SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
• Размер: 3 040 376 байт
• Зависимости: libbpf.so.1, libm.so.6, libc.so.6
• Встроенный SHA-256 объекта eBPF: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• Смещение встроенного объекта eBPF: 0x324f9
• Исходный SHA-256 tarball: 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

Возможности этого ELF-полезного груза включают сбор учетных данных, постоянство, передачу и загрузку через каналы связи, а также попытку включения компонента eBPF-скрытности при наличии прав root или соответствующих возможностей. Ниже подробно описано каждое из них.

Повторное XOR-декодирование и Tor скрытые сервисы C2

В ELF-полезной нагрузке atomic-lockfile@1.4.2 ключевой C2 не представлен в виде открытых строк, а сохранен с использованием repeating-XOR. Образец содержит 32-байтовый ключ по смещению 0x1aa60 и 62-байтовый шифротекст по смещению 0x2da96. Декодирование осуществляется следующим образом:

plain[i] = cipher[i] ^ key[i % 32]

После декодирования получается адрес скрытой службы Tor v3:

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

Длина 62 байта точно соответствует 56 символам Tor v3 onion-имени хоста плюс суффикс .onion. Помимо C2-хоста, образ также использует аналогичный подход для кодирования идентификатора и версии агента:

• Имя агента: atomic, смещение ключа 0x1bc60, смещение шифра 0x3fddf
• Версия агента: 0.8.2, смещение ключа 0x1c900, смещение шифра 0x3fde5

Этот дизайн обеспечивает отсутствие полного C2 в обычных выходных данных строк. Следовательно, такой скрытый сервис C2 может не быть обнаружен только с помощью strings | grep .onion, текстовых правил YARA или простых процедур извлечения IOC.

Tor/SOCKS-канал связи

Хотя C2 хост скрыт с помощью XOR-кодирования, в ELF всё ещё видны открытые строки, связанные с SOCKS/Tor, например:

Эти строки в сочетании с декодированным адресом .onion указывают, что данный payload содержит встроенный коммуникационный фреймворк для доступа к скрытому сервису C2 через SOCKS/Tor.

В то же время в ELF присутствуют строки, связанные с формированием и загрузкой HTTP-запросов, включая POST, GET, HTTP/1.0, HTTP/1.1, Host:, Content-Length:, Content-Type: application/json, Content-Type: application/octet-stream, POST /upload HTTP/1.1 и Content-Type: multipart/form-data. Наличие шаблонов POST /upload и multipart указывает на возможность загрузки payload, однако соответствие этому сервису temp.sh и фактическая передача данных за пределы системы требуют подтверждения с помощью динамического трафика, логов прокси или данных компьютерной криминалистики хоста.

Credentials and development environment collection surface

Этот ELF охватывает несколько ключевых точек хранения учетных данных на современных рабочих станциях разработчиков.

В контексте удаленных учетных данных нагрузка содержит строки, связанные с проверкой токена GitHub и перечислением репозиториев: GET /user, GET /user/repos, Authorization: Bearer, Accept: application/vnd.github+json; строки проверки токена npm: GET /-/whoami, registry.npmjs.org, _authToken=; а также строки, связанные с учетными данными Vault: /.vault-token, X-Vault-Token:

В области инструментов мгновенного обмена сообщениями и сотрудничества строки, связанные с Slack, содержат пути API auth.test, conversations.list, users.info и SQL-запросы к Cookie для %.slack.com; в отношении Teams/Skype присутствуют X-Skypetoken:, authsvc.teams.microsoft.com и запросы к Cookie для %teams.microsoft.com; также встречаются строки, связанные с Discord, такие как discord:.

В контексте локальных и контейнерных сред, нагрузка фокусируется на файлах SSH-учетных данных, таких как .ssh, known_hosts, PRIVATE KEY, PuTTY-User-Key-File, а также на путях к файлам .bash_history, .zsh_history, .env и куки/локальному хранилищу браузеров семейства Chromium. Строки, связанные с Docker/Podman и инструментами DevOps — включая docker login, docker push, docker pull, docker build, docker run, docker tag, docker-compose, podman login, podman push — присутствуют в ELF, однако на данный момент они служат лишь статическими строковыми подсказками, полная цепочка сбора данных еще не подтверждена. Claude: аналогичные строки могут служить подсказками, связанными с инструментами ИИ, но сами по себе не доказывают сбор данных Claude.

Загрузка и скачивание на втором этапе

Полезная нагрузка содержит шаблон HTTP-загрузки multipart, а также пути временного хранения данных, такие как /var/tmp и /secrets. Образ обладает способностью осуществлять обмен задачами и результатами через onion C2, а также формировать запросы multipart-загрузки; соответствие службе temp.sh, успешная загрузка или передача данных на конкретной заражённой хост-машине требуют подтверждения путём динамического выполнения, анализа прокси-логов или экспертизы хоста. Цепочка загрузки второго этапа оставляет чёткие статические следы: пути /bin/sha256/ и строка "sha256 fetch:" указывают на путь проверки хеша второго этапа; сообщения "server returned empty binary" и "tmp 200 headers too large" свидетельствуют о наличии логики обработки ошибок при неудачной загрузке второго этапа. Следы извлечения Tor bundle в виде /tor-expert-bundle- в сочетании с цепочкой передачи через SOCKS формируют подсказки для стадии загрузки.

Подозрительные признаки криптомайнеров

В ELF-файле atomic-lockfile обнаружена строка /usr/bin/monero-wallet-gui. В сочетании со второй фазой цепочки загрузки предполагается, что нагрузка может загружать двоичные файлы, связанные с майнингом Monero. В текущем образе не подтверждены сильные признаки майнеров, такие как xmrig, randomx, stratum, домены пулов или адреса кошельков, поэтому нельзя утверждать наличие встроенного майнера.

Постоянное хранение

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

eBPF скрытие и анти-фоrensикс

eBPF (расширенный фильтр пакетов Berkeley) — это механизм, предоставляемый ядром Linux, который позволяет пользователям загружать и выполнять в ядре ограниченные пользовательские программы без изменения исходного кода ядра. В обычных условиях eBPF используется для фильтрации сети, наблюдаемости и мониторинга безопасности, но компонент eBPF в данном образце разработан как инструмент обратного направления — не для того, чтобы «видеть» систему, а для того, чтобы «спрятать» себя.

ELF-полезная нагрузка atomic-lockfile@1.4.2 из src/hooks/deps зависит от libbpf.so.1 и пытается загрузить встроенный переносимый объект eBPF с помощью API, таких как bpf_object__open_mem, bpf_object__load, bpf_program__attach и bpf_map__pin. Эта логика не выполняется безусловно: образ сначала вызывает geteuid() для проверки, является ли пользователь root, затем считывает /proc/self/status, анализирует поле CapEff: и проверяет биты возможностей, соответствующие CAP_BPF и CAP_SYS_ADMIN. Точнее говоря, образ переходит к попытке загрузки eBPF только при выполнении условий прав доступа. То есть это скорее условный скрытый модуль; текущие статические доказательства не показывают, что он самостоятельно выполняет повышение привилегий.

Дизассемблирование показывает, что хостовая программа считывает встроенный объект длиной 0xce28 по смещению 0x324f9, то есть eBPF-объект размером 52 776 байт. SHA-256 этого объекта:

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Извлеченный объект eBPF является отдельным компилированным продуктом, тип файла — ELF 64-bit LSB relocatable, с информацией отладки / BTF и не очищенный. В его отладочной информации также утечка путей исходного кода:

/cloud/scales/agent/../ebpf/scales.bpf.c

Этот объект eBPF сочетает BPF maps (таблицы данных для хранения состояния) и tracepoints (точки подключения к событиям ядра), чтобы создать множество следов скрытности и анти-фоrensics. В отладочной информации и символах встречаются имена hidden_pids, hidden_names, hidden_inodes, net_fds, diag_fds, getdents64, ptrace, recvmsg и bpf_probe_write_user, что указывает на цели дизайна: скрытие процессов, скрытие записей каталогов, скрытие сокетов/inode, связанных с сетевыми соединениями, а также вмешательство в присоединение отладчиков.

Подробно рассматривая этот объект eBPF, его функциональные следы можно разделить на три категории:

1. Скрытие процессов и записей каталогов: hidden_pids используется для хранения PID, которые необходимо скрыть; логика, связанная с sched_process_exec, при выполнении новой программы сопоставляет имя процесса с hidden_names и добавляет совпадающие PID в набор скрытых элементов. Логика, связанная с getdents64, обрабатывает результаты чтения каталогов, позволяя вредоносным образам скрывать указанные PID или записи каталогов из списков каталогов, таких как /proc.
2. Интерференция с перечислением сетевых соединений: подсказки, такие как recvmsg, socket, hidden_inodes, net_fds, diag_fds, указывают на вмешательство в результаты перечисления сетевых соединений, что может повлиять на информацию о сокетах/inode, видимую такими инструментами, как ss и netstat.
3. Блокировка отладки и подмены возвращаемых результатов: ptrace, PTRACE_ATTACH, PTRACE_SEIZE и bpf_send_signal(9) указывают на анти-фоrensик-дизайн, препятствующий присоединению отладчика; множество строк bpf_probe_write_user свидетельствуют о реализации модификации пользовательских буферов чтения, что является ключевым способом скрытия записей каталогов и сетевых элементов.

Поскольку данный анализ был статическим и образец не выполнялся динамически, невозможно подтвердить успешность фактической загрузки данного eBPF-объекта на конкретном хосте, а также утверждать, что он действительно скрыл процессы, записи каталогов или сетевые соединения. Однако на основе логики проверки прав, структуры map, покрытия tracepoint и следов использования bpf_probe_write_user можно заключить, что его цель — скрывать следы процессов, записей каталогов и сетевых соединений (socket/inode) при наличии прав root или соответствующих возможностей ядра, а также создавать препятствия для динамического анализа.

js-digest@4.2.2 — это подтвержденный вредоносный npm-пакет, использовавшийся в последующей волне атаки. Этот пакет маскируется под библиотеку инструментов для JavaScript-хеширования/шифрования и содержит внешние файлы исходного кода, такие как aes.js, sha256.js, hmac-sha512.js, index.js. Атакующие также настроили вход preinstall в package.json:

Основное отличие от atomic-lockfile заключается в стратегии именования полезной нагрузки. Расширение .mjs в файле install-deps.mjs намекает, что это модуль ESM JavaScript, что может снизить бдительность у людей, проводящих аудит, и у правил обнаружения на основе расширений. Однако статическая идентификация типа файла показывает, что это на самом деле Linux x86-64 PIE ELF. Ключевые метаданные:

• Путь к файлу: lib/install-deps.mjs
• Суффикс указывает: ESM JavaScript-модуль
• Фактический тип файла: ELF 64-битный LSB pie исполняемый файл, x86-64, динамически связанный, обрезанный
• ELF SHA-256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
• Размер: 3 193 176 байт
• Зависимости: libbpf.so.1, libm.so.6, libc.so.6
• Встроенный SHA-256 объекта eBPF: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• Смещение встроенного объекта eBPF: 0x37d91
• Исходный SHA-256 tarball: 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

js-digest также использует повторяющийся XOR для скрытия C2. 32-байтный ключ встроен по смещению 0x1cba0, 62-байтный шифртекст хранится по смещению 0x32bcb; результат декодирования полностью совпадает с atomic-lockfile:

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

Его идентификатор агента и версия:

• Имя агента: cryjs (смещение ключа 0x1d740, смещение шифра 0x45ec2)
• Версия агента: 0.8.4 (смещение ключа 0x1ec40, смещение шифра 0x45ec7)

Имена агентов (atomic против cryjs) и версии (0.8.2 против 0.8.4) различаются, но используют один и тот же onion-адрес C2 и один и тот же встроенный объект eBPF.

js-digest в отношении строк, связанных с сбором учетных данных, SOCKS/Tor-цепочек передачи, шаблонов multipart-загрузки, шаблонов постоянного хранения systemd и фрагментов двухэтапной загрузки (/bin/sha256/, sha256 fetch:) имеет высокую степень сходства с atomic-lockfile. Связи, связанные с Docker/Podman и @reboot, у js-digest менее очевидны, чем у atomic-lockfile, а путь /usr/bin/monero-wallet-gui в js-digest не подтвержден.

Суффикс .mjs, используемый в качестве маскировки, является методом обхода, заслуживающим внимания в рамках этой атаки: он использует слепые зоны дифференциального обнаружения — правила сопоставления по строкам и именам файлов могут классифицировать файлы .mjs как «JavaScript-модули» в белом списке, не проверяя их реальный MIME-тип или ELF-заголовок.

Связанный образец: двойные конкретные доказательства общего onion C2 и eBPF объекта

Между двумя злонамеренными пакетами npm atomic-lockfile@1.4.2 и js-digest@4.2.2 существуют два независимо подтверждаемых явных доказательства:

Улика №1: Общий Tor-скрытый сервис C2. Два ELF-загрузчика, хотя и имеют разные хосты, разные имена агентов (atomic vs cryjs), разные версии (0.8.2 vs 0.8.4), а также используют разные ключи и шифрованные данные repeating-XOR, после декодирования указывают на один и тот же Tor-скрытый сервис: olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion. Невозможно, чтобы два независимо разработанных вредоносных фреймворка случайно выбрали один и тот же 56-символьный v3 onion-адрес в качестве C2.

Второе конкретное доказательство: байты разделяемого объекта eBPF полностью совпадают. SHA-256 встроенных в каждый ELF переносимых объектов eBPF идентичны:

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Размер этого объекта eBPF составляет 52 776 байт, тип файла — ELF 64-битный LSB relocatable, с debug_info и не stripped, путь к исходному коду указан как scales.bpf.c. Ключевые maps (hidden_pids, hidden_names, hidden_inodes), tracepoints (getdents64, sched_process_exec, ptrace, openat, recvmsg и др.) и основные функции (walk_dirent, name_to_pid, bpf_probe_write_user) полностью совпадают в обоих образцах. Объект eBPF является результатом компиляции; полное байт-точное совпадение означает, что оба ELF были собраны из одной и той же исходной кодовой базы eBPF C.

Помимо вышеуказанных прямых доказательств, два ELF-нагрузки также демонстрируют высокую степень схожести в дизайне с точки зрения инженерных возможностей, таких как строки, связанные с сбором учетных данных, архитектура передачи SOCKS/Tor, шаблоны multipart-загрузки и строки шаблонов持久изации systemd. Эти совпадения являются дополнительными наблюдениями, дополнительно подтверждающими вывод о едином происхождении обоих образцов.

Ключевые различия между двумя образцами следующие: хеши ELF хоста различаются, имя и версия агента различаются (atomic / 0.8.2 против cryjs / 0.8.4), стратегия именования нагрузки различается (src/hooks/deps против маскировки .mjs), /usr/bin/monero-wallet-gui встречается только в atomic-lockfile, а ExecStart=@reboot также статически попадает только в atomic-lockfile. Эти различия указывают на то, что два образца тесно связаны с одной и той же инфраструктурой операций, одной и той же цепочкой сборки или одним и тем же кластером активности, а не являются простым повторным упаковыванием.

Сводка

Атака на цепочку поставок Arch Linux AUR в этот раз демонстрирует комбинированное использование двух структурных слабостей в экосистеме открытого программного обеспечения: во-первых, механизм передачи заброшенных пакетов AUR не включает проверку доверия к новым владельцам; во-вторых, исполняемые сценарии жизненного цикла менеджеров пакетов (pacman и npm) имеют соединенные границы доверия на этапе установки — злоумышленник не использует никаких уязвимостей в программном обеспечении, а лишь злоупотребляет механизмами поддержки экосистемы открытого исходного кода и проектированием менеджеров пакетов для построения полной цепочки атаки.

Технические особенности данной цепочки атак можно кратко охарактеризовать на трех уровнях:

AUR злоупотребляет наследованием доверия. Вместо создания новых пакетов или эксплуатации уязвимостей программного обеспечения злоумышленники захватывают не поддерживаемые пакеты AUR, чтобы наследовать существующую базу пользователей. Например, в случае runescape-launcher злоумышленник, воспользовавшись легитимным процессом захвата пакета в AUR, вставил команду npm install atomic-lockfile в файл install.sh и вызвал post_install() через post_upgrade(), чтобы она срабатывала и при обновлении. Пользователи, выполняющие обычные команды yay -S или paru -S, не ожидают, что PKGBUILD и скрипты .install были изменены.

Двухуровневая цепочка жизненного цикла и скрытие C2. Злоумышленник использует scriptlet post_install()/post_upgrade() пакета pacman в качестве точки входа, чтобы при установке/обновлении пакета AUR запускать npm install, а затем использовать жизненный цикл preinstall npm для выполнения Linux ELF-полезной нагрузки. Адрес C2 полезной нагрузки скрыт с помощью repeating-XOR-кодирования, и простые команды strings/grep .onion не позволяют напрямую извлечь его. Onion C2 лучше рассматривать как канал для передачи задач, результатов и состояния; полезная нагрузка также обладает способностью формировать multipart-запросы на загрузку. Соответствует ли это службе temp.sh и успешно ли загружена полезная нагрузка на конкретную жертву, необходимо подтверждать динамическими данными или логами.

Пayload-комбинация охватывает многоэтапные атаки. ELF-пейлоид обеспечивает статические возможности сбора учетных данных (GitHub/npm/Slack/Discord/Teams/Vault/SSH/браузеры, а также подсказки DevOps-строк, такие как Docker/Podman), каналы связи и загрузка с использованием шаблонов (onion C2 + шаблон multipart upload), шаблоны персистентности (systemd user/system service с совместимостью WantedBy=multi-user.target и WantedBy=default.target), а также условное обходное поведение (при наличии соответствующих прав — попытка включения eBPF для скрытия процессов, имен файлов и сокетов/inode, блокировка отладки ptrace с помощью bpf_send_signal(9)). js-digest дополнительно внедряет маскировку с помощью суффикса .mjs, что дополнительно снижает эффективность обнаружения на основе расширений.

Рекомендация:

1. Немедленно проверьте установленные пакеты AUR на наличие PKGBUILD или .install-скриптов, содержащих команды npm install atomic-lockfile, bun install js-digest или аналогичные команды извлечения через npm/Bun. При обнаружении уязвимых пакетов немедленно проведите цифровую экспертизу и смену учетных данных в изолированной среде.
2. Проверьте наличие аномальных systemd-сервисов/таймеров в ~/.config/systemd/user и /etc/systemd/system, а также наличие аномальных BPF-карт, таких как hidden_pids, hidden_names, hidden_inodes, в /sys/fs/bpf/.
3. Для затронутых разработческих хостов смените GitHub PAT/GITHUB_TOKEN, токены npm, сессии Slack/Discord/Teams, токены Vault, SSH-приватные ключи, учетные данные Docker/Podman и все ключи, хранящиеся в .env.
4. Среда CI/CD должна перестраиваться на основе доверенного базового образа, а не просто очищаться от node_modules или удалением отдельных вредоносных пакетов.
5. Рекомендуется пользователям AUR перед установкой любых недавно заявленных или долго необновляемых пакетов построчно проверять PKGBUILD и скрипты .install на наличие вызовов внешних команд, таких как npm install, bun install, curl, wget.

IOC

Домен

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion

Злоупотребление зависимостью

npm:atomic-lockfile@1.4.2

npm:js-digest@4.2.2

npm:nextfile-js@1.4.2

npm:lockfile-js@1.4.2

Вредоносный файл

имя файла: src/hooks/deps SHA256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

filename: lib/install-deps.mjs SHA256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

имя файла: atomic-lockfile-1.4.2.tar.gz SHA256: 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

имя файла: js-digest-4.2.2.tar.gz SHA256: 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

имя файла: встроенный объект eBPF SHA256: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Эта статья подготовлена командой угроз SlowMist на основе системы разведки угроз MistEye и анализа, основанного на AI SlowMist Agent. Если у вас есть вопросы, пожалуйста, свяжитесь с нами.

Ссылка для справки

1. https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency