วันศุกร์ที่ 3 สิงหาคม พ.ศ. 2550

หมดยุคของ vmware สำหรับการวิเคราะห์ malware

หากกล่าวถึง vmware หลายๆคนก็คงเคยเล่นกัน โดยเฉพาะพวกที่ชอบเล่นกับ malware หรือไม่ก็ exploit เพราะเนื่องจากเจ้า vmware นี่แหละ ที่ช่วยให้เราสามารถรันระบบปฏิบัติการหลายๆระบบ พร้อมกันไปในเครื่องคอมพิวเตอร์เพียงเครื่องเดียว ทำให้เราไม่ต้องหาเครื่องคอมพิวเตอร์อีกเครื่องเพื่อสร้างขึ้นมาเป็น test-based แต่ใช้เครื่องของเราเนี่ยแหละทำเป็น test-based ได้ไปในตัวได้เลย :)

ด้วยเหตุนี้ vmware จึงเหมาะสำหรับนำมาวิเคราะห์ malware เพราะการวิเคราะห์ malware นั้น นอกจากจะต้องวิเคราะห์แบบ static คือการวิเคราะห์โค้ดที่เขียนขึ้น (ผ่านทาง reverse engineering) ยังต้องวิเคราะห์แบบ dynamic คือการวิเคราะห์การทำงานจริง โดย vmware มักถูกนำมาใช้สำหรับการวิเคราะห์แบบ dynamic กล่าวคือทำการรันบน malware บนระบบปฏิบัติการที่สร้างขึ้นจาก vmware แล้วดูลักษณะการทำงานของ malware เนื่องด้วยระบบปฏิบัติการที่รัน malware เป็นระบบปฏิบัติการที่สร้างขึ้นบน vmware ดังนั้นนักวิเคราะห์มัลแวร์จึงไม่ต้องกังวลในกรณีที่ malware จะอันตรายกับระบบปฏิบัติการของตัวเอง

แต่ตอนนี้แนวทางการวิเคราะห์ใมัลแวร์ดังกล่าวทำท่าว่าจะมีปัญหาซะแล้ว เนื่องจากนาย Kato Ken นักวิจัยด้านความปลอยภัยคอมพิวเตอร์ชาวญี่ปุ่น ได้ค้นพบวิธีการตรวจสอบว่าระบบปฏิบัติการที่รันอยู่นั้นเป็นระบบที่อยู่บน vmware หรือไม่ โดยใช้ภาษา assembly ไม่เพียงกี่บรรทัดเท่านั้น ถ้าสนใจสามารถอ่านเพิ่มเติมได้ที่นี่ครับ

เนื่องจากผมไม่ค่อยมีเวลามาก (ทั้งๆที่แค่ใส่ inline assembly ลงไปในโค้ดไม่กี่บรรทัด แหะๆ) ดังนั้นก็เลยพยายามหาโค้ดสำเร็จรูปสำหรับการทดสอบที่มีชาวบ้านเขียนไว้แล้ว ซึ่งก็ได้พบกับ VmDetect ซึ่งพัฒนาโดย lallous ซึ่งโค้ดของหมอนี่นอกจากจะสามารถตรวจสอบ vmware ได้แล้ว ยังสามารถตรวจสอบ Microsoft Virtual PC ได้ด้วย

นี่เป็นภาพที่ทำการรัน VmDetect บนระบบปฏิบัติการธรรมดาครับ

Photo Sharing and Video Hosting at Photobucket

ส่วนนี่ก็เป็นภาพที่รัน VmDetect บนระบบปฏิบัติการที่อยู่บน vmware

Photo Sharing and Video Hosting at Photobucket

แล้วมันสำคัญยังไง ? มันสำคัญตรงที่ว่านักพัฒนา malware สามารถใช้ความรู้ตรงจุดนี้เพิ่มความสามารถให้กับ malware เพื่อให้ทำการตรวจสอบว่าตัว malware เองรันอยู่บน vmware หรือไม่ หากรันอยู่บน vmware ตัว malware เองจะไม่ทำงาน หรืออาจะสั่งให้ทำลายระบบปฏิบัติการบน vmware เลยก็ได้... evil ครับ evil

pulsing zombie

