برمجية أندرويد خبيثة تستعين بالذكاء الاصطناعي للسيطرة على الجهاز والتنقل داخله تلقائياً

لم تعد برمجيات أندرويد الخبيثة تعتمد فقط على أوامر ثابتة أو سيناريوهات مبرمجة مسبقاً. مع ظهور عائلة جديدة تحمل اسم RatHat، بدأ نموذج مختلف بالظهور: برمجية خبيثة لا تكتفي بسرقة البيانات أو إساءة استخدام صلاحيات النظام، بل تستعين بمحرك يعتمد على الذكاء الاصطناعي لفهم واجهة الجهاز والتنقل داخلها بشكل ديناميكي.

البحث الذي نشره فريق Zimperium zLabs يكشف عن برمجية تستهدف مستخدمي أندرويد عبر الإعلانات الخبيثة ورسائل SMS ومواقع التصيد التي تدفع المستخدم إلى تنزيل ملفات APK من خارج Google Play.

لكن الجزء الأكثر أهمية في RatHat لا يكمن فقط في طريقة الانتشار، بل في الطريقة التي تجمع بها بين إساءة استخدام صلاحيات Accessibility والوصول إلى ADB Shell وعوامل الاستمرارية والأنفاق العكسية، ثم تضيف فوق كل ذلك طبقة من الأتمتة الموجهة بالذكاء الاصطناعي.

#بداية الإصابة: ملف APK وصلاحيات تتحول إلى سيطرة كاملة

يعتمد RatHat، مثل العديد من عائلات البرمجيات الخبيثة على أندرويد، على إقناع المستخدم بتثبيت ملف APK من خارج المتجر الرسمي، ثم الحصول على صلاحيات Accessibility.

هذه الصلاحية صُممت في الأصل لمساعدة المستخدمين ذوي الاحتياجات الخاصة على التعامل مع واجهة النظام، لكنها تمنح التطبيق قدرة كبيرة على مراقبة عناصر الشاشة والتفاعل معها وتنفيذ إجراءات بالنيابة عن المستخدم.

عند إساءة استخدامها، تستطيع البرمجية الخبيثة قراءة محتوى الواجهة، الضغط على الأزرار، مراقبة تغيّر النصوص والتنقل بين التطبيقات والنوافذ الحساسة.

في حالة RatHat، لا تتوقف الإساءة عند هذا المستوى.

#من Accessibility إلى ADB Shell

واحدة من أبرز قدرات RatHat هي تفعيل:

Developer Options

ثم تشغيل:

Wireless Debugging

بهذه الطريقة تستطيع البرمجية الوصول إلى سياق تنفيذ محلي بامتيازات:

ADB Shell

دون الحاجة إلى وجود جهاز كمبيوتر خارجي متصل بالهاتف.

هذا الأسلوب يشبه آليات ظهرت سابقاً في عائلات أندرويد خبيثة مثل:

ToxicPanda

و:

RedHook

الوصول إلى ADB Shell يوسّع نطاق قدرة البرمجية بشكل كبير، لأنه ينقلها من مستوى التفاعل مع واجهة المستخدم فقط إلى القدرة على تشغيل أوامر داخل بيئة النظام بامتيازات أعلى من التطبيق التقليدي.

#العامل الأول: liblocal-service.so

بعد الوصول إلى ADB Shell، يقوم RatHat بتثبيت عامل مكتوب بلغة Go باسم:

liblocal-service.so

هذا العامل قادر على تنفيذ أوامر بامتيازات:

ADB Shell

كما يُستخدم لإنشاء آليات تتجاوز قيود البطارية وإدارة الاستمرارية داخل الجهاز.

الأهم أن العلاقة بين البرمجية الأساسية وهذا العامل ثنائية الاتجاه.

إذا توقفت البرمجية أو تمت إزالتها، يستطيع العامل إعادة تشغيلها أو استعادتها. وفي المقابل، إذا أُزيل العامل، تحاول البرمجية الأساسية إعادة تثبيته.

هذه البنية تجعل عملية الإزالة أكثر تعقيداً، لأن المكوّنين يعملان كقناتين منفصلتين للاستمرارية.

#العامل الثاني: نفق عكسي دائم إلى المهاجم

يستخدم RatHat عاملاً ثانياً باسم:

libmedia_codec.so

هذا المكوّن يعمل كعميل:

FRP Reverse Proxy

ويُنشئ نفقاً دائماً إلى البنية التحتية التي يتحكم بها المهاجم.

وجود نفق عكسي دائم يمنح المشغّل قناة اتصال مستقرة مع الجهاز المصاب، ويقلل الحاجة إلى الاعتماد على الاتصالات التقليدية المباشرة التي قد تكون أكثر وضوحاً أمام حلول الحماية.

#سرقة بيانات التطبيقات البنكية والعملات الرقمية

لا يقتصر RatHat على التحكم في الجهاز، بل يستخدم أيضاً صفحات HTML Overlay تستهدف تطبيقات بنكية وتطبيقات عملات رقمية.

