في نوفمبر 2025 كشف باحثو Bitdefender عن أسلوب غير معتاد استخدمته مجموعة التهديدات Curly COMrades: بدل تشغيل أدواتها الخبيثة مباشرة داخل Windows، فعّلت Microsoft Hyper-V على أجهزة مخترقة وشغّلت داخلها آلة افتراضية صغيرة بنظام Alpine Linux، ثم وضعت أدوات التحكم والاتصال داخل هذه البيئة المعزولة.
النتيجة كانت نقطة عمياء مهمة لبعض حلول EDR (Endpoint Detection and Response) التي كانت تراقب نظام Windows المضيف، بينما العمليات الخبيثة الفعلية تعمل داخل نظام Linux ضيف منفصل.
لكن من المهم تصحيح سوء فهم منذ البداية: الحادثة ليست ثغرة CVE في Hyper-V، وليست Zero-Day في Windows. التقرير يصف إساءة استخدام لوظيفة افتراضية شرعية بعد أن كان المهاجم قد حصل بالفعل على وصول إلى الأنظمة المستهدفة. Hyper-V نفسه ظل يؤدي وظيفته الطبيعية؛ الخطر جاء من استخدامه لإنشاء بيئة تشغيل لا تغطيها طبقة المراقبة الموجودة على المضيف.
ماذا كشف تحقيق Curly COMrades؟
نشرت Bitdefender نتائج التحقيق الأصلية في 4 نوفمبر 2025 بالتعاون مع CERT الجورجي. وكان الاكتشاف الأبرز هو استخدام Hyper-V على أجهزة Windows 10 مخترقة لإنشاء قاعدة تشغيل معزولة ومنخفضة الظهور داخل الجهاز نفسه.
وفق التحقيق، فعّل المهاجمون مكوّن Hyper-V على أنظمة مختارة، مع تعطيل أدوات الإدارة الرسومية، ثم استوردوا آلة افتراضية مجهزة مسبقًا وشغلوها تحت اسم WSL. الاسم كان مضللًا فقط؛ الآلة لم تكن Windows Subsystem for Linux، بل VM حقيقية تعمل فوق Hyper-V ومنفصلة عن WSL.
كانت الآلة الافتراضية مبنية على Alpine Linux وخفيفة للغاية: نحو 120 ميجابايت من مساحة القرص و256 ميجابايت من الذاكرة بحسب Bitdefender. وداخلها وُضعت أداتان مخصصتان هما CurlyShell وCurlCat.
كيف عملت الحيلة تقنيًا؟
لفهم سبب فعالية هذه التقنية، يجب التمييز بين نظام التشغيل المضيف Host ونظام التشغيل الضيف Guest. عند تشغيل Hyper-V، تحصل الآلة الافتراضية على بيئة تنفيذ خاصة بها تشمل عمليات Linux ونظام الملفات والخدمات والتطبيقات.
إذا كان حساس EDR مثبتًا على Windows فقط، فهو يمتلك رؤية قوية لما يجري على المضيف، لكنه لا يتحول تلقائيًا إلى حساس أمني داخل كل نظام تشغيل ضيف يتم تشغيله فوق Hyper-V.
سلسلة النشاط التي وثقها التحقيق يمكن تبسيطها دفاعيًا إلى المراحل التالية:
- وجود وصول مسبق إلى جهاز Windows المستهدف.
- تفعيل ميزة Hyper-V باستخدام أدوات Windows الشرعية.
- تنزيل ملفات آلة افتراضية مجهزة مسبقًا.
- استيراد الـVM باستخدام إمكانات Hyper-V الرسمية.
- تشغيل آلة Alpine Linux المخفية نسبيًا.
- تشغيل أدوات الاتصال والتحكم داخل Linux بدل Windows.
- استخدام الشبكة الافتراضية للمضيف لإخراج اتصالات Command and Control إلى الشبكة.
الأمر المهم هنا أن المهاجم لم يكن بحاجة إلى كسر العزل بين الـVM وWindows. بل استفاد من العزل نفسه لإبعاد جزء حساس من نشاطه عن طبقة المراقبة التي تعمل على المضيف.
لماذا لم ير EDR كل ما يحدث داخل Linux؟
حل EDR العامل على Windows يبني رؤيته عادة من أحداث وعمليات وملفات وذاكرة وسلوكيات تخص نظام Windows الذي ثُبت عليه الحساس. أما برنامج ELF يعمل داخل Alpine Linux في VM منفصلة فلا يصبح عملية Windows عادية يستطيع حساس المضيف تحليلها بالطريقة نفسها.
| الطبقة | ما يمكن مراقبته من Windows | المشكلة المحتملة |
|---|---|---|
| المضيف Windows | PowerShell، العمليات، الملفات، تغييرات النظام، Hyper-V | توجد Telemetry مفيدة قبل تشغيل الـVM وحولها |
| الضيف Alpine Linux | رؤية محدودة من حساس Windows وحده | العمليات والبرمجيات داخل الضيف قد لا تخضع لتحليل EDR الخاص بالمضيف |
| الشبكة | الاتصالات لا تزال تمر في النهاية عبر البنية الشبكية للمضيف | يمكن تعويض جزء من نقطة العمى بمراقبة الشبكة |
وهذا لا يعني أن "EDR لا يستطيع حماية Linux". توجد منتجات EDR تدعم تثبيت حساس مستقل داخل أنظمة Linux نفسها؛ فمثلًا توفر Microsoft Microsoft Defender for Endpoint لأنظمة Linux. نقطة الضعف التشغيلية في السيناريو الذي وثقته Bitdefender هي الاعتماد على Telemetry المضيف وحدها مع وجود Guest غير مُدار أمنيًا.
دور Hyper-V Default Switch في إخفاء مصدر الاتصال
لم تقتصر الفائدة على عزل العمليات. فقد ضُبطت الآلة الافتراضية لاستخدام Hyper-V Default Switch، بحيث يمر اتصالها عبر شبكة المضيف باستخدام NAT.
تشرح وثائق Microsoft الخاصة بشبكات NAT في Hyper-V أن الآلة الافتراضية تستطيع الوصول إلى موارد الشبكة باستخدام عنوان IP الخاص بالمضيف عبر Virtual Switch داخلي.
في حالة Curly COMrades أدى ذلك إلى ظهور الاتصالات الصادرة كما لو أنها تأتي من الجهاز المضيف نفسه. وهذه نقطة مهمة لمحللي SOC: عدم رؤية عملية خبيثة واضحة في Windows لا يعني أن حركة الشبكة الخارجة من ذلك الجهاز سليمة.
ما CurlyShell وCurlCat؟
احتوت آلة Alpine Linux على عائلتين مخصصتين من البرمجيات وصفتهما Bitdefender بأنهما تشتركان إلى حد كبير في قاعدة الشيفرة، مع اختلاف وظيفتهما الرئيسية.
CurlyShell
CurlyShell عبارة عن Reverse Shell يعمل داخل Linux ويتيح استقبال أوامر من البنية التحتية للتحكم وتنفيذها ثم إعادة النتائج. واستخدم آلية استمرار داخل Alpine Linux لإعادة تشغيل نفسه دوريًا.
CurlCat
CurlCat صُمم بصورة أكبر لتمرير البيانات وإنشاء قناة Proxy/Tunneling مرتبطة بـSSH بدل تنفيذ الأوامر مباشرة. وبهذا تمكن المهاجم من استخدام الـVM كنقطة وصول داخلية إلى الشبكة المستهدفة.
الفكرة الأخطر ليست اسم الأداتين بحد ذاته، بل نقل أدوات ما بعد الاختراق إلى نظام تشغيل آخر داخل الجهاز نفسه، بحيث تقل قيمة بعض قواعد الكشف التي تفترض أن النشاط الهجومي سيظهر كعمليات Windows.
هل هذه ثغرة أمنية في Hyper-V؟
لا يصف بحث Bitdefender ثغرة في Hyper-V تم استغلالها للحصول على الاختراق الأولي. Hyper-V ميزة افتراضية شرعية مدمجة في إصدارات Windows المدعومة، ويمكن تفعيلها بأدوات مثل DISM وPowerShell عندما يمتلك المستخدم الصلاحيات المناسبة. وتوثق Microsoft رسميًا طرق تثبيت وتفعيل Hyper-V.
كما أن أمر PowerShell Import-VM الذي ظهر في التحقيق وظيفة إدارية طبيعية هدفها استيراد آلة افتراضية من ملفاتها.
لذلك فإن البحث عن "تحديث يصلح ثغرة Hyper-V هذه" يعالج المشكلة من الزاوية الخطأ. المطلوب هو منع الوصول الإداري غير المصرح به، ومراقبة إساءة استخدام أدوات النظام، واكتشاف الآلات الافتراضية غير المعتمدة.
ما الذي يجب أن تبحث عنه فرق SOC وBlue Team؟
الميزة الدفاعية في هذه الحادثة أن إخفاء الحمولة داخل VM لم يجعل سلسلة الهجوم غير مرئية بالكامل. المهاجم يحتاج إلى تنفيذ عدة أنشطة على Windows قبل أن تصبح بيئة Linux جاهزة.
1. تفعيل Hyper-V في جهاز لا يحتاج إليه
ظهور Hyper-V فجأة على محطة عمل لا تستخدم الافتراضية يستحق التحقيق، خصوصًا إذا حدث التغيير بعد نشاط إداري غير معتاد أو تنفيذ PowerShell عن بُعد.
لا ينبغي اعتبار Hyper-V نفسه مؤشر اختراق؛ فالكثير من المطورين وفرق IT يستخدمونه بصورة شرعية. القيمة تأتي من مقارنة الحدث بخط الأساس الخاص بالمؤسسة.
2. مراقبة استيراد وتشغيل VMs الجديدة
ابحث عن استخدام غير متوقع لأوامر وإجراءات Hyper-V مثل Import-VM وStart-VM، خاصة على أجهزة المستخدمين التي لا يفترض أن تستضيف آلات افتراضية.
إنشاء ملفات .vmcx أو .vhdx في مسارات غير معتادة داخل ProgramData أو مجلدات تحاول التشبه بمكونات Microsoft الشرعية يستحق الفحص كذلك.
3. لا تفترض أن اسم WSL يعني WSL
في الحادثة أطلق المهاجمون اسم WSL على الـVM. لذلك يجب الاعتماد على نوع المورد وتقنية تشغيله، وليس الاسم المعروض فقط.
وجود VM باسم يبدو شرعيًا لا يثبت أنها جزء من البنية المعتمدة.
4. راقب حركة الشبكة وليس العمليات فقط
أكدت Bitdefender أن العزل داخل VM يحجب جزءًا من Telemetry الخاصة بالحمولة، لكن اتصالات C2 ما زالت بحاجة إلى مغادرة الجهاز عبر الشبكة.
لهذا تصبح NDR، وتحليل DNS، وProxy Logs، وFirewall Telemetry، وNetFlow أو حلول فحص الشبكة على المضيف طبقات مكملة مهمة لـEDR.
هذه الحادثة مثال عملي على أهمية الدفاع متعدد الطبقات في الأمن السيبراني بدل افتراض أن منتج Endpoint واحد قادر على تغطية جميع مسارات الهجوم.
5. راقب LSASS وKerberos أيضًا
لم يقتصر التحقيق على Hyper-V. اكتشفت Bitdefender أيضًا PowerShell مرتبطًا بالتلاعب بتذاكر Kerberos والوصول إلى LSASS، وهي أنشطة تحدث خارج الـVM وتوفر فرص كشف إضافية.
لذلك فإن تركيز الصيد على "Linux VM" وحدها قد يفوّت أجزاء أكثر وضوحًا من سلسلة الاختراق، مثل سرقة الاعتمادات والحركة الجانبية.
6. راجع Group Policy والحسابات المحلية
وجد الباحثون كذلك سكربتات موزعة عبر Group Policy أنشأت حسابات محلية أو أعادت ضبط كلمات مرورها بصورة متكررة بهدف الحفاظ على الوصول.
أي تغيير غير مصرح به في GPO أو إنشاء حسابات محلية متزامن على مجموعة من الأجهزة يجب أن يُعامل كحدث أمني عالي الأولوية.
كيف تقلل المؤسسات خطر هذا الأسلوب؟
قلّل الامتيازات الإدارية
تمكين Hyper-V واستيراد VMs وإجراء تغييرات عميقة على Windows يتطلب قدرات إدارية. لذلك يظل Least Privilege، وفصل الحسابات الإدارية، وتقليل Local Admin من أهم وسائل تقليص مساحة الهجوم.
حدد أين يُسمح باستخدام Hyper-V
إذا لم تكن الافتراضية مطلوبة على فئة معينة من أجهزة المؤسسة، يمكن التحكم فيها عبر سياسات الإدارة ومنع تفعيلها دون موافقة. أما في أجهزة المطورين أو المختبرات التي تحتاج Hyper-V، فيجب إدارة الآلات الافتراضية نفسها كأصول أمنية وليس كملفات مجهولة داخل الجهاز.
أدخل الـVMs في Asset Inventory
يجب أن يجيب الجرد الأمني عن أسئلة مثل: ما الآلات الافتراضية الموجودة؟ من أنشأها؟ ما نظام التشغيل بداخلها؟ ولماذا تحتاج إلى الشبكة؟
ظهور Guest جديد لا يعرفه فريق IT يجب ألا يمر دون مراجعة، خصوصًا على أجهزة لا تستخدم عادة كـHyper-V hosts.
لا تعتمد على Host EDR وحده
يجمع التصميم الأقوى بين Endpoint Telemetry ومراقبة الشبكة والهوية والسجلات المركزية. وإذا كانت المؤسسة تشغل Linux VMs بصورة شرعية، فمن الأفضل تحديد متطلبات حماية الضيوف أنفسهم وتثبيت الحساسات المناسبة عندما يكون ذلك مدعومًا ومطلوبًا.
راقب أدوات Windows الشرعية
PowerShell وDISM وHyper-V ليست أدوات خبيثة، وحظرها عشوائيًا قد يضر الإدارة الطبيعية. الأفضل بناء سياسات تسمح بالاستخدام المتوقع وتكشف الانحرافات: من شغّل الأداة، وعلى أي جهاز، وبأي حساب، وما الأحداث التي سبقتها وتلتها.
ادمج Endpoint وIdentity وNetwork Telemetry
لو نظر المحلل إلى عمليات Windows وحدها قد يرى Hyper-V وخدمات Microsoft شرعية. ولو نظر إلى الشبكة وحدها قد يرى اتصالًا صادرًا من IP جهاز معروف. الجمع بين السياقين هو ما يحول الأحداث المنفصلة إلى قصة هجوم قابلة للاكتشاف.
ماذا تفعل إذا اشتبهت بوجود VM خبيثة؟
إذا ظهرت مؤشرات تتطابق مع هذا النمط، يجب التعامل معها كحادث اختراق محتمل وليس مجرد مشكلة Hyper-V.
- اعزل الجهاز المتأثر وفق إجراءات Incident Response المعتمدة لمنع استمرار C2 أو الحركة الجانبية.
- حافظ على الأدلة قبل حذف الـVM أو ملفاتها، لأن إيقافها ومسحها مباشرة قد يدمر معلومات مهمة للتحقيق.
- اجرد جميع VMs والمفاتيح الافتراضية Virtual Switches وإعدادات Hyper-V الموجودة على المضيف.
- افحص ملفات VHDX وVMCX غير المعروفة وأماكن إنشائها وتوقيتها ومصدر تنزيلها.
- راجع سجل PowerShell والأحداث الإدارية لمعرفة متى تم تفعيل Hyper-V واستيراد وتشغيل الـVM.
- حقق في LSASS وKerberos إذا ظهرت مؤشرات لسرقة الاعتمادات أو Ticket Injection.
- راجع Group Policy والحسابات المحلية على مستوى الدومين، وليس الجهاز المصاب فقط.
- نفّذ Threat Hunt على بقية البيئة للبحث عن VMs أو مسارات أو حسابات أو أنماط شبكة مشابهة.
- غيّر بيانات الاعتماد المتأثرة بالترتيب الصحيح إذا أثبت التحقيق تعرض الحسابات أو تذاكر المصادقة للخطر.
- أعد بناء الأنظمة عند الحاجة إذا لم يتمكن الفريق من إثبات إزالة آليات الاستمرار بصورة موثوقة.
وتوفر Bitdefender ملف Indicators of Compromise العام الخاص بتحقيق Curly COMrades. يمكن استخدام هذه المؤشرات كبداية للصيد، لكن لا ينبغي الاعتماد عليها وحدها، لأن العناوين والبنى التحتية والأدوات يمكن تغييرها بينما تبقى التقنية السلوكية نفسها فعالة.
ماذا تغير بعد الحادثة حتى 2026؟
أهم استنتاج ما زال صالحًا في 2026 هو أن هذه التقنية ليست مشكلة تُحل بتوقيع Malware واحد أو CVE واحد. إنها مثال على إساءة استخدام طبقة افتراضية شرعية لإنشاء حدود جديدة للرؤية الأمنية.
كذلك فإن الأجهزة التي تناولها التحقيق الأصلي كانت تعمل بنظام Windows 10. ومنذ 14 أكتوبر 2025 انتهى الدعم العام لـWindows 10، وفق Microsoft. المؤسسات التي ما زالت تشغّل إصدارات Windows 10 القياسية في 2026 تحتاج إلى مسار مدعوم، مثل Extended Security Updates عندما ينطبق أو الانتقال إلى Windows 11، بدل ترك أجهزة غير محدثة ضمن بيئة المؤسسة.
لكن الانتقال من Windows 10 وحده لا يعالج تقنية Curly COMrades؛ Hyper-V ميزة شرعية أيضًا في Windows 11 Pro وEnterprise. الحل الحقيقي هو التحكم في الامتيازات والافتراضية، ومراقبة إنشاء الـVMs، وتوسيع الرؤية إلى الشبكة والهوية والأنظمة الضيفة.
الخلاصة
أظهر تحقيق Curly COMrades أن المهاجم لا يحتاج دائمًا إلى تعطيل EDR أو مهاجمته مباشرة. في بعض الحالات يكفيه نقل الجزء الأكثر حساسية من نشاطه إلى بيئة لا يغطيها الحساس الموجود.
استخدم المهاجمون Hyper-V على أجهزة Windows مخترقة لتشغيل Alpine Linux خفيف، ووضعوا CurlyShell وCurlCat بداخله، ثم استفادوا من عزل الـVM وشبكة Hyper-V لتقليل رؤية أدوات الحماية القائمة على المضيف.
لكن التقنية تركت إشارات دفاعية متعددة: تفعيل Hyper-V، استيراد VM غير معروفة، ملفات VHDX وVMCX غير معتادة، نشاط PowerShell، اتصالات شبكية جديدة، تلاعب Kerberos وLSASS، وتغييرات في الحسابات وGroup Policy.
الدرس الأهم ليس أن EDR أصبح عديم الفائدة، بل أن EDR يجب أن يكون جزءًا من منظومة رؤية متعددة الطبقات. عندما تُراقب المؤسسة المضيف والضيف والشبكة والهوية والتغييرات الإدارية معًا، يصبح إخفاء الحمولة داخل آلة افتراضية أصعب بكثير من مجرد تجاوز حساس واحد.