ได้รับเคสตรวจพิสูจน์เครื่องเซิร์ฟเวอร์ติด ransomware ที่ encrypt ข้อมูลแล้วเปลี่ยนนามสกุลไฟล์เป็น .xtbl โดยจุดประสงค์ของการตรวจไม่ได้ต้องการให้กู้ไฟล์กลับคืนมา แต่ต้องการให้ช่วยค้นหาว่ามันติดเข้ามาที่เครื่องนี้ได้ยังไง เพื่อจะได้ป้องกันไม่ให้เกิดเหตุการณ์ลักษณะนี้กับเครื่องอื่น เพราะจากข้อมูลแล้ว ransomware ตัวนี้ (ดูเหมือนจะชื่อ Troldesh) ยังไม่เจอใครรายงานว่ามันแพร่กระจายผ่านเครือข่ายหรือเข้ามาติดในเครื่องได้โดยไม่จำเป็นต้องมี interaction อะไรจากผู้ใช้ เพราะเท่าที่เห็นส่วนใหญ่ก็บอกว่าติดผ่านเว็บไซต์ไม่ก็ไฟล์แนบในอีเมล ซึ่งเครื่องเซิร์ฟเวอร์ปกติคงไม่น่ามีใครมาเปิดอะไรพวกนี้หรอก (รึเปล่า?)

forensics-ransomware-0

เนื่องจากเคสนี้เป็นงานนอก ไม่ได้มีข้อมูล sensitive (เครื่องที่ติด ransomware เป็นเครื่องให้บริการเว็บไซต์) ไม่ได้ต้องการเอาผลตรวจไปใช้ในทางกฎหมาย และได้รับอนุญาตจากผู้เสียหายแล้วว่าสามารถเผยแพร่ analysis report เพื่อเป็น case study ได้ ก็เลยเขียนบล็อกนี้ขึ้นมาเผื่อจะมีประโยชน์กับคนที่สนใจงานด้าน Digital Forensics & Incident Response (DFIR) ครับ

Preparation

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

  • เป็น VM ที่รันผ่าน Hyper-V
  • ถูกใช้งานเป็นเครื่องเว็บเซิร์ฟเวอร์ โดยมีการติดตั้ง IIS และเปิด FTP ไว้
  • เวลาจะเข้ามาแก้ไขข้อมูลอะไรในเครื่อง จะทำผ่าน FTP หรือไม่ก็ remote desktop
  • OS เป็น Windows Server 2012
  • RAM 4 GB แต่ไม่ทราบความจุ hard disk
  • เครื่องน่าจะติด ransomware เมื่อวันที่ 19 กรกฎาคม 2559 เวลาประมาณ 6:19 น. (ดูจากวันเวลาที่ไฟล์ถูกสร้าง)
  • ตอนนี้ตัว VM ยังเปิดใช้งานอยู่
  • หลังจากที่เจอว่าเครื่องติด ransomware ได้มีการใช้ antivirus สแกนไปแล้วครั้งนึงก่อนจะติดต่อมาขอให้ช่วยตรวจพิสูจน์

ปัญหา

  • เครื่องนี้ตั้งอยู่ต่างจังหวัด ไม่สามารถเอา hard disk ไปจิ้มหน้าเครื่องเพื่อเก็บข้อมูลได้ ต้องหาวิธีดาวน์โหลดไฟล์ VM ออกมาวิเคราะห์
  • ปัจจุบันผู้ดูแลระบบเองไม่สามารถ remote desktop เข้าไปใช้งานตัวเซิร์ฟเวอร์ที่ติดมัลแวร์ได้แล้ว โดยจะค้างอยู่ที่หน้า login แต่ยังไม่ทราบสาเหตุว่าเกิดจากอะไร
  • เนื่องจากเป็นเคสติด ransomware เพราะงั้นอาจมีการทำลาย artifact เพื่อไม่ให้ตรวจพิสูจน์ว่าติดมาได้ยังไง
  • เนื่องจากมีการใช้ antivirus สแกนไปก่อนแล้วรอบนึง เพราะงั้นอาจจะมี artifact บางอย่างถูกทำลายไป เช่น ตัวไฟล์มัลแวร์ (อาจจะโดนลบหรือโดน quarantine) registry ที่มัลแวร์สร้าง หรือ timestamp ของไฟล์ที่เกี่ยวข้อง

Acquisition

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

  1. remote เข้าไปเครื่องหลักที่ใช้จัดการ Hyper-V
  2. คัดลอกโฟลเดอร์ที่เก็บไฟล์ VM (RAM, hard disk, config) ออกมาไว้ข้างนอก
  3. คำนวณค่า hash ของทุกไฟล์ที่จะนำมาวิเคราะห์
  4. zip โฟลเดอร์ที่คัดลอกมาโดยตั้งรหัสผ่าน และเลือก split file ที่ 4 GB (เผื่อไฟล์เสียจะได้โหลดใหม่ได้)
  5. ทยอยดาวน์โหลดไฟล์ผ่าน FTP โหลดเสร็จก็เทียบค่า hash อีกทีว่าทุกไฟล์ตรงกัน

เริ่มปฏิบัติงานตามขั้นตอนที่วางแผนไว้ โดยหลังจาก remote เข้าไปยังเครื่องหลักที่ใช้จัดการ Hyper-V ได้ก็พบว่าเครื่องเซิร์ฟเวอร์ที่ติด ransomware กำลังเปิดใช้งานอยู่ โดยข้อมูล snapshot ล่าสุดยังเป็นของเดือนมกราคมปี 2558 ดังนั้นเพื่อป้องกันความผิดพลาด ก็เลยสั่งสร้าง snapshot อันใหม่ขึ้นมาเพื่อเก็บไว้เป็นข้อมูลล่าสุดก่อนที่จะเริ่มการตรวจพิสูจน์ พอสร้าง snapshot เสร็จก็สั่ง pause ตัว VM

เปิดเข้าไปดูในโฟลเดอร์ที่เก็บไฟล์ VM พบว่ามีข้อมูลแบบที่เห็นในรูป

forensics-ransomware-1

อธิบายโครงสร้างข้อมูลที่พบแบบคร่าวๆ (อ้างอิงจาก MSDN)

โฟลเดอร์ Snapshots

  • เก็บ RAM ของแต่ละ snapshot โดยจะเป็นไฟล์ .bin
  • เก็บ config ของแต่ละ snapshot

โฟลเดอร์ Virtual Machines

  • เก็บ RAM ของ VM ที่เปิดใช้งานอยู่ในปัจจุบัน โดยจะเป็นไฟล์ .bin
  • เก็บ config ของแต่ละ VM

ไฟล์ .vhd และ .avhd

  • เป็นไฟล์ hard disk ของแต่ละ VM โดยไฟล์ .vhd จะเป็นข้อมูลตั้งแต่ตอนที่เริ่ม start VM ส่วนไฟล์ .avhd จะเป็นข้อมูล difference ที่บอกว่า snapshot นี้มีข้อมูลอะไรเปลี่ยนไปจากตอนเริ่มต้นบ้าง
  • เนื่องจากไฟล์ .vhd มีข้อมูลเก่าตั้งแต่ตอนสร้าง VM ส่วนไฟล์ .avhd มีข้อมูลล่าสุด การจะเอาข้อมูล hard disk ไปวิเคราะห์ต่อจำเป็นต้อง merge สองไฟล์นี้เข้าด้วยกันก่อน

การเก็บ RAM จากเครื่อง VM ใน Hyper-V นี่ก็มีหลายประเด็น อย่างแรกคือไฟล์ RAM ที่เห็นเป็น .bin เนี่ยมันเป็น physical memory chunk ไม่สามารถเอาออกมาอ่านตรงๆ ได้ ต้องแปลงให้อยู่ในรูปแบบ raw หรือ crash dump ก่อน ซึ่งก็อาจจะต้องใช้เครื่องมืออย่าง Sysinternals LiveKd ทำเป็น crash dump ออกมา ปัญหาคือไม่สามารถดาวน์โหลดและติดตั้งเครื่องมืออะไรลงในเครื่องหลักที่ใช้จัดการ Hyper-V ได้ ก็เลยลองอีกวิธีนึง คือ login เข้าไปในเครื่องที่ติดมัลแวร์เพื่อจะสั่ง dump RAM แต่ปรากฏว่าเข้าไม่ได้ ค้างอยู่ที่หน้าจอ login

