بعد أكثر من 20 عامًا من الصمود: كيف سقطت شبكة Sality عندما تحولت قوة الـ P2P إلى نقطة انهيار؟

بعض شبكات الروبوتات تنهار بمجرد إغلاق خادم قيادة وتحكم واحد. وبعضها الآخر يُبنى منذ البداية على فرضية أن هذا الخادم يجب ألا يوجد أصلًا.

هنا تكمن قصة Sality.

منذ ظهورها لأول مرة في عام 2003، تطورت البرمجية الخبيثة من مصيب للملفات إلى شبكة روبوتات تعتمد على بنية Peer-to-Peer (P2P) موزعة، بلا نقطة فشل مركزية واضحة. هذه البنية منحتها قدرة استثنائية على الاستمرار لأكثر من عقدين، حتى أصبحت واحدة من أكثر البنى الإجرامية صمودًا على الإنترنت.

لكن في 31 أغسطس 2026، نفذت CrowdStrike Counter Adversary Operations بالتعاون مع جهات إنفاذ قانون وشركاء صناعيين عملية تعطيل منسقة استهدفت البنية نفسها التي جعلت Sality عصية على الإزالة.

لم يكن الهدف مجرد حجب نطاق أو مصادرة خادم.

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

[!tldr] نجحت عملية تعطيل Sality عبر استغلال خصائص بروتوكولها P2P والتلاعب بقوائم الأقران داخل الأجهزة المصابة، ثم إدخال عقد Sinkhole مكان الأقران الشرعيين. النتيجة: عزل الأجهزة المصابة عن البنية التي يسيطر عليها المشغل، ومنع وصول تعليمات تحميل الحمولة الخبيثة الجديدة إليها، مع بقاء البرمجيات الخبيثة الموجودة مسبقًا على الأجهزة بحاجة إلى معالجة فعلية.

#ما هي Sality؟ ولماذا بقيت كل هذه السنوات؟

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

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

بدلًا من النموذج التقليدي:

Infected Host -> C2 Server -> Command

كانت البنية أقرب إلى:

Infected Host <-> Peer <-> Super Peer <-> Peer <-> Infected Host

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

هذا الاختلاف المعماري كان جوهر قدرتها على الاستمرار.

#سببان رئيسيان وراء صمود Sality

الأول هو مرونة بنية:

Peer-to-Peer (P2P)

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

أما الثاني فهو طريقة انتشارها بصفتها:

Polymorphic File Infector

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

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

#شبكتان مستقلتان داخل Sality

حتى تنفيذ عملية التعطيل، كانت هناك شبكتان مستقلتان من Sality:

Sality v3
Sality v4

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

Protocol Version
Cryptographic Keys

وهذا يعني أن التوافق بينهما لم يكن مباشرًا رغم انتمائهما إلى نفس البنية التشغيلية.

هذه النقطة مهمة دفاعيًا؛ لأن التعامل مع عائلة برمجية واحدة لا يعني دائمًا أن لديك شبكة واحدة أو قناة تحكم واحدة أو حتى مفاتيح تحقق واحدة.

#أكثر من 33 ألف جهاز ضمن البنية المصابة

وفق البيانات المنشورة حول العملية، مكنت شبكة Sality المشغل من توزيع حمولات خبيثة على أكثر من:

33,000+

جهاز مصاب حول العالم.

الشكل 1: توزيع الأجهزة المصابة ضمن شبكة Sality.

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

#Sality لم تكن الحمولة النهائية

إحدى أهم النقاط في تحليل Sality هي أن وظيفتها الرئيسية لم تكن تنفيذ غرض إجرامي واحد فقط.

كانت أقرب إلى منصة توزيع.

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

وعبر تاريخها، استُخدمت لتوزيع برمجيات مرتبطة بـ:

وهنا تظهر خطورة شبكات التوزيع الخبيثة: إزالة حمولة واحدة لا تعني إزالة القدرة التشغيلية للمهاجم إذا بقيت قناة التوزيع موجودة.

#EggJagger: سرقة العملة من الحافظة

خلال السنوات الثماني الأخيرة قبل عملية التعطيل، كانت إحدى أبرز الحمولات المرتبطة بالشبكة أداة:

EggJagger

وهي أداة من نوع:

Clipjacking

تراقب الحافظة في النظام بحثًا عن عناوين محافظ العملات الرقمية.

عندما ينسخ المستخدم عنوان محفظة Bitcoin أو Ethereum لإجراء عملية دفع، تستبدل البرمجية العنوان في الحافظة بعنوان يعود إلى المشغل.

التسلسل يصبح على النحو التالي:

Victim copies wallet address
        |
        v
Malware detects the address
        |
        v
Clipboard value is replaced
        |
        v
Victim pastes attacker-controlled address
        |
        v
