ملخص تنفيذي

شهد مشهد تهديدات الأجهزة المحمولة تطورًا حاسمًا، حيث تحول من تعديل التطبيق (إعادة تعبئة ملفات APK) إلى معالجة بيئة وقت التشغيل عبر إطار LSposed. يسمح ناقل الهجوم الجديد هذا للجهات الفاعلة في مجال التهديد باختطاف تطبيقات الدفع المشروعة وغير المعدلة من خلال «إلقاء الضوء» على نظام تشغيل Android الأساسي. نظرًا لأن الوحدة الضارة (التي قمنا بتحليلها كانت تسمى «Digital Lutera») تربط واجهات برمجة التطبيقات على مستوى النظام بدلاً من التطبيق نفسه، يظل التوقيع الرقمي لتطبيق الدفع صالحًا، ويتجاوز بشكل فعال Google Play Protect وفحوصات التكامل التقليدية التي حددت سابقًا الثنائيات المعدلة.

في صميم هذه المنهجية هو التفكيك المنهجي لـ ربط بطاقة SIM باستخدام UPI، الدعامة الأمنية الأساسية للنظام البيئي المالي الهندي. من خلال ربط SMSManager و TelephonyManager، تقوم الجهات الفاعلة في مجال التهديد باعتراض رموز التسجيل الصادرة، وانتحال هويات الأجهزة (أرقام الهواتف)، وتسريب بيانات 2FA إلى Telegram. بشكل حاسم، تستخدم الوحدة سوكيت. يو للقيادة والتحكم في الوقت الفعلي (C2)، مما يسمح للمهاجمين بحقن سجلات الرسائل القصيرة المصطنعة عن بُعد في قاعدة بيانات الجهاز «المرسلة». هذا يخدع خوادم البنوك للتحقق من «وجود بطاقة SIM الفعلية» على جهاز يقع على بعد آلاف الأميال من بطاقة SIM الفعلية. ومع ذلك، تجدر الإشارة هنا إلى أن الشرط المسبق لتنفيذ هذا الهجوم هو أن المهاجمين يطلبون من الضحية بشكل عام اختراقها ملفات APK المجسمة مثل vahan challan المزيفة أو دعوة الزفاف التي يمكن للمهاجم قراءة/حذف/إعادة توجيه رسائل SMS من جهازها.

ويتمثل التأثير في التآكل الكامل للثقة في المصادقة القائمة على الأجهزة، مما يتيح عمليات الاستحواذ غير المصرح بها على الحسابات وتنسيق الاحتيال في الوقت الفعلي على نطاق واسع. وللتخفيف من هذه المخاطر، يجب على المؤسسات المالية تجاوز الكشف الأساسي عن الجذر وتنفيذه واجهة برمجة تطبيقات النزاهة في Google Play مع متطلبات MEETS_STRONG_INTEGRITY الصارمة لضمان قفل أداة تحميل التشغيل وعدم العبث بنظام التشغيل. علاوة على ذلك، يجب أن تنتقل أنظمة الواجهة الخلفية إلى التحقق من جانب الناقل، للتحقق من أن رسائل التسجيل اجتازت بالفعل الشبكة الخلوية بدلاً من الاعتماد على التأكيد المحلي للجهاز.

كيف تعمل الرسائل القصيرة المرتبطة ببطاقة UPI SIM؟

ال تجليد الجهاز العملية عبارة عن بروتوكول أمان متعدد القنوات. من خلال طلب تطابق بين إشارة SIM المادية (SMS) و طلب تطبيق رقمي (الإنترنت)، يضمن النظام أنه حتى إذا كان لدى المخترق التفاصيل المصرفية للمستخدم، فلن يتمكن من الوصول إلى الحساب دون الحيازة المادية لهاتف المستخدم وبطاقة SIM.

1. الإعداد الأولي (المرحلة 1.0 - 1.2)

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

2. إعداد الأجهزة (المرحلة 2.0 - 2.2)

في هذه المرحلة، يقوم التطبيق بإنشاء «بصمة رقمية» للجلسة:

• الخطوة 2.1: يحدد التطبيق الأجهزة المحددة (على سبيل المثال، فيفو V2338).
• الخطوة 2.2: إنه يولد رمز سري (على سبيل المثال، 29de0hb... 797ZQ). هذا رمز عشوائي لمرة واحدة يمنع «هجمات إعادة التشغيل» (يحاول المتسللون إعادة استخدام بيانات التحقق القديمة).

3. مرحلة الإثبات المادي (المرحلة 3.0 - 3.3)

هذا هو الفحص الأمني «Zero-Trust» الذي يثبت أن بطاقة SIM موجودة فعليًا داخل الهاتف.

• الخطوة 3.1 و 3.2: يقوم التطبيق بإنشاء رسالة نصية صامتة بصيغة TDL TRB [Token] وإرسالها إلى رقم التحقق الخاص بالبنك.
• الخطوة 3.3: عندما تمر الرسائل القصيرة عبر الشبكة الخلوية (Jio/Airtel)، يقوم الناقل تلقائيًا بإرفاق هوية المرسل - رقم الهاتف المحمول 8888888888—إلى رأس الرسالة. هذا «طابع» على مستوى الأجهزة لا يمكن للمستخدم تزويره.

4. رسم الخرائط من جانب خادم البنك (المرحلة 4.0 - 4.3)

يعمل خادم البنك الآن كـ «وسيط».