พยายามลองอีกวิธีนึง คือในเมื่อเรามี snapshot กับสั่ง pause ตัว VM ไว้แล้ว ก็น่าจะลองคัดลอกไฟล์ RAM ออกมาแล้วหาวิธี convert มันทีหลัง (ยังไม่รู้ว่าทำได้จริงรึเปล่าแต่ก็อยากลองเอาออกมาดูซะหน่อยอย่างน้อยก็ดีกว่าไม่มีอะไรเลย)

ไฟล์ snapshot สามารถคัดลอกออกมาได้ปกติ แต่เมื่อพยายามคัดลอกไฟล์ RAM ที่อยู่ในโฟลเดอร์ Virtual Machines ออกมา ก็พบว่าไม่สามารถทำได้ โดยเจอ error แจ้งว่าตัว Hyper-V ล็อคไว้ไม่ให้ process อื่นมายุ่งเกี่ยวอะไรกับไฟล์นี้ (ไม่ยอมให้สิทธิ์ open file เลยด้วยซ้ำ)

ลองหาข้อมูลในเว็บ Microsoft, TechNet เกี่ยวกับวิธีแก้ปัญหานี้ ก็ยังไม่เจอวิธีเอาไฟล์ RAM ออกมา ถึงแม้ว่าจะสั่ง Stop Services แล้วก็ตาม สุดท้ายเมื่อลองพยายามแล้วแต่มันไม่ได้จริงๆ ก็โอเคยอมรับว่างั้นเราคงวิเคราะห์ข้อมูลใน RAM จากแค่ไฟล์ snapshot เอาละกัน

หลังจากที่เก็บ RAM แล้ว ต่อมาก็เก็บข้อมูล hard disk โดยต้อง merge ไฟล์ .vhd กับ .avhd เข้าด้วยกัน วิธีง่ายที่สุดคือใช้คำสั่ง Edit Disk แล้วเลือก Merge รอแป๊บนึง สุดท้ายก็จะได้ไฟล์ .vhd ออกมาซึ่งจะเป็นไฟล์ที่มีข้อมูลล่าสุดแล้ว

forensics-ransomware-2

สรุปว่าตอนนี้เราได้ไฟล์ snapshot RAM กับไฟล์ harddisk มาแล้ว ขนาดไฟล์รวมกันประมาณ 40 GB จากนั้นก็สั่งคำนวณค่า hash ของแต่ละไฟล์เพื่อที่จะได้ใช้ยืนยันว่าไฟล์ต้นฉบับที่อยู่ในเครื่องกับไฟล์ที่เราเอามาตรวจพิสูจน์นี่มันคืออันเดียวกัน

ปกติแล้วใน Windows จะมีเครื่องมือที่ใช้สำหรับคำนวณค่า hash แบบง่ายๆ มาให้อยู่ เท่าที่รู้สามารถทำได้ 2 วิธี คือใช้ PowerShell กับ CertUtil

ถ้าเป็น PowerShell จะใช้คำสั่ง Get-FileHash ดังนี้

Get-FileHash {filename} -Algorithm {algorithm}

เช่น ถ้าต้องการคำนวณค่า MD5 ของไฟล์ชื่อ test.txt ก็พิมพ์

Get-FileHash test.txt -Algorithm MD5

ปัญหาคือการจะใช้คำสั่ง Get-FileHash ได้ต้องเป็น PowerShell เวอร์ชัน 4 ขึ้นไป แต่ในเครื่องหลักที่ใช้จัดการ Hyper-V มันเป็น PowerShell เวอร์ชัน 3 เพราะงั้นต้องหาวิธีใหม่

ก็ลองอีกวิธีนึงคือใช้คำสั่ง CertUtil ซึ่งจริงๆ มันเอาไว้สำหรับจัดการ digital certificate แต่ก็สามารถใช้คำนวณค่า hash ของไฟล์ได้เหมือนกัน โดยใช้รูปแบบคำสั่ง

