سارق أسرار GitHub Actions المسمّى wfx: كيف تتعقّبه حين لا يكفي تدوير المفاتيح

في 10 نوفمبر 2026، بدأت حملة لسرقة بيانات الاعتماد يسمّيها الباحثون wfx (وتُعرف أيضًا باسم wfx-loot وWFX Phantom) بدفع أدوات لسرقة أسرار CI إلى مستودعات GitHub على نطاق واسع. وتُظهر بيانات SafeDep أن الإيداعات الخبيثة بدأت بالوصول منذ الساعة 12:46 UTC في 10 نوفمبر.

ردّ الفعل التلقائي هو تدوير كل شيء. ينبغي لك أن تُدوّر المفاتيح فعلًا، لكن التدوير وحده قد يترك للمهاجم طريقًا صالحًا للعودة عبر إعدادات الثقة التي لا يتحكّم فيها أي سرّ.

ما هو wfx، ولماذا يبدو كعمل مطوّر عادي

لا توجد ثغرة في GitHub Actions في قلب هذه الحملة. يذكر تحليل StepSecurity أن المهاجم يمتلك رموزًا صالحة لحسابات مطوّرين وبوتات حقيقية ويستخدمها كما يفعل أي مطوّر، فيفتح طلبات السحب ويدفع الإيداعات. لا شيء في سجل النشاط لديك يبدو كاستغلال لثغرة، بل يبدو كزميل أو بوت يؤدي عملًا روتينيًا.

النطاق واسع. تفيد Aikido بأن 4,837 حسابًا مخترقًا فتحت طلبات سحب استكشافية في 61,764 مستودعًا، وأن 1,835 مستودعًا على الأقل شغّلت الحمولة وسُرّبت منها بيانات اعتماد. وأحصت SafeDep بشكل مستقل 61,879 طلب سحب استكشافيًا في 61,734 مستودعًا صادرة عن 4,833 حسابًا، ولا يزال 91% منها مفتوحًا. وأفادت StepSecurity بوجود أكثر من 63,000 طلب سحب استكشافي حتى الساعة 07:40 UTC في 12 نوفمبر، نحو 90% منها لا يزال مفتوحًا، مع ظهور طلبات جديدة كل بضع دقائق.

لماذا تختلف أرقام الباحثين

كل إحصاء يقيس شيئًا مختلفًا في لحظة مختلفة، لذا فإن هذه الأرقام تكمّل بعضها بدلًا من أن تتعارض. أحصت SafeDep عدد 8,093 مستودعًا تلقّت إيداعات خبيثة بين الساعة 12:46 UTC في 10 نوفمبر والساعة 04:36 UTC في 12 نوفمبر، وكانت الحملة لا تزال نشطة وقت إجراء ذلك البحث. وتشير SecurityWeek إلى أن رقم الإيداعات لا يعني بالضرورة تنفيذًا ناجحًا، في حين يعكس رقم Aikido البالغ أكثر من 1,800 مستودع مؤشرات على أن أداة السرقة قد عملت فعلًا. أما مجموعة بيانات GitGuardian الخاصة فتضم 28,500 رقعة حمولة من 2,367 حسابًا عبر 17,715 مستودعًا.

طلب السحب الاستكشافي يعني أن حسابًا حاول الدخول، والإيداع الخبيث يعني أنه امتلك صلاحية الكتابة، والتنفيذ المؤكَّد يعني أن الأسرار خرجت على الأرجح. أيّ هذه الحالات الثلاث ينطبق عليك هو ما ينبغي أن يحدّد خطوتك التالية، ولا تستطيع أن تخبرك بذلك سوى سجلاتك الخاصة.

كيف تصل أداة السرقة إلى أسرار CI

طلبات السحب الاستكشافية تختبر الوصول

نقترح التعامل مع أي طلب سحب استكشافي على أنه علامة على أن أحدًا اختبر ما يمكن لرمز مسروق الوصول إليه. تفيد Help Net Security بأن 10,431 من طلبات السحب الاستكشافية ذهبت إلى مستودعات لا يملكها الحساب، وتم الوصول إليها عبر صلاحيات المتعاون أو المؤسسة، ما يعني أن رمزًا مسروقًا واحدًا يكشف كل مشروع يستطيع صاحبه الكتابة فيه، أيًّا كان مالك المستودع.

حقن سير العمل كان مسار التسليم الرئيسي

بمجرد تأكيد الوصول، تكون الخطوة المعتادة التالية هي حقن أداة السرقة في سير عمل موجود. وجدت StepSecurity أكثر من 21,000 إيداع برسالة ci: refresh build cache بين 10 و12 نوفمبر. ووجدت SafeDep عدد 1,343 مستودعًا كان فيها مؤلف الإيداع الخبيث حسابًا غير المالك، مثل متعاون أو بوت. هذا الرقم الثاني مهم لتحديد النطاق، لأنه حين يُسرق رمز متعاون أو بوت، يصل الإيداع الخبيث إلى مستودعك باسمه، وأي مراجعة تقتصر على نشاط المالك ستغفل عنه.

احتجاز GitHub أوقف نسخة واحدة دون الأخرى

تفيد GitGuardian بأن كل عمليات تشغيل الحمولة في نوفمبر التي استطاعت رصدها من تغييرات ملفات سير العمل وُضعت في حالة action_required ولم تبدأ قط. أما نسخة خطّاف npm فلم تُحتجز: ففي عيّنة من 19 مستودعًا نُفّذ فيها النص البرمجي، أبلغ 18 منها عن تسريب ناجح للبيانات. قراءتنا أن خطّاف الاعتمادية يعمل ضمن سير عمل موجود مسبقًا بدلًا من أن يصل كتغيير في ملف سير عمل، لذا قد لا تنبّه إليه عملية مراجعة تركّز على ملفات سير العمل وحدها. بالنسبة إلى المدافعين، يعني هذا مراجعة ملفات بيان الاعتماديات بالقدر نفسه من الريبة الذي تُراجَع به ملفات سير العمل.

مسارات أخرى: تطبيقات GitHub والتسريب عبر Telegram

لم تكن كل الرموز المسروقة رموزًا شخصية. وجدت StepSecurity أن 173 طلب سحب استكشافيًا، فُتحت من 19 حسابًا، أُنشئت عبر تطبيق Fly.io على GitHub (معرّف التطبيق 34557). لذا يجب أن يشمل تحديد النطاق لديك منح OAuth وتثبيتات تطبيقات GitHub إلى جانب رموز الوصول الشخصية. كما تغيّرت طريقة التسريب أيضًا. فالنسخ المبكرة كانت ترسل البيانات إلى عناوين IP محددة، وتفيد StepSecurity بأن التحوّل إلى Telegram يعني أن قوائم الحظر المبنية على عناوين IP الخاصة بيوم 10 نوفمبر لا تلتقط أحدث النسخ. لا يزال أي تطابق مع تلك العناوين جديرًا بالتحقيق، لكن النتيجة الفارغة من قائمة الحظر لا تخبرك إلا بالقليل عمّا إذا كانت البيانات قد خرجت.

لماذا لا يُنهي تدوير المفاتيح الاختراق

صمّمت GitHub تكامل OIDC الخاص بها للحدّ من الضرر. وتوضح وثائق GitHub أن مزوّد الخدمة السحابية يُصدر رمز وصول قصير العمر يكون صالحًا لمهمة واحدة فقط ثم تنتهي صلاحيته. رمز OIDC المسروق وحده لا قيمة كبيرة له، لذا فإن المهاجم الذي يريد البقاء عليه أن يحوّل تلك النافذة القصيرة إلى علاقة ثقة تدوم.

بيانات اعتماد الهوية الموحّدة في Entra كباب خلفي

على Azure، تُعدّ بيانات اعتماد الهوية الموحّدة الأداة البديهية لذلك. تصفها Microsoft بأنها بيانات اعتماد تُنشئ علاقة ثقة بين تطبيق ومزوّد هوية خارجي. وتفيد Aikido بأنه بمجرد زرع هذا الباب الخلفي، يستطيع أي سير عمل في ذلك المستودع المصادقة على Azure دون سرّ مخزَّن، حتى بعد تدوير كل الرموز.

سياسات ثقة AWS فضفاضة النطاق لـ GitHub OIDC

على AWS، يكمن الانكشاف في سياسات الثقة الخاصة بالأدوار. تحذّر AWS من أنك إذا لم تقيّد مفتاح الشرط token.actions.githubusercontent.com:sub بمؤسسة أو مستودع محدد، فإن GitHub Actions من مؤسسات أو مستودعات خارج سيطرتك يمكنها تولّي الأدوار المرتبطة بمزوّد هوية GitHub في حسابك.

يستبدل التدوير الأسرار المسروقة لكنه يترك إعدادات الثقة كما ضبطها المهاجم تمامًا، وهذه هي النقطة التي تحتاج القيادة أكثر من غيرها إلى سماعها قبل اعتماد الاستجابة على أنها مكتملة.

تعقّب wfx: ترتيب العمليات

الخطوة 1: تحديد نطاق الهويات

أعدّ قائمة بكل حساب بشري وبوت وتطبيق GitHub يملك صلاحية الكتابة عبر مؤسساتك، بما في ذلك المتعاونون الخارجيون. أي حساب يظهر في طلبات السحب الاستكشافية عالي الخطورة. ضع علامة أيضًا على الحسابات التي أصابتها موجة GhostAction في أكتوبر: فقد وجدت Aikido أن تلك الحسابات كانت أكثر عرضة بشكل ملحوظ من المعدّل الأساسي للتأثّر بـ wfx، ووجدت GitGuardian أن 431 حسابًا من حسابات wfx، أي نحو 20%، كانت قد اختُرقت من قبل في GhostAction.

الخطوة 2: البحث في GitHub

ابحث في كل مستودع تستطيع حساباتك الكتابة فيه، لا في المستودعات التي تملكها فقط. ابحث عن:

• طلبات سحب استكشافية، مفتوحة أو مغلقة، من حسابات لا تتوقّعها.
• إيداعات بعنوان ci: refresh build cache، على الفروع الافتراضية وغير الافتراضية.
• تغييرات على الملفات ضمن .github/workflows/ منذ 10 نوفمبر.
• تغييرات على نصوص دورة الحياة في package.json مثل preinstall وinstall وpostinstall.

الخطوة 3: فحص سجل تشغيل سير العمل

نقترح مقارنة سجل تشغيل سير العمل بسجل التدقيق الخاص بمؤسستك، مع تدوين أي عمليات تشغيل حُذفت، ومن حذفها ومتى. وحيثما تأكّد التنفيذ، افترض أن كل سرّ كان متاحًا لتلك المهمة قد انكشف.

الخطوة 4: مراجعة بيانات الاعتماد الموحّدة في Microsoft Entra

نقترح سرد بيانات اعتماد الهوية الموحّدة على كل تسجيل تطبيق وعلى كل هوية مُدارة يعيّنها المستخدم. حقّق في أي شيء لم تُنشئه، وفي أي جهة إصدار أو موضوع غير متوقَّع، وفي أي موضوع يشير إلى مستودع أو فرع أو بيئة لا تعرفها. لم نجد مصدرًا مسمّى من أحد المورّدين يؤكّد نمط تسمية محددًا لبيانات الاعتماد الدخيلة، لذا تعامل مع أي أسماء متداولة بشكل غير رسمي، مثل wfx-ci-*، على أنها خيوط غير مؤكَّدة لا مؤشرات، وتذكّر أن بيانات الاعتماد المُعاد تسميتها لن تتطابق في كل الأحوال. نقترح استخدام سجلات التدقيق لتحديد متى أُضيفت كل بيانات اعتماد ومن أضافها، وهو في رأينا اختبار أكثر موثوقية من أي اسم.

الخطوة 5: مراجعة سياسات ثقة AWS

راجع كل دور IAM يثق بمزوّد GitHub OIDC. ينبغي تقييد شرط sub بمؤسسات ومستودعات محددة، ويُفضَّل أيضًا بفروع أو بيئات محددة. يبدو الشرط المحكم النطاق على هذا النحو:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
  }
}

