Memory Forensics – Windows

ဒီ Article မှာ Memory Forensics အကြောင်းပြောပြသွားမှာဖြစ်ပြီး Windows ပိုင်းကိုအဓိကထားပြီးရေးသားသွားပါမယ်

ဒီ Article ရေးဖြစ်တဲ့အကြောင်းအရင်းကတော့ မကြာသေးခင်ကမှ SANS ရဲ့ Forensics Course တစ်ခုဖြစ်တဲ့ FOR508 ကို Melbourne မှာ In-person တက်ရောက်ပြီးစီးထားတာဖြစ်လို့ အဲ့မှာသင်သွားခဲ့တဲ့စာတွေကို ပြန်နွှေးတဲ့အနေနဲ့ GCFA Certification အတွက်ပြင်ဆင်ရင်း Blog တွေပါ တစ်ပါတည်းရေးချင်တာကြောင့်ဖြစ်ပါတယ် (အရမ်း Advanced ဖြစ်တာတွေကိုတော့ ရှင်းရမှာကသီလို့ ချန်လှပ်ခဲ့ပါတယ်)

ကျွန်တော်တို့ Forensics လုပ်ရာမှာအရေးအကြီးဆုံးက Data Acquisition ပဲဖြစ်ပါတယ် .. Data ကောင်းကောင်းမရှိရင် Forensics သေချာလုပ်လို့မရပါဘူး .. ဒါကြောင့် Memory Forensics အကြောင်းပြောမယ်ဆို Windows Memory Acquisition ကနေစပြောတာ ပိုအဆင်ပြေပါမယ် .. Acquisition အကြောင်းမပြောခင် ဘာကြောင့် Memory Forensics လုပ်လဲဆိုတာ ဆွေးနွေးသွားပါမယ်

Why Memory Forensics?

ကဲဒီတော့ ဘာလို့ Memory (RAM) ကို Digital Forensics မှာ သုံးကြတာလဲ?

ဘာလို့လဲဆိုတော့ Memory ထဲရှိနေတဲ့ Information တွေက Forensics အတွက်အလွန်အသုံးဝင်လို့ဖြစ်ပါတယ် .. Windows မှာ OS ကနေ Process လုပ်မယ့် Data မှန်သမျှဟာ RAM ကိုဖြတ်ပြီး CPU ဆီကိုသွားရပါတယ် .. CPU ကိုရောက်ဖို့ဆို Memory ကို Bypass လုပ်လို့မရပါဘူး .. နောက်တစ်ခုက CPU ကနေတိုက်ရိုက် Read လို့ရအောင် Memory ထဲမှာ Machine Readable အနေနဲ့အားလုံးကို Unpack လုပ်ပေးထားရပါတယ် .. ဒါကြောင့် Packed Malware တွေဟာ Memory ထဲမှာဆိုရင် ဘူးပေါ်သလိုပေါ်လာကြပါတယ်

နောက်ပြီးတော့ Processes, Threads, Handles, DLL, Network Connections, Passwords (ဟုတ်ပါတယ် .. Developer တွေက Memory ထဲရှိနေတဲ့ Password ကို Plain Text အတိုင်းပဲထားတတ်ကြတာများပါတယ်), Cache, Registry, CommandLines, Windows API, Internet Activites အစရှိသဖြင့် System က Data အားလုံးလိုလိုက Memory ပေါ်ရှိနေတာပါ

Memory က Forensics အတွက် ပိုပြီးသင့်လျော်တဲ့အချက်တစ်ချက်တော့ Memory-only Exploits/Rootkits တွေဟာ Disk ပေါ်မှာမရှိပဲ Memory ထဲမှာပဲရှိတတ်ပါတယ် .. ဒီကောင်တွေကို Memory Forensics လုပ်ကြည့်ချင်းအားဖြင့် ဖော်ထုတ်နိုင်ပါတယ်

Memory Acquisition – Windows

ဒီတော့ Memory ကိုဘယ်လို Acquire လုပ်ကြမလဲ?

