كشفت Elastic Security Labs عن منظومة برمجيات خبيثة مصرفية تحمل اسم KREMLIN وتستهدف متصفحات مبنية على Chromium، وبصورة أساسية Google Chrome وMicrosoft Edge. المثير في هذه الحملة ليس سرقة كلمات المرور فقط، بل قدرة البرمجية على زرع إضافة متصفح خبيثة مع إعادة إنشاء قيم التحقق التي يستخدمها Chromium لحماية إعدادات المتصفح من التلاعب.
الحملة، التي تتعقبها Elastic باسم REF9334، ركزت بصورة رئيسية على مستخدمي المؤسسات والخدمات المصرفية في البرازيل. كما استخدمت بنية متعددة المراحل تشمل JavaScript وNode.js وبرامج C++ وتقنية DLL Sideloading، ثم أضافت منذ مايو 2026 طبقة غير معتادة: استخدام Ethereum Smart Contracts لتخزين وتغيير مواقع خوادم التحكم والسيطرة C2 ومواقع تنزيل الحمولة الخبيثة.
KREMLIN لا يعتمد فقط على إضافة متصفح خبيثة تقليدية. يبدأ عادةً بملف JavaScript يخدع المستخدم لتشغيله، ثم ينفذ سلسلة تحميل متعددة المراحل، ويزرع إضافة داخل Chrome أو Edge بعد تعديل ملف Secure Preferences وإعادة توليد قيم التكامل التي يتوقعها Chromium. بعد ذلك يستطيع سرقة Cookies وSession Tokens وبيانات تسجيل الدخول ومحتوى الصفحات وتنفيذ Keylogging واعتراض بعض طلبات الويب. كما يستخدم Smart Contracts على Ethereum كآلية Dead Drop Resolver لتغيير البنية التحتية دون الاعتماد على عنوان C2 ثابت.
ماذا حدث في حملة KREMLIN؟
تتبعت Elastic Security Labs نشاط REF9334 منذ مايو 2025، وربطت به سبع حملات مختلفة تطورت تدريجياً من أدوات تحميل وبرمجيات RAT إلى منظومة أكثر تكاملاً تستهدف المتصفح نفسه. استخدمت الحملات ملفات ورسائل تحاكي مستندات بنكية وفواتير ومستندات شركات، وكان بدء العدوى في الحالات التي حللتها Elastic يعتمد على قيام الضحية بتشغيل ملف خبيث.
ورغم الاسم، لا توجد دلالة في التقرير على أن اسم KREMLIN يعني ارتباط العملية بالحكومة الروسية. الاسم ظهر داخل البرمجية نفسها مع الاسم المستعار Kr3mlin4rt1st، بينما أظهرت المؤشرات التي درستها Elastic تركيزاً واضحاً على البرازيل، بما في ذلك اللغة البرتغالية وأسماء الطعوم المصرفية والبنية التشغيلية.
لا ينبغي تفسير اسم KREMLIN على أنه Attribution جغرافي أو سياسي. تسمية البرمجية مأخوذة من الاسم الموجود داخل عينات البرمجية، بينما تشير أدلة الحملة التي نشرتها Elastic إلى نشاط يستهدف القطاع المصرفي البرازيلي بصورة أساسية.
تمكنت Elastic كذلك من تسجيل نطاق Canary كانت البرمجية تستخدمه للتحقق من وجود Sandbox. أدى ذلك إلى ظهور اتصالات من 1,515 نظاماً مصاباً وقت إعداد التقرير، وكان نحو 98.75% منها في البرازيل. هذا الرقم يمثل الأنظمة التي رصدتها Elastic بهذه الآلية تحديداً، وليس بالضرورة إجمالي عدد الإصابات عالمياً.
كيف تبدأ العدوى؟ سلسلة KREMLIN متعددة المراحل
تعتمد الحملة على سلسلة تنفيذ تجعل اكتشافها أصعب من مجرد تشغيل ملف EXE واحد. يبدأ السيناريو الذي حللته Elastic عادةً بملف JavaScript يبدو كوثيقة مصرفية أو فاتورة أو مستند شركة.
بعد تشغيل الملف يختبر KREMLIN البيئة بحثاً عن مؤشرات تدل على Sandbox أو Virtual Machine. أحد الأساليب المرصودة كان عدّ الملفات الموجودة على سطح المكتب وعدد العمليات النشطة، ثم إيقاف التنفيذ إذا بدت البيئة أقرب إلى مختبر تحليل منها إلى جهاز مستخدم حقيقي.
تستخدم إحدى السلاسل Node.js لتنفيذ المرحلة التالية. وتسمح هذه البنية للمهاجم بتوزيع منطق التنفيذ بين عدة مكونات بدلاً من وضع جميع الوظائف داخل ملف واحد.
وثقت Elastic مهمة مجدولة باسم:
MicrosoftNodeRuntimeUpdaterويتم استخدامها لإعادة تشغيل مرحلة Node.js بعد تسجيل دخول المستخدم، ما يمنح البرمجية وسيلة بقاء داخل النظام.
بدلاً من تضمين جميع عناوين التنزيل داخل البرمجية، تستطيع بعض مراحل KREMLIN قراءة إعداداتها من Smart Contract على Ethereum. يسمح ذلك للمشغل بتغيير عنوان المرحلة التالية دون الحاجة إلى إرسال نسخة جديدة من البرمجية إلى الأجهزة المصابة.
وثق الباحثون أيضاً إساءة استخدام الملف الشرعي SentinelMemoryScanner.exe المرتبط بمنتجات SentinelOne لتحميل DLL خبيث ينتحل اسم:
SentinelAgentCore.dllوجود اسم SentinelOne في سلسلة الهجوم لا يعني أن منصة SentinelOne نفسها خبيثة أو مخترقة. الأسلوب هنا هو DLL Sideloading، حيث يستغل المهاجم سلوك تحميل مكتبة بواسطة برنامج شرعي وموقع رقمياً لتنفيذ DLL غير موثوق.
كيف يتجاوز KREMLIN آليات سلامة Chrome وEdge؟
يحمي Chromium إعدادات حساسة داخل ملفات Profile من خلال آليات Integrity Verification. ومن أهم الملفات هنا Secure Preferences، الذي يحتوي على إعدادات مرتبطة بالإضافات وغيرها من خصائص المتصفح.
إذا عدّلت برمجية عادية هذا الملف وأدرجت إضافة جديدة بطريقة مباشرة، فمن المفترض أن تكشف آليات التكامل أن البيانات لم تعد مطابقة للقيم المحمية. لكن KREMLIN لا يكتفي بتعديل الإعداد؛ بل يعيد إنشاء قيم التحقق التي يتوقع Chromium رؤيتها.
وفق تحليل Elastic، يقوم KREMLIN بإضافة ملفات الإضافة إلى ملفات تعريف المستخدمين، وتفعيل Developer Mode، ثم تحديث البيانات المرتبطة بالإضافة داخل Secure Preferences مع إعادة إنشاء قيم HMAC والـ encrypted hashes المطلوبة.
طورت Google تقنية App-Bound Encryption لتصعيب وصول برمجيات سرقة المعلومات إلى Cookies والبيانات المحمية في Windows، وذلك عبر ربط عملية فك التشفير بهوية التطبيق بدلاً من الاعتماد على حماية حساب المستخدم فقط.
لكن KREMLIN يذهب أبعد من قراءة ملف Cookies مباشرة. فقد رصد الباحثون تشغيل Chrome أو Edge تحت Debugger واستخراج معلومات تشفير من عملية المتصفح نفسها، ثم استخدامها لإنشاء القيم التي يحتاجها لتعديل ملف الإعدادات بصورة يقبلها المتصفح.
هذا لا يعني أن تشفير Chromium «تم كسره» رياضياً، كما أن تقرير Elastic لا يقدم KREMLIN باعتباره استغلالاً لثغرة Zero-Day جديدة في Chrome. البرمجية تعمل أساساً بعد حصول المهاجم على قدرة تنفيذ كود داخل جهاز Windows، ثم تستخدم تقنية موثقة للتلاعب بملف Profile وإعادة إنتاج قيم التكامل المطلوبة.
وهذه نقطة مهمة دفاعياً: تحديث Chrome وEdge يبقى ضرورياً، لكنه لا يغني عن حماية Endpoint ومنع تنفيذ الملفات الخبيثة ومراقبة تغييرات المتصفح.
ماذا يستطيع KREMLIN سرقته من المتصفح؟
الخطر الأكبر ليس ظهور إضافة مجهولة في قائمة Extensions فقط، بل الصلاحيات التي تحصل عليها الإضافة وقدرتها على العمل داخل الصفحات التي يزورها المستخدم.
الإضافة التي حللتها Elastic ظهرت باسم قريب من AVSync System Inc. وطلبت صلاحيات للوصول إلى Tabs وCookies وStorage وواجهات webRequest.
| القدرة | ما الذي يستطيع المهاجم الحصول عليه؟ | الخطر العملي |
|---|---|---|
| Cookie Theft | ملفات Cookies وبيانات الجلسة | الاستيلاء على جلسات مصادقة قائمة في بعض الخدمات |
| Session Storage / Local Storage | Tokens وبيانات يحتفظ بها تطبيق الويب داخل المتصفح | الوصول إلى معلومات لا تظهر داخل كلمة المرور نفسها |
| Screenshot | صورة التبويب النشط | التقاط بيانات حسابات أو معلومات مالية معروضة للمستخدم |
| Page Source | HTML الخاص بالصفحة المفتوحة | جمع محتوى التطبيق ومعلومات النموذج المعروض |
| Keylogging | النص المكتوب داخل حقول الإدخال | سرقة أسماء المستخدمين وكلمات المرور أو البيانات المدخلة |
| Request Interception | بعض بيانات طلبات HTTP المطابقة لقواعد الاستهداف | التجسس على تفاعل المستخدم مع المواقع المستهدفة |
| HTML Injection / Redirect | إضافة محتوى أو توجيه المستخدم وفق قواعد يرسلها C2 | إنشاء سيناريوهات تصيد داخل جلسة المتصفح نفسها |
إذا نجح المهاجم في الحصول على Cookie أو Session Token صالح، فقد يستطيع في بعض الخدمات استخدام الجلسة بعد إتمام الضحية لعملية تسجيل الدخول وMFA بالفعل. النتيجة تعتمد على كيفية إدارة الموقع للجلسات وربطها بالجهاز ومدة صلاحيتها وآليات اكتشاف سرقتها.
لهذا السبب، عند تأكيد الإصابة لا يكفي تغيير كلمة المرور فقط. يجب أيضاً إبطال الجلسات الحالية Revocation وتسجيل خروج الحساب من الأجهزة والجلسات النشطة بعد تنظيف الجهاز. للمزيد حول هذه الفكرة يمكن الرجوع إلى مقال شرح Session Hijacking وكيف يمكن سرقة الحساب دون معرفة كلمة المرور.
لماذا يستخدم KREMLIN عقود Ethereum الذكية؟
أحد أكثر الجوانب إثارة للاهتمام في الحملة هو استخدام Blockchain ليس لنقل الأموال فقط، بل كجزء من بنية التحكم بالبرمجية.
وثقت Elastic أول Smart Contract خبيث مرتبط ببنية KREMLIN في 19 مايو 2026. احتوى العقد على متغيرات تخزن مواقع مراحل البرمجية والإضافة، ويمكن للمشغل تحديث هذه القيم عبر معاملات Blockchain.
وفي الحملات اللاحقة أصبحت بعض المكونات تستخدم Ethereum كنوع من Dead Drop Resolver: تعرف البرمجية عنوان العقد، ثم تستخرج منه الموقع الحالي الذي يجب الاتصال به أو تنزيل الحمولة منه.
| الأسلوب التقليدي | استخدام Ethereum في KREMLIN |
|---|---|
| عنوان C2 مكتوب داخل البرمجية | البرمجية تستطيع قراءة الموقع الحالي من Smart Contract |
| حظر النطاق قد يعطل الاتصال | يمكن للمشغل تحديث القيمة المخزنة والإشارة إلى نطاق آخر |
| تحديث البنية قد يتطلب إصدار Malware جديد | يمكن تغيير بعض مواقع Payload وC2 عبر تحديث بيانات العقد |
| الاعتماد على بنية مركزية | يستفيد المهاجم من Blockchain عامة كطبقة Resolution |
هذا لا يجعل البنية «غير قابلة للإيقاف»، لكنه يجعل الاعتماد على حظر Domain واحد أقل فعالية. فريق الدفاع يحتاج إلى الجمع بين مؤشرات الشبكة والسلوك على Endpoint وتغييرات المتصفح وعمليات التنفيذ غير المعتادة.
كيف تكتشف KREMLIN وما الذي يجب فعله عند الاشتباه؟
بسبب قدرة الحملة على تغيير بعض البنية التحتية، يجب التعامل مع مؤشرات الاختراق IOCs كجزء من التحقيق وليس كقائمة ثابتة تكفي وحدها للكشف.
| المؤشر | القيمة أو المثال | الملاحظة |
|---|---|---|
| Threat Activity | REF9334 / KREMLIN | اسم التتبع المستخدم في بحث Elastic |
| Extension ID مرصود | ndpbidppejfanjbhfgjlohfanbfbklff |
مرتبط بعينة الإضافة الحديثة التي حللتها Elastic |
| اسم الإضافة | AVSync / AVSync System Inc. | لا تعتمد على الاسم وحده لأن المهاجم يستطيع تغييره |
| Scheduled Task | MicrosoftNodeRuntimeUpdater |
مؤشر Persistence في السلسلة الحديثة |
| Smart Contract | 0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b |
استخدمته عينات حديثة للحصول على إعدادات ديناميكية |
| Domain | volmira[.]site |
ظهر ضمن بنية تنزيل الإضافة وسرقة البيانات |
| Domain | zaviro[.]online |
ظهر ضمن البنية الحديثة |
| C2 | luizestrelhashapr[.]online |
ظهر كوجهة C2 للإضافة التي حللتها Elastic |
| Extension SHA-256 | 223be3f8648bf6998c4a58b972522e5fda8d9d0a57b4e163811930de66c3f7ca |
Hash لعينة محددة؛ قد تظهر إصدارات مختلفة لاحقاً |
لا تعتبر عدم وجود هذه النطاقات أو الـHash دليلاً على أن الجهاز نظيف. إحدى الخصائص الأساسية للحملة هي القدرة على تغيير البنية التحتية، كما استخدمت حملات KREMLIN السابقة Extension IDs ونطاقات وسلاسل تنفيذ مختلفة.
يمكن لمسؤول النظام التحقق من المهمة الموثقة في التقرير باستخدام PowerShell:
Get-ScheduledTask -TaskName "MicrosoftNodeRuntimeUpdater" -ErrorAction SilentlyContinue |
Select-Object TaskName, TaskPath, State, Actions, Triggersوجود المهمة يحتاج إلى تحقيق إضافي، خصوصاً إذا كانت Actions تشير إلى تشغيل Node.js أو ملفات ضمن مسار مستخدم غير معتاد.
$id = "ndpbidppejfanjbhfgjlohfanbfbklff"
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\*\Extensions\$id" `
-ErrorAction SilentlyContinue
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Edge\User Data\*\Extensions\$id" `
-ErrorAction SilentlyContinueيجب أيضاً فحص جميع Profiles وعدم الاكتفاء بالـDefault Profile، لأن KREMLIN يحاول نشر الإضافة داخل ملفات تعريف متعددة يستطيع الوصول إليها.
- تشغيل ملفات JavaScript أو JSE غير موثوقة من مجلد Downloads أو مسارات المستخدم.
- ظهور Node.js بصورة مفاجئة على جهاز موظف لا يحتاج إليه في عمله.
- Scheduled Task جديد يحمل اسماً يبدو مشروعاً لكنه يشغل ملفات من مسار المستخدم.
- تشغيل
SentinelMemoryScanner.exeمن موقع غير متوقع أو مع DLL غير موثوق بجانبه. - إطلاق Chrome أو Edge تحت Debugger أو وصول عملية غير معتادة إلى ذاكرة المتصفح.
- تغييرات غير مفسرة على Secure Preferences وملفات Extension داخل Browser Profiles.
- ظهور Developer Mode على أجهزة مؤسسية لا تستخدم إضافات داخلية غير Packed.
- وصول عمليات غير معتادة إلى ملفات Login Data أو Cookies أو Local State الخاصة بالمتصفح.
إذا كنت تجمع سجلات Windows وEndpoint Security مركزياً، يمكن ربط هذه السلوكيات داخل SIEM بدلاً من البحث عنها يدوياً. راجع أيضاً دليل Wazuh SIEM وXDR العملي لفهم كيفية تجميع الأحداث وتحويلها إلى تنبيهات قابلة للتحقيق.
- اعزل الجهاز عن الشبكة مع الحفاظ على الأدلة اللازمة للتحقيق.
- لا تكتفِ بحذف الإضافة. الحملة متعددة المراحل وقد توجد Persistence أو Payloads أخرى على الجهاز.
- راجع Scheduled Tasks والعمليات والملفات التي سبقت ظهور الإضافة.
- احصر الحسابات التي استُخدمت على Chrome أو Edge أثناء فترة الإصابة.
- بعد احتواء الجهاز، قم بإبطال Sessions وRefresh Tokens الخاصة بالحسابات الحساسة.
- غيّر كلمات المرور من جهاز موثوق ونظيف بعد إبطال الجلسات.
- راجع سجلات الهوية بحثاً عن Logins غير معتادة أو Tokens أعيد استخدامها.
- في الأجهزة الحرجة، قيّم إعادة بناء الجهاز من Image موثوقة بدلاً من الاعتماد على إزالة الملفات يدوياً فقط.
- حدّث EDR وBrowser وWindows ثم أجرِ فحصاً جديداً قبل إعادة الجهاز إلى الشبكة.
- استخدم سياسات Enterprise لإدارة إضافات Chrome وEdge، واسمح فقط بالإضافات المطلوبة للعمل عندما يكون ذلك عملياً.
- يمكن في البيئات المقيدة تطبيق Blocklist افتراضي لجميع الإضافات ثم Allowlist للإضافات المعتمدة.
- امنع Local Administrator عن حسابات الموظفين إلا عند وجود حاجة تشغيلية واضحة.
- استخدم Application Control مثل WDAC أو AppLocker للحد من تشغيل Scripts وبرامج غير معتمدة.
- راقب Browser Profile directories وملفات Secure Preferences عبر EDR أو File Integrity Monitoring.
- أنشئ Detection لسلوك الوصول إلى Chrome Login Data وCookies وLocal State بواسطة عمليات غير معتادة.
- اجمع DNS وProxy وEDR telemetry معاً لأن حظر Domain واحد لن يكون كافياً أمام بنية ديناميكية.
- طبق سياسات جلسات مناسبة للخدمات الحساسة، مع إمكانية Revocation سريع للجلسات عند وقوع Incident.
ميزة KREMLIN الأساسية هي الدمج بين تنفيذ محلي، وتلاعب بالمتصفح، وسرقة الجلسات، وبنية C2 قابلة للتغيير. لذلك يجب أن يكون الكشف متعدد الطبقات أيضاً: Endpoint + Browser + Identity + Network، وليس مجرد قائمة Domains داخل Firewall.
هل KREMLIN ثغرة في Google Chrome؟
KREMLIN هو Malware وليس اسم CVE أو ثغرة منفردة في Chrome. التقرير يصف استخدام تقنية لتعديل ملفات Profile وإعادة إنشاء قيم Integrity بعد حصول البرمجية على قدرة تنفيذ داخل Windows.
هل تحديث Chrome أو Edge يكفي للحماية؟
لا. تحديث المتصفح مهم دائماً، لكن سلسلة KREMLIN تبدأ من إصابة Endpoint وتشغيل كود خبيث ثم التلاعب بملفات المتصفح. تحتاج الحماية أيضاً إلى EDR وApplication Control وإدارة الإضافات ومنع تشغيل الملفات غير الموثوقة.
هل MFA يمنع سرقة الحساب في هذه الحالة؟
MFA يقلل كثيراً من خطر سرقة الحساب عبر كلمة المرور، لكنه لا يلغي خطر سرقة Session Token صالح بعد المصادقة. عند تأكيد الإصابة يجب إبطال الجلسات والرموز النشطة، وليس الاكتفاء بتغيير كلمة المرور.
لماذا يستخدم المهاجم Ethereum بدلاً من C2 عادي؟
الهدف هو استخدام Smart Contract كمرجع يمكن تحديثه ليشير إلى مواقع C2 أو Payload جديدة. بهذه الطريقة لا يعتمد بعض مكونات البرمجية على عنوان ثابت واحد مضمّن داخل الملف.
هل يجب حظر Ethereum داخل شبكة الشركة بسبب KREMLIN؟
ليس بالضرورة. القرار يعتمد على بيئة الشركة واستخداماتها المشروعة. الأهم هو مراقبة السلوك والاتصالات غير المعتادة، وحظر مؤشرات الاختراق المعروفة، وتطبيق سياسات Egress مناسبة، وعدم الاعتماد على حظر Blockchain بالكامل كحل وحيد.
الخاتمة
توضح حملة KREMLIN كيف انتقلت بعض برمجيات سرقة المعلومات من محاولة قراءة كلمات المرور والـCookies مباشرة إلى استهداف المتصفح باعتباره جزءاً من سلسلة الهوية نفسها. زرع إضافة خبيثة داخل Chrome أو Edge مع إعادة إنشاء قيم Integrity يجعل اكتشاف النشاط أصعب من مجرد البحث عن Extension مثبتة بالطريقة التقليدية.
كما أن استخدام Ethereum Smart Contracts لتغيير مواقع Payload وC2 يجعل القوائم الثابتة للمؤشرات قصيرة العمر. لذلك فإن أفضل استراتيجية دفاعية ليست مطاردة Domain جديد كل مرة، بل مراقبة سلسلة السلوك: تشغيل Script غير موثوق، Persistence غير معتادة، DLL Sideloading، الوصول إلى بيانات المتصفح، تعديل Secure Preferences، وسرقة أو إعادة استخدام Session Tokens.
بالنسبة لبيئات الشركات، الأولوية هي إدارة إضافات المتصفح مركزياً، تقليل صلاحيات المستخدمين، مراقبة Browser Profiles عبر EDR، وتجهيز إجراء Incident Response يتضمن إبطال جلسات المستخدمين فور الاشتباه بسرقة بيانات المتصفح.