ثغرة أمنية · مستغلة بشكل نشط

ثغرة اليوم صفر في ⁦Outlook⁩ (⁦CVE-2026-124194⁩)يكفي فتح ملف واحد لتصل بيانات اعتماد ⁦Windows⁩ إلى المهاجمين

أغلقت ⁦Microsoft⁩ في 10 نوفمبر 2026 ثغرة في ⁦Outlook⁩ الكلاسيكي لـ ⁦Windows⁩ تُستغل بالفعل في هجمات. فإذا فتح مستخدم ملف رسالة مُعدًّا خصيصًا، يتصل ⁦Outlook⁩ بخادم تابع للمهاجمين دون التحذير المعتاد، ويكشف خلال ذلك تجزئة ⁦NTLMv2⁩ الخاصة بالحساب. وقد أدرجت الوكالة الأمريكية ⁦CISA⁩ الثغرة في اليوم نفسه في كتالوجها للثغرات المستغلة. وتبدو درجة ⁦CVSS⁩ البالغة ⁦6.5⁩ هيّنة، لكن الوضع ليس كذلك.

  • ⁦CVSS 6.5⁩ · مستغلة
  • في ⁦CISA KEV⁩ منذ 10 نوفمبر 2026
  • المهلة للجهات الحكومية الأمريكية: 24 نوفمبر 2026
  • الإصلاح في تحديث ⁦Office⁩ لشهر نوفمبر

في لمحة

ما الذي حدث، وما الذي يعنيه ذلك لكم

في يوم التحديثات الأمنية لشهر نوفمبر، أغلقت ⁦Microsoft⁩ أكثر من ألف ثغرة. وواحدة منها فقط تُستغل بالفعل بحسب ما أعلنته ⁦Microsoft⁩: ⁦CVE-2026-124194⁩ في ⁦Outlook⁩ الكلاسيكي لـ ⁦Windows⁩. وهي لا تمنح المهاجمين وصولًا إلى الجهاز، لكنها تمنحهم شيئًا يكاد يعادله قيمةً في كثير من الشبكات: بيانات اعتماد قابلة للاستغلال خاصة بالمستخدم. [1][2][9]

  1. يحتاج الهجوم إلى نقرة. يرسل المهاجمون ملف رسالة مُعدًّا خصيصًا ويدفعون المستخدم إلى فتحه في ⁦Outlook⁩. وبحسب ⁦Microsoft⁩، لا يُعدّ جزء المعاينة مسارًا للهجوم.
  2. لا يحذّر ⁦Outlook⁩. عند الفتح، يتصل ⁦Outlook⁩ بوجهة شبكية تابعة للمهاجمين دون أن يعرض التنبيه المعتاد بشأن المحتوى الخارجي.
  3. التجزئة هي الغنيمة. وخلال ذلك تصل تجزئة ⁦NTLMv2⁩ الخاصة بالمستخدم إلى المهاجمين. ويمكنهم كسرها دون اتصال أو تمريرها إلى خدمات أخرى، فينتحلون بذلك صفة المستخدم.
  4. تصنّف السلطات الثغرة على أنها عاجلة. تُدرجها ⁦CISA⁩ منذ 10 نوفمبر في كتالوج الثغرات المستغلة المعروفة؛ ويتعيّن على الوكالات الفيدرالية الأمريكية التحرك بحلول 24 نوفمبر.
  5. التصحيح هو تحديث لـ ⁦Office⁩. ⁦Windows Update⁩ وحده لا يكفي. فالعامل الحاسم هو بنية ⁦Outlook⁩ المثبّتة، لا حالة التوزيع في لوحة الإدارة.

ما هو معروف

  • تؤكد ⁦Microsoft⁩ الاستغلال («⁦Exploitation Detected⁩»)؛ ولم تكن الثغرة معروفة علنًا قبل التصحيح.
  • المتأثر هو ⁦Microsoft 365 Apps for Enterprise⁩ وكذلك ⁦Office LTSC 2021⁩ و⁦2024⁩، بإصداري 32 و64 بت لكل منها.
  • لا تُدرج ⁦Microsoft⁩ ضمن المتأثرين كلًّا من ⁦Outlook⁩ الجديد و⁦Outlook⁩ على الويب و⁦Outlook⁩ لـ ⁦Mac⁩ وتطبيقات الهاتف المحمول.
  • وهي الثغرة المستغلة الوحيدة في تحديث نوفمبر.
  • تذكر ⁦Microsoft⁩ بوصفهما مكتشفَي الثغرة «⁦nono⁩» و⁦Benoit Sevens⁩، والأخير مع الإضافة «⁦using Claude with Anthropic⁩».

ما لم يُحسم بعد

  • من يستغل الثغرة وضد من: لا تذكر ⁦Microsoft⁩ جهات فاعلة ولا أهدافًا.
  • كم عدد الهجمات التي وقعت، ومنذ متى.
  • لم تُنشر حتى الآن مؤشرات على الاختراق (⁦IOCs⁩).
  • أي تنسيق ملفات يستخدمه المهاجمون، وعبر أي بروتوكول يتصل ⁦Outlook⁩.
  • ما إذا كانت شيفرات إثبات المفهوم (⁦Proof of Concept⁩) التي ظهرت على ⁦GitHub⁩ تعمل؛ إذ لم يُتحقق من أي منها.
سلسلة الهجوم

كيف يتحول ملف إلى حساب مسروق

تصف ⁦Microsoft⁩ بنفسها الخطوات الثلاث الأولى. أما الخطوتان الرابعة والخامسة فتبيّنان كيف يستخدم المهاجمون عادةً، بحسب الخبرة، تجزئات ⁦NTLMv2⁩ التي يستولون عليها. وهذا تقييمنا، وليس معلومة عن الهجمات الحالية.

  1. بحسب ⁦Microsoft⁩

    الطُّعم

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

  2. بحسب ⁦Microsoft⁩

    الفتح

    يفتح المستخدم الملف في ⁦Outlook⁩. وهذه الخطوة وحدها هي ما يُطلق الهجوم، لا مجرد تحديد الملف في جزء المعاينة.

  3. بحسب ⁦Microsoft⁩

    اتصال دون تحذير

    يتصل ⁦Outlook⁩ بخادم تابع للمهاجمين دون التحذير من المحتوى الخارجي. ويسجّل ⁦Windows⁩ الدخول هناك تلقائيًا.

  4. تقييم ⁦VamiSec⁩

    الاستيلاء على التجزئة

    ينقل تسجيل الدخول استجابة تحدٍّ من نوع ⁦NTLMv2⁩ (⁦Challenge-Response⁩). ويسجّلها خادم المهاجمين، دون أن يلاحظ المستخدم شيئًا.

  5. تقييم ⁦VamiSec⁩

    إساءة الاستخدام

    يمكن كسر كلمات المرور الضعيفة دون اتصال. أو يُمرَّر تسجيل الدخول فورًا إلى خدمات داخلية (⁦NTLM Relay⁩)، مثل ⁦Exchange⁩ أو خوادم الملفات أو خدمات الشهادات.

ما لا تمثّله الثغرة

  • ليست هجومًا دون نقرة (⁦Zero-Click⁩): لا يحدث شيء دون فتح الملف. وهذا ما يميزها عن ⁦CVE-2023-23397⁩ التي كانت تُطلَق بمجرد وصول رسالة.
  • ليست تنفيذًا للشيفرة: لا يستولي المهاجمون على الجهاز مباشرة، بل يستولون على بيانات الاعتماد.
  • ليست هجومًا عبر جزء المعاينة.

لماذا تُعدّ التجزئة ثمينة إلى هذا الحد

  • بكلمة المرور المكسورة يسجّل المهاجمون الدخول أينما كان الحساب صالحًا، بما في ذلك ⁦VPN⁩ والسحابة، إذا لم يكن هناك عامل ثانٍ مفعّل.
  • وعبر التمرير (⁦Relay⁩) لا يحتاجون إلى كلمة المرور أصلًا: فهم يمرّرون تسجيل الدخول ما دامت الخدمات تقبل ⁦NTLM⁩ دون توقيع أو ربط بالقناة.
  • وإذا أصاب ذلك حساب مسؤول، فقد يصبح مجال ⁦Windows⁩ بأكمله مكشوفًا في أسوأ الأحوال.
  • تحمي المصادقة متعددة العوامل الخدمات السحابية، لكنها لا تحمي من كسر التجزئة، ولا من كل مسار تمرير داخلي.
التقييم

لماذا لا تعني ⁦6.5⁩ أن الخطر قد زال

يقيّم ⁦CVSS⁩ مدى الخطورة التقنية للثغرة، لا ما إذا كانت تتعرض للهجوم حاليًا. وفي تحديد الأولويات، ما يهم هو وضع التهديد.

6.5درجة ⁦CVSS⁩ الأساسية

«متوسطة»: يجب أن يتفاعل المستخدم، والمتأثر هو السرية فقط. [1]

1.6%توقّع ⁦EPSS⁩

الاحتمال الإحصائي للاستغلال خلال 30 يومًا، وفق بيانات 12 نوفمبر. [21][11]

نعمفي كتالوج ⁦CISA KEV⁩

الاستغلال مؤكد. وهذا أثقل وزنًا من أي توقّع. [4]

مرتفعنضج الاستغلال بحسب ⁦Microsoft⁩

تضع ⁦Microsoft⁩ في متجه ⁦CVSS⁩ القيمة ⁦E:H⁩: توجد شيفرة هجوم فعّالة. [1]

النمط معروف

استُغلت ثغرات تسريب ⁦NTLM⁩ ذات التصنيف «المتوسط» مرارًا خلال السنوات الماضية. فقد حملت ⁦CVE-2024-43451⁩ و⁦CVE-2025-24054⁩ أيضًا درجة ⁦CVSS 6.5⁩، ومع ذلك انتهى بهما المطاف في كتالوج ⁦KEV⁩. وبحسب ⁦Check Point⁩، استغل المهاجمون ⁦CVE-2025-24054⁩ بعد ثمانية أيام من صدور التصحيح. [15][20][17]

اكتُشفت بالذكاء الاصطناعي

تتوجّه ⁦Microsoft⁩ بالشكر على هذا الاكتشاف إلى «⁦nono⁩» وإلى ⁦Benoit Sevens⁩ «⁦using Claude with Anthropic⁩». ولا تذكر ⁦Microsoft⁩ ما إذا كانت الثغرة قد اكتُشفت من خلال هجمات رُصدت أم عبر بحث مستقل. والواضح أن الذكاء الاصطناعي يسرّع أبحاث الثغرات لدى الطرفين. وبحسب ⁦SecurityWeek⁩، أغلقت ⁦Microsoft⁩ في 2026 حتى الآن أكثر من 5,000 ثغرة، منها في أكتوبر وحده رقم قياسي بلغ 1,413 ثغرة. وعمليات التصحيح التي صُمّمت لبضع عشرات من الثغرات شهريًا لا تواكب هذه الوتيرة. [1][10][9]

في التحديث نفسه: 19 ثغرة أخرى في ⁦Outlook⁩

إلى جانب ⁦CVE-2026-124194⁩، يغلق تحديث نوفمبر 18 ثغرة أخرى في ⁦Outlook⁩ قد تتيح تنفيذ الشيفرة، وثغرة واحدة للإفصاح عن المعلومات. وفي ثلاث منها، هي ⁦CVE-2026-110043⁩ و⁦CVE-2026-110068⁩ و⁦CVE-2026-111309⁩، يُعدّ جزء المعاينة مسارًا للهجوم. ولا تُستغل حتى الآن بحسب ⁦Microsoft⁩، لكن التحديث مستحق في كل الأحوال. [2]

التسلسل الزمني

⁦Outlook⁩ و⁦NTLM⁩ وما سبق ذلك

تأتي الثغرة الحالية ضمن سلسلة من الهجمات التي تستولي على بيانات تسجيل الدخول إلى ⁦Windows⁩ عبر ⁦Outlook⁩ ومستكشف الملفات.

  1. استغلال

    ⁦CVE-2023-23397⁩: ثغرة دون نقرة في ⁦Outlook⁩

    كان يكفي تذكير يحتوي على مسار إلى خادم خارجي، فيكشف ⁦Outlook⁩ التجزئة دون أي تدخل من المستخدم. وتنسب ⁦Microsoft⁩ الهجمات إلى المجموعة الروسية ⁦Forest Blizzard (APT28)⁩، وتعود آثارها إلى أبريل 2022. ⁦CVSS 9.8⁩. [13][4]

  2. الشركة المصنِّعة

    ⁦CVE-2024-21413⁩: «⁦MonikerLink⁩»

    تجاوز رابط مُعدّ خصيصًا يحتوي على علامة تعجب طريقةَ العرض المحمية، وكشف بيانات اعتماد ⁦NTLM⁩، وفتح طريقًا لتنفيذ الشيفرة. ⁦CVSS 9.8⁩؛ وأدرجت ⁦CISA⁩ الثغرة في كتالوج ⁦KEV⁩ في فبراير 2025. [14][4]

  3. استغلال

    ⁦CVE-2024-43451⁩: تسريب ⁦NTLMv2⁩ بدرجة ⁦CVSS 6.5⁩

    كان مجرد حذف ملف ⁦URL⁩ مُعدّ خصيصًا أو نقله كافيًا. واستغلت جهة فاعلة يُشتبه في أنها روسية الثغرةَ قبل صدور التصحيح ضد أهداف في أوكرانيا. [15][16]

  4. استغلال

    ⁦CVE-2025-24054⁩: استُغلت بعد ثمانية أيام من التصحيح

    أطلق ملف ⁦.library-ms⁩ مُعدّ خصيصًا تسجيلَ الدخول إلى خادم ⁦SMB⁩. ورصدت ⁦Check Point⁩ حملات ضد جهات حكومية وشركات في بولندا ورومانيا. ⁦CVSS 6.5⁩. [17][20][4]

  5. الشركة المصنِّعة

    تعلن ⁦Microsoft⁩ نهاية ⁦NTLM⁩

    من المقرر تعطيل ⁦NTLM⁩ افتراضيًا مع الإصدارات الرئيسية التالية من ⁦Windows⁩. وتستمر الإصدارات الحالية في دعمه، ويبقى التحصين مهمة الشركات. [12]

  6. استغلال

    تصحيح لـ ⁦CVE-2026-124194⁩، والاستغلال مؤكد

    تنشر ⁦Microsoft⁩ تحديث ⁦Office⁩ وتصنّف الثغرة على أنها مستغلة. وفي اليوم نفسه تُدرجها ⁦CISA⁩ في كتالوج ⁦KEV⁩. [1][2][4][9]

  7. جهة رسمية

    ⁦NVD⁩ و⁦CISA⁩ تقيّمان الثغرة

    حلّلت ⁦NVD⁩ الإدخال. وتصنّف ⁦CISA⁩ الثغرة كما يلي: استغلال نشط، وغير قابل للأتمتة، وأثر تقني جزئي. [5]

  8. مهلة

    المهلة في كتالوج ⁦KEV⁩

    يجب على الوكالات الفيدرالية الأمريكية تثبيت التحديثات بحلول هذا التاريخ. وبالنسبة إلى الشركات، يُعدّ ذلك معيارًا جيدًا. [4]

الإصدارات المتأثرة

أي تثبيتات ⁦Outlook⁩ تحتاج إلى التحديث

المتأثر هو ⁦Outlook⁩ الكلاسيكي لـ ⁦Windows⁩ من حزم ⁦Office⁩ هذه. والمعيار هو البنية المثبّتة: فاعتبارًا من أرقام البنية المذكورة تكون الثغرة مغلقة، كما تتضمن البنيات اللاحقة الإصلاح أيضًا.

أرقام البنية بحسب ⁦Microsoft⁩، حتى 10 نوفمبر 2026، لإصداري 32 و64 بت [1][3]
المنتجالقناة أو النسخةالإصدارالبنية المتضمنة للإصلاح
⁦Microsoft 365 Apps for Enterprise⁩⁦Current Channel⁩261020527.20196
⁦Microsoft 365 Apps for Enterprise⁩⁦Monthly Enterprise Channel⁩26102609260820527.2019420430.2026420326.20320
⁦Microsoft 365 Apps for Enterprise⁩⁦Semi-Annual Enterprise Channel⁩26102609260820527.2019220430.2026220326.20318
⁦Office LTSC⁩ (ترخيص كمي)⁦Office LTSC 2024⁩240816.0.17932.21140
⁦Office LTSC⁩ (ترخيص كمي)⁦Office LTSC 2021⁩210816.0.14334.21048

بالنسبة إلى ⁦Microsoft 365 Apps⁩، لا تذكر ⁦Microsoft⁩ في إدخال ⁦CVE⁩ رقم بنية ثابتًا، بل تحيل إلى ملاحظات الإصدار الخاصة بالتحديثات الأمنية لـ ⁦Office⁩؛ ومنها أُخذت هذه القيم. ويتلقى ⁦Semi-Annual Enterprise Channel⁩ في الوقت الحالي بنيات ⁦Monthly Enterprise Channel⁩.

فحص البنية

اختاروا القناة، وأدخلوا رقم البنية، وشاهدوا النتيجة. تجدون رقم البنية في ⁦Outlook⁩ ضمن ملف › حساب ⁦Office⁩ › حول ⁦Outlook⁩.

يجري الفحص في متصفحكم فقط، ولا يُرسَل أي شيء.

لم يُدخَل رقم بنية بعد

تظهر النتيجة بمجرد إدخال رقم البنية.

الإصلاح اعتبارًا من البنية
261020527.20196

غير مُدرجة ضمن المتأثرين

  • ⁦Outlook⁩ الجديد لـ ⁦Windows⁩
  • ⁦Outlook⁩ على الويب
  • ⁦Outlook⁩ لـ ⁦Mac⁩
  • ⁦Outlook⁩ لـ ⁦iOS⁩ و⁦Android⁩

لا تذكر ⁦Microsoft⁩ الإصدارين ⁦Office 2016⁩ و⁦Office 2019⁩ بالنسبة إلى هذه الثغرة. لكن عدم الإدراج لا يعني أن الأمان قد ثبت بالفحص: فمن يشغّل إصدارات أقدم ينبغي أن ينفّذ تحصين ⁦NTLM⁩ بصرامة خاصة.

لعدد كبير من الأجهزة: قراءة رقم البنية عبر ⁦PowerShell⁩

في تثبيتات ⁦Click-to-Run⁩ يُسجَّل رقم البنية في السجل (⁦Registry⁩). ولمجمل الأجهزة، تصلح ⁦Intune⁩ أو ⁦Defender Vulnerability Management⁩ أو ⁦Microsoft 365 Apps Admin Center⁩.

PowerShell
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' |
  Select-Object VersionToReport, UpdateChannel, CDNBaseUrl

بدء التحديث فورًا على جهاز واحد

يبدأ هذا الأمر التحديث؛ ويجب إعادة تشغيل ⁦Outlook⁩ بعد ذلك.

PowerShell
& "$env:CommonProgramFiles\Microsoft Shared\ClickToRun\OfficeC2RClient.exe" /update user
اختبار ذاتي

ما مدى حمايتكم من سرقة بيانات ⁦NTLM⁩ عبر ⁦Outlook⁩؟

ثمانية أسئلة، أجيبوا عنها بصدق. «نعم» هي الإجابة الآمنة في كل مرة. ويبقى التقييم في متصفحكم.

  1. هل تعمل جميع الأجهزة التي تستخدم ⁦Outlook⁩ الكلاسيكي، على نحو مثبت، بالبنية المتضمنة للإصلاح، بما في ذلك أجهزة العمل من المنزل وخوادم الطرفيات وبيئات ⁦VDI⁩؟
  2. هل حركة ⁦SMB⁩ الصادرة (⁦TCP 445⁩) إلى الإنترنت محظورة على جدار الحماية وعلى الأجهزة المحمولة؟
  3. هل الحسابات ذات الامتيازات غير قادرة على استخدام ⁦NTLM⁩، مثلًا لأنها أعضاء في مجموعة «المستخدمون المحميون» (⁦Protected Users⁩)؟
  4. هل تسجّلون أو تحظرون حركة ⁦NTLM⁩ الصادرة إلى خوادم خارجية؟
  5. هل توقيع ⁦SMB⁩ و⁦LDAP⁩، وربط القناة في ⁦LDAP⁩، و⁦Extended Protection⁩ لخدمات الشهادات و⁦Exchange⁩ مفعّلة؟
  6. هل تفحص بوابة البريد لديكم ملفات الرسائل وملفات ⁦Office⁩ الواردة من مرسلين خارجيين أو تحتجزها؟
  7. هل يكتشف ⁦SOC⁩ أو ⁦MDR⁩ لديكم قيام ⁦outlook.exe⁩ بإنشاء اتصالات بعناوين خارجية عبر ⁦SMB⁩ أو ⁦WebDAV⁩؟
  8. هل يعلم موظفوكم أنه ينبغي ألا يفتحوا ملفات الرسائل غير المتوقعة، وأن يبلّغوا فورًا عن الحالات المشتبه بها؟
نتيجتكم

تمت الإجابة عن ⁦0⁩ من أصل ⁦8⁩ أسئلة

لا يغني الاختبار الذاتي عن فحص بيئتكم.

خطة الإجراءات

ما ينبغي فعله الآن

ثلاث مراحل: إغلاق الثغرة اليوم، وتوسيع نطاق الدفاع حتى مهلة ⁦KEV⁩، ثم التخلص من ⁦NTLM⁩ خطوة بخطوة. [12][13][18][19]

اليوم

إغلاق الثغرة

  • توزيع تحديث ⁦Office⁩ الصادر في 10 نوفمبر على جميع الأجهزة التي تستخدم ⁦Outlook⁩ الكلاسيكي، وفرض تثبيته.
  • فحص البنية المثبّتة، لا حالة التوزيع فقط.
  • حظر ⁦TCP 445⁩ الصادر إلى الإنترنت، بما في ذلك على الحواسيب المحمولة خارج شبكة الشركة.
  • تحذير الموظفين: عدم فتح ملفات الرسائل غير المتوقعة.
  • البحث باستخدام الاستعلامات الواردة أدناه عن اتصالات ⁦Outlook⁩ بخوادم خارجية.
حتى 24 نوفمبر

توسيع نطاق الدفاع

  • إضافة الحسابات ذات الامتيازات إلى مجموعة «المستخدمون المحميون».
  • تسجيل حركة ⁦NTLM⁩ الصادرة إلى خوادم خارجية، ثم حظرها مع قائمة استثناءات.
  • تفعيل توقيع ⁦SMB⁩ و⁦LDAP⁩، وربط القناة، و⁦Extended Protection⁩.
  • إيقاف خدمة ⁦WebClient⁩ على الأجهزة التي لا تحتاج إلى ⁦WebDAV⁩.
  • فحص ملفات الرسائل الخارجية في بوابة البريد أو احتجازها.
من 30 إلى 90 يومًا

التخلص من ⁦NTLM⁩

  • تفعيل التسجيل الموسّع لـ ⁦NTLM⁩ وتحليله لبضعة أسابيع (⁦Windows 11⁩ اعتبارًا من ⁦24H2⁩، و⁦Windows Server 2025⁩).
  • تحويل التطبيقات من ⁦NTLM⁩ المضبوط بشكل ثابت إلى ⁦Negotiate⁩، كي يُستخدم ⁦Kerberos⁩.
  • إلغاء تسجيلات الدخول عبر عناوين ⁦IP⁩، وتسجيل أسماء ⁦SPN⁩ المفقودة.
  • حظر ⁦NTLM⁩ في حلقات نشر متتالية، بدءًا بالحسابات الأشد حاجة إلى الحماية.
  • توثيق الاستثناءات المتبقية وتحديد مدة لها.

لفرق تشغيل تقنية المعلومات و⁦SOC⁩

  • الإبلاغ يوميًا عن نسبة تغطية التصحيح حتى المهلة.
  • تفعيل قواعد الكشف لاتصالات ⁦SMB⁩ و⁦WebDAV⁩ الصادرة من ⁦Outlook⁩.
  • مراقبة تسجيلات الدخول عبر ⁦NTLM⁩ من مصادر غير معتادة على وحدات التحكم بالمجال.

للإدارة العليا ومسؤول أمن المعلومات

  • تحديد 24 نوفمبر هدفًا داخليًا، والمطالبة بالتقدم نحوه.
  • تخصيص الموارد للتخلص من ⁦NTLM⁩: فلن تعطّل ⁦Microsoft⁩ بروتوكول ⁦NTLM⁩ إلا في الإصدارات المستقبلية.
  • توضيح ما إذا كانت حالة مشتبه بها تستوجب الإبلاغ بموجب ⁦NIS2⁩ أو ⁦DORA⁩.
هل تشتبهون في تسرّب بيانات الاعتماد؟

أعيدوا تعيين كلمة مرور الحساب، وألغوا الجلسات والرموز المميزة (⁦Tokens⁩)، وابحثوا عن الشهادات الصادرة للحساب، واحظروا الطرف المقابل. ويدعمكم فريق ⁦CSIRT⁩ لدينا على مدار الساعة.

الإبلاغ عن حادث csirt@vamisec.com
الكشف

البحث عن الآثار

لم تنشر ⁦Microsoft⁩ أي مؤشرات. وتساعد هذه الاستعلامات على العثور على الاتصالات وتسجيلات الدخول المريبة. وهي أمثلة لـ ⁦Microsoft Defender XDR⁩ و⁦Microsoft Sentinel⁩ وأحداث ⁦Windows⁩؛ اختبروها في بيئتكم قبل استخدامها.

⁦Outlook⁩ يتواصل عبر ⁦SMB⁩ مع الإنترنت

اتصالات من ⁦outlook.exe⁩ عبر المنفذ ⁦139⁩ أو ⁦445⁩ إلى عناوين عامة خلال آخر 30 يومًا.

KQL · Defender XDR
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "outlook.exe"
| where RemotePort in (139, 445)
| where RemoteIPType == "Public"
| summarize Connections = count(), FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp) by DeviceName, RemoteIP, RemotePort

⁦WebDAV⁩ كمسار بديل

إذا كان المنفذ ⁦445⁩ محظورًا، يمكن لـ ⁦Windows⁩ اللجوء إلى ⁦WebDAV⁩ عبر ⁦HTTP⁩. ويكون النمط المعتاد حينها ⁦rundll32⁩ مع ⁦davclnt.dll⁩.

KQL · Defender XDR
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_all ("davclnt.dll", "DavSetCookie")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine,
    InitiatingProcessFileName

حركة ⁦NTLM⁩ الصادرة في سجل ⁦Windows⁩

إذا كان نهج ⁦NTLM⁩ مضبوطًا على التدقيق، يسجّل ⁦Windows⁩ تسجيلات الدخول الصادرة بوصفها الحدث ⁦8001⁩ مع الخادم الهدف.

PowerShell
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 500 |
  Where-Object Id -eq 8001 |
  Select-Object TimeCreated, Message

تسجيلات دخول ⁦NTLM⁩ مريبة

قد تشير تسجيلات الدخول الشبكية عبر ⁦NTLM⁩ (الحدث ⁦4624⁩، نوع تسجيل الدخول ⁦3⁩) من مصادر جديدة بالنسبة إلى حساب ما، إلى تمرير أو إلى كلمات مرور مكسورة.

KQL · Microsoft Sentinel
SecurityEvent
| where TimeGenerated > ago(14d)
| where EventID == 4624 and LogonType == 3
| where AuthenticationPackageName == "NTLM"
| summarize Logons = count(), Sources = make_set(IpAddress, 20)
    by TargetUserName, Computer
| order by Logons desc

النتائج مؤشرات لا أدلة. وعند وجود نتائج، تعاملوا مع الحساب على أنه مخترق إلى أن يثبت العكس.

⁦NIS2⁩ و⁦DORA⁩

ما الذي تقوله التشريعات في ذلك

الثغرة وحدها لا تستوجب الإبلاغ. لكن ما يُحدثه المهاجمون باستخدام بيانات الاعتماد المستولى عليها قد يصبح خاضعًا لالتزام الإبلاغ.

  • معالجة الثغرات واجب

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

  • مهل الإبلاغ في حالة الطوارئ

    إذا أدت سرقة بيانات الاعتماد إلى حادث أمني جوهري، يسري في ألمانيا ما يلي: إنذار مبكر إلى ⁦BSI⁩ خلال 24 ساعة، وإبلاغ خلال 72 ساعة، وتقرير نهائي بعد شهر.

  • القطاع المالي: ⁦DORA⁩

    تصنّف البنوك وشركات التأمين وغيرها من الكيانات المالية حوادث تقنية المعلومات والاتصالات وفق ⁦DORA⁩، وتبلّغ جهة الرقابة المختصة عن الجسيمة منها. والحسابات المخترقة جزء من هذا التقييم.

  • الدليل بدلًا من الحدس

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

كيف تدعمكم ⁦VamiSec⁩

الفحص والتحصين والإثبات

من الفحص السريع لمدى التأثر حتى التخلي المنظّم عن ⁦NTLM⁩.

عاجل

فريق ⁦CSIRT⁩ وتقييم الاختراق

عند الاشتباه، نوضّح ما إذا كانت بيانات الاعتماد قد تسرّبت واستُخدمت، عبر نقاط النهاية والسجلات والهويات والبنية التحتية.

تقييم الاختراق (⁦Compromise Assessment⁩)
الفحص

اختبار اختراق يركّز على تمرير ⁦NTLM⁩

نفحص ⁦Active Directory⁩ لديكم بحثًا عن مسارات التمرير، وغياب التوقيع، والحسابات التي قد تتيح لتجزئة مستولى عليها الوصول بعيدًا.

اختبارات الاختراق
الكشف

⁦Managed Detection & Response⁩

نراقب نقاط النهاية والهويات، ونستجيب عندما يُنشئ ⁦Outlook⁩ اتصالات غير معتادة أو عندما تظهر على الحسابات سلوكيات مريبة.

⁦MDR⁩ لدى ⁦VamiSec⁩
الوقاية

مراقبة ثغرات اليوم صفر

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

مراقبة ثغرات اليوم صفر
العنصر البشري

التوعية الأمنية مع ⁦KnowBe4⁩

محاكاة تصيّد احتيالي بمرفقات وتدريبات قصيرة، كي يُبلَّغ عن الملفات المريبة بدلًا من فتحها.

التوعية الأمنية
العملية

إدارة الثغرات

عملية تعالج إدخالات ⁦KEV⁩ أولًا، وتحدد المهل، وتبرّر الاستثناءات، بدلًا من الاكتفاء بالفرز وفق ⁦CVSS⁩.

إدارة الثغرات
VamiGRCمنصة ⁦GRC⁩ وكيلية

⁦VamiGRC⁩: رصد الثغرات المستغلة، وإدارة المهل، وتوثيق الأدلة

تُطابَق في ⁦VamiGRC⁩ بيانات ⁦CISA KEV⁩ و⁦NVD⁩ و⁦EPSS⁩ مع أصولكم. وعندما تظهر ثغرة مستغلة مثل ⁦CVE-2026-124194⁩، ترون أي الأصول المسجّلة متأثرة، وتديرون الإجراءات والمهل حتى الإثبات.

  • تُطابَق ⁦CISA KEV⁩ و⁦NVD⁩ و⁦EPSS⁩ مع أصولكم ومنتجاتكم وقوائم ⁦SBOM⁩ لديكم.
  • تتجدّد الأدلة الواردة من الأنظمة المتصلة بتجدّد مصدرها، بدلًا من تحديثها وقت التدقيق.
  • مع تسجيل الحادث يبدأ مؤقّت المهل لـ ⁦NIS2⁩، وينشئ ⁦VamiAI⁩ مسودات البلاغات، ويتولى فريقكم المراجعة والتقديم.
  • ضابط واحد لأطر تنظيمية متعددة: يُطبَّق مرة واحدة ويُربط بـ ⁦NIS2⁩ و⁦ISO 27001⁩ ومعايير أخرى.
  • يتولّى وكلاء الذكاء الاصطناعي المهام الروتينية وفق قواعد الموافقة التي تحددونها، ويتخذ فريقكم القرار.