အားလုံးသိတဲ့အတိုင်း RAM ပေါ်မှာရှိတဲ့ Data တွေက Volatile ဖြစ်ပါတယ် .. ဆိုလိုတာက Computer ကို Shutdown or Restart လုပ်လိုက်မယ်ဆိုရင် RAM ပေါ်မှာရှိတဲ့ Data တွေဟာပျက်သွားမှာပါ

ဒါကြောင့် ရဲတွေဟာ Crime Scene ကိုရောက်လို့ Devices တွေကိုသိမ်းတော့မယ်ဆိုရင် ပွင့်နေတဲ့စက်တွေကို Power Off မလုပ်ပဲ Seize လုပ်ကြရပါတယ် .. အထဲက RAM ကို Capture လုပ်ချင်လို့ပါ

Live Systems

ဒီလိုမျိုး Live System (Power On) ပေါ်က RAM Image ကို WinPMEM, MagnetForensics RAM Capture, Belkasoft Live RAM Capturer, FTK Imager, F-Response တို့လို Tools တွေနဲ့ Acquire လုပ်လို့ရပါတယ် .. ဒီ Tools တွေဟာ Signed System Driver တွေကို Install လုပ်ပြီး Windows Kernel ကနေတစ်ဆင့် Memory ကို Access လုပ်ပြီး Bit-by-bit Copy လုပ်ပြီး Raw File ထုတ်ပေးပါတယ် .. ဒီထဲမှာကျွန်တော်အကြိုက်ဆုံးကတော့ WinPMEM ဖြစ်ပြီး Linux နဲ့ macOS အတွက်ပါရှိပါတယ်

Dead Systems

အပေါ်မှာပြောခဲ့သလို Power On နေတဲ့အနေအထားမှာ RAM ကို Capture လုပ်တာအကောင်းဆုံးဆိုပေမယ့် Power Off သွားတဲ့ System (Dead Systems) တွေမှာ လုံးဝကြီးယူလို့မရတာမျိုးတော့မဟုတ်ပါဘူး .. Live System လောက် Data စုံစုံလင်လင်ပြန်မရနိုင်ပေမယ့် Power Off နေတဲ့အချိန်မှာဆို Try ကြည့်သင့်ပါတယ်

Laptop တွေမှာ အားကုန်ခါနီးဆို Hibernate Mode ကိုအလိုအလျောက်ပြောင်းသွားတတ်ပါတယ် .. Hibernate Mode ရောက်သွားပြီဆိုရင် Windows က အလိုအလျောက် Memory ကို Compress လုပ်ပြီး "%SystemDrive%\hiberfil.sys" အနေနဲ့သွားသိမ်းထားပါတယ် .. ဒီလိုအခြေအနေကနေ အားကုန်ပြီး Power ပိတ်သွားတယ်ဆိုရင် ဒီ hiberfil.sys file ကို acquire လုပ်ပြီး Analyse လုပ်လို့ရပါတယ် .. တစ်ခါတလေ Memory ကို မြန်မြန် Capture လုပ်ချင်တဲ့အခါ System ကို Force Hibernate လုပ်ပြီး hiberfil.sys file ကို acquire လုပ်လိုက်လို့ရပါတယ် (Not recommended)

Dead System တွေမှာ Acquire လုပ်လို့ရတဲ့နောက်ထပ်နည်းတစ်ခုကတော့ Page နဲ့ Swap File တွေပါ .. ဒါတွေကလည်း Live RAM နဲ့ hiberfil.sys လိုမျိုး Data များများစားစားမရှိပါဘူး .. Memory ထဲမှာ မသုံးပဲအချိန်ကြာကြာရှိနေတဲ့ Data တွေကို "%SystemDrive%\pagefile.sys" နဲ့ "%SystemDrive%\swapfile.sys" ထဲမှာ သွားသိမ်းထားလေ့ရှိပါတယ် .. ဒါကြောင့် System က Power ပိတ်နေတဲ့အနေအထားမှာ hiberfil.sys ကိုလည်းယူလို့မရဘူးဆိုရင် အနည်းဆုံးတော့ ဒီ Page နဲ့ Swap Files တွေကိုယူပြီး Analyse လုပ်ကြည့်လို့ရပါတယ် .. နောက်ပြီး တစ်ချို့ Live System Acquisition တွေမှာ ဒီ Page & Swap Files တွေကိုယူလေ့ရှိပါတယ် Full Visibility ရှိလို့ပါ