zombie ในเชิงของ computer security หมายถึงเครื่องคอมพิวเตอร์ที่ถูกแฮกและถูกนำมาใช้เป็นเครื่องมือเพื่อกระทำสิ่งต่างๆตามที่ผู้บุกรุกต้องการ ไม่ว่าจะเป็นทำการสแกนเครื่องของชาวบ้านเค้า โจมตี DoS (Denial of Service) หรือ DDoS (Distributed Denial of Service) เพื่อทำให้ระบบเครื่อข่ายหรือเซิร์ฟเวอร์เป้าหมายไม่สามารถใช้งานได้อย่างปกติ ด้วยลักษณะของการที่เครื่องคอมพิวเตอร์ที่ถูกแฮค (ตายไปแล้ว) และได้ถูกใช้มาทำการโจมตีระบบอื่นๆอย่างบ้าคลั่ง (ถูกปลุกขึ้นมาและอะละวาด) ทำให้เป็นที่มาของคำว่า zombie นั่นเอง

แต่วันนี้ผมจะไม่กล่าวถึง zombie เพราะรู้สึกว่าก็น่าจะรู้จักกันมาพอสมควรแล้ว แต่ที่จะกล่าวในวันนี้จะเป็นรูปแบบหนึ่งที่พัฒนาขึ้นจาก zombie แบบธรรมดา โดยจุดประสงค์ของมันเพื่อหลีกเลี่ยงการตรวจสอบของผู้ดูแลระบบ และถึงแม้สามารถตรวจพบก็ไม่สามารถมั่นใจได้ว่าเป็น zombie หรือไม่ ชื่อของมันคือ pulsing zombie

pulsing zombie คือ zombie ประเภทหนึ่ง เป็นเครื่องคอมพิวเตอร์ที่ถูกแฮกและถูกนำมาใช้เพื่อทำการโจมตีระบบอื่นเช่นเดียวกับ zombie แบบธรรมดา แต่อย่างไรก็ตามข้อแตกต่างระหว่าง pulsing zombie และ zombie แบบธรรมดาก็คือ pulsing zombie จะไม่โจมตีเป้าหมายอย่าง "บ้าคลั่ง" (จำนวนมาก/เวลาน้อย) แต่จะโจมตีเหยื่ออย่าช้าๆ ค่อยเป็นค่อยไป (จำนวนปกติ/เวลานาน) ด้วยเหตุนี้เองทำให้มีความยากลำบากในการตรวจสอบ pulsing zombie มากกว่า zombie แบบธรรมดา เพราะลักษณะการโจมตีจะเหมือนการใช้งานธรรมดาของผู้ใช้นั่นเอง

โดยปกติแล้ว pulsing zombie มักถูกนำมาใช้เพื่อทำการ slow-down เป้าหมายมากกว่าการ shutdown เป้าหมาย หรือเรียกอีกอย่างหนึ่งว่า Degradation of Service ซึ่งเป็นรูปแบบหนึ่งของ DoS นั่นเอง (ตัวย่อ DoS เหมือนกันด้วย เฮ่อๆ)

แล้วทำไมถึงใช้คำว่า "pulsing" ? คำนี้ๆสามารถแปลได้ว่า ลักษณะของบางสิ่งบางอย่างที่มีการเต้นขึ้น-ลง เหมือนกับคลื่นหัวใจ ซึ่งก็ถูกนำมาใช้กับเจ้า zombie รูปแบบนี้ที่คล้ายๆกับคนที่ยังมีชีวิตอยู่นั่นเอง (แต่ที่จริงมันก็ตายไปแล้วนั่นแหละนะ) :)

วันอังคารที่ 29 พฤษภาคม พ.ศ. 2550

ว่าด้วยเรื่องของ xp_cmdshell

หากกล่าวถึง xp_cmdshell บรรดาแฮกเกอร์มือเก๋าหรือหัดใหม่ก็คงรู้จักกันเป็นอย่างดี เนื่องจาก xp_cmdshell เป็น extend stored-procedure ของ Microsoft SQL Server ซึ่งมีความสามารถพิเศษคือ สามารถใช้รันคำสั่งของระบบปฏิบัติการได้

exec master..xp_cmdshell 'dir'

ซึ่งหากอยากจะให้ MSSQL ของเราปลอดภัยจากการโดนยิงในระดับนึงแล้ว เราควรทำการปิดการใช้งาน xp_cmdshell ด้วยคำสั่งดังต่อไปนี้