• الخطوة 4.1 و 4.2: يتلقى البنك الرسائل القصيرة ويستخرج رمز سري من نص النص، ويسجل رقم الهاتف المحمول من ختم الشبكة.
• الخطوة 4.3: يقوم بتخزين هذا الزوج في قاعدة بيانات معلقة. يعرف البنك الآن: «يحاول الرقم 8888888888 حاليًا ربط جهاز باستخدام الرمز 29de0hb...»

5. مرحلة مصافحة الإنترنت (المرحلة 5.0 - 5.3)

الآن، يجب أن يؤكد التطبيق هويته عبر الإنترنت لإغلاق الحلقة.

• الخطوة 5.1: يستدعي التطبيق واجهة برمجة تطبيقات /bindDevice باستخدام اتصال بيانات الهاتف (WiFi أو 5G).
• الخطوة 5.2 (المباراة الحرجة): يقارن البنك الرمز الذي تم استلامه عبر الإنترنت مع الرمز الذي تم استلامه عبر SMS.
  
  • إذا تطابقا، فهذا يثبت أن تطبيق (الإنترنت) و بطاقة سيم (SMS) موجودة على نفس الجهاز.
• الخطوة 5.3: بعد نجاح المباراة، يصدر البنك رمز جلسة آمنة، وهو «المفتاح الرئيسي» لجميع المعاملات المستقبلية على هذا التطبيق.

6. الاكتشاف والإكمال (المرحلة 6.0 - 6.3)

المرحلة النهائية تكمل عملية الإعداد.

• الخطوة 6.1 و 6.2: باستخدام الرمز الآمن الجديد، يطلب التطبيق من البنك «اكتشاف» جميع الحسابات (HDFC، SBI، ICICI، إلخ) المرتبطة بـ 8888888888.
• الخطوة 6.3: يتم ربط الحسابات، وتصبح UPI نشيط. ال 8888888888 تم قفل الحساب الآن بشكل مشفر لهذا المحدد فيفو V2338.

‍

كيف استغل ممثلو التهديد الرسائل القصيرة المرتبطة ببطاقة UPI SIM في وقت سابق عبر ملفات APK المعدلة؟

من خلال الجمع بين جهاز محمول ثلاثي (الضحية) و الدفع المعدل باستخدام UPI APK (على جهاز المهاجم)، يمكن للجهات الفاعلة في مجال التهديد خداع خوادم البنوك للاعتقاد بأن بطاقة SIM الخاصة بالضحية موجودة فعليًا في هاتف المهاجم.

‍

‍1. اختطاف تسجيل الدخول إلى الحساب (المرحلة 1)

يبدأ الهجوم من خلال اختراق هاتف الضحية باستخدام حصان طروادة (برنامج ضار) لديه أذونات «القراءة/الكتابة عبر الرسائل القصيرة». يتم ذلك غالبًا باستخدام ملفات APK المجسمة مثل ملفات APK «Vahan Chalan» أو «Wedding Invitation» التي يتم خداع المستخدم لتثبيتها عبر الهندسة الاجتماعية.

• الإجراء: يستخدم المهاجم نسخة معدلة من APK للدفع على جهازه الخاص ويدخل رقم الهاتف المحمول للضحية (8888888888).
• ذا بريتش: عندما يرسل الخادم كلمة مرور لمرة واحدة لتسجيل الدخول إلى الضحية، يقوم حصان طروادة باعتراضها بصمت وإعادة توجيهها إلى لوحة يتحكم فيها المهاجم. يشيع استخدام هذه اللوحات من قبل المهاجمين لعرض رسائل SMS وإرسالها من جهاز الضحية.
• النتيجة: نجح المهاجم في تسجيل الدخول إلى ملف تعريف حساب الضحية دون أن ترى الضحية أي إشعار.

2. استخراج رمز التجليد (المرحلة 2)

بمجرد دخول التطبيق، يحاول المهاجم تمكين مدفوعات UPI.

• الإجراء: يقوم جهاز المهاجم بتشغيل عملية «التحقق من UPI». يقوم ملف APK المعدل بإنشاء ملف رمز التجليد السري فريد من نوعه لـ أجهزة المهاجم.
• إعادة التوجيه: بدلاً من إرسال رسالة التحقق محليًا، يقوم APK المعدل باعتراض الرسالة وإرسالها إلى مجموعة Telegram.
• لماذا يهم هذا: يمتلك المهاجم الآن «المفتاح» المحدد الذي يحتاجه البنك للتحقق من جهازه، لكنه يفتقر إلى إثبات «بطاقة SIM المادية».

3. تنفيذ الرسائل القصيرة المخادعة (المرحلة 3)

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

• الإجراء: يقوم المهاجم بنسخ الرمز المميز من Telegram وإرسال أمر إلى Trojan على هاتف الضحية.
• ذا سبوف: يجبر حصان طروادة هاتف الضحية على إرسال رسالة نصية قصيرة صامتة (TDL TRB [رمز المهاجم]) إلى رقم بوابة البنك.
• ختم تيليكوم: نظرًا لأن الرسائل القصيرة تنشأ من بطاقة SIM الفعلية للضحية، فإن الشبكة الخلوية «تطبعها» برقم الضحية (8888888888).

4. رسم الخرائط من جانب خادم البنك (المرحلة 4)

تم تصميم نظام الأمان الخاص بالبنك بحيث يثق في هوية شبكة الاتصالات.

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

5. مصافحة الإنترنت وإعادة تعيين رقم التعريف الشخصي (المرحلة 5)

