کمپین Gheist؛ سوءاستفاده از توکن‌های سرقت‌شده گیت‌هاب برای سرقت Secrets — Gheist campaign plants secret-dumping workflows using stolen GitHub tokens
خلاصه
محققان امنیتی کمپینی به نام Gheist را شناسایی کرده‌اند که با استفاده از توکن‌های دسترسی سرقت‌شده گیت‌هاب، فایل‌های پیکربندی مخرب در مخازن قربانیان ایجاد می‌کند. این ابزار با دور زدن سیستم‌های ماسک‌کردن، تمامی Secretها و کلیدهای حیاتی پروژه‌ها و زیرساخت‌های ابری را به سرقت می‌برد.
تیم تحقیقاتی Wiz در حال ردیابی یک کمپین سازمان‌یافته به نام Gheist است که با سوءاستفاده مقیاس‌پذیر از توکن‌های به سرقت رفته گیت‌هاب (GitHub)، به شکل خودکار اقدام به تزریق ورک‌فلوهای مخرب به مخازن نرم‌افزاری می‌کند. این حمله ابعاد گسترده‌ای داشته و از پروژه‌های شخصی تا مخازن خصوصی سازمان‌های بزرگ را هدف قرار داده است.
نحوه کار کمپین Gheist
در این حمله، مهاجمان برای هر مخزنِ در دسترس با استفاده از توکن‌های کامپرومایز شده، یک شاخه (Branch) جدید با الگوی نام‌گذاری ci-sync- و شش کاراکتر تصادفی ایجاد می‌کنند. سپس فایل .github/workflows/sync-check.yml را با پیام کامیت ci: sync config به مخزن اضافه می‌کنند.
این ورک‌فلو عمدتاً کارهای زیر را انجام می‌دهد:
- چاپ کردن مقادیر سراسری و محیطی مخزن
- استفاده از انکودینگ base32 روی متغیرها (
base32 -w 120) برای دور زدن مکانیزم‌های امنیتی گیت‌هاب که مقادیر Secret را به صورت پیش‌فرض در لاگ‌ها ماسک می‌کنند. - استفاده از ماتریکس دپلویومنت‌ها برای استخراج Secretهای مختص محیط‌های حساس و پروداکشن.
- دانلود کردن لاگ اجرای ورک‌فلو از طریق API گیت‌هاب و سپس حذف سریع آن برای پاک کردن ردپا.
نکته فنی جالب اینجاست که از آنجایی که داده‌ها از طریق خود APIهای گیت‌هاب خارج می‌شوند، هیچ دامنه یا ارتباط خروجی مشکوکی توسط فایروال‌ها قابل مسدودسازی نیست.
تکامل ابزار و نفوذ به هاست‌های Self-Hosted
این ابزار در نسخه‌های جدیدتر خود (Tool B)، قابلیت‌های پیشرفته‌تری مانند Job دوم با نام sync-host اضافه کرده است که روی رانرهای Self-Hosted اجرا می‌شود. این بخش به دنبال فایل‌های حساس، توکن‌های هوش مصنوعی (مانند Anthropic، Hugging Face، Groq و NVIDIA)، کلیدهای خصوصی، فایل‌های .env و تاریخچه شل می‌گردد. همچنین با استفاده از سوکت داکر (Docker Socket) به فایل سیستم ریشه میزبان دسترسی پیدا کرده و توکن‌های ابری (AWS، GCP، Azure) و توکن‌های سرویس اکانت Kubernetes را استخراج می‌کند.
نقش مکانیسم‌های دفاعی گیت‌هاب
گیت‌هاب از اواخر تابستان اجرای ورک‌فلوهای بالقوه مخرب در مخازن عمومی را تا زمان تایید توسط یک همکار متوقف می‌کند (Approval Hold). این مکانیزم باعث شد که در مخازن عمومی، تمام تلاش‌های این کمپین در وضعیت action_required متوقف شوند و کدی اجرا نشود. با این حال، این کنترل امنیتی شامل مخازن خصوصی و سرورهای GitHub Enterprise نمی‌شود و در آنجا حملات با موفقیت اجرا شده‌اند.
همچنین شواهد نشان می‌دهد حساب‌های آلوده شده در این کمپین، گاهی هدف سایر مهاجمان نیز قرار گرفته‌اند؛ از جمله توزیع بدافزارها از طریق تغییر نام مخازن (Malware Distribution)، ماینینگ غیرمجاز ارز دیجیتال، و حتی آلودگی‌های زنجیره تأمین مانند بدافزارهای مرتبط با کره شمالی (PolinRider) که کدهای مخرب را به فایل‌های پیکربندی مثل vite.config.js تزریق می‌کنند.
اقدامات واکنشی برای تیم‌های امنیتی و توسعه‌دهندگان
اگر سازمان شما در معرض این تهدید قرار گرفته است، اقدامات زیر ضروری است:
- جستجوی شاخه‌های مشکوک: به دنبال شاخه‌هایی با الگوی
ci-sync-*و کامیت‌های مربوط بهsync-check.ymlبگردید. - بررسی لاگ‌های ابری (OIDC): اگر ورک‌فلوهای شما با ابر احراز هویت می‌شوند، لاگ‌های کلود (مثل CloudTrail) را برای نقش‌هایی که توسط این شاخه‌ها فرض شده‌اند بررسی کنید.
- چرخش کامل Secretها (Rotation): تمامی Secretهای مخزن، سازمان و محیط‌های استقرار که ممکن است در معرض خطر قرار گرفته باشند را فوراً تعویض کنید. پاک کردن شاخه یا لاگ، داده‌های افشاشده را به عقب برنمی‌گرداند.
- بررسی رانرهای خودمیزبان (Self-Hosted): وجود فایل‌هایی مثل
.gdmp_patیا رشتهgdmp-pivotنشان‌دهنده کمپین است و هاست باید کاملاً ایزوله و بررسی شود. - سخت‌سازی زیرساخت: استفاده از توکن‌های کوتاه‌مدت و با دسترسی محدود (Fine-grained Tokens) به جای Personal Access Tokens و اجرای رانرها به شکل موقت (Ephemeral) بدون دسترسی مستقیم به سوکت داکر.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل