از تاریخ ۱۰ نوامبر، یک عامل تهدید (Threat Actor) با استفاده از اعتبارنامه‌های سرقت‌شده GitHub، یک Payload مخرب را در قالب جریان‌های کاری (Workflow) به ده‌ها هزار مخزن (Repository) تزریق کرده است. این حمله با هدف سرقت کلیدهای امنیتی (Secrets) مربوط به GitHub Actions و اعتبارنامه‌های سرویس‌های ابری (Cloud Credentials) انجام می‌شود.
جزئیات حمله و دامنه اثرگذاری
تحقیقات نشان می‌دهد که این حمله از طریق Pull Requestهای مشکوک آغاز می‌شود که در ابتدا تنها یک مرحله بررسی (Probe) هستند، اما بلافاصله با Commitهایی که حاوی Payload اصلی هستند، دنبال می‌شوند. اگر یک کاربر در مرحله بررسی (Probe) مورد هدف قرار گیرد، حتی اگر مرحله Workflow اجرا نشود، حساب کاربری وی نیز در معرض خطر قرار دارد.
تاکنون شواهدی از اجرای این بدافزار در حداقل ۱۸۰۶ مخزن شناسایی شده است، هرچند این رقم احتمالاً کمتر از میزان واقعی آسیب است. مهاجمان با حذف لاگ‌های اجرا (Run Logs) در مخازن آسیب‌دیده، تلاش کرده‌اند ردپای خود را از بین ببرند. در صورت اجرای این Payload، باید فرض کرد که تمامی Secretها و نقش‌های ابری (Cloud Roles) در دسترس آن Workflow کاملاً لو رفته‌اند.
تحلیل فنی بدافزار wfx
این بدافزار که با نام “wfx” در لاگ‌ها شناخته می‌شود، یک اسکریپت Shell با حدود ۱۵۰۰ خط کد است که در چهار مرحله عمل می‌کند:
- جمع‌آوری (Collect): استخراج اعتبارنامه‌ها از تمامی منابع موجود در Runner.
- ارتقاء سطح دسترسی (Escalate): استفاده از اعتبارنامه‌های جمع‌آوری‌شده برای دستیابی به دسترسی‌های عمیق‌تر در محیط‌های ابری.
- ماندگاری (Persist): انجام اقداماتی برای بقا در سیستم، حتی پس از چرخش کلیدها (Credential Rotation).
- خروج داده‌ها (Exfiltrate): بسته‌بندی داده‌ها در قالب یک فایل gzipped tarball و ارسال آن‌ها از طریق پروتکل HTTP POST به سرورهای مهاجم.
تفاوت با فعالیت‌های GhostAction
اگرچه حساب‌های تحت تأثیر در این موج با فعالیت‌های GhostAction در ماه اکتبر همپوشانی دارند، اما به دلیل تفاوت در زیرساخت‌ها، ابزارها و تکنیک‌ها (TTPs)، این حملات به یک عامل تهدید واحد نسبت داده نمی‌شوند. در واقع، اعتبارنامه‌های سرقت‌شده اغلب در اختیار چندین عامل مختلف قرار می‌گیرند.
توصیه‌های امنیتی
برای شناسایی موارد آسیب‌دیده، نبود artifacts مربوط به wfx یا نبود خلاصه مراحل (Step Summaries) لزوماً به معنای عدم سرایت نیست، زیرا مهاجمان لاگ‌ها را حذف می‌کنند. یکی از نشانه‌های قابل اعتمادتر، نبود شماره اجرای (Run Number) در Commitهای مهاجم است. توصیه می‌شود تمامی Workflowها و دسترسی‌های ابری مرتبط با مخازن GitHub به دقت بازبینی شوند.
