มีทางรอดแล้ว! นักวิจัยเปิดเครื่องมือกู้ไฟล์ Synology โดน C3RB3R Ransomware คืนข้อมูล GitLab เกือบ 49GB กลับมาได้ 80 โปรเจกต์

ผู้ดูแลระบบที่ตกเป็นเหยื่อ Ransomware บน NAS ของ Synology อาจยังมีโอกาสกู้ข้อมูลกลับคืนมา หลังนักวิจัยด้านความปลอดภัยเผยแพร่โปรเจกต์โอเพนซอร์สชื่อ c3rb3r-rescue บน GitHub ซึ่งรวบรวมวิธีวิเคราะห์หน่วยความจำ (Memory Forensics) ค้นหาข้อมูลกุญแจถอดรหัสที่หลงเหลืออยู่ใน RAM และนำไปใช้กู้คืนสำเนาไฟล์ที่ถูกเข้ารหัสจากการโจมตี C3RB3R ที่เกี่ยวข้องกับ Synology DSM และ GitLab

ความสำเร็จที่น่าสนใจคือ ผู้พัฒนาสามารถกู้คืนไฟล์สำรองข้อมูล GitLab ขนาดประมาณ 49 GiB จากวันที่ 24 ตุลาคมได้สำเร็จ โดยนำไปทดลองกู้ระบบในสภาพแวดล้อมแยกต่างหาก และสามารถเรียกคืนข้อมูลได้ถึง 80 โปรเจกต์ ผู้ใช้งาน 23 ราย กลุ่มผู้ใช้ 16 กลุ่ม และ Git LFS Objects อีก 9,253 รายการ

โครงการนี้จึงเป็นแนวทางที่มีคุณค่าสำหรับผู้ดูแลระบบและองค์กรที่ได้รับผลกระทบ โดยเฉพาะกรณีที่มัลแวร์เข้ารหัสข้อมูลสำรองไปด้วยจนไม่สามารถใช้วิธีกู้คืนตามปกติได้

ดาวน์โหลดและตรวจสอบรายละเอียดได้ที่ GitHub: c3rb3r-rescue

หัวใจสำคัญคือกุญแจถอดรหัสที่ยังหลงเหลืออยู่ใน RAM

แนวคิดหลักของ c3rb3r-rescue ไม่ใช่การเจาะระบบของผู้โจมตีหรือค้นหากุญแจถอดรหัสกลางที่สามารถใช้กับเหยื่อทุกคน แต่เป็นการตรวจสอบหน่วยความจำของเครื่องที่ถูกโจมตี เพื่อค้นหาข้อมูลที่เกี่ยวข้องกับกระบวนการถอดรหัสซึ่งอาจยังหลงเหลืออยู่ใน RAM

สาเหตุที่ต้องให้ความสำคัญกับหน่วยความจำ เพราะข้อมูลบางส่วนที่ใช้ในกระบวนการเข้ารหัสและถอดรหัสอาจถูกเก็บไว้ในหน่วยความจำระหว่างที่ระบบยังทำงานอยู่ หากเครื่องถูกปิดหรือรีบูต ข้อมูลเหล่านี้จะสูญหายไป

ผู้พัฒนาเตือนว่า เมื่อพบอุปกรณ์ถูกโจมตี สิ่งสำคัญคือการรักษาหลักฐานในหน่วยความจำให้เร็วที่สุด โดยควรหยุดการเข้ารหัสเพิ่มเติมและรักษาช่องทางบริหารจัดการระบบไว้ จากนั้นจึงเก็บข้อมูลหน่วยความจำของโปรเซสและ RAM ของระบบตามความเหมาะสม

สิ่งที่ไม่ควรรีบทำ ได้แก่

• รีบูตหรือปิดเครื่องทันที

• ปิดโปรเซสของมัลแวร์โดยไม่เก็บหลักฐาน

• อัปเกรดระบบปฏิบัติการทันที

• บูตเครื่องด้วย Rescue Disk เพื่อทำความสะอาดก่อนเก็บหลักฐาน

• ลบไฟล์หรือเปลี่ยนแปลงระบบต้นฉบับโดยไม่เก็บสำเนาและหลักฐานที่จำเป็น

เหตุผลคือเมื่อเครื่องสูญเสียพลังงาน ข้อมูลสำคัญที่ยังอยู่ใน RAM อาจหายไปอย่างถาวร ทำให้โอกาสในการตรวจสอบและค้นหาวัสดุสำหรับถอดรหัสลดลงอย่างมาก

ทั้งนี้ การเก็บหน่วยความจำไม่ได้รับประกันว่าจะพบกุญแจที่ใช้งานได้ และการดำเนินการกับระบบที่ถูกโจมตีควรอยู่ภายใต้การดูแลของผู้เชี่ยวชาญด้าน Incident Response เพื่อไม่ให้เกิดความเสียหายเพิ่มเติม

