تحذير برنامج الفدية SafePay: المهاجمون يستهدفون خوادم Veeam ويعيدون ضبط نسخ NAS إلى إعدادات المصنع

في 20 أكتوبر 2026 نشر مكتب التحقيقات الفيدرالي FBI ووكالة CISA وجهاز الخدمة السرية الأمريكي وجهات شرطية في ألمانيا والمملكة المتحدة التحذير المشترك AA26-293A حول برنامج الفدية SafePay. يقول التحذير إن SafePay "كان من بين أنشط مجموعات الفدية في 2026" وإنه أصاب "ما لا يقل عن 600 ضحية منفصلة" منذ أغسطس 2024. معظم النص يشبه أي تحذير آخر عن الفدية: كلمات مرور VPN مسروقة، وPsExec، وRClone. لكن هناك تفصيلين مختلفين يهمّان كل من يدير غرفة خوادم صغيرة.

اثنتان من الثغرات الخمس التي يستغلها SafePay موجودتان في Veeam Backup & Replication، أي في خادم النسخ الاحتياطي نفسه. وقبل التشفير توقف المجموعة خدمة Volume Shadow Copy وتعيد جهاز NAS الذي يحمل نسخ الضحية الاحتياطية "إلى إعدادات المصنع الأولية". يتخلصون من النسخ الاحتياطية أولًا، ثم يشفّرون. إذا كانت خطة الاستعادة لديك هي أن يكتب Veeam إلى جهاز NAS في الخزانة المجاورة، وكلاهما على الشبكة نفسها ويصل إليهما المسؤولون أنفسهم، فهذا التحذير يشرح بالضبط كيف تفشل تلك الخطة. في ما يلي: ماذا يفعل SafePay، وكيف تتحقق من مدى انكشافك، وأي ترتيب للنسخ الاحتياطي يبقى صالحًا حتى عندما يسيطر المهاجم على خادم النسخ الاحتياطي وجهاز NAS معًا.

ماذا يقول التحذير عن أسلوب SafePay

الدخول. رصدت الجهات المُعدّة للتحذير تسريب بيانات الدخول وتخمين كلمات المرور بالقوة الغاشمة والدخول عبر VPN. يستخدم المهاجمون حسابات تعرّضت للتصيد وعناوين IP تابعة لخدمة Mullvad VPN لاستغلال ثغرتين في Cisco ASA وFirepower: CVE-2020-3259 التي تكشف محتوى الذاكرة عبر واجهة خدمات الويب، وCVE-2023-20269 التي تسهّل تخمين بيانات دخول VPN للوصول عن بعد. كما تستهدف سكربتات آلية ثلاث ثغرات في أنظمة مكشوفة على الإنترنت: CVE-2023-27532 وCVE-2024-40711 في Veeam، وCVE-2024-40766 في SonicWall SonicOS.

بعد الدخول يستولون على حسابات إدارية أو ينشئون حسابات جديدة، ويتنقلون بأدوات مدمجة: PsExec وWinRM وRDP وبرامج الإدارة عن بعد. يحددون المجلدات المشتركة باستخدام ShareFinder.ps1 وSharpShares.exe، ويسحبون بيانات الدخول بأداة Mimikatz وأداة dcsync.exe، ويعطّلون برامج الحماية، وأحيانًا يغيّرون كلمات مرور المستخدمين كي لا يتمكن أحد من الدخول. تُضغط البيانات بـ7-Zip أو WinRAR وتُسرَّب عبر RClone أو WinSCP أو FileZilla أو OneDrive أو أداة b2.exe الخاصة بـBackblaze. وتظهر أيضًا AnyDesk وTeamViewer وScreenConnect.

ثم مرحلة الضرر. تُشفَّر الملفات بمزيج من ChaCha20 وRSA وتحصل على الامتداد .SafePay. توضع رسالة الفدية على سطح المكتب أو في جذر القرص وتحيل إلى بوابة محادثة على شبكة Tor. ويضيف التحذير أن ممثلًا عن SafePay يتصل هاتفيًا بالضحية للضغط عليها، وأن البيانات المسروقة تُنشر على موقع التسريب إن لم يُدفع المبلغ، وأن برنامج الفدية قد يحذف نفسه بعد ذلك.