exec sp_dropextendedproc 'xp_cmdshell'

คำสั่งดังกล่าวต้องรันด้วยสิทธิของ Administrator หรือ sa ของ MSSQL ถึงจะสามารถดร็อป stored-procedure ดังกล่าวได้ครับ

อย่างไรก็ตามวิธีการ drop stored-procedure ดังกล่าวไม่สามารถป้องกันการโดนโจมตีจาก xp_cmdshell ได้ร้อยเปอร์เซ็นต์ เนื่องจากหากผู้บุกรุกมีสิทธิสูงอย่างเพียงพอ ผู้บุกรุกสามารถใช้คำสั่งดังต่อไปนี้เพื่อดึง xp_cmdshell กลับมาได้

exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'

ดังนั้นเพื่อความชัวร์จึงควรลบไฟล์ xplog70.dll ออกไปจากระบบด้วย ซึ่้งการลบไฟล์นี้ออกไปจากระบบ จะทำให้ stored-procedure ดังต่อไปนี้ไม่สามารถใช้งานได้
  • xp_sscanf
  • xp_sprintf
  • xp_msver
  • xp_enumgroups
  • xp_logevent
  • xp_loginconfig
นอกจากนี้การดร็อป xp_cmdshell จะมีผลต่อ stored-procedure อีกหลายน่ะ ติดตามได้จากที่นี่เด้อ http://support.microsoft.com/kb/891984

หมายเหตุ: ถ้ามีการลง Services Pack ของ MSSQL ต้องคอยตรวจสอบด้วยว่าไฟล์ xplog70.dll ได้กลับมาหรือไม่ ในกรณีที่เราลบไฟล์นี้ออกไปจากระบบแล้ว

วันอังคารที่ 15 พฤษภาคม พ.ศ. 2550

การดูเวลาที่สร้างและเวลาครั้งสุดท้ายที่ทำการแก้ไขไฟล์ PDF

วันก่อนเจอ case เกี่ยวข้องกับการปลอมเอกสาร PDF ก็เลยนำมาเล่าสู่กันฟังเด้อ :) โจทย์ก็คือเราจะสามารถทราบได้อย่างไรว่าไฟล์เอกสาร PDF ที่ทำการตรวจสอบนั้น ถูกสร้างขึ้นเมื่อใดและถูกแก้ไขครั้งสุดท้ายเมื่อใด

วิธีการดูค่าเวลาต่างๆของไฟล์ PDF นั้นจะดูที่ค่า metadata ของไฟล์ PDF นั่นเอง ซึ่งสามารถดูได้ด้วยวิธีการนี้


  • เปิดไฟล์ PDF ที่ต้องการตรวจสอบด้วยโปรแกรม Adobe Reader
  • คลิกที่เมนู File แล้วเลือกที่ Document Properties...

Photo Sharing and Video Hosting at Photobucket

  • ที่ tab ชื่อ Description จะมีข้อมูลเกี่ยวข้องกับไฟล์ PDF อยู่ไม่ว่าจะเป็น ผู้ที่ทำการสร้างไฟล์ (Author), เวลาที่ทำการสร้างไฟล์ (Created) หรือ เวลาครั้งสุดท้ายที่ทำการแก้ไขไฟล์ (Modified)

Photo Sharing and Video Hosting at Photobucket

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

อย่างไรก็ตามค่า metadata ดังกล่าวของไฟล์ PDF นั้นสามารถปลอมแปลงได้ ซึ่งอาจทำให้ผู้ที่ทำการปลอมแปลงเอกสารนั้น ทำการปลอมแปลงวันเวลาที่สร้างเอกสารให้เป็นวันที่เกิดขึ้นก่อนเอกสารของฝ่ายเรา ทำให้ดูเหมือนว่าเอกสารของเราเป็นของปลอม ดังนั้น forensic investigator จึงควรระวังตรงจุดนี้ไว้ สำหรับวิธีการรับมือกับการปลอมเวลาการสร้างไฟล์ PDF นั้นสามารถทำได้โดยการทำ construct timeline ของ activitity ของไฟล์บนระบบ ซึ่งถ้า activity timeline ไม่ตรงกับเวลาที่ไฟล์ถูกสร้างขึ้น เราจะสร้างใช้ข้อมูลตรงจุดนี้ทำการแย้งได้ (วิธีนี้จะใช้ได้ผลก็ต่อเมื่อค่า MAC ของไฟล์บนระบบไม่ถูกปลอมแปลงให้สัมพันธ์กับค่า metadata ของไฟล์ PDF)