تمنح المرحلة النهائية المهاجم السيطرة الكاملة على الأموال.

• نجاح الربط: يستدعي تطبيق المهاجم واجهة برمجة تطبيقات /bindDevice. يرى البنك أن الرمز المميز يطابق الرسائل القصيرة «الشرعية» المستلمة في المرحلة 4 ويربط الحساب المصرفي للضحية بـ هاتف المهاجم.
• إعادة تعيين رقم التعريف الشخصي: يستخدم المهاجم ميزة «نسيت رقم التعريف الشخصي لـ UPI». يقوم البنك بإرسال رمز OTP المعاد ضبطه إلى رقم الضحية، والذي يقوم حصان طروادة مرة أخرى باعتراضه وإعادة توجيهه إلى المهاجم.
• النتيجة: يقوم المهاجم بتعيين رقم تعريف شخصي جديد لـ UPI ويمكنه الآن تحويل جميع الأموال من الحسابات المصرفية للضحية. الحد الأقصى هو 5 آلاف روبية هندية في أول 24 ساعة و 1 ألف روبية هندية في اليوم بعد ذلك.

لماذا يعمل الهجوم:

1. الثقة في رأس الرسائل القصيرة: يفترض البنك أنه لا يمكن خداع عنوان SMS، وهذا صحيح، لكنه لا يدرك محتوى تم إرسالها بواسطة مخترق بعيد باستخدام بطاقة SIM كدمية.
2. تكامل التطبيق: لا يمكن لخادم البنك التمييز بسهولة بين APK الشرعي وAPK المعدل (المعاد تجميعه) الذي يستخدمه المهاجم.
3. الاعتراض الصامت: نظرًا لأن حصان طروادة يعمل في الخلفية، فليس لدى الضحية أي فكرة عن إرسال رسائل SMS أو استلامها حتى نفاد الأموال بالفعل.

يعتمد نموذج أمان UPI الحالي على MSISDN (رقم الهاتف المحمول) مقدمة من شبكة الاتصالات كدليل مطلق على الحيازة المادية. هذا الهجوم يثبت ذلك يختلف التواجد الفعلي لبطاقة SIM عن أمان الجهاز.

ملفات APK المعدلة

لتسجيل الدخول إلى حسابات الضحية، يستخدم المهاجمون الإصدارات المعدلة من تطبيقات الدفع عبر الهاتف المحمول المشروعة المستخدمة في النظام المصرفي الهندي. بعد التحليل الثابت، اكتشفنا أن المهاجم قد قام بتعديل حزمة APK الأصلية بحيث لا يتم إرسال رسالة SMS لمصادقة UPI عبر الرسائل القصيرة ولكن تتم إعادة توجيهها إلى قناة برقية حيث يمكن للمهاجم إعادة توجيه الرسالة من جهاز الضحية عبر حصان طروادة المثبت. لهذا الغرض، قام المهاجم بتعديل إحدى ملفات APK الخاصة بالدفع أرسل رسالة نصية تعمل في حزم مثل أجهزة محاكاة الموجات فوق الصوتية. كما هو موضح في الكود الموضح أدناه، أضاف المهاجم وظيفة تسمى المرسل () حيث تم تمرير السلسلة التي تحتوي على رمز المصادقة (المتغير المسمى str2 في هذه الحالة). أثناء الانتقال إلى وظيفة sendTextMessage، لم يتم تمرير المتغير str2.

‍

كانت وظيفة المرسل هذه موجودة في حزمة مخصصة تسمى كوم جلال بابا بول تم إنشاؤها بواسطة المهاجم خصيصًا لإرسال سلسلة الرمز المميز إلى قناة برقية عبر رمز telegram bot. تستخدم الوظيفة /إرسال رسالة نقطة نهاية Telegram لإعادة توجيه رمز المصادقة كما هو موضح في الكود أدناه.

الهجوم الجديد: من ملفات APK المعاد حزمها إلى الخداع على مستوى نظام التشغيل عبر Lsposed

تمثل منهجية الهجوم هذه تحولًا من تعديل التطبيق (تغيير التطبيق) إلى معالجة بيئة وقت التشغيل (تغيير العالم الذي يعيش فيه التطبيق). باستخدام LSPosed، يضمن عامل التهديد بقاء توقيع تطبيق الدفع صالحًا، مما يجعله غير مرئي للعديد من عمليات التحقق من النزاهة القياسية.

‍

ما هو Lsposed؟

مفترض هو إطار ربط قوي وحديث لنظام Android يعمل كخليفة لمشروعي Xposed و edXposed الأصليين. يعمل من خلال الدمج مع Android Runtime (ART) من خلال طريقة الحقن على مستوى النظام (عادةً عبر Magisk/Zygisk أو Riru). بمجرد التثبيت، يسمح LSPosed لـ «الوحدات» المتخصصة باعتراض وتعديل الاتصال بين التطبيقات ونظام التشغيل Android في الوقت الفعلي. على عكس تعديلات التطبيقات التقليدية، التي تتطلب «إعادة تعبئة» أو «فك» ملف APK (وبالتالي تغيير توقيعه الرقمي)، يترك lSposed التطبيق المستهدف غير معدلة تمامًا على القرص. بدلاً من ذلك، يتم «ربط» ذاكرة التطبيق أثناء تشغيله، مما يسمح للوحدة بتغيير سلوك أساليب Java المحددة - مثل إجبار الفحص الأمني على إرجاع «صحيح»، أو انتحال إحداثيات GPS، أو، كما رأينا في حالة «Digital Lutera»، اعتراض رسائل SMS الصادرة وحظرها.

