كيف حوّل LeakySensey أجهزة مهملة إلى شبكة تضم 87 ألف عنوان IP

قد يبدأ الاختراق من شيء لا يلفت الانتباه: راوتر قديم ما زال يعمل في زاوية مكتب، جهاز VPN لم يعد أحد يتذكر سبب وجوده، أو وحدة NAS بقيت متصلة بالإنترنت بعد انتهاء عمرها التشغيلي.

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

هذا ما تكشفه عملية LeakySensey التي رصدها فريق أبحاث Cybernews. ووفقاً للبيانات التي عُثر عليها في البنية التحتية المكشوفة للمشغل، تجاوز مخزون الشبكة المخترقة 87,000 عنوان IP، جُمعت أساساً عبر البحث الآلي عن خدمات قديمة مكشوفة للإنترنت ثم تنفيذ هجمات تخمين كلمات المرور عليها. بعد ذلك، تحولت بعض الأجهزة المخترقة إلى نقاط Residential Proxy تُباع للمستخدمين ومزودي خدمات البروكسي.

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


#العملية في أرقام

المؤشر ما كشفته البنية التحتية


إجمالي عناوين IP المخترقة أكثر من 87,000 مخترقة عبر PPTP أكثر من 63,000 مخترقة عبر L2TP أكثر من 24,000 مخترقة عبر SSH 24 عناوين بحالة ready أو connected للبروكسي 17,858 مستخدمو الخدمة أكثر من 56,000 حسابات Telegram المرتبطة أكثر من 11,000 المعاملات منذ 2024 أكثر من 24,000 إجمالي العائدات المرصودة نحو 202,000 دولار

هذه الأرقام مهمة لأنها توضح أن العملية لم تعتمد على استغلال تقني متطور في كل مرحلة. جزء كبير من النجاح جاء من اتساع سطح الهجوم ووجود أجهزة قديمة مكشوفة بكلمات مرور ضعيفة.


#الواجهة تبدو كخدمة تقنية عادية

بحسب Cybernews، ظهرت العملية خلف واجهة موقع sensey24[.]ru الذي قدم نفسه كجهة روسية تعمل في تطوير البرمجيات والاستشارات التقنية. لكن الخادم المكشوف كشف بنية مختلفة تماماً في الخلفية.

واجهة موقع
Sensey24

واجهة العملية كما ظهرت على موقع Sensey24 --- المصدر: Cybernews.

اكتشف الباحثون الخادم في 20 يوليو 2026، وكان مكشوفاً بدرجة أتاحت رؤية أدوات هجومية، وقوائم عملاء، ومخزون من عناوين IP مع بيانات اعتماد صالحة، وسجلات تشغيلية، وحتى آثار حوادث اختراق تعرضت لها البنية التحتية الخاصة بالمشغل نفسه.

هذه النقطة بالذات تكشف مفارقة أمنية: بنية صُممت لاختراق أجهزة الآخرين كانت هي الأخرى تعاني من ضعف في الحماية التشغيلية.


#كيف بُنيت شبكة البروكسي؟

المنهج الأساسي للعملية يمكن اختزاله في سلسلة مترابطة:

text
Internet-wide Scanning
        ↓
Discovery of PPTP / L2TP / SSH
        ↓
Password Spraying / Brute Force
        ↓
Valid Credentials
        ↓
Compromised Network Device
        ↓
Proxy Enablement
        ↓
Residential Proxy Inventory
        ↓
Resale to Customers / Providers

تبدأ العملية بمسح واسع للإنترنت بحثاً عن منافذ وخدمات محددة، خصوصاً:

text
PPTP
L2TP
SSH

ثم تُستهدف الأنظمة المكتشفة بمحاولات تخمين تعتمد على بيانات اعتماد شديدة الضعف، من بينها:

text
admin
admin123

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

بحسب الملفات التي عُثر عليها، استخدم المشغل أدوات متخصصة تحمل أسماء:

text
PPTP API Server v3.2
ipgo3

وكانت البيئة تدعم عمليات اكتشاف جماعية لخدمات:

text
PPTP
L2TP
SSH

سجلات محاولات Brute
Force

سجلات مرتبطة بعمليات استهداف خوادم VPN --- المصدر: Cybernews.


#لماذا كان PPTP وL2TP هدفين جذابين؟

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

بروتوكول:

text
PPTP

هو بروتوكول VPN قديم يعمل عادة عبر المنفذ:

text
1723

وبحسب الأرقام الواردة في المصدر، أظهرت عمليات المسح العامة عبر Censys نحو 1.9 مليون مضيف ما زال يعرض هذه الخدمة القديمة.

أما:

text
L2TP

فهو بروتوكول نُشر عام 1999، ويظهر عادة على المنفذ:

text
1701

وأشار المصدر إلى أن عمليات المسح لهذا المنفذ أعادت أكثر من 3 ملايين جهاز مكشوف عالمياً.

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