⁦Valeri Milke⁩، المؤسس والمدير العام لشركة ⁦VamiSec GmbH⁩
حدّدوا موعد محادثة

لنتحدث عن وضع ⁦Outlook⁩ و⁦NTLM⁩ لديكم

سواء تعلّق الأمر بفحص مدى التأثر، أو بتحصين ⁦NTLM⁩، أو بالأدلة لأغراض ⁦NIS2⁩: يساعدكم ⁦Valeri Milke⁩ وفريق ⁦VamiSec⁩ على استخلاص خطوات تالية ملموسة من تقرير الوضع هذا.

«أمن تقنية المعلومات والامتثال دون الذكاء الاصطناعي ثغرة أمنية.»

⁦Valeri Milke⁩المؤسس والمدير العام · ⁦VamiSec GmbH⁩مدقق رئيسي لـ ⁦ISO/IEC 27001⁩ و⁦ISO/IEC 42001⁩
20عامًا من خبرة المؤسس في ⁦GRC⁩
⁦ISO 27001⁩⁦VamiSec⁩ نفسها حاصلة على الشهادة
⁦T Cloud Public⁩تشغيل في مراكز بيانات ألمانية
24/7فريق ⁦CSIRT⁩ للحوادث الأمنية
الأسئلة الشائعة

أسئلة شائعة حول ثغرة اليوم صفر في ⁦Outlook⁩

ما هي ⁦CVE-2026-124194⁩؟

ثغرة انتحال (⁦Spoofing⁩) في ⁦Outlook⁩ الكلاسيكي لـ ⁦Windows⁩، أغلقتها ⁦Microsoft⁩ في 10 نوفمبر 2026. فإذا فتح مستخدم ملف رسالة مُعدًّا خصيصًا، يتصل ⁦Outlook⁩ دون التحذير المعتاد بوجهة شبكية تابعة للمهاجمين، ويكشف خلال ذلك تجزئة ⁦NTLMv2⁩ الخاصة بالمستخدم. وتقيّم ⁦Microsoft⁩ الثغرة بدرجة ⁦CVSS 6.5⁩ («متوسطة»)، وتؤكد أنها مستغلة.

هل هذا هجوم دون نقرة؟

لا. يجب أن يفتح المستخدم الملف، ولا يُعدّ جزء المعاينة مسارًا للهجوم بحسب ⁦Microsoft⁩. وكان الأمر مختلفًا عام 2023 مع ⁦CVE-2023-23397⁩ التي كانت تُطلَق بمجرد وصول رسالة.

ما إصدارات ⁦Outlook⁩ المتأثرة؟

⁦Outlook⁩ الكلاسيكي لـ ⁦Windows⁩ في ⁦Microsoft 365 Apps for Enterprise⁩ وفي ⁦Office LTSC 2021⁩ و⁦Office LTSC 2024⁩، بإصداري 32 و64 بت لكل منها. ويتضمن الإصلاحَ ⁦Office LTSC 2021⁩ اعتبارًا من البنية ⁦16.0.14334.21048⁩، و⁦Office LTSC 2024⁩ اعتبارًا من ⁦16.0.17932.21140⁩، و⁦Microsoft 365 Apps⁩ اعتبارًا من بنيات نوفمبر في كل قناة، مثل ⁦20527.20196⁩ في ⁦Current Channel⁩. ولا تُدرج ⁦Microsoft⁩ ضمن المتأثرين ⁦Outlook⁩ الجديد ولا ⁦Outlook⁩ على الويب ولا إصدار ⁦Mac⁩ ولا تطبيقات الهاتف المحمول.

هل يكفي ⁦Windows Update⁩؟

لا. فالثغرة موجودة في ⁦Office⁩. والمعيار هو التحديث الأمني لـ ⁦Office⁩ الصادر في نوفمبر 2026، والذي يصل في ⁦Microsoft 365 Apps⁩ عبر قناة التحديث المعنية. تحققوا من البنية المثبّتة في ⁦Outlook⁩ ضمن ملف › حساب ⁦Office⁩ › حول ⁦Outlook⁩، أو مركزيًا عبر ⁦Intune⁩ أو ⁦Defender Vulnerability Management⁩.

لماذا تُعدّ ثغرة بدرجة ⁦CVSS 6.5⁩ عاجلة إلى هذا الحد؟

لأنها مستغلة. يصف ⁦CVSS⁩ الخطورة التقنية، لا وضع التهديد. وقد أدرجت ⁦CISA⁩ الثغرة في كتالوج الثغرات المستغلة المعروفة، وحدّدت للوكالات الفيدرالية الأمريكية مهلة حتى 24 نوفمبر 2026. كما تعرّضت ثغرات تسريب ⁦NTLM⁩ سابقة بالتقييم نفسه لهجمات نشطة.

ماذا يمكن للمهاجمين أن يفعلوا بتجزئة ⁦NTLMv2⁩؟

