يمكن لحركة هجوم DDoS أن تبدو، على مستوى البروتوكول والترويسات، أقرب إلى جلسة تصفح عادية عبر Google Chrome. هذه هي الفكرة التي يدفع بها الإصدار الجديد Kimwolf v7 إلى مستوى أكثر تعقيدًا: بدل الاكتفاء بإغراق الهدف بطلبات كثيفة، يستخدم البوتنت HTTP/2 ويبني بصمة متصفح كاملة تحاكي سلوك Chrome، ما يجعل فصل الحركة الخبيثة عن التصفح المشروع أكثر صعوبة.

لكن التغيير الأهم لا يقتصر على طبقة الهجوم. الإصدار الجديد يعيد هندسة بنية Command and Control (C2) نفسها، فيجمع بين Ethereum Name Service (ENS) وخدمة Tor .onion مضمّنة داخل البرمجية ووكيل محلي يمر عبره اتصال التحكم كله، سواء كان متجهًا إلى الإنترنت التقليدي أو شبكة Tor.

رصد باحثو Palo Alto Networks Unit 42 هذا الإصدار، الذي يتتبعونه باسم Kimwolf v7، في فبراير 2026. وتشير التغييرات إلى أن المشغلين فصلوا مرحلة الانتشار والوصول الأولي عن الحمولة الأساسية: لم يعد Kimwolf نفسه مسؤولًا عن المسح والاستغلال وbrute force، بل أصبح يركز على تنفيذ هجمات DDoS والعمل كـ proxy relay، بينما تُترك مهمة الوصول الأولي إلى loader خارجي.

#TL;DR

  • Kimwolf v7 هو إصدار جديد من بوتنت Kimwolf/AISURU يستهدف Android وIoT، وقد رصدته Unit 42 في فبراير 2026.
  • أضاف الإصدار هجوم HTTP/2 flood باستخدام مكتبة nghttp2 مع بصمات تحاكي Google Chrome على مستوى البروتوكول والترويسات.
  • يعتمد C2 على بنية متعددة الطبقات تشمل ENS عبر خدمات Ethereum RPC عامة، وخدمة Tor .onion احتياطية، وproxy محلي على 127.0.0.1:23075.
  • أزيلت وظائف المسح والاستغلال وbrute force من الحمولة الأساسية، ما يشير إلى فصل الانتشار عن تنفيذ DDoS والـ proxy relay.
  • يستهدف Kimwolf بصورة معروفة أجهزة Android TV التي يكون فيها ADB متاحًا على المنفذ 5555، بينما يركز نظيره AISURU على أجهزة Linux IoT.
  • لا يذكر المصدر Patch محددًا؛ التخفيف الموصى به هو عزل أجهزة Android TV عن شبكات المؤسسة وتعطيل ADB أو حصره في USB فقط.

#من بوتنت انتشار إلى حمولة متخصصة

كان Kimwolf معروفًا باستهداف أجهزة Android TV منذ أغسطس 2025، في حين يركز نظيره على Linux، AISURU، بصورة أساسية على أجهزة IoT. ووفق المادة المنشورة، يعود نشاط البوتنت إلى منتصف 2024 على الأقل.

في النمط التشغيلي المعروف للعملية، تُستغل خدمات residential proxy للوصول إلى أجهزة Android TV التي تأتي مع Android Debug Bridge (ADB) مفعّلًا على المنفذ 5555 داخل الشبكات المحلية. بعد الوصول، تُثبّت البرمجية الخبيثة بحيث يصبح الجهاز قادرًا على المشاركة في هجمات DDoS والعمل كمرحّل لحركة خبيثة أخرى.

عند التشغيل، تحاول البرمجية الاندماج مع بيئة Android عبر الظهور بأسماء تشبه عمليات النظام، مثل netd_service. إلا أن Kimwolf v7 يذهب أبعد من مجرد الإخفاء الاسمي، إذ يعيد توزيع الأدوار داخل البنية التشغيلية نفسها.

إزالة مكونات scanner والاستغلال وbrute force من النسخة الجديدة تعني أن Kimwolf لم يعد يحاول تنفيذ كامل سلسلة الاختراق بمفرده. تشير Unit 42 إلى أن المشغلين فصلوا propagation pipeline عن core payload: loader خارجي يتولى الوصول الأولي، بينما يتعامل Kimwolf مع مرحلتين واضحتين هما تنفيذ DDoS وتشغيل proxy relay.

#HTTP/2 flood ببصمة متصفح كاملة

أبرز إضافة في Kimwolf v7 هي آلية HTTP/2-based DDoS flood مبنية على مكتبة nghttp2. الجديد هنا ليس استخدام HTTP/2 وحده، بل الطريقة التي تُصاغ بها الحركة.

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

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

#بنية C2 مصممة للبقاء

