在資安事件中，常常聽到客戶資料遭外洩，這時大家就會想說，是不是 Web Server 或公司內部電腦是否有木馬病毒入侵，但是並不是什麼案件都是被植入執行程式，而是利用SQL語法的盲點或該網站漏洞進行攻擊，有些企業尤其是電商，對資安概念較不注重，前台資料送往後台時沒做一些字串過濾與篩檢直接跟資料庫溝通，導致資料庫回傳出不該傳的資料出現，好比客戶名單或非正常登入後台，我用SQLite簡單展示SQL語法盲點，我們先看 DB Table：
接下來用正常 SQL 語法去做 Select
那我用 SQL 註解符號去繞過 password 判別，一樣可以成功
接下來 Select 該 Table 底下所有資料非正常語法
Table 底下所有名單就被顯示出來了，這範例是在演示網站在輸入帳號密碼的欄位裡，給予SQL語法看該網站會不會吐出不該出現的重要資訊，要是出現了客戶資訊就可能這樣被撈走。
在企業界裡，很多大公司或機敏性較高的公家單位，對機密資料外流嚴重性非常重視，尤其像台積電這種大公司以及軍方單位，最害怕的就是有內賊把內部資料外流出去，畢竟這些單位的網路都是封閉的，所以就有可能會用USB外接儲存裝置把內部資料流出，不過這些單位在這方面的防護都做得非常好，但我還是介紹一下，要是有外接裝置插入，我們可以從哪裡調查。
可以從 Registry 裡找到外接裝置插入這台電腦相關的安裝資訊，如圖：
就連手機有插入這台電腦資訊都可得知，還可以從 Windows API 裡去獲取更詳細的 USB devices 的資訊：
欄位比較多
從上面的資訊，我們可以得知裝置安裝的時間，以及最後插入時間、最後拔出時間，這些都是對數位鑑識調查非常重要資訊。
在數位鑑識裡，有可能遇到公司想調查離職員工的使用電腦，或是檢警調查嫌犯電腦的操作紀錄等…，我們可以從 C:\Users\[使用者名稱]\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations 這個路徑下的檔案做解析，如下圖：
可以從這些檔案解析出該使用者開啟過什麼檔案，時間點是什麼時候，好推測此電腦人為操作的時間流程，而且還可以找到嫌犯可能的犯罪證據，畢竟他開啟過的檔案中，裡面或許有他的犯罪檔案內容，這都值得調查的，我們看看解析後的結果吧！
這是欄位名稱
紅框這一欄 record time 就是最主要的開啟時間資訊，其他時間只是該檔案的(.lnk)資訊內容也是可以做些參考，有興趣的朋友也能自己試看看，你開啟一個檔案後，找個解析 Jumplist 的工具，看看 record time 有沒有符合你剛剛開啟該檔案的時間。
要是對這些鑑識調查系統資訊模組或工具製作有興趣，可以到粉絲團 facebook.com/rexlintechnology跟我留言或聯絡，不吝嗇給個讚跟追蹤吧！
在調查惡意程式時，我們應該得先瞭解惡意程式是怎麼撰寫的，因為您要是更熟悉製作手法就越能知道我該從哪裡下手調查，這次我用簡單方式來講解程式加殼，以前很多惡意程式被多家防毒軟體掌握，導致無法對該電腦進行執行，因此加殼手法在惡意程式上越來越常見，我們看下圖：
出處：https://www.researchgate.net/figure/PE-structure-of-normal-executable_fig1_259647266
這是 Windows 執行程式的檔案格式圖，我們只要看紅框這部分，其實加殼就是把紅框這一塊它是程式的執行區，做加密或壓縮放在這執行程式檔案其中一個位置，通常是不會影響該程式執行的位置，執行區的動作就置換成：先找到原本執行區所存放的位置後。進行解密或解壓的動作還原，在跟記憶體要求一塊位置，再把原執行區載入該位置加以執行，其實 Linux 的 ELF 執行程式加殼原理也是這麼做，ELF 執行程式的檔案格式圖：
出處：http://www.cjwind.idv.tw/Executable-Format/
我們可以用 Process Explorer 這工具找到哪個 Process 是否有加殼。
在數位鑑識調查中，往往會留意程式的網路行為，因為木馬就是把您個人重要資料上傳出去，我們通常作法就是監控封包或連線行為，但是開始調查後，也就是事件發生之後，不見得當下還能偵測到異常流量，所以可以解析 C:\Windows\System32\sru\srudb.dat 裡面有記載您電腦 app 也就是程式的網路上傳與下載的總流量，從這裡的資訊去辨別哪支程式是沒註冊、位置也較可疑，就可以留意他上傳的流量，是否異常過多，好去追蹤分析該程式行為，是否為木馬程式。我們看看資訊內容：
上圖就是我從 C:\Windows\System32\sru\srudb.dat 解析出來的資訊，裡面紅框就是我剛說的程式名稱與上傳流量的資訊，有興趣的朋友也能去解析該檔案內容資訊，它裡面記載的資訊不只這些。
要是對這些鑑識調查系統資訊模組或工具製作有興趣，可以到粉絲團 facebook.com/rexlintechnology跟我留言或聯絡，不吝嗇給個讚跟追蹤吧！
我們在調查一台主機時，往往會想知道這台主機到底執行過哪些程式，以及他到底是什麼時間啟動的，在 Windows 的數位鑑識調查裡，可以從 C:\Windows\Prefetch 裡的 .pf 檔案去做解析可得知這台電腦到底執行過哪些程式，但 Windows 版本不同，他的 Binary 格式也有所不同，像 XP、Server 2003 他跟 Win7、Server 2008 Binary 位移就不一樣，而且他們的執行時間只記錄最後一次那筆，到 Win8 後他執行時間都會有紀錄，Win10 後他的 Binary 又多做一層壓縮演算法，所以要先解壓在解析 .pf 檔，看解析後的下圖：
我們可以看到 exe 的名稱與路徑，他的建立時間、修改時間、檔案大小，但最主要的是會去看到執行次數與最後執行時間，因為在分析可疑程式時，第一會去找該 exe 的路徑是否在那些常看到的不尋常路徑，像 Temp、Appdata 底下那些目錄下層，要是有就會觀察他執行時間的變動，看是不是跟我上次說的開機啟動那篇一些手法起來時間吻合，要是有就多好幾個方向做調查，這些都是數位鑑識調查的眉角，有興趣的朋友可以參考看看。
要是對這些鑑識調查系統資訊模組或工具製作有興趣，可以到粉絲團 facebook.com/rexlintechnology跟我留言或聯絡，不吝嗇給個讚跟追蹤吧！
我們在尋找可疑程式或檔案時，看到工作管理員或其它第三方工具檢視正在執行的程序，往往最多的程序執行位置落在 C:\Windows\System32，但是這麼多的程序又不知道到底是不是 Windows 自身的程式還是被人惡意放入在該位置執行的，您或許會調查他的數位簽章，可是 System32 裡的程式並不是每個都有簽章，那我們該如何判斷該程序是否是 Windows 自身的程式，我提供一個方向讓大家可以參考看看。
據我所知道的在 C:\Windows 這目錄底下包含子目錄的執行程式(.exe)，它的可完整操作權限使用者名稱為：Trusterinstaller，他可以完全控制、修改、執行、讀取、寫入，但其他使用者權限如：SYSTEM、Administrators、Users 只能執行與讀取，我們可以進入到 C:\Windows 這目錄找一隻執行程式(.exe)，按右鍵 > 內容 > 安全性看看他的權限結構，如圖：
如果不是 Windows 自身程式進入到 C:\Windows 這目錄底下的話權限結構會如下圖：
從上面所看到的，要是非 Windows 自身執行程式進入到該目錄，第一他沒有 Trusterinstaller 這使用者權限，第二他的SYSTEM、Administrators的權限是完全控制的，我們就能以這權限差異來判斷是否更進一步解析這支可能是不正常程式。
其實我之前在調查惡意程式的案例中，其中有一件就是在受害端電腦裡找到那支藏在 C:\Windows\System32 底下的惡意程式，我還特別去解析他的 PE 格式，裡面還有他 Debug 檔案路徑位置，還滿有趣的，這只是我的調查經驗分享給大家。
在調查惡意程式時，尤其是木馬類型的程式，他基本特性就是要常駐，不能因為重開機就停止運作，不然就沒任何作用跟一般垃圾檔案沒兩樣，所以它得一直維持它的運作方法就是寫入開機啟動，但寫開機啟動方法好幾個，我舉常見的這四種方式。
1.Registry
Registry 就是我們常說的機碼、登入檔、註冊表，中文翻譯名稱很多反正就是說 Registry，在微軟網站敘述，提供用於表示 Windows 登錄中根目錄機碼的 RegistryKey 物件，以及用於存取機碼/值組的 static 方法。簡單來講就是全域變數有寫過程式的應該馬上就能理解，也就是說系統裡面程序一起來，會去看 Registry 當時的設定值，而執行當下該要執行的動作。好回歸正題，程式可以在 Registry 寫入開機啟動路徑如下：
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
在上一篇 Ext4 的介紹，最後講到我們可以從 Ext4 的一個地方有機會找到該筆刪除檔案的檔案實體位置，這個地方就是 Ext4 Journal ，我們可以從 Inode 表裡找到它，它在表裡編號為 8，Journal 裡面記錄著 Ext4 裡檔案與目錄的變化，是記載著這些檔案、目錄 Inode 內容，所以我們可以從這裡找到那筆刪除檔案還沒被修改成已刪除的 Inode 內容，找到這筆 Inode 內容後，就能看到他檔案實體位置資訊，藉此將這筆刪除檔案復原，當然 Journal 也是有最大 Size 限制，換句話說時間經過太久或檔案變動過多，也是可能被覆蓋資訊，那就來看下面尋找刪除檔案方法展示圖：
這張圖是上一篇介紹的刪除檔案 Inode 內容資訊
紅框內是來找該筆檔案的特徵，我們用該特徵在 Journal 裡找到該筆檔案 Inode
在 Journal 裡面的位置前面，找到這筆刪除檔案已被註記被刪除 Inode 資訊，可以看看它跟上圖的內容是一樣的
這筆 Inode 就是該筆刪除檔案還沒被註記被刪除 Inode 資訊，因此我們可以從紅框看到它檔案實體位置資訊並不是為 0 ，再從橘框擷取這 Inode 位置去做檔案復原動作，我把橘框位置 16進位換成10進位
在前幾篇文章講完 Windows 使用為主的 NTFS 硬碟邏輯格式，這次來分享 Linux 常用的硬碟邏輯格式 Ext4，因為本人習慣用 Windows 系統，所以 Ext4 邏輯是用 Windows 去解析此格式的硬碟，雖然 Windows 不支援 Ext4 但解析硬碟格式邏輯資料方式都是一樣的，不管是什麼作業系統。
我以簡單方式說明，其實 Ext4 一開始從 Super Block 找到 Inode 位置，我們就可以用遞迴方式解析該硬碟底下所有目錄與檔案，Inode 簡單來說就是紀錄硬碟內的檔案與目錄詳細資訊，感覺跟 NTFS 的 MFT 表很像但沒比它記錄的結構邏輯這麼複雜，所以一開始會從 Root 在 Inode 編號為 2 開始解析，資料結構內容如下：
Root 是一個目錄，從他的 Inode 得到他詳細資訊後，找到 Root 目錄內容資訊所存放的位置，Recovery 後所得到的內文，就是上圖底下的 Binary ，記錄著 Root 目錄底下有哪些目錄與檔案，他們的 Inode 編號各別為多少，權限資訊與名稱等等…，我舉上圖看到的 abc 目錄底下的檔案 Inode 的內容基本有哪些常調查的資訊，我們看下圖：
你們應該會問我，為何會知道紅色那筆是刪除檔案，難道上面沒顯示該檔案名稱就這樣認定，其實不是，我們可以在上圖的 Binary 裡對應到每筆檔案結構資訊，其中有一個訊息會告訴你下一筆檔案在哪個位置，所以該筆檔案刪除後，他上一筆的檔案資訊會跳過該筆刪除檔案的位置直接指到下下筆檔案位置，當然要是知道這筆是刪除的資訊，我們還是能找到他 Inode 編號，我們來看看 Inode 內容吧：
上圖內容是剛上上圖那筆刪除檔案的 Inode 內容，其實裡面記錄著檔案 mode 、大小、四個時間、檔案內文位置等…詳細資訊，我框出時間資訊，框的顏色對應同顏色文字，其中綠色的刪除時間只有該檔案被刪除才會出現，我們也能依此根據來判斷該筆是否刪除，再來解說檔案內文儲存位置資訊，來看下兩張圖：
NTFS 刪除檔案其實只是在 MFT 表裡的 File Record Header 結構中的 Flage 為 0，系統就會知道這筆資料已被刪除，他所存放的硬碟空間位置將會釋出，該位置隨時都有可能被新進的檔案覆蓋，當被覆蓋時刪除的檔案就救不回來了，除非你有做備份或還原點， 我們知道 MFT 表就是一張索引表紀錄著每個目錄與檔案的詳細資訊，當該筆檔案索引被註記為刪除後，這筆索引也隨時有可能被新進的檔案或目錄所取代，當索引被取代就算你 0x80 檔案實體位置還沒被覆蓋也難以找回你所刪除的檔案，尤其現在的 Windows 10 系統背後讀寫非常之頻繁，每次刪除檔案後過個幾秒後，就找不到剛刪除的痕跡，索引跟實體很快就被覆蓋了，資料越來越不好救，除非是非系統磁區（非C：磁區）。下圖為 File Record Header 結構中的 Flage 狀態：
正常檔案：
刪除檔案：
以上是刪除檔案的介紹。
這是我的粉絲團facebook.com/rexlintechnology 我也有開一些課程有興趣可以參考看看，不吝嗇給個讚跟追蹤吧！
今天來說說 Attribute List 也就是 MTF 表的 0x20 ，這個 0x20 在MFT表裡是不常出現的，通常是MFT表單一檔案資訊內的 Attribute 資訊太多可能寫入空間會不夠，畢竟 MFT 表一筆資料空間只有 65536 Byte ，就會把一些 Attribute 資訊分散在 MFT 表其他位置，再把分散在哪的這些資訊記錄在 0x20，所以舉個例子，我上次說過檔案內文資訊存放在 0x80 裡，但這檔案的 MFT 表資訊並沒 0x80 的紀錄，我們就要到 0x20 去找該檔案的 0x80 資訊存放在 MFT 表的位置，再從該位置找到 0x80 資訊把檔案內文讀取出來，如下圖：
我們看到這檔案他的 0x10、0x30 記錄在 MFT 表原本該檔案的位置，但她的 0x80 各分散在不同位置，如下圖：
第二個 0x80
我們可以看到第一張與第二張的紅框就是指 MFT 表的位置。
以上是我對 NTFS 邏輯 Attribute List 0x20 的介紹，對我的文章有興趣的朋友可以關注我，這是我的粉絲團facebook.com/rexlintechnology不吝嗇給個讚跟追蹤吧！