#أكثر من 87 ألف عنوان IP تحت السيطرة

وفقاً للمخزون المكشوف، توزعت الأجهزة المخترقة تقريباً كالتالي:

text
63,000+  PPTP
24,000+  L2TP
24       SSH

لكن ليس كل جهاز مخترق كان مستخدماً فعلياً في خدمة البروكسي في اللحظة نفسها. عند اكتشاف البنية التحتية، كان هناك 17,858 عنوان IP يحمل بيانات اعتماد للبروكسي وحالة:

text
ready

أو:

text
connected

وهذا التفريق مهم؛ فعدد الأنظمة التي تم اختراقها لا يساوي بالضرورة عدد نقاط البروكسي النشطة في لحظة الرصد.

قائمة الأنظمة
المخترقة

جانب من مخزون الأجهزة المخترقة، حيث ظهرت بيانات اعتماد ضعيفة ضمن السجلات --- المصدر: Cybernews.


#من الاختراق إلى نموذج ربحي

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

أظهرت قواعد البيانات المسربة وجود أكثر من 56,000 مستخدم، وأكثر من 11,000 حساب مرتبط بـ Telegram. ومنذ عام 2024، عالجت الخدمة أكثر من 24,000 معاملة بإجمالي عائدات بلغ نحو 202,000 دولار.

تمركزت المدفوعات عبر منصة:

text
cryptomus.com

والتي تدعم عدداً كبيراً من العملات المشفرة.

كما كشفت البيانات عن جهات وأسماء خدمات اشترت وصولاً إلى البروكسيات، من بينها VPN Pure وأسماء أخرى مثل Pure Connect وRich Proxy وOpm Proxy وFor Friends وSkySocks.

تقنياً، هذه المرحلة توضح دورة تحقيق الدخل:

text
Compromise
   ↓
Inventory
   ↓
Proxy Provisioning
   ↓
Customer Access
   ↓
Payment

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


#المفارقة: المهاجم نفسه تعرّض للاختراق

الخادم المكشوف لم يحتوِ فقط على آثار استهداف الآخرين. عثر الباحثون أيضاً على مؤشرات توضح أن البنية التحتية للمشغل تعرضت لحوادث أمنية منفصلة.

في إحدى الحالات، تم نشر مُعدّن للعملة المشفرة:

text
Monero

على الخادم الذي يستضيف مستودع Git. ووفقاً للباحثين، لاحظ المشغل الحادث وحذف 37 مستخدماً غير مصرح به كانوا قد أُنشئوا على مثيل المستودع.

سكريبت تثبيت Crypto
Miner

سكريبت عُثر عليه على خادم مستودع Git ويثبت مُعدّن عملات مشفرة --- المصدر: Cybernews.

وفي حادثة أخرى، سُرقت مفاتيح:

text
API Keys

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

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


#الطبقة الأكثر إثارة: نسخة معدلة من Claude Code

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

text
Claude Code

ووفقاً لتحليل Cybernews، لم تكن النسخة هي الإصدار الرسمي كما هو، بل نسخة تم تعديلها لإزالة عدد من القيود وآليات التأكيد المحلية.

عُثر على خط أنابيب آلي لتعديل Claude Code Binary يتكون من خمسة سكربتات Python تتعامل مع مراحل:

text
Discovery
Analysis
Implementation
Integrity Verification
Distribution

وكانت الفكرة أن يؤدي صدور نسخة جديدة من Claude Code إلى تشغيل مسار يقوم بتطبيق التعديلات المطلوبة عليها.


#ما الذي غيّرته النسخة المعدلة؟

وفقاً للمصدر، شملت التعديلات المكتشفة ما يلي:

السلوك التغيير في النسخة المعدلة


الوصول إلى نظام الملفات وصول كامل دون نافذة ثقة أو تأكيد اختيار النموذج قبول أي Model ID تشغيل الوكلاء الفرعيين إمكانية توجيههم إلى مزودين مختلفين مزودو النماذج دعم نماذج من OpenAI وGemini وQwen وغيرها فلاتر التعليمات إزالة فحص الأمان المحلي على مستوى الـ Prompt تنفيذ الخطط الموافقة التلقائية دون تدخل بشري

وبحسب ما كشفته الملفات، كانت النسخ المعدلة تُوزع داخلياً كحزم:

text
NPM

لبنى وأنظمة متعددة، من بينها:

text
Apple
Windows
Linux

كود تعديل Claude
Code

جزء من كود خط أنابيب تعديل Claude Code --- المصدر: Cybernews.

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


#نموذج واحد؟ لا، طبقة توجيه لعدة نماذج

وجد الباحثون في البيئة:

text
12 Antigravity accounts
1 Claude account
5 Codex accounts
2 Gemini accounts

وكانت الطلبات تمر عبر أداة وسيطة:

text
CLIProxyAPI

وهي طبقة تسمح بتوجيه الطلبات إلى مزودين ونماذج مختلفة.