بالتوازي مع تحسين آلية الهجوم، أعاد المشغلون بناء قناة C2 بهدف زيادة قدرتها على مقاومة جهود التعطيل أو الإزالة.

يستخدم Kimwolf v7 خدمات Ethereum RPC عامة ومشروعة للاستعلام عن سجلات Ethereum Name Service (ENS) والحصول على عناوين C2. هذا يعني أن البرمجية لا تحتاج إلى الاعتماد على عنوان تحكم ثابت واحد داخل بنيتها الأساسية.

وإذا تعذر المسار الأساسي، يحتوي الملف التنفيذي على خدمة Tor .onion احتياطية مضمّنة مباشرة:

edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion

أما على الجهاز المصاب، فتوجد طبقة محلية تفصل البرمجية عن وجهة الاتصال الفعلية. كل حركة C2 تمر عبر proxy محلي على:

127.0.0.1:23075

وتستخدم البرمجية هذا المسار سواء كان الاتصال النهائي متجهًا إلى clearnet أو إلى Tor. النتيجة هي بنية تحكم أكثر تجريدًا: المكوّن الأساسي يتعامل مع proxy محلي ثابت، بينما تتغير طبقة النقل الخارجية بحسب المسار المتاح.

#تحسينات موجهة لأجهزة Android TV

أضاف الإصدار أيضًا دالة UDP flood عالية الأداء وموجهة خصيصًا لمعالجات ARM الموجودة في أجهزة Android TV. هذا يتوافق مع تركيز Kimwolf على هذه الفئة من الأجهزة بدل التعامل معها كهدف ثانوي ضمن مجموعة واسعة من الأنظمة.

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

#APKs متنكرة كخدمة نظام

لم تقتصر تطورات Kimwolf على الملف التنفيذي الرئيسي. فقد رصد الباحثون أيضًا مشغلي Kimwolf وهم يوزعون حزم Android APK تنتحل صفة خدمة نظام باسم SystemService، وتتحقق من وجود صلاحيات root قبل تنفيذ حمولة kernel بصيغة ELF مضمّنة داخل الحزمة.

تم التعرف على ثماني عينات من هذه الـ APKs بين أكتوبر وديسمبر 2025.

وتشير Unit 42 إلى أن أقدم عينة dropped sample كانت تستهدف معمارية x86 وتستخدم استغلال Dirty COW. ويرى الباحثون أن ذلك يوحي بأن العائلة انتقلت من نموذج يعتمد على استغلال Linux بصورة تقليدية إلى نموذج انتشار Android قائم على ADB.

كما رصد الباحثون تعديلات تشغيلية على أسماء الملفات. ففي نوفمبر 2025 تغير الاسم من:

libn[redacted]kernel.so

إلى الاسم الأقل لفتًا للانتباه:

libdevice.so

ثم عاد الاسم إلى حالته السابقة في ديسمبر. وتفسر Unit 42 هذا التغيير والتراجع بوصفه مؤشرًا على تعديلات مستمرة في Operational Security (OPSEC) لدى المشغلين.

#كيف تبدو سلسلة التشغيل في Kimwolf v7؟

يمكن تلخيص البنية الجديدة كما تصفها المادة في تسلسل واضح:

  1. loader خارجي يتولى مرحلة الوصول الأولي بدل أن ينفذ Kimwolf عمليات scanner أو exploit أو brute force بنفسه.
  2. يتم تشغيل الحمولة على جهاز Android أو IoT المصاب، وقد تحاول الظهور باسم عملية شبيهة بالنظام مثل netd_service.
  3. يمر اتصال C2 عبر proxy محلي ثابت على 127.0.0.1:23075.
  4. تُحل عناوين التحكم عبر ENS باستخدام خدمات Ethereum RPC عامة، مع توفر خدمة Tor مخفية hard-coded كمسار احتياطي.
  5. يتلقى الجهاز أوامر تشغيل DDoS أو العمل كـ proxy relay.
  6. يمكن تنفيذ HTTP/2 flood ببصمة Chrome، أو UDP flood محسن لمعالجات ARM، ضمن مجموعة من 15 طريقة هجوم مرقمة.

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

#لماذا يصعب التعامل مع هذا التصميم؟

تقنيًا، يركز Kimwolf v7 على مشكلتين تواجهان مشغلي البوتنتات الكبيرة: تمييز حركة الهجوم واستمرارية البنية التحتية.

في الجانب الأول، يحاول HTTP/2 flood تقليد بصمة متصفح حقيقية بدل إنتاج حركة يسهل فصلها شكليًا عن المستخدمين الشرعيين. وفي الجانب الثاني، لا يعتمد C2 على مسار واحد؛ بل يستخدم ENS لاكتشاف العناوين، وTor كخيار احتياطي، وproxy محليًا يفصل الحمولة عن تفاصيل المسار الخارجي.

