پژوهشگران امنیت سایبری مجموعه‌ای از پکیج‌های مخرب در اکوسیستم‌های npm، PyPI و RubyGems را شناسایی کرده‌اند که از Discord به‌عنوان کانال command-and-control (C2) یا مکانیزم خروج داده استفاده می‌کنند و اطلاعات سرقت‌شده را به وب هوک هایی که بازیگران تهدید کنترل می‌کنند می‌فرستند.
وب هوک‌های Discord این امکان را فراهم می‌کنند که بدون نیاز به ربات یا احراز هویت پیشرفته، پیام‌هایی به یک کانال ارسال شود؛ همین سادگی باعث شده مهاجمان از این سازوکار برای بیرون‌کشیدن داده‌ها به کانال‌های تحت کنترل خود بهره ببرند.
چگونه وب هوک‌ها کار می‌کنند و چرا خطرناک‌اند؟
طبق تحلیل محققان شرکت Socket، آدرس‌های webhook در واقع «write-only» هستند: دریافت‌کننده (attacker) می‌تواند به کانال پیام بفرستد اما کسی که آدرس را دارد به سابقهٔ پیام‌ها دسترسی نمی‌یابد. به‌عبارت دیگر، اگر مهاجمان یک webhook را فاش کنند، مدافعان نخواهند توانست با همان URL سابقهٔ پست‌ها را بخوانند تا رفتار مهاجم را بررسی کنند؛ این ویژگی، استفاده از وب هوک را به یک کانال بسیار جذاب برای exfiltration تبدیل می‌کند.
پکیج‌های کشف‌شده و رفتارهای مخرب‌شان
Socket چندین پکیج را شناسایی کرده که از وب هوک های Discord به شکل‌های مختلف سوءاستفاده می‌کنند:
mysql-dumpdiscord (npm): محتوای فایل‌های پیکربندی توسعه‌دهنده مانند
config.json،.env،ayarlar.jsوayarlar.jsonرا به یک Discord webhook می‌فرستد.nodejs.discord (npm): از وب هوک Discord برای ثبت (log) هشدارها استفاده می‌کند — این رفتار خود به خود بد نیست اما می‌تواند سوکاربرد شود.
malinssx, malicus, maliinn (PyPI): با هر بار
pip install <package>درخواست HTTP به یک کانال Discord ارسال می‌کنند و از آن به‌عنوان C2 بهره می‌گیرند.sqlcommenter_rails (RubyGems.org): اطلاعات میزبان را جمع‌آوری کرده و محتویاتی از فایل‌های حساس مانند
/etc/passwdو/etc/resolv.confرا به یک webhook هاردکد شده ارسال می‌کند.
چرا این روش اقتصادی و مؤثر است؟
اوِلیا براون (Olivia Brown) از Socket می‌گوید: «سوءاستفاده از Discord webhooks هزینهٔ میزبانی و نگهداری زیرساخت‌ها را حذف می‌کند و مهاجمان به‌راحتی می‌توانند از یک سرویس قانونی و پرکاربرد برای خروج داده استفاده کنند. همچنین این ترافیک اغلب شبیه به فعالیت‌های قانونی به‌نظر می‌رسد و ممکن است از فیلترهای شبکه و قوانین فایروال عبور کند.»
وقتی این مکانیزم با hookهای زمان نصب (install-time hooks) یا build scripts جفت شود، پکیج‌های مخرب می‌توانند قبل از اجرای اپلیکیشن روی ماشین توسعه‌دهنده یا CI runners فایل‌هایی مثل .env، API keyها و اطلاعات میزبان را جمع‌آوری و ارسال کنند — یعنی خیلی پیش از آنکه مانیتورینگ زمان اجرا متوجه شود.
موج دیگری از پکیج‌های مخرب: کمپین Contagious Interview
علاوه بر این، شرکت Socket مجموعه بزرگی (۳۳۸ پکیج) منتشرشده توسط بازیگران کره‌شمالی مرتبط با کمپینی به نام Contagious Interview را نیز شناسایی کرده است. این پکیج‌ها به‌جای پخش مستقیم یک stealer جاوااسکریپتی، از loaders رمزنگاری‌شده و خانواده‌های بدافزاری مثل HexEval, XORIndex و dropperهایی که BeaverTail را تحویل می‌دهند، استفاده کرده‌اند. مجموع دانلودهای این پکیج‌ها بیش از ۵۰,۰۰۰ بار گزارش شده است.
در این موج، بازیگران با ساخت بیش از ۱۸۰ شخصیت (persona) جعلی و ایمیل‌های ثبت‌نام جدید، توسعه‌دهندگان Web3 و بلاک‌چین و نیز جویندگان کار در پلتفرم‌هایی مانند LinkedIn را هدف قرار داده‌اند. قربانیان اغلب به‌خاطر دریافت «پیشنهاد شغلی» فریب می‌خورند و از آن‌ها خواسته می‌شود یک تکلیف کدنویسی را با clone کردن یک مخزن آلوده انجام دهند — مخزنی که به پکیج مخربی مثل eslint-detector ارجاع می‌دهد.
چه اتفاقی پس از اجرا می‌افتد؟
وقتی پکیج مخرب روی ماشین لوکال اجرا شود، معمولاً رفتارهای زیر رخ می‌دهد:
اجرای یک stealer (مثلاً BeaverTail) که داده‌های مرورگر، کیف‌پول رمزارزی، macOS Keychain، ورودی‌های کیبورد، محتوای clipboard و اسکرین‌شات‌ها را جمع‌آوری می‌کند.
دانلود payloadهای ثانویه مانند backdoor چندسکویی InvisibleFerret (Python).
بسیاری از پکیج‌های منتشرشده توسط بازیگران کره‌شمالی، نوعی typosquatting یا lookalike از کتابخانه‌های واقعی بوده‌اند (مثلاً dotevn به‌جای dotenv، یا ethrs.js به‌جای ethers.js) تا شانس نصب توسط توسعه‌دهنده را بالا ببرند.
ماهیت و سازماندهی کمپین‌ها
Kirill Boychenko، پژوهشگر امنیت، می‌گوید: «Contagious Interview شبیه یک خط تولید صنعتی است؛ این‌یک عملیات دولتی/متمرکز با منابع پایدار و اهداف کمّی است — نه یک گروه هکر آماتور که آخر هفته‌ای کار می‌کند. پاک کردن یک پکیج مخرب کافی نیست اگر حساب ناشر (publisher account) همچنان فعال بماند.»
این کمپین نشان می‌دهد که برخی بازیگران تهدید، اکوسیستم npm را به‌عنوان یک «کانال دسترسی اولیه» قابل تجدید و قابل تولید تلقی می‌کنند.
توصیه‌های امنیتی (عملی و فوری)
برای کاهش ریسک این نوع حملات توصیه می‌شود:
هرگز پکیج‌ها را بدون بررسی از منابع ناشناس نصب نکنید. به خصوص پکیج‌هایی با نام‌های عجیب یا آدرس‌های ثبت‌نام تازه.
در CI/CD از مراحل بررسی وابستگی‌ها و whitelisting استفاده کنید. اجازه ندهید پکیج‌های ناشناس به‌طور خودکار در pipeline نصب شوند.
اسکن مخازن و پکیج‌ها برای رفتارهای مشکوک — مخصوصاً install-time hooks و اسکریپت‌های build که ممکن است اطلاعات لوکال را بخوانند.
محدودیت دسترسی به فایل‌های حساس روی ماشین‌های توسعه و runners (مثلاً جلوگیری از دسترسی خودکار به
.env,~/.ssh, keychains).نظارت بر ترافیک خروجی و شناسایی تماس با Discord webhooks ناشناس یا دامنه‌هایی که معمولاً برای exfiltration استفاده می‌شوند.
آموزش کارکنان و استخدام‌کنندگان برای شناسایی تلهٔ «مصاحبهٔ کار» که مخاطب را ترغیب به clone کردن repoهای ناشناس کند.
حذف و گزارش پکیج‌های مخرب و غیرفعال‌سازی حساب‌های ناشر در صورت لزوم (همچنین همکاری با رجیستری‌ها برای حذف ماندگار).
جمع‌بندی
این مجموعه حملات بار دیگر نشان می‌دهد که زیرساخت‌های توسعه و انتشار پکیج (npm, PyPI, RubyGems) می‌توانند به‌راحتی به‌عنوان حامل و زیرساختِ مخرب مورد سوءاستفاده قرار گیرند — از stealerهای جاوااسکریپتی تا backdoorهای چندسکویی. ترکیب typosquatting، social engineering (مصاحبهٔ دروغین)، و استفاده از کانال‌های سریع و رایگانی مثل Discord webhooks، یک مدل تهدید مقرون‌به‌صرفه و مقیاس‌پذیر فراهم کرده که مدافعان باید با سیاست‌های دقیق، اسکن پیشرفته و فرهنگ امنیتی قوی مقابله کنند.