P.S. การแก้ไขค่า metadata ของไฟล์ PDF จะทำให้ค่า checksum ของไฟล์เปลี่ยนไปด้วย ดังนั้นเราจึงควรเก็บ checksum ของไฟล์เราไว้ด้วยเสมอ

วันพฤหัสบดีที่ 10 พฤษภาคม พ.ศ. 2550

ความสำคัญของ Audit Process Tracking

หากใครทำการปรับแต่ง Log ของระบบปฏิบัติการ Windows ก็คงจะพบคุ้นเคยกับคำว่า Audit Process Tracking กันมาบ้าง เจ้า Audit Policy ตัวนี้จะทำการเก็บล็อคข้อมูลของโปรเซสที่ทำงานบนระบบ ซึ่งโดยปกติแล้วเราก็ไม่ได้สนใจแล้ว Audit Policy ตัวนี้กันสักเท่าไหร่ (เพราะปกติจะสนใจแต่ Logon/Logoff น่ะนะ)

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

หลังจากที่ทำการ enable Audit Process Tracking แล้ว เราสามารถทำการเรียกดูโปรเซสที่เกิดขึ้นได้ด้วยคำสั่งของ Microsoft Log Parser ดังนี้

C:\Program Files\Log Parser 2.2>LogParser -i:EVT -o:DATAGRID
"select EventID,
EXTRACT_TOKEN(Strings, 0, '|') AS ProcessID,
EXTRACT_TOKEN(Strings, 1, '|') AS ProcessName,
EXTRACT_TOKEN(Strings, 2, '|') As ParentProcessID,
EXTRACT_TOKEN(Strings, 3, '|') AS User
from security where eventid in (592)"

ผลลัพธ์ที่ได้เป็นดังภาพ

Photo Sharing and Video Hosting at Photobucket

คำสั่งของ LogParser ดังกล่าวเป็นการแสดงโปรเซสที่เกิดขึ้นบนระบบ (EventID คือ 592) ซึ่งจะแสดงหมายเลขโปรเซส (ProcessID), ชื่อของโปรเซส (ProcessName), หมายเลขของโปรเซสที่ทำการเรียกโปรเซสนั้น (ParentProcessID) และชื่อของผู้ใช้ที่ทำการรันโปรเซสนั้น (User)

หากต้องการทราบว่าโปรเซสใดที่จบการทำงานไป สามารถทำได้โดยการกำหนดหมายเลข EventID เป็น 593

การเปิดใช้งาน Audit Process Tracking มีประโยชน์มากสำหรับระบบที่เป็น honeypot เนื่องจาก honeypot นั้นจะเกิดประโยชน์สูงสุดก็ต่อเมื่อตัว honeypot เองนั้นถูกบุกรุก เช่นเดียวกับเจ้า Audit Policy ตัวนี้ที่จะเกิดประโยชน์สูงสุดเช่นกันหลังจากเกิดเหตุการณ์บุกรุกขึ้นแล้ว :)

วันพุธที่ 2 พฤษภาคม พ.ศ. 2550

การกำจัด malware ที่ใช้เทคนิค DLL injection

เนื่องจากเมื่อวานไปเจอ malware ที่ใช้ DLL injection เข้าไปยัง process ของระบบ ก็เลยมาเล่าสู่กันฟังครับ (ความจริงเขียนไว้กันลืมตะหาก 555) แต่ก่อนที่เล่าถึง malware ตัวดังกล่าว จะขออธิบายก่อนสักเล็กน้อยว่า DLL injection นั้นคืออะไร

DLL injection เป็นเทคนิคที่นักเขียน malware นิยมนำมาใช้ในการฝัง malicious code ในระบบ โดย malicious code ที่ทำการฝังลงไปนั้นจะอยู่ในรูปของ DLL ซึ่งจะถูกฝังเข้าไปยัง process ที่ทำงานอยู่ในระบบเช่น explorer.exe ซึ่งถ้าหาก incident handler ไม่ได้ทำการตรวจสอบ DLL ที่แต่ละ process ทำการโหลด ก็จะไม่ทราบว่าระบบถูกฝัง malware ลงไป เนื่องจาก malware ที่ใช้วิธีนี้เวลาทำงาีนจะไม่ทำการสร้าง process ใหม่ แต่จะสร้าง thread จาก process เดิม ซึ่งไม่สามารถมองเห็นด้วย task manager

