تصيّد رمز الجهاز في OAuth: كيف حوّلت Storm-2372 تدفقًا مشروعًا إلى سرقة رموز

صُمم منح تفويض الجهاز في OAuth 2.0، المعياري في RFC 8628، للأجهزة التي لا تستطيع عرض متصفح أو قبول لوحة مفاتيح بسهولة: التلفزيونات والطابعات وأدوات CLI وأجهزة IoT. ويتيح للمستخدم المصادقة على جهاز ثانٍ بينما يستعلم الجهاز المقيّد عن رمز. وفي 2025 أدرك المهاجمون أن التدفق نفسه بدائية تصيّد ممتازة. فالضحية تُجري تسجيل دخول حقيقيًا على مزوّد هوية حقيقي، وتستوفي MFA، وتوافق على تطبيق حقيقي — ويحصل المهاجم على الرموز.

---

1. التدفق في خمس خطوات

1. يرسل العميل طلبًا إلى نقطة تفويض الجهاز مع client_id والنطاقات المطلوبة.
2. يعيد الخادم device_code (سري وطويل) وuser_code (قصير ومقروء) وverification_uri وانتهاءً.
3. يعرض العميل user_code ويطلب من المستخدم زيارة URI.
4. يسجّل المستخدم الدخول على هاتفه أو متصفحه ويدخل الرمز ويوافق.
5. يستعلم العميل نقطة الرمز بـdevice_code ويتلقى رموز الوصول والتحديث.

لا شيء في هذا التسلسل غير آمن بطبيعته. والضعف اجتماعي: يستطيع المهاجم بدء الخطوتين 1 و2 بنفسه ثم إرسال user_code ورابط تحقق أصلي إلى الضحية. فترى الضحية نطاق Microsoft أو Google أو Okta مشروعًا، وتستكمل MFA، وتظن أنها تسجّل الدخول إلى خدمة. أما المهاجم الذي يملك device_code فيستعلم ويحصل على الرموز.

---

2. Storm-2372 وحملات 2025

وثّقت Microsoft Threat Intelligence نشاط Storm-2372 في فبراير 2025. استخدم الفاعل تصيّد رمز الجهاز ضد مستأجري Microsoft 365، مستهدفًا الحكومات والمنظمات غير الحكومية وخدمات IT والدفاع والاتصالات. ولم تستغل الحملة ثغرة برمجية، بل أساءت استخدام منح تفويض الجهاز بمعرّف عميل مشروع، ثم استخدمت الرموز الناتجة للوصول إلى البريد وموارد أخرى.

ولأن المصادقة وMFA تحدثان على جهاز الضحية وشبكتها، قد يبدو تسجيل الدخول مطابقًا. واستخدام المهاجم اللاحق للرمز يأتي من موقع آخر، لكن حدث المصادقة الأول يبدو كتسجيل دخول عادي. ووثّقت Proofpoint نشاط تصيّد إضافيًا برمز الجهاز في ديسمبر 2025، ما يؤكد انتقال التقنية من ملاحظة تكتيكية إلى كتب لعب إجرامية ومدعومة من دول قابلة للتكرار.

الخداع الجوهري: الضحية لا تعطي المهاجم كلمة مرورها، بل تعطيه رمزًا أصدره مزوّد الهوية بعد تسجيل دخول ناجح محمي بـ MFA.

---

3. لماذا لا ينقذك MFA

يحمي MFA خطوة المصادقة. وفي تصيّد رمز الجهاز تستوفي الضحية تلك الخطوة بشكل صحيح. ولا يرى المهاجم كلمة المرور ولا الرمز لمرة واحدة؛ بل يتلقى ناتج مصادقة ناجحة. ولهذا تُوصف التقنية غالبًا بأنها «تجاوز MFA» رغم أن أي ضابط MFA لم يفشل. فقد حمى الضابط تسجيل الدخول لا إصدار الرمز لجهاز مجهول.

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

---

4. كشف مصادقة رمز الجهاز

في Microsoft Entra ID تظهر عمليات الدخول برمز الجهاز في السجلات مع بروتوكول المصادقة deviceCode. ابحث عن:

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

// مثال بحث في Microsoft Sentinel / Defender XDR
SigninLogs
| where AuthenticationProtocol =~ "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ClientAppUsed
| order by TimeGenerated desc

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

---

5. ضوابط دفاعية

5.1 احجب تدفق رمز الجهاز حيث لا يلزم

يدعم Conditional Access في Entra ID شرط «Authentication flows» الذي يمكنه حجب تدفق رمز الجهاز. أنشئ سياسة لكل المستخدمين مع استثناءات للمجموعة الصغيرة التي تستخدم أدوات CLI شرعًا. وهذا أعلى الضوابط أثرًا.

5.2 قيّد من يمكنه الموافقة

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

5.3 اشترط أجهزة مطابقة أو مُدارة

سياسة تشترط جهازًا مطابقًا للبريد والملفات تحجب إعادة استخدام الرمز من جهاز يتحكم به المهاجم، حتى لو صدر الرمز شرعًا.

5.4 استخدم حماية الرموز والتقييم المستمر

تربط حماية الرموز الرموز بشهادة جهاز حيث تدعم. ويُلغي التقييم المستمر للوصول (CAE) الوصول في وقت شبه حقيقي عند تغيّر المخاطر، مثل إعادة تعيين كلمة مرور.

5.5 قصّر عمر الرموز ودوّر رموز التحديث

قلّل نافذة فائدة رمز التحديث المسروق. وفعّل تدوير الرموز وكشف إعادة الاستخدام كي يُبطل استخدام رمز من موقع ثانٍ السلسلة.

5.6 درّب المستخدمين على الطُعم تحديدًا

لا يكفي التدريب العام. أخبر المستخدمين أن صفحة Microsoft أو Google مشروعة تطلب رمزًا قصيرًا إشارة خطر إلا إذا بدأوا التدفق بأنفسهم. واطلب منهم الإبلاغ عن الرسالة لا إكمال الرمز.

---

6. إذا اشتُبِه بسرقة رمز

1. أبطل رموز التحديث للمستخدم المعني وافرض إعادة المصادقة.
2. أبطل الجلسات وراجع قواعد صندوق البريد ومنح OAuth وإعدادات التحويل.
3. راجع سجلات الدخول والتدقيق لحدث رمز الجهاز واستبدال الرمز والوصول اللاحق.
4. افحص الموافقات الجديدة وأزل غير المعتمد منها.
5. ابحث جانبيًا عن رسائل مرسلة من الحساب المخترق تحتوي رموزًا أو روابط تحقق.

---

7. الخاتمة

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