前言

前幾篇介紹完 WinDbg、Kernel Debugging 和 Rootkit 之後，今天終於可以實際拿 Lab 來練習。

這次要分析的是《Practical Malware Analysis》Chapter 10 的：

Lab 10-1

這個 Lab 提供兩個檔案：

Lab10-01.exe
Lab10-01.sys

其中 Lab10-01.exe 是 User Mode 的執行檔，而 Lab10-01.sys 則是一個 Kernel Driver。

這個 Lab 很適合拿來理解一件事情：

如果惡意行為發生在 Kernel Mode，只觀察 User Mode 的工具可能無法看到完整的行為。

今天會搭配：

• Procmon
• IDA Pro
• WinDbg
• Kernel Debugging

一步一步看看這兩個檔案到底做了什麼。

【聲明】由於時間問題本日文章由 AI 生成QQ

Lab 環境

這個 Lab 的 EXE 可以從任意位置執行，但是 Driver：

Lab10-01.sys

需要放在：

C:\Windows\System32

才能正常執行。

另外因為這次需要分析 Kernel Driver，所以除了 Guest Windows XP VM 之外，也需要前面建立好的 Kernel Debugging 環境。

大致架構如下：

Host
│
└── WinDbg
      │
      │ Kernel Debugging
      ↓
Windows XP VM
│
├── Lab10-01.exe
└── Lab10-01.sys

接著就開始分析。

Question 1：程式有直接修改 Registry 嗎？

第一題要求我們：

Does this program make any direct changes to the registry?

而且題目直接提示可以使用：

Procmon

進行檢查。

因此先開啟 Procmon，再執行：

Lab10-01.exe

為了避免大量無關事件，可以針對：

Lab10-01.exe

進行 Filter，並觀察 Registry 相關操作。

這時會發現一件很奇怪的事情。

Procmon 幾乎沒有看到什麼明顯的惡意 Registry 修改。

唯一可以直接觀察到的 Registry Change 是：

HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed

如果只做到這裡，很容易得到一個結論：

這個 Malware 好像沒有修改什麼重要的 Registry。

但事情當然沒有這麼簡單。

因為我們還有另一個檔案：

Lab10-01.sys

也就是 Kernel Driver。

這代表真正重要的行為可能不是由：

Lab10-01.exe

直接完成。

Question 2：ControlService 之後發生了什麼？

接下來題目給了一個非常重要的線索：

User Space Program 會呼叫：

ControlService

因此第二題要求我們使用 WinDbg 設定 Breakpoint，看看呼叫 ControlService 之後，Kernel 中到底發生了什麼事情。

這就是這個 Lab 最重要的部分。

我們要從：

User Mode

一路追到：

Kernel Mode

找到 ControlService

首先可以把：

Lab10-01.exe

丟進 IDA Pro。

接著找到程式呼叫：

ControlService

的位置。

參考分析中使用的 Address 為：

0x00401080

因此可以先在 VM 裡使用 WinDbg 對 User Mode Program 設定 Breakpoint：

bp 0x00401080

接著：

g

讓程式繼續執行。

當程式跑到這個位置時，就會停在 ControlService 呼叫附近。

這個 Breakpoint 的用途，是讓我們先把程式停在關鍵位置，建立一個「呼叫 ControlService 前」的觀察點。

接下來就可以切換到 Host 上的 Kernel Debugger。

找到 Lab10-01 Driver

在 Host 的 WinDbg 中 Break 進 Kernel。

這時 Guest VM 會暫時停止回應，因為整個 Kernel 已經被 Debugger 暫停。

接著使用：

!drvobj lab10-01

尋找：

Lab10-01.sys

對應的 Driver Object。

參考分析中的 Driver Object Address 為：

0x86534880

接著可以進一步查看 _DRIVER_OBJECT：

dt _DRIVER_OBJECT 86534880

_DRIVER_OBJECT 是 Windows Kernel 用來描述 Driver 的 Structure，其中包含 Driver 的重要資訊。

透過這裡可以進一步找到 Driver 的 Function Address。

這個 Lab 中也可以發現 Lab10-01.sys 沒有提供讓 User Mode Application 直接互動的 Device Object。

對 Driver 設定 Breakpoint

現在我們已經知道 Driver 在哪裡了。

接下來的問題就是：

ControlService 執行之後，這個 Driver 到底做了什麼？

根據 Driver Object 得到的資訊，可以找到需要觀察的 Function。

參考分析在：

0xf7ed8486

設定 Breakpoint：

bp 0xf7ed8486

接著：

g

恢復 Kernel 執行。

Guest OS 此時也會恢復正常運作。

然後回到 VM 裡面原本停住的 Lab10-01.exe，再次：

g

讓程式繼續執行。

接下來 Kernel Debugger 就會再次停下來。

這代表：

我們成功從 User Mode 的 ControlService，追到了 Kernel Driver 裡面的程式碼。

整個流程可以理解成：

Lab10-01.exe
      ↓
ControlService
      ↓
Windows Service
      ↓
Lab10-01.sys
      ↓
Kernel Driver Code
      ↓
WinDbg Breakpoint

現在就可以開始觀察 Driver 真正執行的行為。

Driver 做了什麼？

在 WinDbg 中繼續 Step Driver 的程式碼，可以發現它開始進行：

Registry 操作。

這時事情就變得有趣了。

因為第一題使用 Procmon 時，我們明明沒有看到這些 Registry Changes。

但是現在直接進入 Kernel Driver 裡分析，卻發現：

Lab10-01.sys

正在修改 Registry。

