العودة إلى المدونة →

الإحاطة الأمنية، 26 أبريل 2026: برمجية Snow عبر Teams، واختراق ADT المرتبط بـ ShinyHunters، ونافذة استغلال LMDeploy خلال 13 ساعة

نمط اليوم واضح وقاسٍ: المهاجمون يسيئون استخدام الدردشة الموثوقة، وهوية SaaS الموثوقة، وبنية AI الموثوقة أسرع مما تستطيع كثير من الفرق ترقيعه أو التحقق منه.

---

---

1. UNC6692 يحول الثقة في helpdesk داخل Microsoft Teams إلى سلسلة كاملة من برمجية Snow

بحسب Google Mandiant، يستخدم UNC6692 قصف البريد الإلكتروني وانتحال الهوية داخل Microsoft Teams للضغط على الموظفين كي يثبتوا تحديثاً مزيفاً لمكافحة الرسائل المزعجة. الضحية في الواقع يشغل مجموعة Snow: إضافة المتصفح SnowBelt، والنفق SnowGlaze، والباب الخلفي Python SnowBasin. بعد ذلك يفرغ المهاجمون LSASS، وينفذون حركة جانبية، ويصلون إلى domain controllers، ويهرّبون بيانات Active Directory. هذا ليس مجرد رسالة تصيد إضافية؛ بل مسار اختراق مولود من داخل الدردشة ومتنكر كدعم داخلي.

• اعتبر أي تواصل IT غير متوقع عبر Teams عدائياً حتى يتم التحقق منه خارج القناة.
• اربط بين Telemetry الخاصة بـ Quick Assist والدعم عن بعد والمهام المجدولة وإضافات المتصفح بدلاً من قراءتها كجزر منفصلة.
• إذا جرى تشغيل التحديث المزيف، فافترض سرقة هوية وحركة جانبية.

---

2. ADT تؤكد الاختراق بعد أن زعمت ShinyHunters اختراق حساب موظف مدعوم بـ Okta عبر vishing

تقول ADT إن المهاجمين سرقوا بيانات عملاء ومهتمين محتملين، بما يشمل الأسماء وأرقام الهواتف والعناوين، وفي نسبة أصغر تواريخ الميلاد وآخر أربعة أرقام من SSN أو المعرّفات الضريبية. وأبلغت ShinyHunters موقع BleepingComputer أن التسلل بدأ بهجوم vishing على حساب Okta SSO لموظف ثم توسع إلى Salesforce. سواء كانت كل ادعاءات المهاجمين دقيقة أم لا، فالدرس التشغيلي واضح: عندما تسقط هوية SaaS موثوقة، تصبح منصات الأعمال المتصلة كلها نصف قطر الانفجار.

• أدخل تحققاً صوتياً أقوى وخطوات إعادة اتصال في كل مسار helpdesk واستعادة الهوية.
• افحص سجلات Okta وSalesforce وبقية خدمات SaaS كحادثة واحدة لا كتذاكر منفصلة.
• أعد فحص أقل قدر من الامتيازات ومراقبة التصدير في منصات CRM والدعم فوراً.

---

3. LMDeploy يثبت أن نافذة استغلال AI تنهار إلى ساعات

يقال إن ثغرة SSRF في LMDeploy، CVE-2026-33626، استُغلت خلال 12 ساعة و31 دقيقة من الإفصاح. استخدم المهاجمون vision-language image loader لفحص AWS metadata وRedis وMySQL وواجهات الإدارة المحلية ونقطة callback خارجية. وهذا مهم لأن LMDeploy هو بالضبط نوع مكونات LLM serving التي تنشرها الفرق بسرعة وتراجعها بخفة. عندما تمنح advisory سبب الخلل ومسار الكود المتأثر، فلن ينتظر المهاجمون sprint القادم لديك.

• قم بترقيع أو تعطيل عمليات LMDeploy vision-language الضعيفة فوراً.
• امنع افتراضياً وصول مسارات model serving إلى cloud metadata والخدمات الإدارية الداخلية.
• تعامل مع خوادم AI inference كبنية مكشوفة للإنترنت، لأن المهاجمين يفعلون ذلك بالفعل.

---

ما الذي يجب أن تفعله فرق الأمن اليوم

1. أحكم ضبط workflows الدعم المعتمدة على Teams وأعد التحقق من أي أحداث مساعدة عن بعد حديثة.
2. نفذ مراجعة لحادث هوية SaaS إذا كانت بيئتك تعتمد على Okta أو Salesforce أو موصلات high-trust مشابهة.
3. احصر مكونات AI-serving المكشوفة أو القابلة للوصول وقم بترقيع LMDeploy قبل موجة الفحص التالية.
4. استخدم هذا الصباح لإغلاق فجوات الثقة، لا مجرد إغلاق التذاكر.

---

---

الخلاصة النهائية: نمط اليوم واضح وقاسٍ: المهاجمون يسيئون استخدام الدردشة الموثوقة، وهوية SaaS الموثوقة، وبنية AI الموثوقة أسرع مما تستطيع كثير من الفرق ترقيعه أو التحقق منه.