هشدار باج‌افزار SafePay: حمله به سرورهای Veeam و ریست کارخانه‌ای بکاپ‌های NAS

روز ۲۰ اکتبر ۲۰۲۶، FBI، CISA، سرویس مخفی آمریکا و نهادهای پلیس آلمان و بریتانیا هشدار مشترک AA26-293A دربارهٔ باج‌افزار SafePay را منتشر کردند. طبق این هشدار، SafePay «در سال ۲۰۲۶ جزو فعال‌ترین گروه‌های باج‌افزاری بوده» و از اوت ۲۰۲۴ تا امروز «دست‌کم ۶۰۰ قربانی جداگانه» داشته است. بخش بزرگی از متن شبیه هر هشدار باج‌افزاری دیگری است: رمزهای VPN دزدیده‌شده، PsExec و RClone. اما دو نکته فرق دارد و برای هر کسی که یک اتاق سرور کوچک را اداره می‌کند مهم است.

دو مورد از پنج CVE که SafePay از آن‌ها سوءاستفاده می‌کند در Veeam Backup & Replication است، یعنی خودِ سرور بکاپ. و این گروه پیش از رمزگذاری، سرویس Volume Shadow Copy را متوقف می‌کند و NAS حاوی بکاپ‌های قربانی را «به تنظیمات کارخانه» برمی‌گرداند. اول بکاپ‌ها را از بین می‌برند، بعد رمزگذاری می‌کنند. اگر برنامهٔ بازیابی شما این است که Veeam روی یک NAS در رک کناری بنویسد و هر دو در یک شبکه و در دسترس همان ادمین‌ها باشند، این هشدار دقیقاً نشان می‌دهد آن برنامه چطور شکست می‌خورد. در ادامه: SafePay چه می‌کند، چطور میزان در معرض بودن خود را بسنجید، و چه چیدمان بکاپی حتی وقتی مهاجم هم سرور بکاپ و هم NAS را در اختیار دارد کار می‌کند.

هشدار می‌گوید SafePay چه می‌کند

ورود. نهادهای نویسندهٔ هشدار، افشای اطلاعات ورود، حدس رمز به روش brute force و دسترسی از راه 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 برای فشار آوردن به قربانی تلفن هم می‌زند، اگر پولی پرداخت نشود داده‌های دزدیده‌شده در سایت افشا منتشر می‌شود، و باج‌افزار ممکن است پس از کار خودش را پاک کند.

چرا CVEهای Veeam اصل ماجراست

سرور بکاپ کلید همهٔ سیستم‌هایی را که از آن‌ها بکاپ می‌گیرد نگه می‌دارد. KB4424 خود Veeam می‌گوید CVE-2023-27532 به «کاربر احراز هویت‌نشده‌ای که داخل محدودهٔ شبکهٔ زیرساخت بکاپ است» اجازه می‌دهد اطلاعات ورود رمزشده را از پایگاه دادهٔ پیکربندی بگیرد، و این «ممکن است به دسترسی مهاجم به میزبان‌های زیرساخت بکاپ منجر شود.» پروسهٔ آسیب‌پذیر Veeam.Backup.Service.exe روی پورت TCP 9401 است. بیلدهای اصلاح‌شده 12.0.0.1420 P20230223 و 11.0.1.1261 P20230227 هستند. CISA آن را در ۲۲ اوت ۲۰۲۳ به فهرست آسیب‌پذیری‌های مورد بهره‌برداری (KEV) اضافه کرد.

CVE-2024-40711 بدتر است. بولتن سپتامبر ۲۰۲۴ Veeam (KB4649) آن را بحرانی با امتیاز CVSS 9.8 می‌داند، آن را اجرای کد از راه دور بدون احراز هویت توصیف می‌کند و می‌گوید بیلد 12.1.2.172 و همهٔ بیلدهای قدیمی‌تر نسخهٔ ۱۲ را درگیر می‌کند. اصلاح آن در 12.2.0.334 آمد. CISA آن را در ۱۷ اکتبر ۲۰۲۴ مورد بهره‌برداری اعلام کرد.

وصلهٔ هر دو سال‌هاست منتشر شده. گروهی که در ۲۰۲۶ با اسکریپت خودکار سراغشان می‌رود، این کار را می‌کند چون هنوز هدف پیدا می‌کند. تجربهٔ ما این است که سرور بکاپ همان سیستمی است که کسی نمی‌خواهد به آن دست بزند، چون «کار می‌کند» و ارتقا ممکن است زنجیرهٔ jobها را به هم بریزد. این هشدار دقیقاً همین عادت را تنبیه می‌کند.

گام ۱: سرور 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 باز است. نسخهٔ ۱۱ و قدیمی‌تر پشتیبانی نمی‌شوند و KB4649 می‌گوید نسخه‌های بدون پشتیبانی «احتمالاً آسیب‌پذیرند و باید آسیب‌پذیر فرض شوند.» KB2680 نسخهٔ 13.1.2 (بیلد 13.1.2.57، ۲۷ اکتبر ۲۰۲۶) را تازه‌ترین نسخهٔ v13 و بیلد 12.3.2.4934 (۲۹ سپتامبر ۲۰۲۶) را برای شاخهٔ 12.3 فهرست کرده است. به تازه‌ترین بیلدِ یک شاخهٔ تحت پشتیبانی بروید، نه فقط بیلدی که این دو CVE را رد کرده باشد.