Funds are redirected

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

يكفي تغيير الوجهة قبل اعتماد المستخدم للمعاملة.

#كم جنت العملية؟

قدرت CrowdStrike أن المشغل سرق عبر أسلوب EggJagger وحده ما لا يقل عن:

₽12.1M

أي قرابة:

$150,000 USD

بينما بلغت القيمة القصوى للمحافظ التي لم تُنفق أموالها قرابة:

₽147M

في يناير 2025.

الشكل 2: قيمة الأموال المرتبطة بحمولة EggJagger كما وردت في تحليل العملية.

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

#عندما تتحول شبكة توزيع إلى سلاح DDoS

رغم أن الدافع المالي كان الأكثر وضوحًا، فإن Sality استُخدمت أيضًا في ثلاث حملات DDoS بارزة.

#أبريل 2016: استهداف منتدى مالي عربي

استهدفت إحدى الحمولات:

forex2030[.]com

وهو موقع عربي كان يغطي شركات تداول الموارد الطبيعية.

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

#فبراير 2022: استهداف منتدى أوكراني

في 25 فبراير 2022، وزعت Sality حمولة DDoS استهدفت:

kharkovforum[.]com

وكان المنتدى يستضيف نقاشات مرتبطة بالأحداث العسكرية في خاركيف.

أنتجت الحمولة حركة HTTP ضخمة لإغراق الخدمة ومنع الوصول إليها.

#سبتمبر 2023: استهداف منصة عملات رقمية

استهدفت حمولة أخرى منصة:

AvanChange

وهي منصة روسية لتبادل العملات الرقمية.

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

عملية التعطيل: إسقاط شبكة بلا رأس

هنا تبدأ أكثر أجزاء القصة أهمية من الناحية التقنية.

في شبكات C2 التقليدية، قد تركز عملية التعطيل على:

Domain Seizure
Server Takedown
DNS Sinkhole
Hosting Provider Coordination

لكن Sality لم تعتمد على نقطة مركزية واحدة.

لذلك كان لا بد من مهاجمة منطق الشبكة نفسها.

[!signal] نقطة الضعف لم تكن في وجود خادم مركزي ضعيف، بل في افتراض ثقة داخل بروتوكول P2P: أي جهاز يستجيب بالشكل الصحيح للمصافحة يمكن قبوله كعضو شرعي في الشبكة.

#البروتوكول الذي لا يمكن ترقيعه

من أبرز عناصر الضعف في Sality أن بروتوكولها لا يمكن ترقيعه بسهولة بالطريقة التقليدية.

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

أما Sality فانتشرت عبر إصابة الملفات نفسها.

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

نتيجة ذلك أن سلوك البروتوكول ظل إلى حد كبير ثابتًا على مدى سنوات طويلة.

وأي ضعف بنيوي في البروتوكول أصبح ضعفًا دائمًا.

#الثقة كانت نقطة الانهيار

أجهزة Sality كانت تثق في الشبكة من دون تحقق قوي من هوية العضو.

لم تكن هناك آليات مثل:

Peer Authentication
Cryptographic Identity
Allowlist

الشرط الأساسي كان أن يكون الجهاز متاحًا علنًا وأن يجيب بصورة صحيحة على:

P2P Handshake

عندها يمكن أن يُعامل كـ Peer شرعي.

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

التلاعب بقائمة الأقران Peer List Manipulation

كل جهاز داخل Sality يحتفظ بقائمة محدودة من:

Super Peers

وهي أجهزة مصابة متاحة من الإنترنت وتشكل العمود الفقري لاتصالات شبكة P2P.

وكان الجهاز يتحقق تقريبًا كل:

40 minutes

من حالة الأقران المخزنين لديه.

المنطق مبسطًا:

Peer responds
    -> Reputation increases

Peer does not respond
    -> Reputation decreases
    -> Peer may eventually be removed

عملية التعطيل استغلت دورة الصيانة هذه.

#المرحلة الأولى: إخراج الأقران الشرعيين

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

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

بصيغة مبسطة:

Original Peer List
------------------
Legitimate Peer A
Legitimate Peer B
Legitimate Peer C

        |
        v

Manipulation / Invalidations

        |
        v

Peer List
---------
[empty / degraded]

#المرحلة الثانية: إدخال Sinkholes

بعد تفريغ أو إضعاف القائمة، تم إدخال عقد مخصصة من نوع:

Sinkhole

فتصبح الصورة:

Peer List
---------
Sinkhole A
Sinkhole B
Sinkhole C

وهنا يتغير اتجاه الشبكة.

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

#لماذا استُهدفت Super Peers أولًا؟

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

عند عزلها، يتوقف انتشار نوعين مهمين من البيانات داخل Sality:

URL Packs
File Packs

