باتنت Glassworm که توسعهدهندگان را در حملات زنجیره تأمین نرمافزار هدف قرار میداد، پس از از کار افتادن زیرساخت فرماندهی و کنترل (C2) مختل شد. باتنت Glassworm پیشتر از یک معماری مقاوم و چندلایه برای حفظ ارتباط با سیستمهای آلوده استفاده میکرد که شناسایی و از کار انداختن آن را دشوار میساخت.
در یک عملیات هماهنگ، شرکت CrowdStrike، گوگل و بنیاد Shadowserver چهار کانال مجزای C2 این شبکه را از دسترس خارج کردند؛ کانالهایی که بهطور خاص برای مقاومت در برابر اختلال طراحی شده بودند.
سابقه این کمپین در حملات زنجیره تأمین نرمافزار
کمپینهای باتنت Glassworm از اکتبر 2025 آغاز شدند و توسعهدهندگان را از طریق افزونههای مخرب منتشرشده در OpenVSX و Microsoft VS Code هدف قرار دادند. این افزونهها با هدف سرقت کیف پولهای رمزارزی و اعتبارنامههای کاربران طراحی شده بودند.
در ادامه، دامنه فعالیت این گروه به مخازن GitHub و پکیجهای npm نیز گسترش یافت؛ بهطوریکه در یکی از کمپینهای شناساییشده در ماه مارس، بیش از 400 آرتیفکت نرمافزاری تحت تأثیر قرار گرفت.
در یکی از جدیدترین حملات، اپراتورهای Glassworm دهها افزونه را در OpenVSX منتشر کردند که در زمان انتشار هیچ عملکرد مخربی از خود نشان نمیدادند، اما بهگونهای طراحی شده بودند که پس از دریافت بهروزرسانی، کامپوننت مخرب آنها فعال شود. این رویکرد نشان میدهد Glassworm با تمرکز مستقیم بر ابزارها، مخازن و کانالهای مورد استفاده توسعهدهندگان، به یکی از تهدیدات جدی علیه زنجیره تأمین نرمافزار (Software Supply Chain) تبدیل شده است.
معماری مقاوم زیرساخت C2 در باتنت Glassworm
یکی از دلایل دوام باتنت Glassworm، تکیه آن بر زیرساخت فرماندهی و کنترل با کانالهای ارتباطی غیرمعمول و مقاوم در برابر اختلال بود. این ساختار از ترکیب بلاکچین، شبکههای همتابههمتا (P2P) و سرویسهای قانونی وب بهعنوان لایههای شناسایی آدرسهای C2 استفاده میکرد.
در این معماری، سرورهای اصلی پشت چندین لایه پنهانسازی قرار داشتند و همین موضوع امکان شناسایی و از کار انداختن مستقیم آنها را دشوار میکرد.
کانالهای ارتباطی کلیدی C2
پژوهشگران اعلام کردند برای مختلسازی باتنت Glassworm، هر چهار کانال زیر باید بهصورت همزمان هدف قرار میگرفتند:
- بلاکچین Solana: آدرسهای سرورهای C2 در فیلد memo تراکنشهای Solana کدگذاری شده بودند و بهعنوان یک مخزن پنهان داده (Dead Drop) عمومی و تغییرناپذیر عمل میکردند.
- شبکه BitTorrent DHT: بدافزار GlasswormRAT از شبکه BitTorrent DHT برای دریافت دادههای پیکربندی خود استفاده میکرد. این دادهها بر اساس کلیدهای عمومی هاردکدشده منتشر شده بودند و هیچ نقطه ضعف واحدی نداشتند.
- سرویس Google Calendar: در این روش، باتنت Glassworm از عنوان رویدادهای Google Calendar بهعنوان مخزن پنهان داده استفاده میکرد. مسیرهای C2 بهصورت Base64 رمزگذاری شده بودند و از آنها برای بازیابی ارتباطات بعدی استفاده میشد.
- اتصال مستقیم به سرورهای VPS: در مرحله نهایی، زیرساخت سنتی C2 روی سرورهای VPS در ارائهدهندگان تجاری مستقر بود و برای ارسال کدهای مخرب (Payload) استفاده میشد.
پیامدهای اختلال در باتنت Glassworm
به گفته CrowdStrike، هر چهار کانال باید بهصورت همزمان از دسترس خارج میشدند تا باتنت Glassworm کاملاً مختل شود. پس از این عملیات، سیستمهای آلوده همچنان به یک آدرس IP مشخص که توسط CrowdStrike مدیریت میشود، درخواستهای ارتباطی (Beacon) ارسال میکنند.
سازمانها باید این شاخص شبکهای را در لاگهای خود بررسی کرده و در صورت مشاهده هرگونه ارتباط، فوراً فرآیند پاکسازی و پاسخ به رخداد (Remediation) را آغاز کنند. همچنین پژوهشگران قوانین YARA را برای شناسایی و تأیید آلودگی در میزبانهای مشکوک منتشر کردهاند.
این رخداد نشان میدهد حتی پس از قطع زیرساخت فرماندهی و کنترل، همچنان نیاز به شناسایی میزبانهای آلوده و پاکسازی کامل محیط وجود دارد.