إعدادات
Patcher

إعدادات مرتبطة بالنسخة المعدلة وآلية التوجيه --- المصدر: Cybernews.

كما استُبدلت نقاط الاتصال الافتراضية في Claude Code بهذا الوسيط، ما أتاح دعماً لعدة نماذج وإضافة قيود تشغيلية مرتبطة بالتكلفة، مثل التحكم في:

text
Thinking Budget
Reasoning Level
Provider-specific Constraints

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

مستودعات توزيع النسخ
المعدلة

مستودعات توزيع النسخ المعدلة كما ظهرت على الخادم --- المصدر: Cybernews.


#أين يدخل الذكاء الاصطناعي فعلياً في سلسلة الهجوم؟

من السهل اختزال القصة في عبارة مثل "الذكاء الاصطناعي اخترق 87 ألف جهاز"، لكن هذا الوصف يفقد التفاصيل المهمة.

البنية التي كشفها الباحثون تشير إلى منظومة تتكون من عدة طبقات:

text
Legacy Internet-facing Assets
            ↓
Automated Service Discovery
            ↓
Credential Attacks
            ↓
Compromised Devices
            ↓
Proxy Infrastructure
            ↓
Commercial Resale

وفي موازاة ذلك توجد طبقة أتمتة مبنية حول أدوات AI Agent معدلة ومتعددة النماذج.

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


#البعد المؤسسي: المشكلة تبدأ قبل الاختراق

بالنسبة لفرق الأمن السيبراني والحوكمة، لا ينبغي قراءة هذه الحادثة كقصة مهاجم منفرد فقط. الأهم هو السؤال: لماذا بقيت عشرات الآلاف من الأجهزة قابلة للوصول بهذه الصورة؟

الحادثة تربط عدة مجالات عادة ما تُدار داخل المؤسسة بصورة منفصلة:


المجال الخطر الذي تكشفه الحالة


Asset Management أجهزة قديمة قد تبقى خارج الجرد الفعلي

Vulnerability Management استمرار خدمات وبروتوكولات متقادمة

Identity & Access Management كلمات مرور افتراضية أو ضعيفة

Attack Surface Management منافذ وخدمات مكشوفة دون حاجة

Lifecycle Management أجهزة تجاوزت عمرها التشغيلي

Third-Party Risk احتمال شراء خدمة تعتمد على بنية مصدرها غير موثوق

Logging & Monitoring صعوبة اكتشاف إساءة استخدام جهاز كـ Proxy

#AI Governance مخاطر تشغيل وكلاء برمجيين مع صلاحيات واسعة ودون نقاط اعتماد بشرية

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


#من منظور GRC: أين يمكن أن تفشل الضوابط؟

وجود سياسة تمنع كلمات المرور الافتراضية لا يعني أن جميع الأجهزة ملتزمة بها. ووجود معيار لإيقاف البروتوكولات القديمة لا يعني أن PPTP اختفى فعلاً من البيئة.

لذلك يمكن النظر إلى الحالة عبر ثلاث طبقات:

#الحوكمة

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

#المخاطر

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

text
Internet Exposure
Protocol Age
Authentication Strength
Patchability
Business Criticality
End-of-Life Status

#الالتزام

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


#الذكاء الاصطناعي يغيّر اقتصاديات الهجوم أكثر مما يغيّر أساسياته

عملية LeakySensey تقدم نموذجاً مهماً لفهم المرحلة الحالية من التهديدات.

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

هذه المعادلة يمكن التعبير عنها ببساطة:

text
Old Weaknesses + Automation + Scale = High Operational Impact

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


#خادم في فرنسا ومؤشرات تقود إلى روسيا

كانت البنية التحتية المكشوفة مستضافة لدى:

text
OVH SAS

في فرنسا، على العنوان الذي أورده المصدر بصيغة منزوعة التسليح:

text
37[.]187[.]136[.]86[:]9999

ولم يعد المنفذ نشطاً عند نشر النتائج، ورجح الباحثون أن المشغل نقل الخادم.

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

كما وُجد على الخادم عميل:

text
Xray

إضافة إلى آثار بحث حول تجاوز أنظمة الرقابة والتصفية، بما فيها:

text
TSPU
DPI

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


#الخلاصة: أخطر جهاز قد يكون الجهاز الذي نسي الجميع أنه موجود

عملية LeakySensey تكشف فجوة مألوفة في الأمن السيبراني: المؤسسات تستثمر في تقنيات حديثة، بينما قد يبقى أصل قديم على حافة الشبكة يعمل ببروتوكول متقادم وبيانات اعتماد ضعيفة.

المهاجم هنا لم يحوّل ضعفاً واحداً إلى اختراق واحد؛ بل حوّل الإهمال المتكرر عبر آلاف الأجهزة إلى نموذج أعمال.

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

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

لأن الراوتر الذي نُسي منذ سنوات قد لا يكون خاملاً كما يبدو.