نقترح بعد ذلك مراجعة سجل التدقيق السحابي بحثًا عن تعديلات حديثة على سياسات الثقة وأدوار أُنشئت حديثًا، وعن عمليات تولّي أدوار من مستودعات لا تتوقّعها.

الخطوة 6: مراجعة استخدام مزوّدي الذكاء الاصطناعي

لكل مفتاح OpenAI وAnthropic وGemini يمكن لـ CI الوصول إليه، راجع الاستخدام والفوترة. أنت تبحث عن إنفاق أو نماذج أو مناطق أو أنماط طلبات لا تتوافق مع أعباء عملك. وللأسئلة الأوسع التي ينبغي طرحها حين يُحتمل أن تكون مفاتيح الذكاء الاصطناعي قد أُسيء استخدامها، قد تفيدك قائمة التحقق من مخاطر مزوّدي الاستدلال الخاصة بنا.

الخطوة 7: حفظ الأدلة قبل تغيير أي شيء

صدّر سجلات التدقيق، وسجلات تشغيل سير العمل، والبيانات الوصفية لطلبات السحب والإيداعات، وإدخالات تدقيق Entra، وأحداث CloudTrail قبل بدء التنظيف. إذا حذفت طلب سحب خبيثًا أو بيانات اعتماد دخيلة دون الاحتفاظ بسجل، فستفقد الخط الزمني الذي ستحتاجه لتحديد النطاق وإعداد التقارير وأي إخطار تنظيمي.

الاحتواء والتعافي، بالتسلسل

التسلسل مهم لأن السرّ المُدوَّر يمكن جلبه مجددًا عبر مسار ثقة لا يزال قائمًا: فما دامت بيانات اعتماد موحّدة دخيلة أو سياسة ثقة فضفاضة تعمل، يستطيع سير عمل يتحكّم فيه المهاجم الوصول إلى القيم الجديدة بسهولة وصوله إلى القديمة. التسلسل الذي نقترحه:

1. أزل وصول المهاجم الدائم أولًا. احذف بيانات الاعتماد الموحّدة الدخيلة وشدّد سياسات ثقة AWS قبل التدوير، أو في الوقت نفسه.
2. ألغِ الوصول إلى GitHub. ألغِ رموز الوصول الشخصية المخترقة ومنح OAuth وتثبيتات تطبيقات GitHub، بما في ذلك تطبيقات الجهات الخارجية مثل التطبيق الذي حدّدته StepSecurity.
3. دوّر الأسرار. ويعني ذلك أسرار Actions، ومفاتيح السحابة، ورموز سجلات الحزم، ومفاتيح مزوّدي الذكاء الاصطناعي.
4. نظّف الشيفرة. أغلق طلبات السحب الاستكشافية أو احذفها، وتراجع عن تغييرات سير العمل والحزم المحقونة على الفروع الافتراضية وغيرها. أي طلب سحب استكشافي يُترك مفتوحًا في قائمة المراجعة هو فرصة لأن يدمجه أحد المشرفين عن طريق الخطأ.
5. أكمل تنظيف GhostAction. وجدت Aikido أكثر من 100 مستودع حُقن فيها wfx في ملفات سير عمل GhostAction. إذا كان تنظيف أكتوبر جزئيًا فقط، فأكمله الآن.
6. راقب. استخدم نتائج التعقّب كخط أساس، واضبط التنبيهات من الآن فصاعدًا على بيانات الاعتماد الموحّدة الجديدة وتعديلات سياسات الثقة وتغييرات ملفات سير العمل.

تحصين مفاتيح مزوّدي الذكاء الاصطناعي في CI

في رأينا، تستحق مفاتيح مزوّدي الذكاء الاصطناعي مكانًا صريحًا في أي خطة تدوير إلى جانب بيانات الاعتماد السحابية. يوصي تحالف أمن السحابة (Cloud Security Alliance) بوضع مفاتيح الذكاء الاصطناعي خلف حدود إنفاق لكل مشروع وتنبيهات لشذوذ الاستخدام، وتفضيل بيانات الاعتماد قصيرة العمر أو المُدارة عبر وسيط على المفاتيح الثابتة في CI، وإدراج مزوّدي الذكاء الاصطناعي في أدلة تشغيل التدوير عند الحوادث إلى جانب بيانات اعتماد السحابة والسجلات.