Dead System Acquisition မှာလုပ်လို့ရတဲ့နောက်ဆုံးတစ်ခုကတော့ Kernel-mode dump file ပါ .. Crash dump file လို့လည်းခေါ်ကြပါတယ် .. ဒီ File တွေက Windows Crash သွား (ဥပမာ – Blue Screen Error တက်) တဲ့အချိန်တွေမျိုးဆို RAM ပေါ်မှာရှိတဲ့ Data တွေကို "%SystemRoot%\memory.dmp" အနေနဲ့သွားသိမ်းပါတယ် .. ဒါပေမယ့် တကယ်လက်တွေ့မှာတော့ Complete Dump အဖြစ်မြင်ရလေ့မရှိပါဘူး .. တစ်ခါတလေမှာတော့အသုံးဝင်နိုင်ပါတယ်

Memory Capture ဟာ RAM Size ပေါ်မူတည်ပြီးအချိန်ကြာလေ့ရှိပါတယ် .. ဒါကြောင့်မြန်မြန်ဆန်ဆန် Acquire လုပ်ချင်တယ်ဆိုရင် ကိုယ်လိုချင်တဲ့ Data တွေကို ရွေးပြီး Quick Triage လုပ်လို့ရပါတယ် .. ဒီလိုအခြေအနေမျိုးမှာ KAPE ဆိုတဲ့ Tool ကသင့်လျော်ပါတယ် .. ဒီလို Quick Triage မှာ ဘယ်လို Artifact မျိုးကို အဓိကထားပြီး Acquire လုပ်သင့်သလဲဆိုတော့ အောက်က List ကို အဓိကထားသင့်ပါတယ်

1. Registry Hives နဲ့ Backups တွေ -> SAM, SYSTEM, NTUSER.DAT, USERCLASS.DAT
2. LNK Files -> File နဲ့ Folder Opening အတွက် Evidence
3. Jump Lists -> Recently Used Files တွေအတွက် Evidence
4. Prefetch -> Application Execution အတွက် Evidence
5. Event Logs -> ဒါကတော့ Multi-Purpose ပါ
6. AppData နဲ့ Browser Artifact များ
7. Recycle Bin
8. Master File Table ($MFT) -> Windows ပေါ်ကရှိသမျှ File and Folder တွေရဲ့Metadata ကို MFT ထဲသိမ်းပါတယ်
9. NTFS Journal Files -> File Open, Close, Creation, Deletion အတွက် Evidence
10. Hibernation File (hiberfil.sys) -> အပေါ်မှာ Discuss ခဲ့သလိုပါပဲ

နောက်ပြီး Memory ရဲ့ Structure ဟာ Windows Kernel Version ပေါ်မူတည်ပြီးအပြောင်းအလဲရှိတတ်ပါတယ် .. ဒါကြောင့်လည်း ကျွန်တော်တို့ Volatility 2 မှာ Memory Analysis လုပ်ရင် Windows Profile ထည့်ပေးရတာဖြစ်ပါတယ် .. ဒီ Windows Profile ပေါ်မူတည်ပြီး RAM Capture Image ကဘယ် Structure ဆိုတာဆုံးဖြတ်တာဖြစ်ပါတယ် .. Volatility 3 မှာတော့ ထည့်ပေးစရာမလိုတော့ဘူး .. သူ့မှာ Profile တွေကို Auto Detect လုပ်ပေးနိုင်ပါပြီ