من منظور Business Continuity، يعني ذلك أن الأجهزة المصابة يمكن أن تتحول إلى مصدر لحركة DDoS وإلى relay لحركة ضارة، بينما تزيد مرونة C2 من صعوبة تعطيل العملية بالكامل. ومن منظور Security Monitoring، تصبح مراقبة الأجهزة غير التقليدية مثل Android TV أكثر أهمية عندما تكون متصلة ببيئة مؤسسة، لأن الجهاز هنا ليس مجرد endpoint استهلاكي بل قد يصبح عقدة داخل بنية هجوم موزعة.

#التخفيف وتقليل مساحة الهجوم

التوصيات التي تنقلها Unit 42 مباشرة تركز على أجهزة Android TV ومسار الانتشار الأساسي:

  • التعامل مع أجهزة Android TV باعتبارها أجهزة غير موثوقة داخل بيئة المؤسسة.
  • عزلها عبر network segmentation بدل وضعها ضمن الشبكات التي تحتوي على أنظمة حساسة.
  • تعطيل ADB عندما لا تكون هناك حاجة إليه.
  • أو تقييد ADB ليعمل عبر USB فقط، ما يزيل مسار الانتشار الأساسي الذي يعتمد عليه هذا البوتنت.

المصدر لا يذكر Patch أو إصدارًا مصححًا محددًا، لأن جوهر المشكلة هنا مرتبط بتعرض ADB وبطريقة نشر الحمولة أكثر من كونه عيبًا واحدًا ذا تحديث إصلاحي موحد.

#مؤشرات الاختراق IOCs

text
Tor hidden service:
edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion

Local C2 proxy:
127.0.0.1:23075

Observed / referenced process and package names:
netd_service
SystemService

Observed / referenced library names:
libn[redacted]kernel.so
libdevice.so

ADB port referenced in propagation model:
5555

#موجة أوسع من بوتنتات IoT

يأتي رصد Kimwolf v7 وسط ظهور عدة عائلات botnet أخرى خلال الأشهر الأخيرة، ولكل منها تركيز تشغيلي مختلف.

AryStinger يستهدف أجهزة الراوتر المنزلية القديمة والضعيفة ويضمها إلى شبكة تستخدم في distributed reconnaissance والـ proxying.

أما RustDuck فيستولي على أجهزة الراوتر المنزلية وكاميرات IP وAndroid boxes وخوادم سيئة التأمين، ثم يستخدمها ضمن بنية لتنفيذ هجمات DDoS.

ويأخذ NadMesh اتجاهًا أكثر اتساعًا، إذ يجمع scanning وexploitation وجمع معلومات الاعتماد وخدمات AI في منصة مستقلة تبحث عن Redis وDocker وMCP وKubernetes وComfyUI وOllama وn8n وOpen WebUI وLangflow وGradio، وتزرع SSH backdoor وتجمع credentials وenvironment variables وaccount tokens وإعدادات AWS وDocker.

في المقابل، يعتمد Tengu على قاعدة Mirai ويستخدم Telnet brute-force لاختراق أجهزة IoT، ثم ينفذ أوامر تتيح شن DoS وجمع إعدادات الشبكة وإنشاء persistence وتسريب metadata وتشغيل أوامر وتنزيل payloads إضافية وتحويل الجهاز المصاب إلى proxy.

وسط هذا السياق، يبدو Kimwolf v7 أقل اتساعًا من بعض تلك المنصات من حيث الوظائف، لكنه أكثر تركيزًا على تحسين جودة حركة DDoS وزيادة مرونة C2 وتكييف الأداء مع Android TV.

#الخاتمة

أهم ما تكشفه Kimwolf v7 ليس مجرد إضافة نوع جديد من هجمات DDoS، بل التحول نحو بوتنت متخصص ومقسّم وظيفيًا: الوصول الأولي أصبح مسؤولية loader خارجي، الاتصال بالتحكم أصبح متعدد المسارات ويستفيد من ENS وTor، وتنفيذ الهجوم أصبح مصممًا ليحاكي عميلًا حقيقيًا عبر HTTP/2.

في Kimwolf v7 تعمل هذه الطبقات معًا داخل تصميم واحد: جهاز Android TV مصاب ينفذ DDoS أو يعمل كـ proxy relay، وحركة HTTP/2 تُبنى ببصمة Chrome، وعناوين C2 تُحل عبر ENS باستخدام خدمات Ethereum RPC عامة، مع Tor كمسار احتياطي. لذلك تكمن النقلة التقنية في الإصدار الجديد في فصل وظائف الانتشار عن الحمولة الأساسية، ثم تعزيز كل من تمويه حركة الهجوم ومرونة قناة التحكم؛ وهما بالضبط المجالان اللذان ركزت عليهما تغييرات v7.

#المصادر