عمليًا، امنح كل مشروع مفتاحه الخاص بحدّه الخاص، حتى لا يستطيع تسريب واحد استنزاف ميزانية مشتركة. وحيثما أمكن، وجّه استدعاءات CI عبر وسيط داخلي يحتفظ بالمفتاح الحقيقي، فلا يراه سير العمل أبدًا؛ ويشرح دليلنا حول كيف يُبقي وسيط بيانات الاعتماد مفاتيح API بعيدًا عن وكلاء الذكاء الاصطناعي هذا النمط. والانضباط نفسه ينطبق على ما يسبق CI. نقترح فحص أجهزة المطوّرين أيضًا، لأن ملفات إعداد الوكلاء المحلية قد تحتوي على بيانات اعتماد نشطة؛ ويغطّي شرحنا لتدقيق إعدادات الوكلاء المحلية وتدوير المفاتيح المكشوفة هذا الفحص.

أخطاء شائعة في الاستجابة لـ wfx

• اعتبار التدوير خط النهاية. أصلح إعدادات الثقة أولًا (خطوة الاحتواء 1).
• الاعتماد على قوائم حظر عناوين IP الخاصة بيوم 10 نوفمبر. فهي لا تلتقط النسخ العاملة في مرحلة Telegram.
• افتراض أن احتجاز GitHub قد حماك. افحص خطّافات package.json، لا ملفات سير العمل وحدها.
• فحص المستودعات التي تملكها فقط. حدّد النطاق وفق صلاحية الكتابة، بما في ذلك حقوق المتعاونين والمؤسسات.
• قراءة الأرقام العامة على أنها حكم عليك. لا تستطيع الأرقام العامة أن تخبرك بأي اتجاه ما إذا كنت قد أُصبت؛ أما سجلاتك الخاصة فتستطيع.
• ترك تنظيف GhostAction غير مكتمل. أعد فحص حسابات أكتوبر وملفات سير العمل.

تحفّظات وحدود ما نعرفه

تأتي الأرقام العامة من بحث GitHub في لحظات محددة بينما كانت الحملة لا تزال جارية، فهي لقطات مأخوذة في منتصف الحملة لا مجاميع نهائية. كما أنها تقيس أشياء مختلفة: طلبات السحب المفتوحة والإيداعات المستلمة والتنفيذ المؤكَّد ليست قابلة للتبادل، ورقم الإيداعات لدى SafeDep لا يعني بالضرورة أن الحمولة قد عملت.

نقترح عدم افتراض أن مجموعات البيانات الخارجية تعكس ما حدث في مستودعاتك الخاصة أو مثيلات المؤسسة لديك. بالنسبة إلى معظم المؤسسات، تشكّل سجلات التدقيق وسجلات Entra وCloudTrail الخاصة بها الدليل الأساسي، أما الأبحاث العامة فهي سياق.

لقد تغيّرت المؤشرات مرة بالفعل، كما يُظهر الانتقال من عناوين IP ثابتة إلى Telegram. وقد تتغيّر رسائل الإيداع وأسماء بيانات الاعتماد أيضًا، لذا راجع أحدث مؤشرات الاختراق (IOCs) الصادرة عن المورّدين قبل الاعتماد على أي نمط منفرد.

يفيد تحالف أمن السحابة، نقلًا عن GitGuardian، بأن GhostAction استخدمت نحو 1,900 حساب مخترق لاستهداف أكثر من 30,000 مستودع في أكتوبر. وإذا وُضع ذلك بجانب إحصاء Aikido البالغ 61,764 مستودعًا لحملة wfx، نحصل على موجتين يفصل بينهما نحو شهر، والثانية تقارب ضعف الأولى من حيث عدد المستودعات المستهدفة. نقطتا بيانات لا تكفيان للحديث عن اتجاه، لكنهما سبب كافٍ للاستعداد لموجة أخرى.

لا يحلّ هذا الدليل محلّ تكليف رسمي بالاستجابة للحوادث حين يتعلّق الأمر ببيانات خاضعة للتنظيم أو بوصول إلى بيئة سحابية إنتاجية.