بعد ببینید چه کسی به پورت 9401 دسترسی دارد. از یک کامپیوتر معمولی اداری، نه سیستم ادمین، اجرا کنید:

Test-NetConnection -ComputerName veeam01 -Port 9401

اگر TcpTestSucceeded مقدار True برگرداند، لپ‌تاپ یک کاربر عادی می‌تواند با سرویس بکاپ شما حرف بزند. این را با قوانین فایروال یا یک VLAN جدا برای بکاپ ببندید. برای نصب‌های یکپارچه که اجزای راه دور ندارند، خود KB4424 پیشنهاد می‌کند تا نصب وصله، اتصال خارجی به TCP 9401 را موقتاً مسدود کنید. سرور بکاپ هرگز نباید از اینترنت در دسترس باشد.

گام ۲: تجهیزات لبهٔ شبکه را بررسی کنید

برای 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 است.

وصله کردن فایروال، رمزهای دزدیده‌شده را برنمی‌گرداند. چون SafePay با اطلاعات ورود فیشینگ‌شده و افشاشده وارد می‌شود، بعد از وصله رمزهای VPN را عوض کنید و نشست‌های قدیمی را باطل کنید. همین منطق را در مقالهٔ Citrix NetScaler: تعویض رمزها بعد از وصله توضیح داده‌ایم، و اینکه این اطلاعات ورود اصلاً چطور فیش می‌شوند در مقالهٔ فیشینگ AiTM آمده است.

گام ۳: دنبال نشانه‌های نفوذ در هشدار بگردید

هشدار شامل هش‌ها، نام فایل‌ها، نشانی‌های IP و فایل‌های STIX است. یک بررسی اولیه روی سرورهای ویندوز، با مقادیر 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 نشان می‌دهد shadow copyها هنوز وجود دارند یا نه. اگر قبلاً بودند و حالا نیستند، علتش را پیدا کنید.

گام ۴: چیدمان بکاپی که SafePay نمی‌تواند ریست کند

ریست NAS همان جزئیاتی است که باید طراحی را حول آن چید. اگر مهاجمی با دسترسی domain admin بتواند هم وارد سرور بکاپ و هم وارد فضای ذخیره‌سازی بکاپ شود، هر دو را در اختیار دارد و یک ریست کل تاریخچهٔ شما را با یک کلیک پاک می‌کند. قاعدهٔ قدیمی 3-2-1 (سه نسخه، روی دو نوع رسانه، یکی خارج از محل) هنوز درست است، اما یکی از این نسخه‌ها باید چیزی باشد که برای مدت مشخصی هیچ‌کس در شبکهٔ شما نتواند پاکش کند، حتی خود شما.

توصیه‌های خود هشدار هم همین را می‌گوید: «از داده‌ها بکاپ آفلاین نگه دارید و فرایند بکاپ و بازیابی را مرتب آزمایش و نگهداری کنید»، بکاپ‌ها را رمزگذاری و تغییرناپذیر کنید و نسخه‌ها را در محلی از نظر فیزیکی جدا و تفکیک‌شده نگه دارید. سه راه برای رسیدن به این وضعیت:

• Veeam Hardened Repository. یک سرور لینوکسی که طبق مستندات Veeam، فایل‌های بکاپ در دورهٔ تغییرناپذیری «نه جابه‌جا، نه ویرایش و نه حذف می‌شوند، ولی قابل کپی‌اند.» می‌توان آن را با اطلاعات ورود یک‌بارمصرف اضافه کرد که جایی ذخیره نمی‌شود، بنابراین «حتی اگر سرور Veeam Backup & Replication نفوذ شود، مهاجم نمی‌تواند به این اطلاعات ورود دست پیدا کند.»
• S3 Object Lock در حالت compliance. AWS می‌گوید نسخهٔ قفل‌شدهٔ یک شیء «توسط هیچ کاربری، از جمله کاربر root حساب 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 است؛ پس ورود root را با MFA ببندید و از کار روزمره دور نگه دارید.

NAS را نگه دارید، فقط دیگر آن را نسخهٔ امن حساب نکنید. رابط مدیریتی‌اش را روی شبکه‌ای بگذارید که کامپیوترهای کاربران به آن دسترسی ندارند، یک حساب ادمین محلی بیرون از Active Directory به آن بدهید و مدیریت از راه دوری را که استفاده نمی‌کنید خاموش کنید.

گام ۵: یک آزمون بازیابی که همین هفته می‌توانید اجرا کنید

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 می‌توانند گام‌های ۲ تا ۴ را با SureBackup خودکار کنند که Veeam آن را فناوری‌ای برای «آزمایش بکاپ ماشین‌ها و بررسی امکان بازیابی داده از آن‌ها» توصیف می‌کند. با این حال نسخهٔ دستی را دست‌کم یک بار اجرا کنید. اتوماسیون متوجه نمی‌شود که هیچ‌کس رمز domain admin را به خاطر ندارد.

پرسش‌های متداول

منابع: هشدار AA26-293A از CISA و FBI، ۲۰ اکتبر ۲۰۲۶، 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. اطلاعات نسخه‌ها در ۲ نوامبر ۲۰۲۶ بررسی شده است.