certutil -hashfile {filename} {algorithm}

เช่น ถ้าต้องการคำนวณค่า MD5 ของไฟล์ชื่อ test.txt ก็พิมพ์

certutil -hashfile test.txt MD5

ตัวอย่างการคำนวณค่า MD5 และ SHA1 ของไฟล์ hard disk (merged.vhd) กับ RAM (ram.bin) เป็นดังรูป

forensics-ransomware-3

เมื่อคำนวณค่า hash เสร็จแล้วก็ zip โยนขึ้น FTP แล้วค่อยทยอยดาวน์โหลดมาตรวจพิสูจน์ต่ออีกที พอโหลดเสร็จแตกไฟล์ตรวจค่า hash ว่าตรงกันก็โอเค

Analysis

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

เครื่องมือที่ใช้ในการตรวจพิสูจน์เคสนี้ประกอบด้วย

ใช้โปรแกรม Autopsy เป็นเครื่องมือหลักในการตรวจพิสูจน์ โดยระหว่างที่รอ process ข้อมูล ก็เปิดดู file structure เพื่อตรวจสอบรายละเอียดคร่าวๆ ของเครื่องไปด้วย โดยพบว่ามีไฟล์ .xtbl อยู่ในเครื่องเป็นจำนวนมาก ข้อมูลวันเวลาที่ไฟล์เหล่านี้ถูกสร้างอยู่ในช่วงประมาณ 6 โมงเช้าของวันที่ 19 กรกฎาคม 2559 ซึ่งเป็นช่วงวันหยุดยาวเข้าพรรษา

เครื่องเซิร์ฟเวอร์มีการติดตั้งโปรแกรมให้บริการเว็บไซต์อย่าง IIS, PHP, MySQL, Microsoft SQL Server, FileZilla Server แถมยังมีโปรแกรมสำหรับใช้งานทั่วไปอย่าง Google Chrome, Notepad++ ติดตั้งไว้ด้วย สอบถามแล้วพบว่าลงไว้เผื่อเวลาบางทีอยากแก้ไขไฟล์ในเครื่องก็จะได้ remote เข้ามาแก้ได้เลย

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

ตรวจดูพวก artifact ต่างๆ ก็พบว่าถูกทำลายไปเยอะตามที่คาด ตัวอย่างเช่น

  • C:\Windows ไม่พบโฟลเดอร์ Prefetch
  • IIS log ถูก encrypt
  • ไฟล์ใน C:\Users ถูก encrypt ทำให้ข้อมูลประวัติการใช้งาน เช่น ไฟล์ที่เคยเปิด ไฟล์ที่ถูกดาวน์โหลด ข้อมูลใน %temp% อะไรต่างๆ เหล่านี้ดูไม่ได้เลย

โชคดีหน่อยที่ Registry Hive กับ Windows Event log ไม่ได้ถูกทำลายไปด้วยก็เลยพอเอาออกมาดูได้

ใช้โปรแกรม Registry Viewer ตรวจสอบไฟล์ SAM เพื่อดูบัญชีผู้ใช้ในเครื่อง ก็พบว่ามีผู้ใช้สามรายคือ Administrator, taXXX และ teXXX (ขอเซ็นเซอร์ชื่อ username จริง) ที่มีประวัติการ login เข้ามาใช้งานหลายครั้งและยังมีการ active อยู่ เพราะฉะนั้นก็เลยจะตรวจสอบประวัติการใช้งานของบัญชีผู้ใช้สามรายนี้เป็นหลัก เนื่องจากบัญชีผู้อื่นรายอื่นในเครื่องไม่พบประวัติว่ามีการ login เข้ามาใช้งานหรือพบว่า login ครั้งสุดท้ายเป็นช่วงเวลาก่อนที่จะเกิดเหตุ

forensics-ransomware-4