تظهر هذه الصفحات المزيفة فوق التطبيق الحقيقي بهدف التقاط بيانات الحساب التي يُدخلها المستخدم.

يمكن استخدام هذه التقنية لاعتراض معلومات مثل:

Username
Password
PIN

إضافة إلى بيانات حساسة أخرى مرتبطة بالتطبيقات المستهدفة.

واجهات مزيفة مصممة لسرقة كلمات المرور وأرقام PIN — المصدر: Zimperium

#اعتراض الرسائل والإشعارات ورموز OTP

يمتلك RatHat مجموعة إضافية من القدرات التي ترفع مستوى الخطر على الحسابات المرتبطة بالجهاز المصاب.

من بين هذه القدرات اعتراض:

SMS

والإشعارات التي قد تحتوي على:

One-Time Passwords

كما يستطيع تسجيل أحداث تغيّر النصوص داخل الواجهة، واستخراج الروابط من شريط عنوان المتصفح، والتقاط بيانات شاشة القفل بما في ذلك:

PIN

و:

Password

وأنماط فتح الشاشة.

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

#الذكاء الاصطناعي يدخل مرحلة التحكم في واجهة الجهاز

الجانب الأكثر تميزاً في RatHat هو استخدام محرك لأتمتة واجهة المستخدم يعتمد على الذكاء الاصطناعي.

بحسب Zimperium، يقوم المحرك بتحويل شجرة واجهة أندرويد الخاصة بخدمة:

Accessibility

إلى صيغة:

XML

ثم يرسلها إلى مساعد ذكاء اصطناعي شائع لم يُذكر اسمه في التقرير.

بدلاً من الاعتماد فقط على إحداثيات ثابتة أو سيناريوهات UI Automation جامدة، يستطيع النظام طلب تحليل بنية الواجهة الحالية واتخاذ قرار بناءً على العناصر الموجودة فعلياً على الشاشة.

#ماذا يطلب RatHat من نموذج الذكاء الاصطناعي؟

من بين المهام التي يكلّف بها RatHat النموذج:

تحديد إحداثيات منتصف عنصر واجهة يحمل اسماً معيناً.

تحديد النص الفعلي الظاهر داخل عنصر معين.

إرجاع أوامر تنقل مثل:

SCROLL_DOWN

أو تعليمات مشابهة تستخدم للتحرك داخل الواجهة.

بهذا الأسلوب تصبح عملية التحكم أكثر مرونة من الأتمتة المعتمدة بالكامل على سكربتات ثابتة.

نماذج من التعليمات المستخدمة في محرك التنقل المعتمد على الذكاء الاصطناعي — المصدر: Zimperium

#لماذا يغير الذكاء الاصطناعي طبيعة الأتمتة الخبيثة؟

الأتمتة التقليدية غالباً ما تعتمد على افتراضات ثابتة: مكان زر محدد، نص معين، تسلسل معروف للصفحات، أو إحداثيات لا تتغير.

أي تغيير في تصميم التطبيق أو مكان الزر قد يؤدي إلى فشل السيناريو بالكامل.

في RatHat، يحاول النظام تجاوز هذه المشكلة عبر إرسال الحالة الفعلية للواجهة إلى نموذج ذكاء اصطناعي وطلب تفسيرها.

بدلاً من:

Tap X=420 Y=810

يمكن أن يصبح المنطق أقرب إلى:

Find the button named "Allow"

ثم يستنتج النظام مكان العنصر الحالي من بنية الواجهة.

هذا لا يعني أن البرمجية أصبحت مستقلة بالكامل، لكنه يجعلها أكثر قدرة على التكيف مع الاختلافات بين الأجهزة والواجهات والإصدارات مقارنة بالسكربتات الثابتة.

#مقاومة الإزالة

يمتلك RatHat أيضاً آليات مخصصة لإفشال محاولات الإزالة.

عندما يحاول المستخدم إزالة التطبيق، تستطيع البرمجية اعتراض شاشة تأكيد إلغاء التثبيت وإلغاء العملية.

بعد ذلك يمكن أن تعرض واجهة مزيفة تحاكي:

Google Play

وتعرض رسالة خطأ وهمية لإقناع المستخدم بأن المشكلة ناتجة عن النظام أو المتجر.

وجود هذه الآلية بجانب الاستمرارية الثنائية بين التطبيق والعامل:

liblocal-service.so

يزيد صعوبة إزالة الإصابة بشكل تقليدي.

#تقنيات مضادة للتحليل

لم يقتصر تصميم RatHat على مقاومة المستخدم، بل شمل أيضاً وسائل تهدف إلى إرباك أدوات التحليل الأمني.

من بين التقنيات التي أشار إليها الباحثون:

APK Container Tampering

وتضخيم ملف:

AndroidManifest.xml

إلى حجم يقارب:

61 MB

إضافة إلى إدخال تعليمات زائفة وغير صالحة داخل ملفات:

DEX

الهدف من هذه الأساليب هو تعطيل أو إرباك الأدوات التي تعتمد على تحليل بنية الحزمة والـ DEX بشكل آلي.

بالنسبة لفرق تحليل البرمجيات الخبيثة، فإن هذه الأساليب تعني أن فشل أداة التحليل أو ظهور أخطاء في التفكيك لا يعني بالضرورة وجود ملف تالف، بل قد يكون جزءاً متعمداً من آليات الحماية المضادة للتحليل.

#سلسلة عمل RatHat داخل الجهاز

يمكن تلخيص مسار العمل على النحو التالي:

Malvertising / SMS / Phishing Site
                |
                v
        Malicious APK Install
                |
                v
    Accessibility Permission Abuse
                |
                v
     Enable Developer Options
                |
                v
       Enable Wireless Debugging
                |
                v
          Local ADB Shell
                |
        +-------+--------+
        |                |
        v                v
liblocal-service.so   libmedia_codec.so
        |                |
        v                v
Persistence /        FRP Reverse Tunnel
Command Execution        |
        |                v
        +----------> Remote Operator
                         |
                         v
                 AI-Guided UI Navigation
                         |
                         v
        Credential / OTP / PIN / Data Theft

#المخاطر من منظور أمني وGRC

تقنياً، يوضح RatHat كيف يمكن دمج عدة صلاحيات ومكوّنات تبدو منفصلة داخل سلسلة هجوم واحدة.

لكن من منظور الحوكمة والمخاطر والالتزام، فإن ظهور هذا النوع من البرمجيات يرفع أهمية إدارة مخاطر الأجهزة المحمولة إلى مستوى يتجاوز مكافحة البرمجيات الخبيثة التقليدية.

#ماذا يعني ذلك للمؤسسات؟

الاعتماد على سياسة تمنع تثبيت التطبيقات من خارج Google Play لم يعد مجرد إجراء وقائي بسيط، بل يمثل حاجزاً أولياً أمام سلسلة إصابة قد تتطور لاحقاً إلى سيطرة أعمق على الجهاز.

كذلك، فإن منح صلاحية:

Accessibility

لتطبيق غير موثوق يمثل قراراً أمنياً بالغ الحساسية.

في بيئات المؤسسات، يجب أن تنظر فرق الأمن إلى تفعيل:

Developer Options

أو:

Wireless Debugging

على الأجهزة المُدارة باعتباره مؤشراً مهماً يحتاج إلى رقابة وسياسات واضحة.

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

#مؤشرات سلوكية تستحق المراقبة

لا يقدّم المصدر قائمة IOC تقليدية من عناوين أو نطاقات، لكن السلوك نفسه يقدّم مجموعة من المؤشرات المهمة لفرق الأمن.

من أبرزها ظهور تطبيق غير موثوق يمتلك:

Accessibility Permission

مع تفعيل:

Developer Options

و:

Wireless Debugging

إضافة إلى وجود مكونات مثل:

liblocal-service.so

و:

libmedia_codec.so

أو ظهور اتصالات تتوافق مع نمط:

FRP Reverse Proxy

لكن هذه المؤشرات يجب التعامل معها ضمن سياق التحقيق الكامل، وليس باعتبارها دليلاً منفرداً على وجود RatHat.

#كيف يقلل المستخدم من احتمالية الإصابة؟

يوصي الباحثون بعدم تثبيت ملفات:

APK

من خارج:

Google Play

إلا عند وجود ثقة واضحة بالناشر.

كذلك يجب تجنب منح صلاحيات:

Accessibility

لتطبيقات لا تحتاج إليها فعلياً.

ومن المهم أيضاً فحص الجهاز دورياً باستخدام:

Google Play Protect

خصوصاً في الأجهزة التي تسمح بتثبيت التطبيقات من مصادر خارجية.

#الخلاصة

RatHat ليس مجرد حصان طروادة مصرفي جديد لنظام أندرويد، بل نموذج على تطور أوسع في طريقة بناء البرمجيات الخبيثة.

فهو يجمع بين إساءة استخدام:

Accessibility

والتحكم عبر:

ADB Shell

وعوامل استمرارية مكتوبة بلغة Go، ونفق:

FRP

وسرقة بيانات الدخول والرسائل، ثم يضيف فوق ذلك محركاً يعتمد على الذكاء الاصطناعي لتحليل الواجهة واتخاذ قرارات التنقل داخلها.

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

وبالنسبة لفرق الأمن والحوكمة، فإن الرسالة الأساسية واضحة: حماية الأجهزة المحمولة لم تعد تقتصر على اكتشاف تطبيق خبيث، بل أصبحت تشمل مراقبة الصلاحيات الحساسة، وإعدادات التطوير، وقنوات التحكم، وسلوكيات الاستمرارية، والاتصالات التي قد تمنح المهاجم قدرة تشغيلية طويلة الأمد داخل الجهاز.