ทดลองบน Proxmox VE กู้ข้อมูล RAM 16GB พบ Master Material 48 ไบต์

ผู้พัฒนาเปิดเผยรายละเอียดการทดลองในสภาพแวดล้อม Proxmox VE (PVE) ซึ่งเป็นแพลตฟอร์มสำหรับจัดการระบบ Virtualization โดยทีมตอบสนองเหตุการณ์สามารถเก็บข้อมูลหน่วยความจำของเครื่องเสมือน (Guest OS) ขนาด 16 GiB ได้ในขณะที่ระบบยังทำงานอยู่

จากการวิเคราะห์ข้อมูลที่ได้ พบชุดข้อมูลสำคัญขนาด 48 ไบต์ ซึ่งผู้พัฒนาเรียกว่า Master Material หรือ Session Recovery Candidate ที่สามารถนำมาใช้ประกอบกระบวนการถอดรหัสไฟล์จากเหตุการณ์ดังกล่าวได้

อย่างไรก็ตาม จุดนี้มีข้อควรระวังสำคัญ เพราะข้อมูลขนาด 48 ไบต์ดังกล่าว ไม่ใช่กุญแจ RSA Private Key ของผู้โจมตี และไม่ใช่กุญแจกลางที่ใช้ถอดรหัสให้เหยื่อทุกคนได้

มันเป็นข้อมูลที่หลงเหลืออยู่ในหน่วยความจำของเซสชันที่ถูกตรวจสอบเท่านั้น และได้รับการยืนยันว่าใช้ได้กับไฟล์จากเหตุการณ์นี้ตามขอบเขตที่ผู้พัฒนาระบุ

ดังนั้น หาก NAS ของผู้ใช้อื่นถูกโจมตีด้วยมัลแวร์ตระกูลเดียวกัน ก็ไม่ได้หมายความว่าจะสามารถนำข้อมูล 48 ไบต์ชุดนี้ไปถอดรหัสไฟล์ทั้งหมดได้ทันที เพราะแต่ละเหตุการณ์อาจมีข้อมูลกุญแจและรายละเอียดการเข้ารหัสแตกต่างกัน

กู้ GitLab Backup 49GB คืน 80 โปรเจกต์ และไฟล์ LFS กว่า 9,000 รายการ

หลังจากค้นพบ Master Material ทีมงานได้นำข้อมูลดังกล่าวไปทดสอบร่วมกับคู่ข้อมูลไฟล์ต้นฉบับและไฟล์ที่ถูกเข้ารหัส ซึ่งทราบเนื้อหาอยู่แล้ว (Known Plaintext-Ciphertext Pairs) จำนวน 5 ชุด

การเปรียบเทียบข้อมูลแบบไบต์ต่อไบต์ทั้ง 5 ชุดผ่านการตรวจสอบ ทำให้ทีมงานมีหลักฐานเพียงพอที่จะนำวัสดุการถอดรหัสไปใช้กับสำเนาไฟล์ที่ได้รับผลกระทบในเหตุการณ์เดียวกัน

ผลการทดลองคือสามารถถอดรหัสไฟล์สำรองข้อมูล GitLab ประจำวันที่ 24 ตุลาคม ขนาดประมาณ 49 GiB ได้ครบถ้วน โดยนำไปกู้คืนในสภาพแวดล้อม GitLab ที่ใช้เวอร์ชันเดียวกับระบบเดิม

ผลการตรวจสอบหลังการกู้คืนประกอบด้วย

นอกจากจำนวนข้อมูลที่กู้คืนได้แล้ว ทีมงานยังตรวจสอบองค์ประกอบสำคัญของ GitLab ได้แก่ Repository, Secrets Variables, Attachments และ CI/CD Artifacts ซึ่งผ่านการตรวจสอบความสมบูรณ์ตามที่โครงการรายงาน

หน้าเข้าสู่ระบบของ GitLab ยังตอบสนองด้วย HTTP 200 ซึ่งเป็นอีกหลักฐานว่าระบบที่กู้คืนสามารถเปิดให้บริการในสภาพแวดล้อมทดสอบได้

ความสำเร็จนี้มีความสำคัญมากสำหรับองค์กรที่ใช้ GitLab จัดเก็บซอร์สโค้ด ระบบพัฒนาโปรแกรม และข้อมูลการทำงานของทีม เพราะการสูญเสีย Repository หรือ LFS Objects อาจส่งผลกระทบต่อกระบวนการพัฒนาซอฟต์แวร์โดยตรง

ระวังข้อมูลแบ็กอัปวันที่ 22 ตุลาคม ยังมีส่วนที่กู้คืนไม่สมบูรณ์