แย่หน่อยที่ไฟล์ NTUSER.DAT ของบัญชี Administrator ถูก encrypt ไปแล้วเลยดูข้อมูลไม่ได้ แต่ของบัญชี taXXX กับ teXXX ยังไม่ถูก encrypt (น่าแปลกใจว่าทำไมมันถึงถูก encrypt เฉพาะบัญชีนี้ ของบัญชีอื่นทำไมไม่โดน) การที่ไฟล์ NTUSER.DAT ของบัญชี Administrator ถูก encrypt อาจจะเป็นสาเหตุนึงที่ทำให้พอ remote desktop แล้วค้างอยู่ที่หน้าจอ login

ตรวจสอบ Registry ดูรายชื่อโปรแกรมที่ถูกเรียกขึ้นมาทำงานตอนเปิดเครื่อง (Autoruns) แต่ไม่พบอะไรน่าสงสัย ตรวจสอบข้อมูลใน Recent items เพื่อดูว่าผู้ใช้เคยเปิดไฟล์อะไรบ้าง ก็พบว่าข้อมูลพวกนี้ถูก encrypt ไปหมดแล้ว

forensics-ransomware-5

เนื่องจากดูข้อมูลใน Registry แล้วยังบอกอะไรได้ไม่มาก ต่อมาเลยดูข้อมูล Windows Event Log โดยใช้โปรแกรม Event Log Explorer พบความน่าสนใจคือมีการพยายาม login ผ่าน remote desktop เข้ามา brute force รหัสผ่านของบัญชี Administrator อยู่หลายครั้ง ลักษณะเหมือนเป็นการใช้ bot พยายามโจมตีเข้ามา มีการเปลี่ยน IP ไปเรื่อยๆ ในแต่ละวัน โดยพบว่ามีการโจมตีลักษณะนี้มาตั้งแต่ก่อนที่เครื่องจะติด ransomware อยู่เป็นเดือน จนถึงปัจจุบัน (ช่วงเวลาที่เก็บหลักฐาน) ก็ยังมีการพยายามโจมตีอยู่

อย่างไรก็ตาม ไม่พบว่ามีการ login จากบัญชี Administrator ได้สำเร็จในช่วงเวลาที่เครื่องติด ransomware แต่พบว่ามีการ login ผ่าน remote desktop จากบัญชี taXXX ในวันที่ 19 กรกฎาคม 2559 เวลา 5:57:27 โดย login มาจาก IP ใน Romania (ตรวจสอบแล้วพบว่าเป็น IP ของบริการ Free VPN) จุดสังเกตคือนี่เป็นการ login แบบครั้งเดียวผ่าน เหมือนกับว่าคนร้ายรู้รหัสผ่านของบัญชีนี้อยู่แล้ว

forensics-ransomware-6

forensics-ransomware-7

ไล่ดูลำดับเหตุการณ์ที่เกิดขึ้นต่อมาเรื่อยๆ ก็พบว่าหลังจากที่ remote desktop เข้ามาได้สำเร็จแล้ว ก็มีการพยายามที่จะทำอะไรบางอย่างด้วยสิทธิ์ของผู้ดูแลระบบ จากนั้นก็พบว่า Volume Shadow Copy Service ถูกปิดไป ซึ่งเป็นพฤติกรรมปกติของ ransomware (ป้องกันไม่ให้กู้คืนไฟล์ได้) โอเคละ เราน่าจะเจอสิ่งที่กำลังค้นหาแล้ว

ต่อมาได้ตรวจสอบ MAC timeline ซึ่งเป็นการดูร่องรอยว่ามีการแก้ไข (Modified) เข้าถึง (Accessed) หรือสร้าง (Created) ไฟล์อะไรบ้างในช่วงเวลาที่เกิดเหตุ เพื่อจะได้หาที่มาของการติด ransomware ได้

จากข้อมูล MAC timeline พบว่าในวันที่ 19 กรกฎาคม 2559 เวลา 5:57:42 มีความเปลี่ยนแปลงเกิดขึ้นในโฟลเดอร์ AppData ของ Google Chrome ของผู้ใช้ taXXX ซึ่งจากข้อมูลที่พบเหมือนเป็นการ restore session เก่าของเว็บไซต์ที่เคยถูกเปิดมาก่อนหน้านี้ (มีการเปิดเว็บไซต์เช่น Google, StackOverflow)