على الرغم من أن LSPosed يحظى بتقدير كبير من قبل مجتمع عشاق Android للتخصيصات المشروعة لمستخدمي الطاقة - مثل السمات المتقدمة أو إزالة الإعلانات المتطفلة أو إضافة ميزات إلى ROM المخزنة - فقد أصبح بشكل متزايد أداة مفضلة للجهات الفاعلة في مجال التهديد. نظرًا لأنه يعمل على مستوى النظام، يمكنه ذلك بفعالية تطبيقات «عمياء» لحالة الأمان الخاصة بها. على سبيل المثال، يمكن لوحدة ضارة ربط واجهات برمجة تطبيقات النظام التي تتحقق من الوصول إلى الجذر، مما يجعل الجهاز يبدو «نظيفًا» بالنسبة لتطبيق مصرفي بينما يقوم إطار العمل بسرقة البيانات في الخلفية في نفس الوقت. في سياق الاحتيال المالي، يتم استخدامه لتجاوز «ربط بطاقة SIM» و «بصمة الجهاز» من خلال تزويد تطبيق الدفع بأرقام هواتف مزيفة وسجلات الرسائل القصيرة المحقونة، مما يؤدي بشكل فعال إلى خداع التطبيق للوثوق في جهاز احتيالي كما لو كان الهاتف الشرعي للضحية.

طريقة العمل

المتطلبات المسبقة:

• ضحية مصابة بقدرات القراءة/الكتابة/إعادة توجيه الرسائل القصيرة.
• جهاز متجذر يستخدمه عامل التهديد لتسجيل الدخول إلى حساب UPI الخاص بالضحية (اعتبارًا من الآن، تم اختبار Redmi Note 8 Pro/OnePlus ويتم استخدامه على نطاق واسع من قبل TAs)
• يجب أن يضيء الهاتف الذي تم عمل روت له بـ معارضة وحدة.

الجزء 1: آلية الهجوم (إضاءة الغاز على مستوى نظام التشغيل)

يعمل الهجوم من خلال «إلقاء الضوء على» تطبيقات الدفع الشرعية. يطلب التطبيق من نظام التشغيل Android الحصول على معلومات (على سبيل المثال، «ما هو رقم هاتف بطاقة SIM؟» أو «أرسل رسالة التسجيل هذه»)، وتعترض الوحدة الضارة هذا السؤال، وتقدم إجابة خاطئة، وتخفي الأدلة.

سير العمل

1. إعداد البيئة: يستخدم المحتال جهازًا متجذرًا مع تثبيت LSPosed. يقومون بتثبيت وحدة «Digital Lutera» و شرعي وغير معدل تطبيق الدفع (على سبيل المثال، Paytm و PhonePe).
2. اختطاف النظام: عند التشغيل، يقوم LSPosed بحقن التعليمات البرمجية الضارة في عملية system_server وعملية تطبيق الدفع المستهدف.
3. تجاوز ربط بطاقة SIM (الصادر): عندما يقوم المستخدم بتشغيل تسجيل UPI، يحاول تطبيق الدفع إرسال رسالة نصية قصيرة خلفية. تقوم الوحدة بربط SendTextMessage، والتقاط محتوى الرسالة (الذي يحتوي على مفتاح التشفير للتسجيل)، وحظر الرسائل القصيرة الفعلية من الوصول إلى الشبكة الخلوية، وإرسال البيانات إلى روبوت Telegram. من روبوت التلغرام، يتم إرساله من قبل الجهات الفاعلة في التهديد من جهاز الضحية الذي تم اختراقه من خلال الهندسة الاجتماعية أو غيرها من الوسائل.
4. تزوير الهوية: يقوم تطبيق الدفع باستدعاء getLine1number () للتحقق من بطاقة SIM. تقوم الوحدة باعتراض هذا وإرجاع رقم مخادع يوفره خادم Command & Control (C2).
5. زراعة الأدلة (الواردة/قاعدة البيانات): للتأكد من أن التطبيق قد تم «إرسال» الرسالة القصيرة، يرسل خادم C2 أمرًا عبر Socket.io. تقوم الوحدة بعد ذلك بكتابة رسالة SMS مزيفة يدويًا في قاعدة بيانات Android SMS الداخلية، مما يجعلها تظهر في مجلد «Sent». هذه هي نفس الرسالة التي تم إرسالها عبر جهاز الضحية المخترق بالفعل.

الجزء 2: مراجعة الكود الفني

1. المعترض: XposedHook.java

هذا هو «الدماغ» للعملية. يستخدم واجهة برمجة تطبيقات أسلوب XposedHelpers.findAndHookmod لتعديل سلوك النظام.

‍

• الطريقة: ربط إرسال الرسائل القصيرة
• المنطق: يستهدف نظام أندرويد. الهاتف. مدير الرسائل القصيرة. إرسال رسالة نصية.
• الإجراء الضار: يستخدم Param.setResult (خالية). في Xposed، يؤدي تعيين النتيجة في طريقة beforehookedإلى منع فعلي الطريقة الأصلية من أي وقت مضى. هذا بشكل فعال الصمت رسالة SMS أثناء قيام الرمز بتسلل المحتوى إلى Telegram الخاص بالمحتال.
• الطريقة: طرق ربط رقم الهاتف
• المنطق: يربط رقم GetLine1 ومعلومات الاشتراك. getNumber.
• الإجراء الضار: بغض النظر عن بطاقة SIM الموجودة في الهاتف، فإنها تقوم بإرجاع سلسلة MobileNO من ملف التكوين. يسمح هذا للمحتال بتسجيل حساب لرقم الهاتف A باستخدام جهاز يحتوي بالفعل على بطاقة SIM B.

