前言

雖然我在若干年前打 CTF 的時候已經做過一些流量分析題，但都是非常簡單的題目，例如：

• 給定一個 pcap 檔案，找到其中的 flag：一般來說直接開啟 WireShark 搜尋即可。
• 給定一個 pcap 檔案，找到其中的某個檔案：WireShark 選單的 File -> Export Objects 可以直接匯出 HTTP、FTP 等協議的檔案。

但你們也能看出來，由於我的主業不是安全，這部落格就好久沒有寫安全類的文章了，我自然也沒有機會接觸到更難的流量分析題目了。

面臨挑戰

前幾天跟朋友去爬山，他提到了一個題目，是一個 pcap 的流量分析。乍聽起來好像很簡單：

一個公司發現有重要檔案被盜，但員工沒有使用任何 USB 等裝置，所以檔案一定是透過網路被盜的。幸運的是，他們有當天的網路流量檔案（2.pcap）。作為網路取證專家，你能幫助他們找到以下資訊嗎？

1. 攻擊者的 IP 地址？你是如何找到的？
2. 被盜檔案的 MD5 雜湊值是多少？檔案型別是什麼？
3. 檔案被盜的時間是什麼？

在山上，朋友說：這題只要用 WireShark 開啟檔案，然後用 File -> Export Objects -> FTP Data 匯出檔案，就能找到被盜的檔案了。

在 WireShark 中過濾出所有的 FTP 流量，發現 172.29.1.23 試圖登入 FTP 伺服器，那麼目標 172.29.1.21 一定是那臺“伺服器”，一定是“攻擊者”從“伺服器”上下載了檔案。

將其儲存成 Employee_Information.xls，這是個 Excel 檔案（從檔案頭的 d0 cf 11 e0 也能直接看出來），可以用 Excel 開啟。隨便 md5sum 一下就能得到結果了。

至於時間，在“攻擊者”試圖登入 FTP 後，有一個來自 172.29.1.23 的 Syslog：Mon Jul 14 14:14:15 2014 ... A new process has been created. 這可以作為我們的時間線索。這兩條記錄的時間差大約有 2 秒，所以檔案被盜的時間應該是 14:14:13……

……

……嗎？

有些不對勁

聰明的你可能已經猜到了，從最開始我們的判斷就已經錯了——將 FTP 流量都過濾出來後，我們發現“攻擊者”執行的命令實際上是 STOR 上傳檔案，而不是 RETR 下載檔案。攻擊者沒有理由上傳一個 Excel 到伺服器上啊！看來得好好分析，不能偷懶了。

包裡都有哪些協議？

透過 WireShark 的 Statistics -> Protocol Hierarchy，我們可以看到這個 pcap 檔案中有哪些協議，以及它們所佔的比例：

看起來可疑的協議不多：

• FTP：剛才分析過了，不是下載檔案。
• SMB：只是個 Lanman 協議，不太可能是檔案傳輸。
• HTTP：這個協議的流量比例很大，可以再仔細看看。
• TLS：這個協議的流量比例也不小，可能有加密的檔案傳輸。

HTTP 協議分析

先分析最簡單的 HTTP 協議。透過 WireShark 的 Statistics -> HTTP -> Request Sequences，我們可以看到 HTTP 請求的序列：

不過並沒有什麼有意思的東西，看起來先 Google 搜尋了 http://www.wireshark.org/、打開了它（載入了好多靜態資源），然後又搜尋了 http://Lmgsecurity.com/blog/ 並且打開了它，然後跳回了 Google 首頁，最後是兩個 AOL 郵箱自動收信的請求。看來只能考慮分析 TLS 協議了。

TLS 協議分析

TLS 協議是加密的，我們無法直接看到內容，如果不知道證書的話很難破解。雖然朋友找到了 pcap 中的一些 OCSP 請求，“但這只是一道普通的流量分析題啊，至於那麼麻煩？”我心想，沒有繼續這條路。

那該怎麼辦呢？機智如我想到了透過 SNI 來分析。在 WireShark 的搜尋框裡輸入 tls.handshake.type == 1 過濾出所有 Client Hello 包（期望這道題沒有用 ECH），發現似乎也沒什麼特別的，都是 Google、新聞站 blackhat.com、垃圾站 2o7.net：

普通的 TCP 協議

還有什麼協議可以分析呢？從前文的協議比例中可以發現，還有很多普通的 TCP 協議我們沒有分析。透過 WireShark 的 Statistics -> Conversations，我們可以看到所有的 TCP 會話。按照 Bytes 降序排列，可以發現第一名是到 blackhat.com 的 HTTPS 流量，第二名是到 172.29.1.21 的……krb524 流量？