لماذا ثغرات Veeam هي جوهر القصة

خادم النسخ الاحتياطي يحمل مفاتيح كل ما ينسخه. تقول مقالة Veeam ‏KB4424 إن CVE-2023-27532 تسمح "لمستخدم غير مُصادَق عليه يعمل داخل محيط شبكة البنية التحتية للنسخ الاحتياطي" بالحصول على بيانات دخول مشفّرة من قاعدة بيانات الإعدادات، وهو ما "قد يؤدي إلى وصول المهاجم إلى مضيفي البنية التحتية للنسخ الاحتياطي". العملية المصابة هي Veeam.Backup.Service.exe على المنفذ TCP 9401. الإصدارات المُصلحة هي 12.0.0.1420 P20230223 و11.0.1.1261 P20230227. وأضافتها CISA إلى كتالوج الثغرات المُستغلة (KEV) في 22 أغسطس 2023.

أما CVE-2024-40711 فأخطر. تصنّفها نشرة Veeam الأمنية لشهر سبتمبر 2024 ‏(KB4649) حرجة بدرجة CVSS 9.8، وتصفها بأنها تنفيذ تعليمات برمجية عن بعد دون مصادقة، وتقول إنها تؤثر على الإصدار 12.1.2.172 وكل إصدارات النسخة 12 الأقدم. أُصلحت في 12.2.0.334. وأدرجتها CISA ثغرةً مُستغلة في 17 أكتوبر 2024.

تصحيحات الثغرتين صدرت منذ سنوات. ومجموعة تشغّل سكربتات آلية ضدهما في 2026 تفعل ذلك لأنها ما زالت تجد أهدافًا. من تجربتنا، خادم النسخ الاحتياطي هو الجهاز الذي لا يريد أحد لمسه، لأنه "يعمل" ولأن الترقية قد تكسر سلسلة المهام. وهذه العادة بالذات هي ما يعاقب عليه هذا التحذير.

الخطوة 1: افحص خادم Veeam

استخرج الإصدار المثبّت من ملف الخدمة الذي تذكره KB4424. شغّل هذا الأمر في PowerShell على خادم النسخ الاحتياطي:

(Get-Item "C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.exe").VersionInfo.FileVersion

قارن النتيجة بـقائمة أرقام إصدارات Veeam ‏(KB2680). أي إصدار أقل من 12.2.0.334 مكشوف أمام CVE-2024-40711. النسخة 11 وما قبلها خارج الدعم، وتقول KB4649 إن الإصدارات غير المدعومة "متأثرة على الأرجح ويجب اعتبارها مصابة". وتدرج KB2680 الإصدار 13.1.2 (البناء 13.1.2.57، بتاريخ 27 أكتوبر 2026) أحدثَ إصدار في v13، والبناء 12.3.2.4934 (بتاريخ 29 سبتمبر 2026) لفرع 12.3. انتقل إلى أحدث بناء في فرع مدعوم، لا إلى أي بناء يتجاوز هاتين الثغرتين فقط.

بعد ذلك تحقق ممن يستطيع الوصول إلى المنفذ 9401. من جهاز مكتبي عادي، لا من جهاز إداري، شغّل:

Test-NetConnection -ComputerName veeam01 -Port 9401

إذا عادت القيمة TcpTestSucceeded بـTrue فمعنى ذلك أن حاسوب مستخدم عادي يستطيع التحدث مع خدمة النسخ الاحتياطي. أغلق ذلك بقواعد جدار الحماية أو بشبكة VLAN منفصلة للنسخ الاحتياطي. وفي التثبيتات المتكاملة التي لا تحتوي مكونات بعيدة، تقترح KB4424 نفسها حظر الاتصالات الخارجية إلى TCP 9401 إجراءً مؤقتًا إلى أن يُثبَّت التصحيح. ويجب ألا يكون خادم النسخ الاحتياطي متاحًا من الإنترنت إطلاقًا.