2. الدماغ البعيد: HttpServerService.java

على عكس البرامج الضارة البسيطة التي تسرق البيانات فقط، تعمل هذه الوحدة بمثابة حصان طروادة للوصول البعيد (RAT).

‍

• التكنولوجيا: الاستخدامات سوكيت. يو للاتصال المزدوج الكامل في الوقت الحقيقي.
• مستمع الأحداث: msocket.on («إدراج الرسائل القصيرة»،...)
• المنطق: تظل الوحدة متصلة بـ https://noob-production.up.railway.app. في أي لحظة، يمكن للمهاجم دفع كائن JSON إلى الهاتف. يُستخدم هذا للتحكم الديناميكي في الجهاز أثناء جلسة الاحتيال المباشرة، مما يسمح للمهاجم بالرد على تحديات التحقق المصرفي في الوقت الفعلي.

3. مُصنع الأدلة: SmsContentInserter.java

يعالج هذا الفصل مرحلة «الحقن المحلي».

‍

• عنوان URI المستهدف: المحتوى: //الرسائل القصيرة/المرسلة
• المنطق: يستخدم ContentResolver لإدراج صف جديد يدويًا في مزود الرسائل القصيرة للنظام.
• الإجراء الضار: يقوم بتعيين النوع إلى 2 (الرسالة المرسلة) والحالة إلى 0 (النجاح). وهذا يضمن أنه إذا قام تطبيق الدفع بمسح المجلد «المرسل» للتحقق من إرسال رسالة التسجيل القصيرة بالفعل، فإنه يجد سجلًا مثاليًا ومزورًا.

4. تكوين التخفي: ConfigManager.java

يقوم هذا الفصل بإدارة إعدادات الوحدة ومثابرتها.

‍

• تقنية التصلب: يقوم بتخزين التكوين الخاص به في /data/local/tmp/sms_hook_config.json. يُستخدم هذا الدليل عادةً لثنائيات النظام منخفضة المستوى وغالبًا ما يتم تجاهله بواسطة تطبيقات «منظف» أمان الأجهزة المحمولة القياسية.
• إساءة استخدام الجذر: يستدعي الرمز روناسروت («chmod 666...»). هذا يضمن أنه على الرغم من إنشاء الملف في دليل نظام محمي، يمكن للوحدة (التي تعمل ضمن عمليات تطبيق مختلفة) دائمًا قراءتها والكتابة إليها. كما يستخدم ReentranTreadWriteLock لضمان إمكانية تحديث التكوين بواسطة خادم C2 دون تعطل الخطافات.

لماذا يعتبر هذا «تطورًا» في تكتيكات التهديد؟

• يتجاوز التحقق من توقيع APK: تفشل ملفات APK المعاد تعبئتها في Google Play Protect وعمليات التحقق من التوقيع على مستوى البنك. تترك هذه الوحدة التطبيق الثنائي أصليًا بنسبة 100٪.
• التحكم على مستوى نظام التشغيل: من خلال ربط TelephonyManager، يتحكم المهاجم في تصور التطبيق للواقع. لا يحتوي التطبيق على طريقة لمعرفة أن السلسلة التي تم إرجاعها بواسطة getline1number () هي كذبة.
• تنسيق الاحتيال في الوقت الفعلي: يسمح استخدام Socket.io بدلاً من استطلاع HTTP البسيط للمهاجم بمزامنة أفعاله مع إجراءات الضحية (أو البنك)، مما يجعل من الممكن التغلب على نوافذ التسجيل الحساسة للوقت.

الإسناد

من الكود المصدري، تمكنا من اكتشاف أن ملف APK هذا قد قام بترميز اسم مستخدم برقية بداخله يسمى @Syntext_Erorr (معرف التلغارم: 7975048256). يكشف تحليلنا الإضافي لنشاط التلغرام الخاص باسم المستخدم:

• الممثل المستهدف: @Syntext_Erorr/@Berlin_Market
• الاسم المستعار الأساسي: برلين

يؤكد تحليل اتصالات Telegram المرتبطة بـ @Syntext_Erorr (المضمنة في وحدة «Digital Lutera» Lsposed) أن الممثل هو مطور متطور متخصص في الهندسة العكسية للأندرويد و الاحتيال في مجال التكنولوجيا المالية. الممثل، الذي يعمل تحت الاسم المستعار «برلين،» يعمل كمطور أدوات ومزود خدمة لعمليات «UPI Bypass» و «Cashout». تكشف الاتصالات عن جهود نشطة لتجاوز حزم SDK الأمنية المحمولة المتطورة والمشاركة العميقة في النظام البيئي الهندي «للتمشيط» و «النهب» تحت الأرض.

النتائج الرئيسية وتحليل النوايا

ألف - عمليات الاستغلال والسحب في UPI

يعلن الممثل صراحة عن الخدمات التي تتوافق مع وظائف وحدة «Digital Lutera».

