يتجه مجرمو الإنترنت بشكل متزايد نحو استغلال الأدوات الموجودة بالفعل داخل أنظمة ويندوز لتنفيذ هجماتهم، وقد أصبح MSBuild.exe أحد أدواتهم المفضلة. تعمل هذه الأداة، التي يوثقها نظام التشغيل نفسه، على تنفيذ تعليمات برمجية خبيثة دون ترك ملف تنفيذي تقليدي على القرص.
تم تصميم MSBuild.exe في الأساس لمساعدة مطوري البرمجيات على بناء وتجميع التطبيقات باستخدام ملفات مشاريع تعتمد على XML. نظراً لأنها تحمل توقيعاً رقمياً رسمياً من مايكروسوفت، فإن معظم حلول الأمان تتعامل معها على أنها آمنة. وقد استغل المهاجمون هذا الثقة لإدراج تعليمات برمجية خبيثة بلغة C# مباشرة في ملفات المشاريع وتنفيذها في الذاكرة، تاركين آثاراً قليلة أو معدومة على نظام الملفات، مما يجعل الهجوم غير مرئي تقريباً لأدوات الكشف التقليدية.
استغلال MSBuild.exe في الهجمات الإلكترونية
كشف محللون من ASEC عن سيناريوهين حقيقيين لهجمات تم فيها استغلال MSBuild.exe كأداة “Living Off the Land Binary” (LOLBin). في الهجوم الأول، الذي لوحظ في يناير 2025، أثبتت الأداة قدرتها على إنشاء اتصال TCP Reverse Shell دون إثارة أي تنبيه من Windows 11 Defender، حتى مع تمكين المراقبة في الوقت الفعلي.
أما الحملة الثانية، الأكثر تعقيداً والتي تم اكتشافها في فبراير 2026، فقد عرضت قيام المهاجمين باستخدام MSBuild.exe كأداة لتنزيل ملفات خبيثة من خادم قيادة وتحكم خارجي (C2)، بالاقتران مع تقنية DLL Sideloading.
مميزات MSBuild.exe للمهاجمين
يعود سبب جاذبية MSBuild.exe للمهاجمين إلى ثلاثة عوامل رئيسية. أولاً، قدرتها على تنفيذ تعليمات C# البرمجية مباشرة داخل ملفات المشاريع، مما يلغي الحاجة إلى ملف تنفيذي مستقل. ثانياً، تدعم الأداة تحميل الملفات، والاتصال بالشبكة، وتنفيذ التعليمات البرمجية، وهي كافة المتطلبات التي يحتاجها المهاجم. وأخيراً، بما أنها موقعة رقمياً من قبل مايكروسوفت، فإنها تتجاوز بسهولة فحوصات التحقق من توقيع الكود التي تعتمد عليها العديد من أدوات أمن نقطة النهاية.
تتجلى خطورة هذه الهجمات في أن المؤسسات التي تعتمد فقط على برامج مكافحة الفيروسات التقليدية أو الكشف المستند إلى التواقيع تكون عمياء إلى حد كبير أمام هذه التقنيات. الطبيعة عديمة الملفات للهجوم تعني ترك القليل من الأدلة الجنائية على القرص، واستخدام أداة نظام موثوق بها يجعل من الصعب على المدافعين التمييز بين النشاط الضار وسير عمل المطورين الطبيعي.
سلوكيات الهجوم: التصيد، التنزيل، و DLL Sideloading
توضح حملة الهجوم التي جرت في فبراير 2026، والتي فصّلتها ASEC، آلية عمل هذا التهديد بشكل عملي. تبدأ الهجمة برسالة بريد إلكتروني تصيدية تحتوي على مرفق مضغوط يبدو كدعوة للاجتماع أو مستند متعلق بالعمل.
داخل الأرشيف، يجد الضحية ما يبدو ملفاً عادياً، ولكنه في الواقع نسخة من MSBuild.exe تم تغيير اسمها، مع الاحتفاظ بتوقيع مايكروسوفت الأصلي لتجنب إثارة الشبهات.
عندما يفتح الضحية الملف، يبدأ سلوك MSBuild.exe الافتراضي. تقوم الأداة تلقائياً بالبحث في نفس المجلد عن ملف مشروع (.csproj) وتحميله دون الحاجة إلى أي إدخال من المستخدم.
يحدث هذا بصمت، وعلى مستوى لا يمكن للمستخدمين اكتشافه. يحتوي ملف المشروع الذي تم تحميله على نص برمجي C# مضمن مع عناوين URL مشفرة بـ Base64 تشير إلى خادم C2 خارجي. يقوم النص البرمجي بفك تشفير هذه العناوين وتنزيل ثلاثة ملفات: ملف تنفيذي باسم عشوائي، وملف DLL باسم Avk.dll، وملف بيانات يسمى AVKTray.dat. يتم تخزين هذه الملفات بهدوء داخل المجلد المؤقت للنظام.
بمجرد التنزيل، يقوم MSBuild.exe بتشغيل الملف التنفيذي تلقائياً. هذا الملف التنفيذي، الذي يحمل أيضاً توقيعاً رقمياً صالحاً، يقوم بتحميل ملف Avk.dll الخبيث من نفس الدليل عبر DLL Sideloading، وبالتالي يقوم بحقن تعليمات المهاجم البرمجية مباشرة في الذاكرة.
في أي مرحلة من هذه السلسلة، لا يبدو الهجوم على أنه خبيث بشكل واضح لأدوات الأمان، وهذا هو بالضبط ما يجعله فعالاً.
للحماية من الهجمات التي تستغل MSBuild.exe، يجب على فرق الأمن مراقبة MSBuild.exe أثناء تنفيذه خارج بيئات المطورين، والإبلاغ عن ملفات .csproj التي تعمل من مجلدات مؤقتة أو مجلدات التنزيل، وتتبع اتصالات الشبكة الصادرة التي يقوم بها MSBuild، والكشف عن أنماط DLL Sideloading حيث تقوم الملفات التنفيذية الموقعة بشكل قانوني بتحميل ملفات DLL غير طبيعية.
يظل الاعتماد على نهج كشف متعدد الطبقات قائم على السلوك، بدلاً من الاعتماد على تواقيع الملفات وحدها، هو الطريقة الأكثر موثوقية لاكتشاف هذا التهديد قبل حدوث الضرر.