يمكنهم محاولة كسر كلمة المرور دون اتصال، وهو ما ينجح بسرعة مع كلمات المرور الضعيفة. أو يمرّرون تسجيل الدخول مباشرة إلى خدمات أخرى (⁦NTLM Relay⁩)، مثل ⁦Exchange⁩ أو خوادم الملفات أو خدمات الشهادات في ⁦Active Directory⁩، ويتصرفون هناك باسم المستخدم. وإذا كان الحساب ذا امتيازات، فقد يعرّض ذلك المجال بأكمله للخطر.

من يستغل الثغرة؟

هذا غير معروف. فلا تذكر ⁦Microsoft⁩ ولا ⁦CISA⁩ جهات فاعلة أو أهدافًا، ولم تُنشر أي مؤشرات. وقد استغلت ثغراتٍ سابقة في ⁦Outlook⁩ تتيح سرقة بيانات ⁦NTLM⁩ جهاتٌ منها المجموعة الروسية ⁦Forest Blizzard (APT28)⁩؛ ولا يمكن استخلاص استنتاجات من ذلك بشأن الحالة الراهنة.

ما علاقة ⁦Claude⁩ بهذا الاكتشاف؟

تتوجّه ⁦Microsoft⁩ بالشكر إلى ⁦Benoit Sevens⁩ مع الإضافة «⁦using Claude with Anthropic⁩»، وكذلك إلى باحث يحمل اسم «⁦nono⁩». ولم يُنشر كيف شارك نموذج الذكاء الاصطناعي تحديدًا. وتبيّن هذه الحالة كيف يسرّع الذكاء الاصطناعي أبحاث الثغرات، لدى المدافعين والمهاجمين على حد سواء.

هل توجد شيفرة استغلال منشورة علنًا؟

ظهر على ⁦GitHub⁩ مستودعان على الأقل يَعِدان بإثبات للمفهوم (⁦Proof of Concept⁩)؛ وأحدهما موصوف صراحةً بأنه غير مُختبَر. لا تنزّلوا مثل هذه الشيفرات دون فحص: فكثيرًا ما تكون عمليات الاستغلال المزعومة برمجيات خبيثة بحد ذاتها.

كيف تدعمكم ⁦VamiSec⁩؟

نفحص في وقت قصير ما إذا كانت تثبيتات ⁦Outlook⁩ لديكم قد حُدّثت، وإلى أي مدى يمكن أن تصل تجزئة مستولى عليها داخل شبكتكم، ونحصّن ⁦NTLM⁩، ونبني قواعد الكشف، ونوضّح الحالات المشتبه بها بتقييم الاختراق (⁦Compromise Assessment⁩) وبفريق ⁦CSIRT⁩ لدينا. ومع ⁦VamiGRC⁩ تديرون الثغرات المستغلة والمهل والأدلة لأغراض ⁦NIS2⁩.

المصادر

المصادر ومعلومات إضافية

تستند المعلومات إلى منشورات صادرة عن ⁦Microsoft⁩ و⁦CISA⁩ و⁦NIST⁩ وباحثين أمنيين حتى 13 نوفمبر 2026. وقد أُشير إلى تقييمات ⁦VamiSec⁩ بوصفها كذلك.

  1. [1]Microsoft Security Response Center: CVE-2026-124194 – Microsoft Outlook Spoofing Vulnerability,
  2. [2]Microsoft Security Response Center: November 2026 Security Updates – Release Notes,
  3. [3]Microsoft Learn: Release notes for Microsoft Office security updates,
  4. [4]CISA: Known Exploited Vulnerabilities Catalog,
  5. [5]NIST National Vulnerability Database: CVE-2026-124194 Detail,
  6. [6]CVE Program: CVE Record CVE-2026-124194,
  7. [7]Cyber Security News: CISA Confirms Active Exploitation of Outlook User Interaction 0-Day Vulnerability,
  8. [8]Cyber Security News: Microsoft Confirms Hackers Are Exploiting Outlook 0-Day to Steal Windows Authentication Hashes,
  9. [9]SecurityWeek: Exploited Outlook Zero-Day Among 1,094 Flaws Patched by Microsoft,
  10. [10]Notebookcheck: Exploited Outlook zero-day was found by a researcher using Claude,
  11. [11]TheHackerWire: CVE-2026-124194: Vulnerability Details,
  12. [12]Microsoft Windows IT Pro Blog: Retiring NTLM: Frequently asked questions,
  13. [13]Microsoft Security Blog: Guidance for investigating attacks using CVE-2023-23397,
  14. [14]Check Point Research: The Risks of the #MonikerLink Bug in Microsoft Outlook and the Big Picture,
  15. [15]NIST National Vulnerability Database: CVE-2024-43451 Detail,
  16. [16]SecurityWeek: Windows Zero-Day Exploited by Russia Triggered With File Drag-and-Drop, Delete Actions,
  17. [17]Check Point Research: CVE-2025-24054, NTLM Exploit in the Wild,
  18. [18]Microsoft Learn: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
  19. [19]Microsoft Learn: Protected Users Security Group
  20. [20]NIST National Vulnerability Database: CVE-2025-24054 Detail,
  21. [21]FIRST: Exploit Prediction Scoring System (EPSS): CVE-2026-124194,

لا يغني تقرير الوضع هذا عن الاستشارة القانونية ولا عن فحص بيئتكم.

تحرّكوا الآن

التصحيح واجب.
والتخلص من ⁦NTLM⁩ يحمي من الثغرة التالية.

حدّدوا موعدًا لمحادثة أولية غير ملزمة: نوضّح معكم مستوى التصحيح والتحصين والخطوات التالية.