• اقتباسات مباشرة: «D0ing c @shout pl byp @ss. الحد الأدنى 15 كيلو متر كحد أقصى 1 لتر. 40% من الوزن الطويل [يأتي للقطع بنسبة 40%]. يتوفر pin r3set.»
• التحليل: تعرض برلين استنزاف الحسابات المصرفية عبر ممرات UPI. يشير ذكر «إعادة تعيين رقم التعريف الشخصي» إلى التحقق من صحة مراجعة الكود السابقة التي تُظهر قدرة الوحدة على اعتراض OTPs لإعادة تعيين أرقام UPI الشخصية، مما يمنح السيطرة الكاملة على أموال الضحايا.

باء - الهدف: أكسيس بنك ومجموعة أدوات Protectt.ai لمكافحة الاحتيال

تظهر رسالة نقدية الممثل الذي يعاني من عطل في تطبيق مصرفي معين.

• التطبيق المستهدف: أكسيس موبايل (com.axis.mobile).
• عقبة الأمان: libprotect-native-lib.so.
• التحليل: قدم الممثل تفريغًا تفصيليًا للتعطل (JNI_onLoad) يشير إلى أنه يحاول إجراء هندسة عكسية أو «ربط» Protectt.ai مكتبة الأمان. Protectt.ai عبارة عن SDK متخصص لمكافحة الاحتيال/مكافحة الاحتيال تستخدمه البنوك الهندية الكبرى. هذا يثبت أن الممثل يعمل بنشاط لتطوير وحدته للبقاء في صدارة الدفاعات المصرفية الحديثة.

ج- الهوية واكتساب الحساب

تبحث برلين كثيرًا عن قنوات اتصال غير قابلة للتتبع.

• المتطلبات: «رقم WhatsApp المزيف مطلوب في أي بلد للاستخدام الشخصي.»
• التفاصيل: يطلب حسابات Telegram برموز البلدان مثل +977 (نيبال) مع ذكر ذلك صراحة «رقم +91 [الهند]، +92 [باكستان].»
• التحليل: يمارس الممثل الأمن التشغيلي (OPSEC) من خلال تجنب الأرقام من منطقته (على الأرجح الهند) لتعقيد الإسناد والتهرب من تطبيق القانون المحلي.

د- مجموعة مهارات الهندسة العكسية

تُظهر الاتصالات في «Revengi Chat» و «Reverse Engineering Lab» أن الممثل يُنظر إليه على أنه مطور رفيع المستوى.

• مجموعة المهارات: الكفاءة في تعديل C ++ وجافا وفلاتر.
• علم أصول التدريس: تدعي برلين أن لديها «دورة متقدمة» للبيع، مما يشير إلى أنهم مرشد/مورد لجهات التهديد الأخرى ذات المستوى الأدنى.

مجموعة هيناتا

استنادًا إلى سجلات Telegram التي قمنا بتحليلها، فإن العلاقة بين الممثل @Syntext_Erorr (برلين) و ال «مجموعة هيناتا» هو مشروع اجتماعي وتعليمي، متجذر في السنوات التأسيسية لتعديل Android الهندي ومشهد الهندسة العكسية.

فيما يلي تفصيل محدد لهذا الاتصال:

1. علاقة «الخريجين»

في رسالة بتاريخ 25 سبتمبر 2025، ترد برلين على مستخدم آخر في المجموعة عالم باغال 🔥، قائلاً:

«أنا أكاديمية سايبر زون، هل تتذكر مجموعة هيناتا حيث نقضي جميعًا الوقت»

هذا يشير إلى ذلك مجموعة هيناتا كان مركزًا أساسيًا أو «حفرة مائية» حيث التقى هؤلاء الممثلون وقضوا وقتًا طويلاً. في صحيفة Indian Telegram underground، تشير كلمة «Hinata» (من المحتمل أن تكون عبارة عن مقبض مستوحى من شخصية الرسوم المتحركة) إلى مسؤول معروف للمجموعات المخصصة لاختراق التطبيقات ومشاركة نصائح الهندسة العكسية.

2. الانتقال من «Modder» إلى «المحتال»

يشير الاتصال إلى مسار تطوري:

• عصر هيناتا: من المحتمل أن تكون برلين طالبًا أو مساهمًا في مجموعة Hinata، مع التركيز على تعديل Android العام (إزالة الإعلانات من التطبيقات، وفتح الميزات المتميزة).
• عصر أكاديمية سايبر زون: قام برلين بتطوير علامته التجارية الخاصة، «أكاديمية سايبر زون» حيث انتقل من مشارك إلى مرشد. هنا، بدأ بيع «الدورات المتقدمة» (كما هو مذكور في الرسالة 91650).
• عصر اللوتيرا الرقمي: قامت برلين الآن بتسليح مهارات الهندسة العكسية التي تعلمتها في أيام «هيناتا» لإنشاء ديجيتال لوتيرا وحدة للسرقة المالية وتجاوز UPI.

3. دائرة اجتماعية مشتركة

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

4. الرابط التشغيلي (أكاديمية سايبر زون)

يعرّف برلين نفسه على أنه وجه أكاديمية سايبر زون. من المحتمل أن تعمل هذه الأكاديمية كواجهة أو ساحة توظيف حيث يحدد المودعين المهرة من دائرة هيناتا ويسحبهم إلى مشاريع الاحتيال المالي الأكثر ربحًا وعالية المخاطر مثل تجاوز Axis Bank/Protectt.ai.