الخطوة 2: افحص أجهزة حافة الشبكة

إن كنت تستخدم Cisco ASA أو FTD فابحث عن إصدارك في تحذيري Cisco المرتبطين أعلاه. توضح Cisco أن CVE-2023-20269 لا تتجاوز المصادقة، وأن جلسة VPN ما زالت تتطلب "عاملًا ثانيًا صالحًا إذا كانت المصادقة متعددة العوامل (MFA) مفعّلة". لذا فتفعيل MFA على VPN حل رخيص يُفشل تخمين كلمات المرور. وبالنسبة لـSonicWall، تقول NVD إن CVE-2024-40766 تؤثر على جدران الحماية من الجيلين Gen 5 وGen 6 وأجهزة Gen 7 العاملة بـSonicOS 7.0.1-5035 وما قبله، وهي على قائمة CISA للثغرات المُستغلة منذ 9 سبتمبر 2024.

تصحيح جدار الحماية لا يُبطل كلمات المرور المسروقة. وبما أن SafePay يدخل ببيانات دخول مسرّبة أو تعرّضت للتصيد، أعد تعيين كلمات مرور VPN وألغِ الجلسات القديمة بعد التصحيح. شرحنا المنطق نفسه في مقالة Citrix NetScaler: تدوير الأسرار بعد التصحيح، وكيف تُسرق بيانات الدخول هذه أصلًا في مقالتنا عن تصيد AiTM.

الخطوة 3: ابحث عن مؤشرات الاختراق الواردة في التحذير

يتضمن التحذير قيم تجزئة وأسماء ملفات وعناوين IP وملفات STIX. هذا فحص أولي سريع على خوادم Windows، بقيم SHA-256 منقولة من التحذير:

$bad = @(
 '327b8b61eb446cc4f710771e44484f62b804ae3d262b57a56575053e2df67917',
 'a0dc80a37eb7e2716c02a94adc8df9baedec192a77bde31669faed228d9ff526',
 '921df888aaabcd828a3723f4c9f5fe8b8379c6b7067d16b2ea10152300417eae'
)
Get-ChildItem C:\Users,C:\ProgramData,C:\Windows\Temp -Recurse -File -Include *.exe,*.dll -ErrorAction SilentlyContinue |
 Get-FileHash -Algorithm SHA256 | Where-Object { $bad -contains $_.Hash }

ثم ابحث بالاسم عن الأدوات التي يذكرها التحذير:

Get-ChildItem C:\ -Recurse -File -ErrorAction SilentlyContinue -Include b2.exe,nxc.exe,sharefinder.ps1,SharpShares.exe,locker.dll,dcsync.exe,netscan.exe |
 Select-Object FullName, LastWriteTime

العثور على netscan.exe أو winrar.exe ليس دليلًا بحد ذاته. فالتحذير ينبّه إلى أن بعض الملفات المذكورة أدوات مشروعة، ويطلب التحقق من عناوين IP قبل حظرها. ابحث كذلك في سجلات VPN وRDP وتسجيل الدخول عن أسماء الأجهزة الواردة فيه، مثل WIN-SBOE3CPNAL وWIN-3IUUOFVTQAR. وأدوات الوصول عن بعد التي لم يوافق عليها أحد تستحق الفحص أيضًا؛ تشرح مقالتنا عن برامج التثبيت المزيفة وأدوات RMM كيف تُبقي تلك القائمة قصيرة. وعلى خوادم الملفات يُظهر الأمر vssadmin list shadows ما إذا كانت النسخ الظلية ما زالت موجودة. إن كانت موجودة سابقًا واختفت الآن، فابحث عن السبب.

الخطوة 4: ترتيب نسخ احتياطي لا يستطيع SafePay إعادة ضبطه

إعادة ضبط NAS هي التفصيل الذي يجب أن يُبنى التصميم حوله. إذا استطاع مهاجم يملك صلاحية domain admin الدخول إلى خادم النسخ الاحتياطي وإلى وحدة التخزين معًا، فهو يملك الاثنين، وإعادة ضبط واحدة تمسح تاريخك كله بنقرة. قاعدة 3-2-1 القديمة (ثلاث نسخ، على نوعين من الوسائط، واحدة خارج الموقع) ما زالت صحيحة، لكن إحدى هذه النسخ يجب أن تكون شيئًا لا يستطيع أحد على شبكتك حذفه لمدة محددة، وأنت منهم.

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

