Контекст

У червні 2026 року в екосистемі Arch Linux AUR виявлено масштабну атаку на ланцюжок постачання, яку Sonatype назвала «Atomic Arch». Ця атака не пов’язана з нульовими дірами в офіційних репозиторіях Arch Linux, pacman, AUR helper чи самій 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 — це власна розробка SlowMist система виявлення загроз та динамічного моніторингу безпеки Web3, яка поєднує функції безпекового моніторингу та агрегації інформації, надаючи користувачам оперативне попередження про ризики та захист активів.

У цій події отруєння ланцюжка постачання Arch Linux AUR MistEye проаналізував та зв’язав етапи атаки, включаючи відповідні зловмисні пакунки, залежності npm, ELF-завантаження, зв’язок із C2 та завантаження другого етапу, а також вилучив відповідні IOC. На основі результатів аналізу MistEye надіслав клієнтам попередження про високий рівень ризику та інформацію про загрози, щоб допомогти клієнтам вчасно виявити та усунути відповідні ризики ланцюжка постачання. Деталі інформації:

Нижче наведено детальний технічний аналіз.

Аналіз ланцюжка атак: AUR install scriptlet до npm-скриптів життєвого циклу

Технічна схема цієї атаки може бути описана як триступенева послідовність: атакуючий спочатку захоплює пакунок 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 — це не звичайний сценарій встановлення залежностей, а ELF-виконуваний файл Linux x86-64 PIE з видаленими таблицями символів. Ключові метадані:

• Шлях до файлу: 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 hidden service 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 не з’являється у виводі звичайних рядків. Тому залежність лише від strings | grep .onion, відкритих текстових правил YARA або простих процесів вилучення IOC може не виявити цей прихований сервіс C2.

Tor/SOCKS канал зв’язку

Хоча C2 хост приховано за допомогою XOR-кодування, у ELF все ще видно відкриті рядки, пов’язані з SOCKS/Tor, наприклад:

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

Облікові дані та збір даних у середовищі розробки

Поверхня збирання облікових даних цього ELF охоплює кілька ключових місць зберігання облікових даних на сучасних робочих станціях розробників.

У контексті віддалених платформних облікових даних, завантаження містить рядки, пов’язані з перевіркою GitHub token та переліком репозиторіїв — GET /user, GET /user/repos, Authorization: Bearer, Accept: application/vnd.github+json; рядки перевірки npm token — 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 та Cookie і Local Storage браузерів сімейства Chromium. Рядки, пов’язані з Docker/Podman та інструментами DevOps — зокрема docker login, docker push, docker pull, docker build, docker run, docker tag, docker-compose, podman login, podman push — зустрічаються в ELF, але наразі вони є лише статичними рядковими підказками, повна ланцюжок збору даних ще не підтверджена. Claude: рядки також можуть слугувати підказками щодо AI-інструментів, але самі по собі не підтверджують збір даних 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-ланцюжком передачі утворюють підказки щодо staging-завантаження.

Підозрілий криптомайнер

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

Підтримка

У зразку присутні шаблони служби systemd, що охоплюють сценарії запуску на рівні користувача та системи. Це свідчить про намір завантаження зареєструвати себе як системну службу та продовжувати роботу після перезавантаження або запуску сеансу користувача.

eBPF приховування та протидія цифровій криміналістиці

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

ELF-навантаження atomic-lockfile@1.4.2 з src/hooks/deps залежить від libbpf.so.1 і через API bpf_object__open_mem, bpf_object__load, bpf_program__attach, bpf_map__pin намагається завантажити вбудований eBPF-об’єкт з можливістю перерозподілу. Ця логіка не виконується безумовно: зразок спочатку викликає 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 (точки підключення до подій ядра), щоб створити різноманітні сліди приховування та протидії цифровій криміналістиці. У його інформації про налагодження та символах зустрічаються назви hidden_pids, hidden_names, hidden_inodes, net_fds, diag_fds, getdents64, ptrace, recvmsg і bpf_probe_write_user, що свідчить про те, що його метою є приховування процесів, каталогів, сокетів/інодів, пов’язаних із мережевими з’єднаннями, а також перешкоджання приєднанню отладчика.

Зокрема, сліди функціональності цього eBPF-об’єкта можна поділити на три категорії:

1. Приховування процесів і елементів каталогу: hidden_pids використовується для зберігання PID, які потрібно приховати; логіка, пов’язана з sched_process_exec, під час виконання нової програми зіставляє імена процесів з hidden_names і додає відповідні PID до множини прихованих. Логіка, пов’язана з getdents64, обробляє результати читання каталогів, дозволяючи зловмисним зразкам приховувати вказані PID або елементи каталогу зі списків, таких як /proc.
2. Перешкоди переліку мережевих з’єднань: підказки, такі як recvmsg, socket, hidden_inodes, net_fds, diag_fds, вказують на перешкоди у результаті переліку мережевих з’єднань, що можуть впливати на інформацію про socket/inode, яку бачать інструменти, такі як ss, netstat.
3. Блокування налагодження та підміна результатів: ptrace, PTRACE_ATTACH, PTRACE_SEIZE та bpf_send_signal(9) свідчать про наявність анти-форензичних механізмів для блокування підключення отладчика; численні рядки 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. Атакуючий також налаштував у package.json вхід preinstall:

Основна відмінність від 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 також використовує repeating-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, менш очевидні, ніж у 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.

Доказ №2: байти спільного об’єкта eBPF повністю збігаються. SHA-256 вбудованих eBPF переносимих об’єктів у двох ELF-файлах повністю однакові:

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Розмір цього eBPF-об’єкта становить 52 776 байт, тип файлу — ELF 64-бітний LSB relocatable, з debug_info та не знятим символами, шлях до вихідного коду позначений як 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, а потім використовувати lifecycle preinstall npm для виконання Linux ELF-завантаження. Адреса C2 завантаження прихована за допомогою repeating-XOR, і простий strings/grep .onion не може безпосередньо витягнути її. Onion C2 краще розглядати як канал для передачі завдань, результатів та стану; завантаження також має здатність формувати multipart-запити на завантаження. Чи відповідає це службі temp.sh, чи завантаження успішно відправлено на конкретну жертву — потрібно підтверджувати динамічними даними або логами.

Комбінація завантажень охоплює багатоетапні атаки. 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 для приховування процесів, імен файлів та socket/inode, bpf_send_signal(9) для блокування ptrace-дебагу). 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

ім’я файлу: 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 та аналізу, запущеного штучним інтелектом SlowMist Agent. Будь ласка, зв’яжіться з нами з будь-якими питаннями або зворотним зв’язком.

Посилання для довідки

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