الأولى تحتوي على تعليمات وروابط تحميل الحمولات.

والثانية تتيح نقل ملفات الحمولة نفسها.

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

#ماذا عن الأجهزة خلف NAT والجدران النارية؟

عدد كبير من الإصابات لم يكن متاحًا مباشرة من الإنترنت بسبب:

Firewall
NAT

وبالتالي لا يمكن الوصول إلى هذه الأجهزة بالطريقة نفسها.

الحل كان أكثر سلبية.

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

من منظور المشغل، النتيجة بسيطة:

Infected machines disappear.

إسقاط روابط الحمولات بالتوازي

لم تعتمد العملية على P2P Sinkholing وحده.

بالتوازي، جرى التنسيق لإزالة الروابط المستخدمة لاستضافة حمولات Sality.

هذه الروابط كانت تصل إلى الأجهزة عبر:

URL Packs

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

العملية بالتالي اعتمدت على طبقتين:

كيف تعرف أن لديك إصابة Sality؟

بعد عملية التعطيل، بدأت الأجهزة المصابة بالاتصال بعقد Sinkhole التي تشغلها CrowdStrike.

أحد أهم المؤشرات المنشورة هو حركة UDP باتجاه عنوان "Lighthouse" التالي:

188.166.101[.]148

وجود اتصال مطابق لهذا المؤشر يعني ضرورة التعامل مع الجهاز باعتباره إصابة تحتاج إلى معالجة.

[!defender-note] تعطيل قناة التحكم لا يعني أن الجهاز أصبح نظيفًا. العملية تمنع وصول مهام وحمولات جديدة، لكنها لا تزيل تلقائيًا البرمجيات الخبيثة الموجودة مسبقًا على النظام.

مؤشرات الاختراق IOC

آخر حزمة روابط منشورة لـ Sality v3 حملت الإصدار:

25202

وتضمنت:

http[:]//theunforgiven.p8[.]hu/img/top.gif
http[:]//painelwebradiodigital.awardspace[.]info/v3/readme.pdf
http[:]//sgwebdesigner.free[.]fr/left.gif
http[:]//www.yonelco[.]com/icon.png
http[:]//pozdravizbeograda[.]com/readme.pdf
http[:]//highclass.atspace[.]com/styles.gif
http[:]//situluimihai.3x[.]ro/top.png

أما حزمة Sality v4 ذات الإصدار:

31010

فتضمنت:

http[:]//gatheredovertime[.]com/nb4
http[:]//imagebucket[.]biz/nv4

محاولات الاتصال بهذه الوجهات تستحق التحقيق وربطها مع بيانات:

DNS
Proxy
Firewall
EDR
NetFlow

قواعد YARA لفحص الذاكرة

القواعد المنشورة تستهدف مفاتيح RSA Public Keys المضمنة داخل إصداري Sality، والمستخدمة للتحقق من توقيعات الحمولات.

#Sality v3

rule CrowdStrike_Salityv3_01 : p2p sality version3
{
    meta:
        copyright = "(c) 2026 CrowdStrike Inc."
        description = "Sality Version 3"
        version = "202608181745"
        last_modified = "2026-08-18"
        actor = "SALTY SPIDER"
        malware_family = "Sality"
    strings:
        $ = "IPFILTERDRIVER"
        $ = {
            99 65 40 34 cd ae 9d b3  af f5 82 ad 8c 2e 63 51
            e1 34 53 fa 47 54 e4 70  97 4c a5 3d 3c a3 9b 57
            29 02 49 89 46 4c f2 76  b1 ad 8e 79 5d b2 41 28
            4f 2a a5 9a 13 18 c0 1d  ed da e4 52 98 16 7f b3
            a9 d7 7a e4 c4 6f 51 f6  38 fe a6 fb ad 8c 64 1d
            23 b5 a4 9d 40 20 74 61  be 81 c3 eb 3d 24 01 75
            13 07 58 c5 f0 56 09 94  58 e7 6b c3 f3 8c 70 73
            4e f5 0b 2d 88 0b 9a bd  18 e4 36 72 26 1a 32 9b
        }
    condition:
        all of them
}

#Sality v4