برلين هي «خريج» بارز من دائرة تعديل هيناتا. إنه يستخدم مجموعة Hinata كنقطة مرجعية تاريخية مشتركة للتواصل مع المهندسين العكسيين المخضرمين الآخرين الذين انتقلوا الآن من تعديل التطبيقات البريئة إلى الجرائم المالية الإلكترونية الخطيرة. لقد استفاد بشكل فعال من المجتمع الذي أنشأته Hinata لتسويق «الأكاديمية» الخاصة به والبرامج الضارة «Digital Lutera» الخاصة به.

‍

المؤشرات الرئيسية

• الأصل الجغرافي: ثقة عالية بـ أصل هندي.
  
  • يستخدم الممثل اللغة العامية الهندية/الهنغليشية.
  • التركيز الأساسي لتحقيق الدخل هو UPI (واجهة المدفوعات الموحدة)، وهو نظام فريد للهند.
  • استهداف محدد لنظام UPI البيئي في الهند عبر ملفات APK المعدلة.
• الملف النفسي: برلين هي ممثل «ألفا» في هذا النظام البيئي. على عكس أطفال البرامج النصية الذين يشترون الأدوات ببساطة، تفهم برلين وقت تشغيل Android (ART) و JNI (واجهة Java الأصلية). من المحتمل أن يكونوا مطورًا تم تعليمه ذاتيًا أو مطورًا مبتدئًا سابقًا لنظام Android انتقل إلى الجرائم الإلكترونية لتحقيق هوامش ربح أعلى (تخفيضات بنسبة 40٪ على تحويلات 1 مليون روبية هندية)

التأثير

إن تأثير هذا التحول - من ملفات APK المعدلة إلى اختراق الإطار على مستوى النظام - عميق. إنه يكسر بشكل أساسي نموذج الأمان الذي تُبنى عليه الخدمات المصرفية الحديثة عبر الهاتف المحمول وأنظمة الدفع (مثل UPI). يمكننا بالفعل أن نرى من لقطة الشاشة الواردة أدناه أن الجهات الفاعلة في مجال التهديد قد بدأت بنشاط في استخدام وحدة LSPOSED هذه لتسجيل الدخول إلى حسابات UPI الخاصة بالضحايا. حتى الآن، تحتوي هذه المجموعة الفردية على أكثر من 500 رسالة تسجيل دخول.

‍

1. تآكل كامل لأمان «ربط بطاقة SIM»

ركيزة الأمان الأساسية للمدفوعات عبر الهاتف المحمول في العديد من المناطق (خاصة الهند) هي ربط بطاقة SIM—الافتراض بأنه لا يمكن الوصول إلى الحساب المصرفي إلا إذا كانت بطاقة SIM الفعلية موجودة في الجهاز.

• التأثير: هذه الوحدة تجعل ربط SIM قديمًا. من خلال انتحال رقم الهاتف واعتراض رسالة التسجيل القصيرة، يمكن للجهات الفاعلة في مجال التهديد تسجيل الحساب المصرفي للضحية على جهاز يقع على بعد آلاف الأميال من بطاقة SIM الفعلية. هذا يسمح بـ عمليات الاستحواذ غير المصرح بها على الحساب على نطاق واسع.

2. تجاوز عمليات التحقق من تكامل التطبيقات

تقليديًا، تحمي البنوك تطبيقاتها من خلال التحقق من توقيع APK. إذا قام أحد المتسللين بتعديل التطبيق لسرقة البيانات، يتغير التوقيع، ويتم حظر التطبيق.

• التأثير: لأن Lsposed يربط النظام وليس التطبيق، يظل تطبيق الدفع أصليًا بنسبة 100٪ ولم يتم العبث به على القرص. يجتاز جميع عمليات التحقق من التوقيع وعمليات فحص Play Protect وتدقيقات النزاهة القياسية، مما يؤدي إلى الهجوم غير مرئية لحلول أمان الأجهزة المحمولة التقليدية.

3. تنسيق الاحتيال في الوقت الفعلي (C2)

يؤدي استخدام Socket.io للاتصال المستمر بخادم الأوامر والتحكم (C2) إلى تحويل «السارق» البسيط إلى حصان طروادة للوصول البعيد (RAT).

• التأثير: يمكن للمهاجمين تنظيم الاحتيال في الوقت الفعلي. عندما تتم مطالبة الضحية برقم OTP أو الطعن في التسجيل، يمكن للمهاجم على الفور «دفع» الأمر إلى الجهاز لإدخال الرسائل القصيرة اللازمة أو انتحال الاستجابة المطلوبة. وهذا يسمح لهم بتجاوز عقبات الأمان الحساسة للوقت التي قد تفوتها الروبوتات الآلية.

4. سرقة المصادقة الثنائية (2FA)

من خلال ربط SMSManager، تتمتع الوحدة بـ «رؤية الله» لجميع حركة مرور الرسائل القصيرة الصادرة (وربما الواردة).

• التأثير: يتم تسريب رموز 2FA الشرعية وتنبيهات المعاملات والاتصالات المصرفية الحساسة مباشرةً إلى Telegram. يمنح هذا المهاجم القدرة على السماح بالتحويلات عالية القيمة وتغيير كلمات مرور الحساب وإبعاد الضحايا بشكل دائم عن حياتهم المالية.

5. الثبات المخفي على مستوى النظام

يعرف معظم المستخدمين كيفية إلغاء تثبيت تطبيق مشبوه. ومع ذلك، فإن وحدة LSPosed هي امتداد لنظام التشغيل Android نفسه.

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

6. الفشل التنظيمي والامتثال