เรื่องเริ่มขึ้นเมื่อเครื่องของชาวบ้านคนหนึ่ง หลังจากที่ทำการเปิดเครื่อง nod32 จะทำการแจ้งเตือนทุกครั้ง

Photo Sharing and Video Hosting at Photobucket

ข้อความแจ้งเตือนดังกล่าวเป็นการบอกว่า explorer.exe ได้ทำการสร้าง malware ขึ้นมา ??!

เมื่อทำการสำรวจ process ที่รันอยู่พบว่ามี explorer.exe รันอยู่เพียงโปรเซสเดียวเท่านั้น ซึ่งเป็น explorer.exe ของระบบ แต่เมื่อเรียกดู DLL ที่ explorer.exe ทำการโหลดเข้าไปนั้นพบว่ามี DLL ที่แปลกประหลาดอยู่

Photo Sharing and Video Hosting at Photobucket

DLL ที่แปลกประหลาดคือ DLL ที่ถูกไฮไลต์ด้วยสีม่วง ซึ่งเป็น DLL ที่ถูก packed หรือทำการเข้ารหัส เมื่อใช้ nod32 ทำการแสกน DLL เหล่านี้ก็ไม่พบความผิดปกติแต่อย่างไร

เมื่อได้รายชื่อของ DLL ที่น่าสงสัย ขั้นตอนต่อไปคือนำรายชื่อของ DLL เหล่านี้ไปคำการค้นหาในตำแหน่ง Auto-Start ต่างๆใน registry key ซึ่งจากการค้นหาพบว่ารายชื่อของ DLL เหล่านี้ปรากฏอยู่ใน

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify


ผมจึงได้ทำการลบ registry key ที่มีชื่อของ malicious DLL ทิ้งไปแล้วทำการ reboot ระบบ แต่เมื่อทำการล็อกอินเข้ามาใหม่พบว่า nod32 ยังคงแจ้งเตือนเหมือนเดิม แต่ชื่อของไฟล์เปลี่ยนไป ผมจึงได้ทำการตรวจสอบ explorer.exe ใหม่อีกครั้ง และพบว่ายังคงถูก DLL inject เข้าไปเหมือนเดิม โดยรายชื่อ malicious DLL นั้นจะมีชื่อที่เหมือนเดิม 2 ไฟล์คือ

ssqolij.dll
vturp.dll

ทั้ง 2 ไฟล์อยู่ใน directory C:\WINDOWS\system32 สำหรับ malicious DLL ตัวอื่นนั้นชื่อจะ random เปลี่ยนไปเรื่อยๆ

ผมจึงได้ทำการ monitoring การเข้าถึง registry key เพื่อทำการตรวจสอบว่ามี process ใดเข้าถึง registry key ของ ssqolij.dll หลังจากที่ทำการลบ key เหล่านี้ทิ้งไป ซึ่งพบว่า winlogon.exe ซึ่งเป็น process ของระบบ (ดูจาก process tree) มีการเรียกดู registry key เหล่านี้ตลอดเวลา และเมื่อใดก็ตามที่ทำการลบ registry key เหล่านี้ทิ้งไป winlogon.exe ก็จะทำการสร้าง key ก็จะทำการสร้าง key ขึ้นมาใหม่ นี่จึงเป็นสาเหตุที่ว่าทำไม registry key เหล่านี้กลับมาอยู่ในระบบ

นอกจากนี้ผมได้ทำการสำรวจ DLL ที่ winlogon.exe ทำการโหลดเข้ามาในระบบ พบว่า winlogon.exe ถูก DLL injection เหมือนกัน ซึ่งมี 2 ไฟล์หลักคือ ssqolij.dll และ vturp.dll

