การกระทำเชิง Incident Response ในส่วน Investigation นั้นเป็นการหา event ใดๆที่มันผิดปกติขึ้นในระบบของเรา เราสามารถใช้ command และเครื่องมือต่างๆมากมายที่จะสืบค้นหาข้อมูลในเครื่องที่ “คาดว่า” จะเกิด incident ซึ่งนั่นคือสิ่งที่เราจะพูดกันในโพสต์นี้

Event คือสิ่งที่เกิดขึ้นกับระบบใดๆ ไม่ว่าจะเป็นทางใดๆก็แล้วแต่ ปกติหรือไม่ปกติ ก็ถือเป็น event ทั้งนั้น ส่วน Incident เป็นเหตุการณ์ที่ทำให้ระบบนั้นเสียหาย ไม่เพียงแค่เป็นการกระทำที่ถูก hack เท่านั้น อะไรก็แล้วแต่ที่ทำให้เกิดผลกระทบกับธุรกิจก็ถือว่าเป็น Incident ทั้งสิ้น เช่น Harddisk เต็มทำให้ service crash, การเปิดเว็บไซด์สำหรับโปรโมชั่นแต่ไม่เตรียมรับมือกับผู้เข้าใช้งานที่ดีพอทำให้ระบบช้าจนถึงไม่สามารถเข้าใช้งาน เป็นต้น

ส่วนกระบวนการ Incident Response (IR) นั้นคือขั้นตอนการสืบหาเตรียมพร้อมรับมือกับ incident ที่จะเกิดขึ้น การสืบหาที่มาที่ไป การแก้ไขระบบ จนกระทั่งไปถึงหาทางรับมือ incident นั้นไม่ให้กลับมาเป็นอีก

รูปภาพกระบวนการ Incident Response ของ NIST

อย่างที่บอกไปแล้วสิ่งที่เราจะ focus ในโพสต์นี้คือเรื่องของ Analysis ซึ่งเป็นส่วนที่ 2 ของกระบวนการทั้งหมด โดย IR นั้นมีการวิเคราะห์และสืบหาที่แตกต่างกันไปขึ้นอยู่กับระบบที่จะทำการ Analysis ซึ่งทาง SANS ได้เคยมีการทำ Cheat Sheet ไว้ดังนี้ครับ

ซึ่งถ้าสังเกตุดูดีๆจะพบว่าแม้ command ของทั้งคู่จะแตกต่างกันแต่ยังคงเป็นการมองหา “Event ที่ไม่ปกติ” นั่นเอง โดยการจะทำอย่างนั้นได้จำเป็นต้องรู้ก่อนว่าอะไรที่ปกติ นั่นหมายความว่าเรา “Incident Responsder” หรือจะเรียกว่า “Blue Team” ไม่สามารถยืนยันการตรวจสอบ incident ได้อย่างถูกต้องแบบ 100% ได้เลย หากปราศจากผู้ใช้งานจริง หรือก็คือเหล่า admin ที่เป็นผู้ดูแลระบบต่างๆที่เกิด incident ขึ้นนั่นเอง

Log ที่ต้องมองหาเป็นลำดับแรกๆใน Linux เมื่อเกิด Incident

โดยปกติแล้ว Linux service ต่างๆจะเก็บ log ภายใต้ /var/log/ ซึ่งแน่นอนว่าการเก็บ log ไว้ในเครื่องนั้นเป็นความคิดที่ไม่ดีซักเท่าไหร่ เพราะหากเครื่องถูกแฮ็คเมื่อใด มีความเป็นไปได้ที่ผู้โจมตีอาจจะเข้าไปเปลี่ยนแปลงแก้ไข log รวมถึงการลบ log ภายในเครื่องก็อาจเกิดขึ้นได้เช่นกัน อีกทั้ง log จากเครื่องเหล่านั้นไม่สามารถพิสูจน์ความถูกต้องของข้อมูลได้ ดังนั้นจะไม่สามารถนำไปในชั้นศาลได้อีกด้วย ดังนั้นจึงแนะนำให้ส่ง log ไปเก๊บที่ Centrailize Log Server ข้างนอกมากกว่าครับ จากนั้นสิ่งที่เราที่ควรจะดูก่อนเลยเมื่อ Linux เกิดเหตุการณ์ผิดปกติคือ

  • หาก่อนเลยว่ามีใครเข้าระบบของเราจาก IP ที่มันผิดปกติหรือไม่ โดยดูจาก ssh log เช่น
  • มีการพยายามเข้าระบบของเราโดย failed เยอะๆหรือไม่ นั่นคือสัญญาณว่าเราอาจถูก brute force อยู่
  • หาเกี่ยวกับ event การเปลี่ยนแปลงใดๆที่เกี่ยวกับ user
  • การพยายามใช้คำสั่ง sudo ใดๆที่พยายามเพื่อให้ได้สิทธิ์ที่สูงขึ้น

  • Service ใดๆที่เกิด failure