มีอีกประเด็นที่ต้องแยกให้ชัดเจนเกี่ยวกับไฟล์สำรองข้อมูลประจำวันที่ 22 ตุลาคม ซึ่งมีการเข้ารหัสซ้ำแทรกอยู่ในข้อมูลเดิม

ข้อมูลใน README ล่าสุดของโครงการระบุว่า แบ็กอัปชุดนี้ยังอยู่ในสถานะกู้คืนไม่สมบูรณ์ เนื่องจากมีการเข้ารหัสซ้ำแบบแทรกสลับกัน ทำให้กระบวนการถอดรหัสซับซ้อนกว่าชุดวันที่ 24 ตุลาคม

ดังนั้น แม้ไฟล์วันที่ 24 ตุลาคมจะกู้คืนได้ครบตามผลการทดสอบ แต่ยังไม่ควรสรุปว่าแบ็กอัปทุกชุดจากเหตุการณ์เดียวกันสามารถกู้คืนได้ทั้งหมด

ความแตกต่างระหว่างไฟล์แต่ละชุดยังเป็นเหตุผลว่าทำไมการตรวจสอบ Hash, โครงสร้างไฟล์ และความสมบูรณ์ของข้อมูลจึงมีความสำคัญมาก ไม่ใช่เพียงเห็นว่าโปรแกรมถอดรหัสทำงานสำเร็จแล้วจะถือว่าข้อมูลกลับมาสมบูรณ์ทันที

เปิดซอร์สโค้ด พร้อมเครื่องมือช่วยถอดรหัสและตรวจสอบแบ็กอัป

ปัจจุบัน c3rb3r-rescue เปิดให้ผู้สนใจเข้าศึกษาและตรวจสอบบน GitHub โดยภายในโครงการมีเครื่องมือและเอกสารสำหรับกระบวนการกู้คืนหลายส่วน ได้แก่

decrypt_copy.py เป็นสคริปต์สำหรับถอดรหัสสำเนาไฟล์ที่ได้รับผลกระทบ โดยออกแบบให้ทำงานกับสำเนาแยกต่างหาก ไม่ใช่ไฟล์ต้นฉบับบนระบบที่ถูกโจมตี

verify_backup.py เป็นเครื่องมือตรวจสอบความสมบูรณ์ของไฟล์สำรองข้อมูลหลังการถอดรหัส เพื่อช่วยตรวจสอบโครงสร้างและข้อมูลภายในก่อนนำไปกู้คืนบริการจริง

SKILL.md เป็นคู่มือสำหรับ AI Agent ที่ช่วยจัดลำดับกระบวนการทำงาน ตั้งแต่การรักษาหลักฐานในหน่วยความจำ การตรวจสอบระบบ การวิเคราะห์ข้อมูล และการยืนยันผลการกู้คืน

นอกจากนี้ยังมีเอกสารเกี่ยวกับกระบวนการ Forensics การตรวจสอบกุญแจ การจัดการหลักฐาน และข้อจำกัดของเครื่องมือ เพื่อให้นักวิจัยและผู้ดูแลระบบสามารถทำซ้ำการทดสอบในสภาพแวดล้อมที่ควบคุมได้

ผู้พัฒนายังระบุว่าโครงการรองรับเฉพาะตัวอย่างมัลแวร์ libgld และรูปแบบไฟล์ที่ผ่านการวิเคราะห์ในเหตุการณ์นี้เท่านั้น ไม่ใช่เครื่องมือถอดรหัสมัลแวร์ C3RB3R ทุกเวอร์ชัน

อีกข้อจำกัดสำคัญคือ การทดลองเก็บ RAM ที่ประสบความสำเร็จทำผ่าน Guest VM บน Proxmox VE ส่วนการเก็บหน่วยความจำทั้งหมดจากอุปกรณ์ Synology DSM แบบ Physical Hardware ยังไม่ได้รับการยืนยันว่าทำได้จริงในอุปกรณ์ภาคสนาม ดังนั้นจึงไม่ควรนำผลทดสอบบน VM ไปสรุปว่า NAS ทุกเครื่องจะสามารถกู้คืนด้วยวิธีเดียวกันได้

เหยื่อ Ransomware ยังมีโอกาสกู้ข้อมูล แต่ต้องรักษาหลักฐานให้ถูกต้อง

การเปิดตัว c3rb3r-rescue ถือเป็นความคืบหน้าที่สำคัญสำหรับวงการ Cybersecurity เพราะแสดงให้เห็นว่าข้อมูลที่หลงเหลือในหน่วยความจำอาจกลายเป็นกุญแจสำคัญในการกู้คืนไฟล์ แม้ระบบสำรองข้อมูลจะถูกเข้ารหัสไปแล้วก็ตาม