為了更清楚知道 Driver 修改哪些東西，可以把：

Lab10-01.sys

放進 IDA Pro。

透過 Static Analysis，可以看到 Driver 會建立或修改 5 個 Registry 項目。

而這些操作的目的都指向同一件事情：

關閉 Windows Firewall。

Driver 將相關設定修改成：

0

藉此停用 Windows Firewall。

為什麼 Procmon 沒看到？

這也是 Lab 10-1 最重要的觀念。

一開始我們透過 Procmon 觀察：

Lab10-01.exe

看到的 Registry 修改非常少。

如果只相信這個結果，就可能判斷：

Lab10-01.exe
→ 幾乎沒有修改 Registry

但是實際流程是：

Lab10-01.exe
        ↓
建立 / 操作 Kernel Service
        ↓
Lab10-01.sys
        ↓
Kernel Mode
        ↓
修改 Registry
        ↓
Disable Windows Firewall

也就是說：

真正修改 Registry 的不是 User Mode EXE，而是 Kernel Driver。

因此只 Filter：

Lab10-01.exe

並不能完整看到 Malware 的所有行為。

這也是為什麼 Malware Analysis 不能永遠只停留在：

Process
File
Registry
Network

這些表面行為。

如果 Sample 包含：

.sys

或者發現它正在建立 Kernel Service，就應該開始考慮：

真正的 Payload 會不會是在 Kernel Mode？

回頭分析 Lab10-01.exe

知道 Driver 的行為之後，再回頭看：

Lab10-01.exe

就比較容易理解整個 Malware 的結構。

這個 EXE 本身並不是直接負責關閉 Firewall。

它比較像是一個負責控制 Driver 的 User Mode Component。

它會建立：

Kernel Service

讓：

Lab10-01.sys

能夠作為 Driver 執行。

接著透過：

ControlService

控制這個 Service。

真正敏感的 Registry 修改則交給 Kernel Driver 完成。

完成修改之後，Driver 會被 Unload。

因此整體架構可以整理成：

Lab10-01.exe
      │
      ↓
建立 Kernel Service
      │
      ↓
載入 Lab10-01.sys
      │
      ↓
ControlService
      │
      ↓
Kernel Driver 執行
      │
      ↓
修改 Firewall Registry
      │
      ↓
Disable Windows Firewall
      │
      ↓
Driver Unload

Question 3：這個程式到底做了什麼？

最後就可以回答第三題：

What does this program do?

綜合前面的 Dynamic Analysis、Kernel Debugging 和 Static Analysis，可以得到完整結果。

Lab10-01.exe 會建立並使用一個 Kernel Service，載入：

Lab10-01.sys

這個 Driver。

接著 Driver 在 Kernel Mode 中修改 Windows Firewall 相關 Registry 設定，把數值設為：

0

藉此：

停用 Windows Firewall。

最後 Driver 再被 Unload。

所以如果只從 User Mode 觀察：

Lab10-01.exe

可能只會看到：

ControlService

以及一些 Service 相關操作。

但是進入 Kernel Mode 後才會發現，真正重要的 Payload 是：

Lab10-01.sys
        ↓
Registry Modification
        ↓
Disable Windows Firewall

Lab 10-1 的分析思路

這個 Lab 真正值得記住的其實不是某一個 WinDbg Command，而是分析流程。

一開始：

Procmon
   ↓
Lab10-01.exe 好像沒做什麼 Registry 修改

接著從 Static Analysis 發現：

ControlService

因此開始懷疑：

User Mode
   ↓
Service
   ↓
Kernel Driver

再利用 WinDbg：

!drvobj lab10-01

找到 Driver Object。

接著：

dt _DRIVER_OBJECT

查看 Driver Structure。

最後設定 Kernel Breakpoint，實際追進：

Lab10-01.sys

才看到真正的 Registry Modification。

所以完整思路是：

Procmon
   ↓
發現 User Mode 行為不多
   ↓
IDA Pro
   ↓
發現 ControlService
   ↓
懷疑 Kernel Driver
   ↓
WinDbg Kernel Debugging
   ↓
找到 Lab10-01.sys
   ↓
Breakpoint
   ↓
追蹤 Driver
   ↓
發現 Registry Modification
   ↓
IDA Pro 驗證
   ↓
確認目的為 Disable Windows Firewall

結語

前幾篇介紹 WinDbg 和 Kernel Debugging 時，很多東西其實都還停留在「這個 Command 可以做什麼」。

到了 Lab 10-1，才真正看到為什麼 Malware Analyst 有時需要進入 Kernel。

如果今天只使用 Procmon 觀察 Lab10-01.exe，可能會得到：

沒有明顯 Registry Modification

但這並不代表整個 Malware 沒有修改 Registry。

因為它把真正的操作交給：

Lab10-01.sys

在 Kernel Mode 中執行。

最後我們才發現真正的行為是：

Lab10-01.exe
        ↓
Kernel Service
        ↓
Lab10-01.sys
        ↓
修改 Registry
        ↓
Disable Windows Firewall

這也是這個 Lab 最重要的收穫：

看不到行為，不代表行為不存在，而是我們可能還沒有站在正確的地方觀察。

User Mode 工具可以解決很多 Malware Analysis 的問題，但當 Sample 開始使用 Kernel Driver 時，就需要繼續往 Kernel Mode 深入。

而 WinDbg 的 Kernel Debugging，正是讓我們可以繼續追下去的工具。

參考資料

• Practical Malware Analysis (Chapter 10)
• https://www.jaiminton.com/Tutorials/PracticalMalwareAnalysis/Chapter10/#

本日貓味