จริงๆยังมีอีกมากมายที่จำเป็นต้องตรวจสอบนะครับ แต่ผมพยายามพูดถึงเรื่อง log analysis เป็นหลัก ดังนั้นจะไม่พูดถึงเรื่องการตรวจสอบส่วนอื่น เช่น process, schedule job เป็นต้น แนะนำให้ดู Cheat Sheet ของ Linux IR ที่ SANS ทำขึ้นมาก็ถือว่าครบถ้วนดีครับ

Log ที่ต้องมองหาเป็นลำดับแรกๆใน Windows เมื่อเกิด Incident

อย่างที่กล่าวไว้ในส่วนการวิเคราะห์ log ของ Linux คือการเก็บ Log ไว้บนเครื่องเป็นส่วนที่ไม่น่าทำนัก ซึ่ง Linux ยังดีที่มี syslog builtin ไว้ ดังนั้นการส่ง log ออกมาข้างนอกนั้นสามารถทำได้ไม่ยากแต่ประเด็นคือ Windows นั้นไม่ได้เป็นแบบนั้น การจะส่ง log ออกมาจาก Windows จำเป็นต้องติดตั้ง Log agent เพิ่มเติมเช่น Snare เป็นต้น โดย Windows Event Log ที่เรามักจะดูกันมีดังนี้

  • หาก่อนเลยว่ามีใครเข้าระบบของเราจาก IP ที่มันผิดปกติหรือไม่ โดยดูจาก Log ของ Security ที่มี Event ID 4624 “Successful Logon”
  • มีการพยายามเข้าระบบของเราโดย failed เยอะๆหรือไม่ โดยดูจาก Log ของ Security ที่มี Event ID 4625 “Failed Login”
  • มีการสร้าง account ใหม่หรือไม่ โดยดูจาก Log ของ Security ที่มี Event ID 4720 “A user account was created”
  • มีการ add user เข้าไปในกลุ่ม Group Security อย่าง Administrator group โดยดูจาก Log ของ Security ที่ม่ี Event ID เป็น 4732
  • การพยายามสร้าง service ใหม่แต่ failure โดยดูจาก log ของ System มี Event ID เป็น 7030
  • การพยายามสร้าง service ใหม่สำเร็จ โดยดูจาก log ของ System มี Event ID เป็น 7045

เราสามารถใช้คำสั่ง wevtutil ในการ query log ของเครื่องได้

จากตัวอย่างคือ query log System ที่มี Event ID = 4720 โดยแสดงผล 5 event, output ออกเป็น text และมีการ sort ตามเวลาการเกิด log

เราสามารถใช้ wmic command ในการ query ข้อมูลของ process ที่น่าสนใจได้เช่นกัน โดยใช้คำสั่ง

เป็นการแสดงผล ชื่อ, processID, Parent Process ID โดยจะ filter ผลลัพธ์ตาม PID ที่เรากำหนด

หากเราจะดู startup tasks สามารถทำได้โดยใช้คำสั่ง

ส่วนที่เหลือของ Windows Analysis ลองตรวจสอบด้วย Cheat Sheet ของ SANS ดูครับ

สรุป

Event ใดๆที่เราหามาได้นั้นไม่สำคัญหากเราไม่สามารถที่จะแยกแยะได้ว่า Event ใดเป็น Event ปกติหรือ Event ที่ผิดปกติ ดังนั้นการทำ Change ใดๆจึงเป็นสิ่งสำคัญ การทำ Chang Management เป็นช่องทางหนึ่งที่ทำให้เราสามารถแยกแยะการทำงานปกติ อีกทั้ง Knowledge base เกี่ยวกับระบบใดๆที่เราทำ Analysis เป็นสิ่งที่สำคัญ อย่าลืมเตรียมตัวก่อนออกสู่สนามรบเสมอครับ

Source::

  • https://jordanpotti.com/2017/01/20/basics-of-windows-incident-response/
  • https://jordanpotti.com/wp-content/uploads/2017/01/linux-cheat-sheet.pdf
  • https://jordanpotti.com/wp-content/uploads/2017/01/windows-cheat-sheet.pdf