rule CrowdStrike_Salityv4_01 : p2p sality version4
{
    meta:
        copyright = "(c) 2026 CrowdStrike Inc."
        description = "Sality Version 4"
        version = "202608181745"
        last_modified = "2026-08-18"
        actor = "SALTY SPIDER"
        malware_family = "Sality"
    strings:
        $ = "IPFILTERDRIVER"
        $ = {
            bb d2 96 8e ed 0b 93 8a  82 e4 e9 bc c3 c5 32 72
            4c 08 aa 56 9f 2d 64 0f  1b 86 68 0e 2b 62 e9 c6
            35 6d 75 b6 32 2d 4f a8  b8 d9 2a 44 8b f0 7f e0
            d9 8e be 66 9d a6 7a 9a  6d e1 45 f1 d3 48 01 0d
            39 2e 9d 2a 45 fb 0b fb  1d 96 f3 b7 4f 55 e5 e1
            16 5b f7 a1 cc 7c 87 c0  c8 9c ef 4e ce 29 58 e2
            99 bd 8a 7a 55 be b4 1c  d9 79 52 25 d8 28 86 7b
            81 39 98 5f 2c 6f 14 bb  a5 6b ce 44 e5 91 93 38
            8b 9a c1 74 46 84 e1 26  ec 04 94 96 75 09 e3 b5
            88 d6 08 f0 4a b7 84 d3  13 2f 00 cc d5 2a 8c 17
            07 09 de 6f b0 d3 d6 2b  c6 a6 9d 38 18 8c 74 9d
            86 16 d5 48 6e 97 32 db  e1 4e f8 04 a6 00 7c 16
            2e 70 1c 23 37 dd 5a 52  76 62 70 d4 86 66 6e df
            0c e9 a1 68 f9 5e e8 dd  09 0c 02 7d 35 d0 54 e7
            00 c0 14 9f ce 4a 9f f3  99 50 1a 0b cd cc ff 05
            b9 04 12 e2 11 76 2f ff  a4 6e 64 18 e0 d0 7b 3b
        }
    condition:
        all of them
}

أين يأتي دور فرق SOC وIncident Response؟

القيمة العملية لهذه العملية لا تتوقف عند معرفة أن شبكة Sality عُطلت.

الفريق الدفاعي يجب أن يتعامل مع المؤشرات كمدخل لتحقيق كامل.

يمكن بناء مسار التحقيق على النحو التالي:

Network IOC Match
      |
      v
Identify Endpoint
      |
      v
Collect EDR Telemetry
      |
      v
Memory / Process Scan
      |
      v
Run YARA Rules
      |
      v
Check Persistence & File Infection
      |
      v
Contain Host
      |
      v
Remediate / Rebuild
      |
      v
Validate No Lateral Spread

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

البعد الأهم في GRC: التعطيل الخارجي لا يلغي المسؤولية الداخلية

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

تعطيل البنية الإجرامية لا يساوي معالجة الخطر داخل المنظمة.

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

هناك فرق بين:

Threat Infrastructure Disrupted

وبين:

Compromised Asset Remediated

الأولى حدث خارجي.

أما الثانية فهي مسؤولية داخلية يجب أن تكون موثقة وقابلة للإثبات.

#ترجمة الحادثة إلى ضوابط GRC

هذه الضوابط ليست إجراءً شكليًا.

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

هل كانت بيئتنا مصابة؟

البحث الرجعي Retroactive Hunting

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

أمثلة على البيانات التي تستحق الفحص:

Firewall Logs
DNS Logs
Proxy Logs
EDR Network Events
NetFlow
Endpoint Process Telemetry

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

188.166.101[.]148

بالإضافة إلى النطاقات والروابط الواردة في حزم URL Packs.

إذا وُجدت اتصالات سابقة، يجب ربطها زمنيًا مع:

Process Creation
File Modification
Network Share Activity
Removable Media Events

للوصول إلى صورة أوضح عن نقطة البداية ومسار الانتشار.

[!research-note] شبكة Sality تُظهر أن العمر الطويل للبنية الخبيثة لا يعني أنها محصنة. أحيانًا تكون نقاط الضعف الأكثر قيمة موجودة في افتراضات التصميم الأصلية للبروتوكول نفسه، لا في ثغرة برمجية تقليدية قابلة للترقيع.

الدرس المعماري: اللامركزية ليست حصانة

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

وهذا صحيح من زاوية معينة.

لكن غياب المركز لا يلغي نقاط الثقة.

في حالة Sality، كان التصميم يعتمد على افتراض جوهري:

If a peer speaks the protocol correctly,
it can be trusted as a legitimate participant.

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

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

الخلاصة

استمرت Sality لأكثر من عشرين عامًا لأنها جمعت بين الانتشار عبر إصابة الملفات وبنية P2P لا تعتمد على نقطة فشل مركزية.

لكن عملية 31 أغسطس 2026 أثبتت أن الصمود المعماري لا يعني المناعة.

من خلال التلاعب بقوائم الأقران، عزل Super Peers، إدخال عقد Sinkhole، وإزالة روابط الحمولات بالتوازي، فقد المشغل القدرة على التواصل مع الأجهزة المصابة وإرسال مهام جديدة إليها.

ومع ذلك تبقى النقطة الأهم للمدافعين:

Disruption != Remediation

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

القصة هنا ليست فقط قصة إسقاط شبكة روبوتات قديمة.

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