ဒီနေရာမှာ Memory Structure ဆိုတာဘာကိုပြောတာလဲပေါ့ .. Memory ထဲမှာ KPCR (Kernel Processor Control Region) ဆိုတဲ့ကောင်လေးရှိပါတယ် .. အဲ့ဒီ KPCR ရဲ့ Location က Windows Kernel Version ရယ်, 32-bit 64-bit ပေါ်မူတည်ပြီးအပြောင်းအလဲရှိတာပါ .. KPCR ထဲမှာမှ KDBG (Kernel Debugger Data Block) ဆိုတဲ့ Block လေးထပ်ရှိပါတယ် .. အဲ့ဒီ KDBG မှာ Memory Forensics အတွက်အရေးကြီးတဲ့အချက်အလက်တွေဖြစ်တဲ့ Running Processes တွေ (PEB, Handles, Threads, Access Tokens) စတာတွေကို EPROCESS Block ထဲထည့်ပြီးသိမ်းထားတာပါ

Memory Analysis

Memory Analysis လုပ်တဲ့နေရာမှာ လွယ်ကူစေဖို့ Flow တစ်ခုရှိသင့်ပါတယ် .. Volatility ထဲ ရှိသမျှ Plug-ins တွေလျှောက် run နေရင် လမ်းကြောင်းပျောက်နေမှာပါ .. ဖြစ်သင့်တဲ့ Flow ကတော့ အောက်ပါအတိုင်းဖြစ်ပါတယ်

1. Identify Rogue Processes
2. Analyse Process Objects
3. Review Network Artifact
4. Review Code Injection Evidence
5. Audit Drivers and Rootkit Detection
6. Dump Suspicious Processes and Drivers

Memory Forensics လုပ်နေကျလူတွေ သို့မဟုတ် CTF တွေဖြေဖူးရင် ကျွန်တော်ဘာပြောနေလဲဆိုတာနားလည်မယ်ထင်ပါတယ်

Identify Rogue Processes

ပထမတစ်ချက်ဖြစ်တဲ့ Rogue Process တွေကိုဖော်ထုတ်ဖို့ကအရေးကြီးပါတယ် .. Windows OS မှာတင် Process 200 ကျော်လောက် Run နေတာပါ .. အဲ့ကြားထဲက Suspicious Process ကိုရှာဖို့ဆိုတာ Windows Internal Process တွေနဲ့မရင်းနှီးထားရင် အတော်လေးတိုင်ပတ်နိုင်ပါတယ် .. ကျွန်တော်ဆိုအရင်က svchost.exe မြင်တိုင်း Suspicious ဖြစ်တယ်ပဲထင်နေတာ 😂 ဒီအတွက် SANS ရဲ့ Hunt Evil ဆိုတဲ့ Poster လေးက အလွန်အသုံးဝင်ပါတယ် .. ပုံမှန်အားဖြင့်တော့

• Image Name -> Threat Actor တွေကို Windows Legitimate Process နာမည်တွေနဲ့ထင်ယောင်ထင်မှားဖြစ်အောင်လုပ်တတ်ကြပါတယ် (ဥပမာ – svchost.exe ကို scvhost.exe ဆိုပြီးပုံမှားရိုက်တာ)
• Full Path -> Process တွေတိုင်းမှာ သူတို့ရှိသင့်တဲ့ Location တွေရှိပါတယ် .. အဲ့ Location တွေကနေသွေဖယ်နေပြီဆိုရင် Suspicious အနေနဲ့ Flag ထားပါ
• Parent Process -> ဥပမာအနေနဲ့ပြောရရင် svchost.exe ရဲ့Parent Process ဟာ အမြဲတမ်း services.exe ဖြစ်ရပါမယ် .. အဲ့လိုမှမဟုတ်ရင်တော့ Malicious လို့သတ်မှတ်လို့ရပါပြီ
• Command Line -> အပေါ်မှာ mention ခဲ့တဲ့ Process Environment Block (PEB) က Process တစ်ခုကို spawn သွားစေတဲ့ full command line ကိုပါသိမ်းထားပါတယ် .. ဒီကနေ Command Line Argument တွေမှာမူမမှန်တာတွေ ပါ/မပါစစ်ဆေးလို့ရပါတယ်
• Start Time -> ဥပမာ lsass.exe ရဲ့ပုံမှန် Start Time က Boot Time နဲ့သိပ်မကွာပါဘူး .. ဒီနေရာမှာအရမ်းကွာနေပြီဆိုရင် Red Flag ပါ
• Security IDs -> ဒါကတော့ ဘယ် User Account က ဒီ Process ကို spawn လိုက်လဲဆိုတာသိရမှာဖြစ်ပါတယ်