เนื่องจาก winlogon.exe เป็น process ที่ทำหน้าที่เกี่ยวกับการล็อกอินของระบบ หากเราทำการ kill process นี้ไปจะทำให้เกิดอาการจอฟ้า ดังนั้นผมเลือกที่จะทำการ suspend winlogon.exe ซึ่งปรากฏว่าได้ผล กล่าวคือไม่มีการเข้าถึง registry key จาก winlogon.exe อีก ในขณะเดียวกันระบบก็ไม่ขึ้นจอฟ้า ซึ่งทำให้ผมสามารถทำงานต่อไปได้

เมื่อหยุด winlogon.exe ได้ ผมจึงทำการลบ regiskey key ทิ้งไป จากนั้นใช้ movefile ทำการกำหนด schedule ให้ทำการลบ malicious DLL ทิ้งไปหลังจากที่ระบบทำการ reboot ใหม่ พบว่า malicious DLL ได้ถูกลบไป และ winlogon.exe และ explorer.exe ก็ไม่ถูก DLL injection อีกต่อไป :)

P.S. พอดี capture รูปมาไม่ครบน่ะนะ แหะๆ

วันศุกร์ที่ 27 เมษายน พ.ศ. 2550

ว่าด้วยเรื่องของ MAC times

หนึ่งในวิธีที่บรรดา incident handler นิยมทำกันในการสืบสวนอาชญากรรมคอมพิวเตอร์คือ การดู timeline ที่เกิดขึ้นบนระบบว่ามีไฟล์ใดถูกสร้างหรือถูกเปลี่ยนแปลงก่อน - หลังจากที่เกิดเหตุการณ์บุกรุกบ้าง การสร้าง timeline จะช่วยให้ incident handler สามารถลำดับเหตุการณ์ต่างๆที่เกิดขึ้นในระบบได้มีประสิทธิภาพมากขึ้น

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

การเรียกดู MAC times บนระบบปฏิบัติการ Windows สามารถทำได้โดยใช้คำสั่ง dir /TW, dir /TA และ dir /TC ตามลำดับ ตัวอย่างผลลัพธ์ของการเรียกดูเวลาที่ไฟล์ถูกสร้างขึ้นแสดงดังข้างล่าง

C:\Documents and Settings\Trirat\Desktop\Sysinternals>dir /TC
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

04/24/2007 11:34 AM DIR .
04/24/2007 11:34 AM DIR ..
04/24/2007 11:31 AM 475,790 Autoruns.zip
04/24/2007 11:51 AM 1,539,243 ProcessExplorer.zip
04/24/2007 11:44 AM DIR PsTools
04/24/2007 11:40 AM 1,022,681 PsTools.zip

ถึงแม้ว่าการสร้าง timeline ของเหตุการณ์จาก MAC times จะเป็นเครื่องอำนวยความสะดวกให้กับ incident handler แต่ทว่าความน่าเชื่อถือของ MAC times นั้นเป็นสิ่งที่ incident handler ควรระมัดระวังเนื่องจาก MAC times ของไฟล์ต่างๆนั้นสามารถปลอมแปลงได้ !!?

เครื่องมือที่ใช้สำหรับปลอมแปลง MAC times มีอยู่มากมาย แต่ในที่นี้จะใช้เครื่องมือจาก Metasploit Anti-Forensics Project ที่ชื่อว่า timestomp

C:\Documents and Settings\Trirat\Desktop\Sysinternals> dir /TC PsTools.zip
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

04/24/2007 11:40 AM 1,022,681 PsTools.zip

C:\Documents and Settings\Trirat\Desktop\Sysinternals> timestomp.exe PsTools.zip -c "Sunday 1/1/2007 1:11:11 AM"

C:\Documents and Settings\Trirat\Desktop\Sysinternals> dir /TC PsTools.zip
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

01/01/2007 01:11 AM 1,022,681 PsTools.zip

จากตัวอย่างข้างบนแสดงการใช้งาน timestomp สังเกตว่าก่อนการใช้ timestomp นั้นเวลาที่ไฟล์ PsTools.zip ถูกสร้างขึ้นคือวันที่ 04/07/2007 เวลา 11.40 หลักจากนั้นจึงใช้ timestomp ทำการปลอมแปลงเวลาที่ไฟล์ถูกสร้างขึ้นให้เป็นวันที่ 01/01/2007 เวลา 01:11

เนื่องด้วยการปลอมแปลง MAC times สามารถทำได้อย่างง่ายดาย ดังนั้น incident handler จึงควรระมัดระวังตรงจุดนี้ไว้ :)