แต่สิ่งที่ต้องเน้นคือ เครื่องมือนี้ไม่ได้รับประกันว่าจะช่วยกู้ข้อมูลของทุกคนได้ และไม่ควรนำไปทดลองกับข้อมูลต้นฉบับบน NAS ที่ถูกโจมตีโดยตรง เพราะอาจทำให้หลักฐานเสียหายหรือข้อมูลสูญหายเพิ่มเติม

สำหรับองค์กรที่กำลังเผชิญเหตุ สิ่งสำคัญที่สุดคือการรักษาหลักฐานต้นฉบับ เก็บสำเนาข้อมูลอย่างเป็นระบบ และดำเนินการวิเคราะห์ในเครื่องแยกที่ปลอดภัย โดยให้ผู้เชี่ยวชาญด้านการตอบสนองเหตุการณ์เข้ามาช่วยตรวจสอบ

สรุป: c3rb3r-rescue เป็นความหวังใหม่สำหรับเหยื่อ Synology/GitLab Ransomware หลังผู้พัฒนาสามารถใช้ข้อมูลที่กู้จาก RAM ขนาด 16GB ค้นพบวัสดุถอดรหัส 48 ไบต์ และนำไปกู้แบ็กอัป GitLab ขนาดเกือบ 49GB กลับมาได้ 80 โปรเจกต์ พร้อม LFS Objects อีก 9,253 รายการ แต่เครื่องมือนี้ยังจำกัดอยู่กับตัวอย่างและรูปแบบไฟล์ที่วิเคราะห์แล้ว ไม่ใช่ Universal Decryptor สำหรับเหยื่อ C3RB3R ทุกคน

ที่มา: X

【試試】如果你不幸成為 Synology 受災戶，先不要放棄治療！有資安研究人員在 GitHub 上釋出名為「c3rb3r-rescue」的開源專案，針對近期的 Synology DSM / GitLab 勒索軟體事件，提供一套基於實證（Evidence-based）的記憶體取證與副本解密復原方法。目前該專案已成功還原 10 月 24 日近 49 GiB 的 GitLab 每週備份檔案，恢復了 80 個專案、23 名使用者、16 個群組與逾 9,000 個 LFS 物件，為遭遇同類勒索攻擊的企業與系統管理員提供了極具參考價值的實戰應變指引。 據了解，「c3rb3r-rescue」並非 C3RB3R 家族通用的萬能解密程式（Universal Decryptor），而是針對已分析的特定樣本（libgld）與檔案格式所建立的鑑識及解密記錄，其核心概念在於搶救記憶體（RAM）中殘留的解密材料，用以解密受災檔案的獨立副本。因此，當設備遭入侵時，關鍵在於「保住揮發性記憶體」，切勿在第一時間直接重開機或變更系統設定。 https://t.co/LjLo2MUzu7 開發者特別提醒，當管理員發現設備遭受勒索攻擊時，首要原則是在封鎖惡意程式繼續加密、同時保留管理通道的前提下，以最快速度擷取處理程序記憶體及整機實體 RAM。千萬不要為了清理惡意程式而貿然結束處理程序（Kill Process）、重新開機、升級作業系統，或是載入救援光碟開機；皆因主機一旦重新開機或電源中斷，記憶體內的揮發性金鑰便會徹底遺失，後續的取證與還原程序亦將完全失效。 在 Proxmox VE（PVE）虛擬化環境的實測中，應變團隊在維持系統運行的狀態下，迅速完成來賓虛擬機（Guest OS）的 16 GiB 記憶體傾印（Memory Dump），最終成功在記憶體殘留中擷取出一組關鍵的 48 位元組主要材料（Master Material）。不過作者強調，這組金鑰僅為該特定工作階段在記憶體內的殘留材料，並非攻擊者的通用 RSA 私鑰，因此無法直接跨受害者套用；其他受害者仍須從自己機器的記憶體中擷取對應金鑰，或在獨立副本上進行比對驗證。 解密過程中，團隊透過這組金鑰配合五組已知明密文逐位元組比對驗證，成功將 10 月 24 日約 49 GiB 的每週備份完整解密，並在隔離環境的同版本 GitLab 中順利恢復出 80 個專案、23 名使用者、16 個群組及 9,253 個 LFS 物件；其程式庫（Repositories）、Secrets 機密變數、附件與 CI/CD Artifacts 均通過完整性校驗，Web 登入頁面亦正常回應 HTTP 200。此外，另一個於 10 月 22 日存在交錯重複加密（Interleaved Encryption）的週備份，最終亦成功達成完美復原。 目前「c3rb3r-rescue」專案已在 GitHub 開源釋出，內容包含取證流程、自動化解密指令碼（decrypt_copy.py）、多階段備份校驗工具（verify_backup.py），並附帶了可供 AI 代理協助引導操作的任務技能說明（SKILL.md），供資安研究人員與受害管理員在獨立副本環境下參考驗證。

— HKEPC (@hkepcmedia) October 29, 2026