ဒါတွေကိုကြည့်ပြီး တကယ် Windows Process နဲ့ကွာခြားမှုရှိနေရင် Suspicious ဖြစ်တယ်လို့ပြောလို့ရပါတယ် .. Volatility မှာဆို PsList, PsScan, PsTree တို့လို Plug-in တွေသုံးပြီး Rogue Process တွေကိုရှာကြည့်လို့ရပါတယ်

Tips:

• Windows မှာ Parent Process က Run မနေတော့ပဲ Child Process ကဆက် Run နေတာမျိုးဟာ Windows Native Process 4 ခု (System, explorer.exe, csrss.exe, wininit.exe) ကလွဲပြီးဖြစ်လေ့မရှိပါဘူး .. ဒီလိုအခြေအနေမျိုးကို Orphan Process လို့ခေါ်ပါတယ်
• ကိုယ် Investigate လုပ်နေတဲ့ System ထဲကို PowerShell Remote ဝင်ထားလားသိချင်ရင် wsmprovhost.exe ကိုရှာပါ .. WMI Remote ဝင်ထားလားသိချင်ရင် WmiPrvSE.exe or scrcons.exe ကိုရှာပါ
• ကျွန်တော်အပေါ်မှာပြောခဲ့သလိုပဲ Windows OS မှာ Legitimate Running Process က 200 ကျော်ရှိပါတယ် .. ဒါတွေကို Baseline သတ်မှတ်ထားတဲ့ Memory Image နဲ့ ကိုယ် Investigate လုပ်နေတဲ့ Memory Image ကို Compare လိုက်ရင် မတူညီတာတွေထွက်လာတာဖြစ်တဲ့အတွက် Investigate လုပ်ရတာအများကြီးပိုလွယ်သွားပါလိမ့်မယ် .. ဒီအတွက် Memory Baseliner ကိုသုံးလို့ရပါတယ်

Analyse Process Objects

ဒီအဆင့်မှာကျွန်တော်တို့ Investigate လုပ်ရမှာက DLL တွေ, Handles တွေ, Threads တွေ, Memory Sections တွေ, Sockets တွေပဲဖြစ်ပါတယ် .. ပုံမှန်အားဖြင့်တော့ အပေါ်မှာ Identify လုပ်ခဲ့တဲ့ Rogue Process တွေနဲ့ပတ်သက်နေတဲ့ DLL, Handles, Threads တွေကို စစ်ဆေးတာပါ .. ဒီအတွက် Volatility Plug-ins တွေဖြစ်တဲ့ DllList, CmdLine, GetSids, Handles စတာတွေက အသုံးဝင်ပါတယ်

Tips:

• ပုံမှန်အားဖြင့် DLL, Handles တွေကအများကြီးရှိတာဖြစ်တဲ့အတွက် အပေါ်မှာ Identify လုပ်ခဲ့တဲ့ Process နဲ့ Filter ခံလိုက်တာက ပိုပြီးအဆင်ပြေစေပါတယ် .. Volatility မှာ --pid ဆိုတဲ့ Argument နဲ့ Filter လို့ရပါတယ်
• အပေါ်မှာပြောခဲ့သလိုပဲ Memory မှာမသုံးပဲအချိန်အကြာကြီးရှိနေတဲ့ File တွေကို pagefile.sys ဒါမှမဟုတ် swapfile.sys ထဲသွားသိမ်းပါတယ် .. ကိုယ်ကြည့်ချင်တဲ့ DLL တွေက အဲ့လို Paging လုပ်ခံထားရရင် အဆင်ပြေမှာမဟုတ်ပါဘူး .. အဲ့ဒီအခါ Volatility 3 သုံးနေတဲ့လူတွေဆိုရင် --single-swap-locations ဆိုတဲ့ Arguments နဲ့ pagefile ထည့်ပေးလို့ရပါတယ်
• DllDump လို Plug-in မျိုးဟာ Reflective DLL Injection လို Attack မျိုးကို သိနိုင်မှာမဟုတ်ပါဘူး .. ဒီလို Advanced Attack တွေကို Investigate လုပ်ချင်ရင် LdrModules, MalFind တို့လို Plug-in တွေသုံးနိုင်ပါတယ်
• Process တစ်ခုကို ဘယ် Permission နဲ့ spawn လိုက်တယ်ဆိုတာသိချင်ရင် GetSIDs ဆိုတဲ့ Plug-in ကိုသုံးနိုင်ပါတယ်