透過 tcp.stream eq 30 過濾出相關流量，並 Follow TCP Stream，我看到了一個很熟悉的檔案頭 4d 5a，以及一個刻在 DNA 裡的字串 This program cannot be run in DOS mode：

需要把流量儲存下來。在命令列執行 tshark -r 2.pcap -Y "tcp.stream eq 30 && tcp.len > 0" -T fields -e data > output.raw 可以將其儲存為 ASCII 檔案（裡面是十六進位制的字串）。刪掉第一行看起來是協議頭的東西，然後用 xxd -r -p output.raw > output.exe 就能得到一個可執行檔案了。

可執行檔案分析

使用 IDA 開啟它，發現它裡面有 501 個函式，沒有符號表，並且 .rdata、.text 等段都無法被自動解析，很顯然不是個正常程式。出題人為了一個流量分析的題目如此大費周折，實在是讓人難以理解。

由於二進位制不是我的強項，於是我們求助了一位專搞二進位制的大佬，然後發現這個程式是個 Meterpreter 生成的遠端控制程式……

• 朋友：難道我真猜對了是遠控？
• 大佬：你猜對了。
• 朋友：為啥我的聯想電腦管家沒報毒？
• 大佬：他是 Meterpreter 生成的。
• 朋友：這怎麼看出來的？
• 大佬：Windows defender 說的。
• 我：……

根據我對 metepreter 的瞭解，它生成的遠端控制程式通常會使用 4444 埠，只不過被 WireShark 識別成了 Kerberos 524 而已。我又完整看了這個 TCP 流：

• 首先是普通的 TCP 三次握手。
• 之後的第一個包（剛才懷疑是協議頭的東西）只有 4 位元組 00 be 0b 00，可能就是開始傳遞檔案的命令。
• 後面一系列包都是單向傳遞檔案。
• 最後是雙方頻繁互相通訊，往來的訊息體都以 17 03 00 00 開頭，應該就是命令和響應。但由於這段流量是加密的，且題目沒有提供核心轉儲檔案，所以我們無法拿到 Meterpreter 的 AES key，無法解密。

在雙方互相通訊的過程中，夾雜了 FTP 協議，看起來是攻擊者控制受害者上傳檔案。

意料之外的結論

我們一開始都以為 172.29.1.21 是伺服器、172.29.1.23 是攻擊者，這跟我們日常的經驗比較相符（IP 最後一位是 1 的裝置通常是閘道器），但實際上剛好相反。攻擊者（172.29.1.21）先透過早已建立的通道傳了一個 Meterpreter 生成的遠端控制程式給受害者（172.29.1.23），然後控制受害者透過 FTP 協議將檔案上傳給了攻擊者。

雖然最開始我們沒能很好地還原現場，不過誤打誤撞，至少被偷走的檔案我們判斷正確了。看起來這道題在 CTF 裡面不止要 200 分，可能至少得 300 分。

還沒完——對時間的分析

第二天朋友又找到我，說我們沒有注意到時間可能有問題。Syslog 內容裡記錄的時間，跟 ETH 報文被捕獲的時間，有很大的誤差（不是時區問題）。

該相信哪一個呢？理論上來說，Syslog 的時間是受害者機器的時間，ETH 報文的時間是抓包機器的時間，都可能會被誤差影響。機智如我又突然想到，不是有人訪問過 Google 嗎？Google 的時間是不是可以作為一個參考呢？於是我又找到 Google 的請求：

• Google 響應體的 Date 頭是正確時間的 20:12:52，相對時間是 62.557605。（注意到 ETH 報文的時間是 20:25:24，抓包機器的時間也快了 12 分 32 秒。）
• 4096（請求包）~4097（響應包）的時間差是這次請求的 TTFB，只有 63 毫秒，可以認為 Google 伺服器延遲導致的誤差可忽略。
• 得出結論：偷竊開始（第一個 FTP Data）時間是相對時間 209.463818，也就是 Google 響應的 2 分 26 秒後，也就是正確時間 20:15:18；整個偷竊過程在 3 毫秒內完成。
• 使用 wireshark.com 的請求也可以得出相同的結論。考慮到 Google 和 WireShark 的伺服器時間不可能同時被篡改，這個結果的可信度非常高。

尾聲

真真假假，假假真真。這道題以它的反直覺性和複雜性，讓我學會了在流量分析中不要過於依賴直覺，要多方面考慮。以及任何蛛絲馬跡都可能是線索，不要放過任何一個細節。

體內的 CTF 基因動了，CTF 簡直太好玩了……