عبارة «قراصنة كوريا الشمالية» لا تشير إلى حملة واحدة أو مجموعة واحدة تستخدم الأسلوب نفسه. في السنوات الأخيرة ظهرت عدة مسارات مرتبطة بجهات موالية لجمهورية كوريا الديمقراطية الشعبية (DPRK): مهاجمون ينتحلون صفة جهات توظيف لإصابة الباحثين عن عمل ببرمجيات خبيثة، وعمّال IT يحصلون على وظائف فعلية بهويات مزيفة، وعمليات منفصلة تستهدف شركات العملات الرقمية مباشرة.
أحد أهم هذه المسارات هو Contagious Interview، وهي حملة مرتبطة بكوريا الشمالية تستغل مقابلات العمل والاختبارات البرمجية لاستهداف المطورين والعاملين في قطاع العملات الرقمية. وحتى 2026 لم تختفِ الحملة؛ بل وثقت Elastic Security Labs نشاطًا جديدًا في مايو 2026 استخدم مشروع اختبار برمجي مفخخًا لإصابة المطورين.
المهم هنا هو عدم الخلط بين كل هذه الأنشطة. BeaverTail وClickFix وعمّال IT المزيفون وسرقة منصات العملات الرقمية قد ترتبط جميعها بمصالح DPRK، لكنها ليست مراحل إلزامية لهجوم واحد ولا ينبغي نسب كل نشاط منها تلقائيًا إلى المجموعة نفسها.
ثلاثة نماذج مختلفة يجب التمييز بينها
| النموذج | من يتعرض للخداع؟ | الهدف الأساسي | مثال |
|---|---|---|---|
| Contagious Interview | الباحث عن وظيفة أو المطور | إصابته ببرمجية خبيثة وسرقة Credentials أوبيانات أوأصول رقمية | BeaverTail واختبارات البرمجة المفخخة |
| DPRK Remote IT Workers | الشركة التي تقوم بالتوظيف | الحصول على راتب ووصول شرعي إلى بيئة الشركة تحت هوية مزيفة | Laptop farms وهويات مسروقة |
| هجمات العملات الرقمية | شركة Crypto أوDeFi أوأفراد ذوو وصول حساس | سرقة الأصول الرقمية | TraderTraitor وهجوم Bybit |
هذا الفصل مهم لأن إجراءات الدفاع تختلف. اكتشاف مستودع برمجي مفخخ يحتاج ضوابط مختلفة عن التحقق من هوية موظف Remote، كما أن حماية مفاتيح ومحافظ العملات الرقمية تتطلب طبقات أخرى من الحماية.
ما هي حملة Contagious Interview؟
بدأ الباحثون بتوثيق Contagious Interview علنًا منذ 2023، مع أدلة على نشاط أقدم. كان السيناريو المعتاد يعتمد على شخص ينتحل دور Recruiter أوصاحب شركة ويتواصل مع مطور عبر منصة وظائف أوشبكة اجتماعية، ثم يدعوه إلى مقابلة تقنية أويرسل إليه مشروعًا لاختبار مهاراته.
المشروع أوالبرنامج الذي يُطلب من الضحية تشغيله لا يكون اختبارًا بريئًا بالضرورة؛ فقد يحتوي على كود يؤدي إلى سرقة البيانات أوتنزيل مراحل خبيثة أخرى. وقد وثقت Unit 42 استخدام تطبيقات مؤتمرات فيديو مزيفة ومستودعات برمجية ضمن هذه العمليات.
أصبحت الحملة اليوم كيانًا موثقًا أيضًا في MITRE ATT&CK تحت المعرّف G1052. ووفق MITRE، تستهدف Contagious Interview أنظمة Windows وLinux وmacOS، وتركز بدرجة كبيرة على المطورين والأشخاص العاملين في البرمجيات والعملات الرقمية.
هي في جوهرها صورة شديدة التخصيص من التصيد والهندسة الاجتماعية: بدل إرسال فاتورة مزيفة أوصفحة تسجيل دخول فقط، يبني المهاجم سيناريو توظيف كاملًا يجعل تشغيل الكود يبدو جزءًا طبيعيًا من المقابلة.
أين تدخل BeaverTail في الهجوم؟
BeaverTail عائلة Malware مرتبطة بحملة Contagious Interview. ويسجلها MITRE ATT&CK باسم S1246، مع إصدارات JavaScript وC++ وقدرة على العمل عبر أكثر من نظام تشغيل.
وظيفتها لا تقتصر على تنزيل ملف آخر. من القدرات التي وثقتها المصادر الأمنية البحث عن معلومات مخزنة في المتصفحات واستهداف بيانات اعتماد وامتدادات مرتبطة بمحافظ العملات الرقمية، إضافة إلى العمل كـDownloader لحمولات لاحقة.
ارتبط BeaverTail تاريخيًا أيضًا ببرمجية InvisibleFerret المبنية على Python، وهي مرحلة أكثر قدرة على البقاء والتحكم وسرقة المعلومات. وقد وثقت Unit 42 عدة إصدارات من BeaverTail وInvisibleFerret ضمن عمليات التوظيف المزيفة.
لكن وجود Contagious Interview لا يعني أن BeaverTail يجب أن تظهر في كل حادثة. الحملات تتغير، وقد استخدمت عمليات أحدث Loaders وRATs وعائلات Malware مختلفة.
ما هي ClickFix ولماذا استخدمها المهاجمون؟
ClickFix ليست ثغرة في Windows أوmacOS، بل أسلوب هندسة اجتماعية يجعل الضحية ينفذ بنفسه أمرًا خبيثًا بحجة إصلاح مشكلة تقنية.
قد تعرض صفحة مزيفة، على سبيل المثال، مشكلة في الكاميرا أوالميكروفون أوخطأ في التحقق، ثم تطلب من المستخدم نسخ تعليمات وتشغيلها على جهازه. بدل أن يستغل المهاجم Vulnerability للحصول على التنفيذ، يتحول المستخدم نفسه إلى نقطة التنفيذ.
لهذا يصنف MITRE هذا السلوك ضمن User Execution: Malicious Copy and Paste. وتشترك ClickFix مع التصيد في الاعتماد على الثقة والسياق، لكنها تدفع الضحية إلى تنفيذ خطوة محلية على الجهاز بدل الاكتفاء بإدخال كلمة مرور في صفحة مزيفة.
ماذا حدث في موجة BeaverTail وClickFix خلال 2025؟
في سبتمبر 2025 نشرت GitLab Threat Intelligence تحليلًا لبنية كانت تستخدم منذ مايو من العام نفسه لتوزيع إصدارات من BeaverTail وInvisibleFerret.
كان هناك تغيران مهمان مقارنة بالصورة التقليدية للحملة.
- استخدام ClickFix ضمن منصة توظيف مزيفة لإقناع الضحية بتنفيذ المرحلة الأولية.
- توسيع بعض الطعوم إلى وظائف التسويق والتداول في شركات Web3 وإلى قطاع التجزئة، بدل الاقتصار على مطوري البرمجيات.
كما ظهرت نسخ مجمّعة يمكن تشغيلها على أجهزة لا تحتوي بالضرورة على بيئات تطوير معتادة. وهذا جعل سيناريو الاستهداف مناسبًا لجمهور أوسع من المطورين فقط.
لكن توجد نقطة مهمة كانت تضيع في كثير من التغطيات: GitLab قيّمت هذه البنية في ذلك الوقت باعتبارها على الأرجح نشاطًا قيد الاختبار، ولم تجد دليلًا على أن هذه الموجة المحددة وُزعت على نطاق واسع. لذلك لا يصح تحويل ملاحظة «توسع الأهداف» إلى ادعاء بأن جميع موظفي التسويق أوالتداول أصبحوا ضمن حملة ضخمة مؤكدة.
ما الذي تغيّر في 2026؟
أهم تحديث هو أن نموذج «المقابلة المعدية» نفسه استمر، لكن طريقة التنفيذ وMalware المستخدمة لم تبق ثابتة.
في 26 مايو 2026 رصدت Elastic حسابًا ينشر عرض عمل داخل مساحة Slack مجتمعية. نُقل المهتمون لاحقًا إلى رسائل خاصة وطُلب منهم إنجاز Coding Challenge باستخدام مشروع يبدو عاديًا.
وفق تحليل Elastic المنشور في يوليو 2026، كان المشروع مفخخًا، واستُخدمت ملفات SVG خاصة بالأعلام لإخفاء أجزاء مشفرة من الحمولة داخل المشروع. عند تشغيل التطبيق، يعاد تجميع الكود وتبدأ سلسلة متعددة المراحل ارتبط سلوكها بعائلة OTTERCOOKIE.
شملت وظائف السلسلة التي حللتها Elastic سرقة Credentials، والبحث عن أصول مرتبطة بالعملات الرقمية، وسرقة ملفات، والوصول عن بُعد، ومراقبة Clipboard.
هذه الواقعة مهمة لسببين. أولًا، تؤكد أن Contagious Interview بقيت تهديدًا فعليًا في 2026. ثانيًا، تظهر أن الدفاع القائم على حفظ اسم Malware واحد مثل BeaverTail ليس كافيًا؛ المهاجم يستطيع تغيير Loader أوطريقة الإخفاء مع إبقاء الخدعة الأساسية نفسها: «شغّل هذا المشروع حتى نقيّم مهاراتك».
كما حدّث MITRE صفحة Contagious Interview في يوليو 2026 لتشمل مجموعة واسعة من الأساليب المرصودة، من مستودعات الكود وحسابات التواصل المزيفة إلى ClickFix واستهداف Credentials والبنية السحابية.
لماذا يعد جهاز المطور هدفًا عالي القيمة؟
جهاز Developer قد يجمع في مكان واحد أشياء لا تجتمع عادة على جهاز مستخدم عادي:
- GitHub أوGitLab credentials.
- SSH keys.
- Cloud credentials.
- API tokens.
- Source code خاص بالشركة.
- أسرار داخل ملفات البيئة المحلية.
- صلاحيات CI/CD أوPackage publishing.
- محافظ أوإضافات متصفح مرتبطة بالعملات الرقمية.
لهذا قد تبدأ الحادثة بإصابة Endpoint واحد، ثم تتحول إلى مشكلة أكبر إذا حصل المهاجم على مفاتيح أوصلاحيات تسمح له بالوصول إلى مستودعات أوأنظمة أخرى.
هذا هو السبب نفسه الذي يجعل حماية حسابات المطورين وسلسلة الحزم مهمة في أمان GitHub وnpm وسلسلة توريد البرمجيات. المشروع الذي يبدو مجرد Coding Challenge يجب ألا يحصل تلقائيًا على الثقة نفسها التي يحصل عليها كود داخلي تمت مراجعته.
عمّال IT الكوريون الشماليون: هجوم مختلف تمامًا
المسار الثاني يبدأ من الاتجاه المعاكس. بدل أن يتظاهر المهاجم بأنه شركة توظف الضحية، يتظاهر العامل بأنه مرشح شرعي وتحصل المؤسسة نفسها على موظف بهوية مزيفة أوبيانات شخص آخر.
تحذر الجهات الأمريكية منذ سنوات من استخدام هويات ووثائق وحسابات ومواقع وشركات واجهة وأجهزة موجودة في دول أخرى لإخفاء الموقع الحقيقي لبعض DPRK Remote IT Workers.
كما حذر FBI في يناير 2025 من أن الخطر لم يعد مقتصرًا على دفع رواتب بصورة غير مشروعة؛ فقد رُصدت حالات تضمنت نسخ بيانات وSource Code، وسرقة معلومات حساسة، وفي بعض الحالات ابتزاز الشركات بعد اكتشاف النشاط.
يمكن استخدام ما يعرف باسم Laptop Farm: يُرسل حاسوب الشركة إلى عنوان يبدو محليًا، بينما يوفر شخص آخر للمستخدم الموجود خارج البلد وسيلة للتحكم في الجهاز عن بُعد. بالنسبة إلى بعض أنظمة الشركة قد يبدو الاتصال وكأنه صادر من جهاز موجود في المكان المتوقع.
هل استمرت قضية Remote IT Workers في 2026؟
نعم. وتوجد هنا أدلة قانونية أحدث من تقارير Threat Intelligence وحدها.
في 15 أبريل 2026 أعلنت وزارة العدل الأمريكية الحكم على شخصين أمريكيين لدورهما في تسهيل مخطط Remote IT Workers مرتبط بكوريا الشمالية. وبحسب الوزارة، شمل المخطط أكثر من 100 شركة واستخدم هويات ما لا يقل عن 80 شخصًا وحقق أكثر من خمسة ملايين دولار من الإيرادات لصالح DPRK.
وتلت ذلك أحكام أخرى في مايو 2026 ضمن الجهود نفسها ضد مشغلي Laptop Farms.
هذا يجعل التوظيف نفسه جزءًا من Attack Surface. فالشركة التي تتحقق جيدًا من البرمجيات والهوية والسحابة لكنها تسمح لشخص غير موثوق بالحصول على حساب Developer وVPN وGitHub وCloud privileges قد تتجاوز بيدها عدة طبقات أمنية.
ماذا عن سرقة العملات الرقمية؟
الدافع المالي موجود أيضًا خارج حملات التوظيف. ومن أوضح الأمثلة هجوم Bybit في فبراير 2025.
أعلن FBI في 26 فبراير 2025 أن كوريا الشمالية مسؤولة عن سرقة نحو 1.5 مليار دولار من الأصول الافتراضية من Bybit في 21 فبراير، وربط النشاط الذي تناولته النشرة باسم TraderTraitor.
لكن هذا لا يعني أن «BeaverTail سرقت 1.5 مليار دولار» أوأن Contagious Interview كانت بالضرورة سلسلة الهجوم الخاصة بحادثة Bybit. اشتراك العمليات في الارتباط بكوريا الشمالية أوفي الاهتمام بالعملات الرقمية لا يجعلها الحملة التقنية نفسها.
وعند التعامل مع مستخدمي العملات المشفرة يجب أيضًا الانتباه إلى حملات مستقلة تمامًا، مثل PoisonSeed واستهداف عبارات استرداد المحافظ، لأن وسائل سرقة الأصول الرقمية متعددة ولا تعتمد دائمًا على Malware.
هل تستخدم هذه الجهات الذكاء الاصطناعي والتزييف العميق؟
نعم، لكن يجب وصف الدور بدقة. استخدام AI لا يعني وجود «ذكاء اصطناعي ينفذ الهجوم بالكامل».
ذكرت Microsoft Threat Intelligence في 2025 أن Remote IT Workers مرتبطين بكوريا الشمالية استخدموا أدوات AI لتحسين الصور وتعديل مواد مرتبطة بالهوية والتوظيف، إلى جانب استخدام Voice-changing software في بعض العمليات.
الاستخدام العملي هنا هو دعم Social Engineering وإنتاج Personas أكثر إقناعًا وتسريع بعض أعمال البحث والمحتوى، وليس استبدال المهاجم البشري بالكامل.
كيف تحمي المطورين من مقابلات العمل المفخخة؟
القاعدة الأكثر أهمية هي أن الكود القادم من Recruiter أوCoding Challenge يجب أن يعامل ككود غير موثوق حتى تثبت سلامته.
- تحقق من الشركة والوظيفة واسم Recruiter عبر قنوات مستقلة.
- لا تشغّل مشروع مقابلة مجهولًا على جهاز الشركة أوالجهاز الذي يحتوي أسرارًا ومفاتيح إنتاجية.
- راجع
package.jsonوScripts والتبعيات والكود الذي يعمل عند بدء المشروع قبل التنفيذ. - استخدم بيئة اختبار معزولة ومحدودة الصلاحيات عندما يكون تشغيل المشروع ضروريًا.
- لا تمنح المشروع Tokens أوSSH keys أوCloud credentials لا يحتاجها.
- اعتبر طلب تعطيل Sandbox أوDocker أوأداة الحماية حتى «يعمل الاختبار» إشارة خطر قوية.
- لا تنسخ أمر Terminal أوPowerShell من صفحة توظيف لمجرد أنها تزعم إصلاح الكاميرا أوالميكروفون.
لا تكفي أيضًا سمعة GitHub وحدها. وجود الكود داخل Repository لا يعني أن المستودع أوصاحبه موثوقان.
كيف تقلل الشركات خطر Remote IT Workers المزيفين؟
الدفاع هنا يحتاج تعاون HR وIT وIdentity وSecurity بدل ترك التحقق لفريق واحد.
- التحقق من الهوية والخبرة وبيانات المرشح عبر أكثر من مصدر.
- مراجعة التناقضات الكبيرة بين موقع المرشح وبيانات الاتصال والجهاز، دون تحويل الجنسية أواللهجة إلى معيار اتهام.
- تطبيق Least Privilege منذ أول يوم عمل.
- استخدام أجهزة Managed بدل السماح بالوصول العشوائي من أجهزة شخصية.
- مراقبة تثبيت أدوات Remote Desktop أوRemote Management غير المصرح بها.
- مراجعة عمليات الوصول غير المعتادة إلى Git repositories وCloud storage.
- مراقبة النسخ الضخم للكود أوالبيانات الحساسة إلى حسابات أوخدمات خارجية.
- إبطال Sessions وCredentials سريعًا عند انتهاء علاقة العمل أوظهور حادثة.
- فصل صلاحيات التطوير عن أسرار Production والأصول المالية كلما أمكن.
لا ينبغي التعامل مع Signal واحدة مثل عنوان IP أوتغيير الموقع كدليل على أن الموظف تابع لكوريا الشمالية. التحقيق الأمني الجيد يجمع عدة أدلة تقنية وإدارية قبل الوصول إلى استنتاج.
ماذا تفعل إذا شغّلت مشروع مقابلة مشبوهًا؟
إذا شغّلت بالفعل Repository أوبرنامجًا أرسله Recruiter غير موثوق، فلا يكفي حذف المجلد والافتراض أن المشكلة انتهت.
- أوقف استخدام الجهاز في الأعمال الحساسة وافصله عن الشبكة عند وجود مؤشرات قوية على الإصابة.
- إذا كان جهاز شركة، أبلغ فريق الأمن أوIncident Response فورًا بدل محاولة تنظيفه سرًا.
- من جهاز موثوق، راجع Sessions النشطة وألغِ الجلسات غير الضرورية.
- تعامل مع Tokens وAPI keys وSSH keys وCloud credentials التي كانت متاحة على الجهاز باعتبارها معرضة للخطر حسب نتائج التحقيق.
- افحص سجلات GitHub وGitLab والبريد والسحابة بحثًا عن استخدام غير معتاد.
- راجع المحافظ وإضافات المتصفح وPassword Managers التي كانت موجودة على النظام.
- استخدم EDR والتحليل الجنائي لتحديد ما تم تنفيذه وما إذا كانت هناك Persistence أوحمولات إضافية.
- أعد بناء الجهاز من مصدر موثوق إذا أثبت التحقيق وجود اختراق لا يمكن ضمان تنظيفه بصورة موثوقة.
الخلاصة
التطور الأهم في حملات DPRK ليس اسم Malware واحدة، بل استخدام الثقة المهنية والتوظيف كوسيلة للوصول. Contagious Interview استمرت من مستودعات وتطبيقات مزيفة إلى ClickFix ثم إلى مشاريع برمجية أكثر تمويهًا في 2026، بينما يمثل Remote IT Workers مسارًا آخر يجعل الشخص المزيف نفسه صاحب وصول شرعي إلى الشركة.
ولهذا فإن حظر Hash أوDomain بعد اكتشافه لا يحل المشكلة وحده. الدفاع الأكثر استدامة هو حماية Developer Workstations والأسرار والمستودعات، وعزل الكود غير الموثوق، ومراقبة الهوية والجلسات، وتشديد عملية Remote Hiring، وتقليل الصلاحيات التي يحصل عليها أي مستخدم أوجهاز قبل إثبات حاجته إليها.