• Process တစ်ခုနဲ့တစ်ခုကြား Communicate လုပ်ချင်ရင် Named Pipes ကိုသုံးပါတယ် .. Named Pipes တွေကိုကြည့်ချင်ရင် Volatility မှာ Handles Plug-in ကို Run ပြီး grep -i pipe ဆိုတဲ့ Command နဲ့ကြည့်လို့ရပါတယ်
  • ဥပမာ Cobalt Strike ရဲ့ Default Named Pipe ဆိုရင် MSSE-xxxx-server ဖြစ်ပါတယ် .. မတူညီတဲ့ Process နှစ်ခုမှာ Named Pipe နာမည်တူကိုတွေ့ပြီဆိုရင် ဒီ Process နှစ်ခုက အချင်းချင်း Communicate လုပ်လို့ရနေပါပြီ .. ဥပမာ powershell.exe က System နဲ့ Communicate လုပ်လေ့မရှိပေမယ့် Named Pipe ချင်းတူနေပြီဆိုရင် အချင်းချင်း Communicate လုပ်နေပြီလို့ ယူဆလို့ရလို့ Suspicious အနေနဲ့ Flag ထားသင့်ပါတယ်
• Mutants (or Mutex) တွေကိုစစ်ကြည့်ချင်ရင် Volatility မှာ Handles Plug-in ကို Run ပြီး egrep "PID|Mutant" ဆိုတဲ့ Command နဲ့ကြည့်လို့ရပါတယ်
  • Mutants ဆိုတာ တကယ်တော့ သွင်းပြီးသား Program တွေကို နောက်တစ်ခါပြန်မသွင်းမိအောင် Memory ထဲမှာ အမှတ်အသားလုပ်ထားတာပါပဲ .. ဥပမာအနေနဲ့ပြောရရင် Chrome Browser ကိုသွင်းပြီးတဲ့အခါ Memory ထဲမှာ Chrome လို့သွားမှတ်ထားတယ်ဆိုပါစို့ .. User က နောက်တစ်ကြမ်း chrome-installer.exe ကိုနှိပ်တဲ့အခါ Memory ထဲမှာ Chrome ရဲ့ Mutex ရှိနေတယ်ဆိုရင် Executable ကို မ Run တော့ပါဘူး .. Malware Author တွေကတော့ Mutex ကို နောက်တစ်ကြိမ် Malware Infect မဖြစ်အောင် ထည့်ရေးလေ့ရှိပါတယ် .. ကိုယ့်မှာ Threat Intel ကောင်းကောင်းရှိရင် Malware Infection ရှိမရှိကို Mutex နဲ့ရှာလို့ရပါတယ်

Review Network Artifact

Threat Actor ကသင့် Environment မှာ implant ထည့်ပြီးပြီဆိုရင် Command & Control (C2) စလုပ်ပါတော့မယ် .. ဒီလိုအချိန်မှာ Network Artifact တွေကို စစ်ကြည့်တာလည်းအသုံးဝင်ပါတယ် .. ဒီအတွက် Volatility Plug-ins တွေဖြစ်တဲ့ NetStat, NetScan စတာတွေက အသုံးဝင်ပါတယ်

Tips:

• Port နဲ့ Service ကိုကြည့်ပါ .. ဥပမာ Chrome.exe က Port 443 Outbound ဖြစ်တာ normal ပေမယ့် services.exe က Port 443 outbound ဆို suspicious activity ဖြစ်ပါတယ်

ဆက်ရန် …..