forensics-ransomware-8

สอบถามข้อมูลเพิ่มเติมจากเจ้าของบัญชี taXXX พบว่าก่อนเกิดเหตุเคย remote desktop เข้ามาใช้งานเซิร์ฟเวอร์นี้เป็นครั้งสุดท้ายเมื่อประมาณเดือนมิถุนายน 2559 โดยได้มีการเปิด Google Chrome เพื่อหาข้อมูลตามรายชื่อเว็บไซต์ที่ปรากฏใน MAC timeline จากสิ่งที่พบก็น่าจะพอสันนิษฐานได้ว่าคนร้าย remote desktop เข้ามาแล้วโปรแกรม Google Chrome ที่ยังถูกเปิดค้างไว้ก่อนหน้านี้ได้ reload หน้าเว็บไซต์เหล่านั้น

ข้อมูล MAC timeline แสดงให้เห็นว่า

19 กรกฎาคม 2559 เวลา 5:58:13 มีความเปลี่ยนแปลงเกิดขึ้นกับ Volume Shadow Service และ System Restore Point

19 กรกฎาคม 2559 เวลา 5:59:22 ไฟล์ .xtbl ปรากฏขึ้นครั้งแรกใน Recycle Bin

forensics-ransomware-9

ไฟล์ .xtbl ถูกสร้างขึ้นเรื่อยๆ ตามโฟลเดอร์ต่างๆ ในเครื่อง โดยไฟล์สุดท้ายถูกสร้างขึ้นเมื่อวันที่ 19 กรกฎาคม 2559 เวลา 6:18:18 หลังจากนั้นก็มีการสร้างไฟล์ How to decrypt your files.txt และ How to decrypt your files.jpg ใส่ไว้ในโฟลเดอร์ของผู้ใช้ พร้อมทั้งตั้งค่าให้ไฟล์รูปภาพนี้เป็น wallpaper ให้เห็นโดดเด่นเป็นสง่า รวมเวลาที่ใช้ในการ encrypt ข้อมูลทั้งเครื่อง 20 นาที

forensics-ransomware-10

จากข้อมูลที่พบก็พอที่จะยืนยันได้แล้วว่าในวันที่ 19 กรกฎาคม 2559 เวลา 5:57:27 จนถึง 5:58:13 มีคนร้าย remote desktop เข้ามาโดยใช้บัญชี taXXX เพื่อติดตั้ง ransomware ลงในเครื่อง ซึ่งจากจุดนี้ก็เพียงพอที่จะตอบคำถามของเคสนี้ได้แล้วว่าเครื่องติด ransomware ได้ยังไง แต่สิ่งที่ยังเป็นข้อสงสัยอยู่คือคนร้ายใช้วิธีอะไรในการนำไฟล์มัลแวร์เข้ามาติดในเครื่อง

น่าเสียดายว่าหลักฐานที่ยังหลงเหลืออยู่ไม่พอที่จะบอกได้ว่าในช่วงเวลาดังกล่าว (ไม่ถึง 1 นาที) คนร้ายใช้วิธีอะไรในการนำไฟล์มัลแวร์เข้ามา แต่ความเป็นไปได้มันเยอะมาก เพราะในเมื่อสามารถ remote desktop เข้ามาถึงหน้าเครื่องได้แล้ว การจะดาวน์โหลดไฟล์มัลแวร์มาติดตั้ง หรือจะทำอะไรอย่างอื่นที่มันมากกว่านี้ก็ไม่ใช่เรื่องน่าแปลกใจอะไร

สิ่งที่ยังคาใจอยู่คงเป็นว่า ถ้าเป็นการดาวน์โหลดไฟล์มัลแวร์มาลงในเครื่อง ทำไมไม่พบว่ามีการสร้างหรือเรียกใช้งานไฟล์มัลแวร์ กำลังสงสัยว่า ransomware ตัวที่พบนี้อาจเป็นรูปแบบ Fileless Ransomware คือทำงานทุกอย่างใน RAM ไม่มีการสร้างไฟล์อะไรลงในเครื่อง พอทำงานเสร็จก็รีบลบตัวเองทิ้งเพื่อไม่ให้หลงเหลือร่องรอยให้ตรวจสอบย้อนหลังได้ เพราะนอกจากไม่พบการตั้งค่าให้มัลแวร์คงอยู่ทุกครั้งที่เปิดเครื่องแล้ว ไฟล์อื่นๆ ที่ถูกสร้างขึ้นมาหลังจากวันที่ 19 กรกฎาคม 2559 เวลา 6:18:18 ก็ไม่ถูก encrypt แต่อย่างใด