• Veeam Hardened Repository. خادم لينكس تكون فيه ملفات النسخ الاحتياطي، بحسب توثيق Veeam، "غير قابلة للنقل أو التعديل أو الحذف، لكنها قابلة للنسخ" خلال فترة الثبات. ويمكن إضافته ببيانات دخول تُستخدم مرة واحدة ولا تُخزَّن، بحيث "حتى لو اختُرق خادم Veeam Backup & Replication، لا يستطيع المهاجم الحصول على بيانات الدخول".
• S3 Object Lock في وضع compliance. تقول AWS إن نسخة الكائن المقفلة "لا يمكن الكتابة فوقها أو حذفها من قبل أي مستخدم، بما في ذلك المستخدم الجذر في حساب AWS" (توثيق S3 Object Lock). ولا تعمل Object Lock إلا على الحاويات التي فُعّل فيها الإصدار versioning.
• نسخة غير متصلة فعلًا. أقراص أو أشرطة مفصولة ومحفوظة في مكان آخر. الاستعادة منها بطيئة، لكن لا يصل إليها أي سكربت.

إنشاء حاوية مقفلة باستخدام AWS CLI يبدو هكذا (مرجع CLI):

aws s3api create-bucket --bucket acme-backup-locked --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1 \
  --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration --bucket acme-backup-locked \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

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

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

الخطوة 5: اختبار استعادة يمكنك تشغيله هذا الأسبوع

1. اختر خادمًا مؤلمًا فقدانه، مثل خادم الملفات أو قاعدة بيانات المحاسبة، لا أسهل جهاز افتراضي.
2. استعده من النسخة غير القابلة للتعديل أو غير المتصلة، لا من النسخة الأساسية، داخل شبكة معزولة لا مسار لها إلى بيئة الإنتاج.
3. احسب الوقت من "بدء الاستعادة" إلى "كان بإمكان مستخدم تسجيل الدخول". هذا هو زمن الاستعادة الحقيقي لديك.
4. افتح ملفات حقيقية أو نفّذ استعلامًا حقيقيًا، وسجّل تاريخ أحدث بيانات. تلك الفجوة هي حجم البيانات التي ستخسرها فعلًا.
5. حاول حذف نسخة احتياطية مقفلة ببيانات الدخول التي تستخدمها خدمة النسخ الاحتياطي نفسها. في S3: aws s3api delete-object --bucket acme-backup-locked --key <key> --version-id <id>. توثّق AWS أن الحذف الدائم لنسخة محمية يعيد خطأ Access Denied. إن نجح الحذف فإعداد القفل لديك خاطئ.
6. دوّن كل ما تعطّل: مفتاح ترخيص، أو DNS، أو كلمة مرور لا يعرفها إلا شخص واحد.

يستطيع مستخدمو Veeam أتمتة الخطوات من 2 إلى 4 باستخدام SureBackup، التي تصفها Veeam بأنها تقنية "لاختبار النسخ الاحتياطية للأجهزة والتحقق من إمكانية استعادة البيانات منها". ومع ذلك شغّل النسخة اليدوية مرة واحدة على الأقل. فالأتمتة لن تلاحظ أن أحدًا لا يتذكر كلمة مرور domain admin.

الأسئلة الشائعة

المصادر: تحذير CISA وFBI رقم AA26-293A، بتاريخ 20 أكتوبر 2026، Veeam KB4424، Veeam KB4649، Veeam KB2680، NVD CVE-2023-27532، NVD CVE-2024-40711، NVD CVE-2024-40766، تحذيرا Cisco بشأن CVE-2020-3259 وCVE-2023-20269، Veeam Hardened Repository، Amazon S3 Object Lock. جرى التحقق من بيانات الإصدارات في 2 نوفمبر 2026.