يُطلب من المؤسسات المالية بموجب القانون (مثل إرشادات RBI في الهند) ضمان الربط الآمن للجهاز والمصادقة متعددة العوامل.

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

7. قابلية التوسع لـ «الاحتيال كخدمة»

تشير بنية هذه الوحدة (مفاتيح التسجيل، خادم C2، روبوتات Telegram) إلى أنها مصممة لـ شبكة الاحتيال الموزعة.

• التأثير: يمكن لمطور واحد بيع هذه «المجموعة» لمئات من «المشغلين» ذوي المستوى المنخفض. لا يحتاج هؤلاء المشغلون إلى مهارات تقنية؛ فهم ببساطة يقومون بتثبيت الوحدة وإدخال مفتاحهم والبدء في نهب الحسابات. وهذا يقلل من حاجز دخول الجرائم الإلكترونية، مما يؤدي إلى زيادة الاحتيال المالي المحلي.

العلاجات

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

1. تنفيذ واجهة برمجة تطبيقات Play Integrity (تكامل قوي)

يتم تجاوز اكتشاف الجذر التقليدي بسهولة بواسطة LSPosed. يجب على المطورين الانتقال إلى Google العب واجهة برمجة تطبيقات النزاهة.

• الإجراء: تحقق على وجه التحديد من حكم MEETS_STRONG_INTEGRITY. هذا يؤكد أن الجهاز يعمل بنظام Android معتمد وأن أداة تحميل التشغيل مقفلة.
• التأثير: نظرًا لأن LSPosed يتطلب أداة تحميل غير مقفلة أو قسم نظام مخترق، فإن فرض تكامل قوي سيؤدي إلى حظر معظم الأجهزة القادرة على تشغيل هذه الوحدة.

2. الحماية الذاتية لتطبيق وقت التشغيل (RASP)

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

• كشف الخطاف: استخدم الكود الأصلي (C/C ++ عبر JNI) للبحث عن وجود أطر ربط معروفة. يمكن أن يؤدي البحث عن liblsposed.so أو libriru.so أو XposedBridge.jar في ملف الخرائط (/proc/self/maps) إلى تحديد إطار العمل.
• تحليل تتبع المكدس: تحقق دوريًا من آثار مكدس الأساليب الهامة (مثل SendTextMessage). إذا أظهرت إحدى الطرق مكالمة صادرة من حزمة غير معروفة أو غير متوقعة (مثل de.robv.android.xposed)، يجب أن ينهي التطبيق الجلسة.

3. نقل المنطق الحرج إلى الكود الأصلي (JNI/NDK)

Lsposed هو في الأساس إطار ربط على مستوى Java.

• الإجراء: انقل منطق التحقق من الهوية وفحص بطاقة SIM وإرسال الرسائل القصيرة إلى مكتبات C/C ++ الأصلية.
• التأثير: في حين أن الربط الأصلي (عبر أدوات مثل Frida) ممكن، إلا أنه أكثر تعقيدًا في التنفيذ والصيانة من خطافات Java المستخدمة في وحدة «Digital Lutera».

4. قم بتحسين «ربط بطاقة SIM» من خلال التحقق من جانب الناقل

لا تثق في الجهاز ليخبرك أنه تم إرسال رسالة SMS.

• الإجراء: يجب ألا يعتمد تدفق التسجيل على رد الاتصال «Success» الخاص بالتطبيق. بدلاً من ذلك، يجب أن تتحقق الواجهة الخلفية من أن الرسائل القصيرة وصلت بالفعل إلى الرمز/البوابة القصيرة للبنك باستخدام البيانات الوصفية الصحيحة (الطابع الزمني ورقم المصدر من الناقل وحمولة التشفير المطابقة).
• التحقق خارج النطاق: استخدم نموذج «push-pull» حيث يرسل الخادم إشعارًا فوريًا مشفرًا إلى التطبيق، ويجب أن يستجيب التطبيق عبر قناة بيانات آمنة (HTTPS)، متجاوزًا طبقة الرسائل القصيرة تمامًا للخطوات الحساسة.

5. الكشف عن مؤشرات البيئة «القذرة»

تترك ملفات APK المستخدمة مثل وحدة «Digital Lutera» آثارًا محددة يمكن أن تبحث عنها حزم SDK الأمنية:

• وجود الملف: ابحث عن ملف التكوين على /data/local/tmp/sms_hook_config.json أو اسم الحزمة com.digitalluteraupi.lsposedModule.
• توقيع خدمات النظام: راقب اتصالات المقبس غير العادية في الوقت الفعلي (مثل Socket.io) التي تعمل في سياق التطبيقات على مستوى النظام.

6. تثبيت الشهادة وتشفير حركة المرور

بينما تركز هذه الوحدة على روابط API المحلية، فإنها تقوم بتصفية البيانات عبر HTTPS إلى Telegram وواجهة برمجة التطبيقات عن بُعد.

• الإجراء: تأكد من أن تطبيق الدفع يستخدم بشكل صارم تثبيت شهادة SSL.
• التأثير: على الرغم من أنه لن يوقف ربط واجهة برمجة التطبيقات المحلية، إلا أنه يمنع الجهاز من التعرض لهجمات man-in-the-middle (MITM) الإضافية على مستوى الشبكة والتي غالبًا ما تصاحب مجموعات الاحتيال هذه.

المراجع

• *مصدر الذكاء وموثوقية المعلومات - ويكيبيديا
• ^#بروتوكول إشارات المرور - ويكيبيديا

https://github.com/LSPosed/LSPosed