ซึ่งจะว่าไปแล้ว การที่ ransomware ไม่มีการ deploy artifact ลงในเครื่อง ไม่มีการสร้างช่องทาง Autorun เพื่อให้ยังคงอยู่ในเครื่องไปตลอด ก็เป็นสิ่งที่สมเหตุสมผลอยู่ เพราะจุดประสงค์ของ ransomware จริงๆ แล้วมีแค่ encrypt ข้อมูลในเครื่อง (อย่างในเคสนี้ใช้เวลาแค่ 20 นาทีก็ได้แล้ว) เสร็จแล้วก็คือจบภารกิจ ไม่จำเป็นต้องอยู่ต่อเพื่อรอให้คนจับมาวิเคราะห์ทีหลัง

Lesson Learned

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

  1. ให้เซิร์ฟเวอร์ทำหน้าที่ของเซิร์ฟเวอร์เป็นหลัก อย่านำมาใช้งานเกินความจำเป็น เพราะขนาดแค่การป้องกันไม่ให้เซิร์ฟเวอร์ถูกแฮกนี่ก็ยังยากแล้ว การเอามาใช้ทำงานอย่างอื่น (โดยเฉพาะการเอาเซิร์ฟเวอร์มาเปิดเบราว์เซอร์เข้าดูเว็บไซต์หรือเช็คอีเมล) ก็ยิ่งจะทำให้มีช่องโหว่ให้ถูกโจมตีได้ง่ายขึ้นไปอีก
  2. ไม่ควรตั้งสิทธิ์ให้ผู้ใช้ทุกคนเป็นผู้ดูแลระบบ เพราะถ้าเกิดมีใคร login เข้ามาบัญชีผู้ใช้นี้ได้ก็เท่ากับได้บัญชีของผู้ดูแลระบบไปเลย
  3. ถ้าจะเปิดให้สามารถ remote desktop เข้ามาที่เซิร์ฟเวอร์ได้ ลองดูคำแนะนำในเว็บไซต์นี้ แต่ถ้าไม่จำเป็นจริงๆ ก็ไม่ควรเปิดช่องทางการเข้าถึงให้มากเกินไป
  4. ควรสำรองข้อมูลสำคัญไว้อย่างสม่ำเสมอ ถ้าเป็นเซิร์ฟเวอร์ที่รันบน VM ก็พยายาม snapshot ในจุดที่เครื่องไม่มีปัญหาไว้เป็นระยะๆ
  5. หากพบว่าระบบมีปัญหา เช่น ถูกแฮก หรือติดมัลแวร์ ถ้าสามารถตัดการเชื่อมต่อเครือข่ายได้ควรรีบทำโดยเร็ว เพื่อป้องกันไม่ให้แพร่กระจายไปเครื่องอื่น
  6. ถ้ามีการสแกนไวรัสหรือทำอะไรกับเครื่องก่อนที่จะมีการทำ forensics ควรจดบันทึกข้อมูล เช่น สิ่งที่ทำ หรือชื่อมัลแวร์ที่พบ ไว้ด้วย เพื่อจะได้ง่ายในการตรวจสอบช่วงเวลาที่เกิดเหตุการณ์สำคัญ

ข้อแนะนำเบื้องต้นสำหรับเคสนี้ก็คงประมาณนี้ ส่วนเรื่องวิธี Secure Windows Server ผมว่าหาอ่านจากเว็บไซต์หรือจากหนังสือทั่วไปน่าจะได้รายละเอียดเยอะกว่า

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

Advertisements

One thought on “DFIR Case Study: วิเคราะห์เครื่องเซิร์ฟเวอร์ติด Ransomware

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s