Windows Event Log Analysis & Threat Hunting Fundamentals วิเคราะห์ Windows Security Events, Sysmon และ PowerShell Logs เพื่อค้นหาพฤติกรรมการโจมตีด้วยหลักฐานจริง

8 พ.ย. 2569 Cyber Security Defensive Security DFIR Event Log Analysis SOC Sysmon Threat Hunting Windows Security

Windows Event Log Analysis & Threat Hunting Fundamentals — วิเคราะห์ Security Events และค้นหาภัยคุกคามด้วย Sysmon และ PowerShell

สมมติว่าผู้ดูแลระบบพบการเข้าสู่ระบบ ไม่สำเร็จหลายครั้งบน Windows Server หลังจากนั้นไม่นาน กลับพบการเข้าสู่ระบบ สำเร็จจากแหล่งที่มาซึ่งไม่คุ้นเคย

เหตุการณ์นี้คือการโจมตีหรือไม่? บัญชีผู้ใช้อาจถูกขโมยรหัสผ่านหรือเปล่า? หรือเป็นเพียงผู้ใช้งานที่พิมพ์รหัสผ่านผิด ก่อนเข้าสู่ระบบสำเร็จตามปกติ?

การตอบคำถามเหล่านี้ต้องอาศัยหลักฐาน จาก Windows Event Logs และการวิเคราะห์ความสัมพันธ์ ระหว่างเหตุการณ์หลายรายการ

ในบทความนี้ Techerest จะพาคุณเรียนรู้ตั้งแต่ Windows Security Event IDs, Sysmon, PowerShell Log Analysis, Event Correlation และ IOC Hunting ไปจนถึงการสร้าง Detection Rules พร้อม Hands-on Safe Lab ที่สามารถนำไปทดลองได้จริง

เป้าหมายคือเปลี่ยนจากการอ่าน Log เป็นครั้งคราว ไปสู่การคิดอย่าง Security Analyst ที่สามารถตั้งสมมติฐาน ค้นหาหลักฐาน ประเมินความเสี่ยง และอธิบายผลการตรวจสอบ ได้อย่างเป็นระบบ

1. Windows Event Logs คืออะไร?

Windows Event Logs เป็นระบบบันทึกเหตุการณ์ของ Windows ที่จัดเก็บข้อมูลการทำงานของระบบ แอปพลิเคชัน และเหตุการณ์ ที่เกี่ยวข้องกับความปลอดภัย

ข้อมูลเหล่านี้ช่วยให้ผู้ดูแลระบบ ตรวจสอบสิ่งที่เกิดขึ้นย้อนหลัง วิเคราะห์ปัญหา และสืบค้น กิจกรรมที่อาจเกี่ยวข้องกับการโจมตี

1.1 ประเภทของ Windows Event Logs

Log	หน้าที่
Security	การเข้าสู่ระบบ การเปลี่ยนสิทธิ์ และเหตุการณ์ Audit
System	บริการ Driver และเหตุการณ์ระบบปฏิบัติการ
Application	เหตุการณ์จากแอปพลิเคชัน
PowerShell Operational	เหตุการณ์ที่เกี่ยวข้องกับ PowerShell
Sysmon Operational	Process, Network, File และกิจกรรมอื่นตามการตั้งค่า

1.2 Windows Event Viewer

บน Windows 11 สามารถเปิด Event Viewer โดยกด Windows + R แล้วพิมพ์

eventvwr.msc

จากนั้นเปิด Windows Logs และเลือก Security, System หรือ Application ตามต้องการ

สำหรับ Sysmon และ PowerShell ให้ดูใน Applications and Services Logs ภายใต้ชื่อ Provider ที่เกี่ยวข้อง

1.3 Event Log มีข้อมูลอะไรบ้าง?

Event ID: ประเภทเหตุการณ์
TimeCreated: เวลาที่บันทึกเหตุการณ์
Provider: แหล่งกำเนิด Event
Computer: เครื่องที่บันทึก Event
Record ID: หมายเลขรายการใน Event Log
EventData: รายละเอียดเฉพาะของเหตุการณ์

Event ID เดียวกันอาจมีความหมายต่างกัน เมื่ออยู่คนละ Provider จึงควรพิจารณา Provider และ Channel ร่วมกับ Event ID เสมอ

2. Windows Security Event IDs ที่ Security Analyst ควรรู้

Windows Security Log มีเหตุการณ์หลายประเภท แต่ผู้เริ่มต้นสามารถเริ่มจาก Event IDs ที่เกี่ยวข้องกับ Authentication, Privileges, Process และ Security Configuration

2.1 Authentication Events

Event ID	ความหมาย
4624	เข้าสู่ระบบสำเร็จ
4625	เข้าสู่ระบบไม่สำเร็จ
4634	Logon Session สิ้นสุด
4648	พยายามเข้าสู่ระบบด้วย Explicit Credentials
4740	บัญชีถูก Lockout

2.2 Privilege และ Account Events

Event ID	ความหมาย
4672	Special Privileges Assigned to New Logon
4720	สร้างบัญชีผู้ใช้
4726	ลบบัญชีผู้ใช้
4732	เพิ่มสมาชิกใน Security-Enabled Local Group
4719	System Audit Policy ถูกเปลี่ยน

2.3 Process และ Persistence Events

Event ID	ความหมาย
4688	Process ถูกสร้าง
4697	Service ถูกติดตั้ง
4698	Scheduled Task ถูกสร้าง
4663	มีการเข้าถึง Object ที่อยู่ภายใต้ Audit
1102	Security Audit Log ถูกล้าง

Event บางรายการต้องเปิด Audit Policy หรือกำหนดการตรวจสอบเพิ่มเติม จึงจะปรากฏในระบบ

2.4 Windows Event IDs ไม่ใช่ Malware Signatures

ตัวอย่างเช่น Event 4688 ที่แสดงการเรียกใช้งาน PowerShell ไม่ได้แปลว่ามีการโจมตี

PowerShell เป็นเครื่องมือบริหารระบบปกติ ซึ่งทั้ง Administrator และผู้โจมตีสามารถใช้งานได้

ต้องพิจารณาว่าใครเรียกใช้งาน เรียกจาก Process ใด ใช้ Command Line อะไร และเกิดขึ้นในบริบทใด

3. Windows Logon Types — วิเคราะห์การเข้าสู่ระบบ

Event ID 4624 มีข้อมูล Logon Type ซึ่งช่วยอธิบายลักษณะการเข้าสู่ระบบ

3.1 Logon Types ที่สำคัญ

Type	ความหมาย
2	Interactive Logon
3	Network Logon
4	Batch Logon
5	Service Logon
7	Unlock
10	RemoteInteractive เช่น RDP
11	CachedInteractive

3.2 ตัวอย่างการวิเคราะห์ RDP

สมมติพบ Event ID 4624 ที่มี Logon Type 10 บน Windows Server

ข้อมูลนี้อาจสัมพันธ์กับ Remote Desktop Logon แต่ไม่เพียงพอที่จะยืนยัน ว่ามีผู้โจมตีเข้าระบบ

ควรตรวจสอบ Account, Source Network Address, TimeCreated, Logon ID และนโยบายการเข้าถึงจากระยะไกล

3.3 Correlate Event 4624 กับ 4672

Event ID 4672 อาจเกิดขึ้น เมื่อ Logon Session ได้รับ Special Privileges

สามารถใช้ Logon ID และข้อมูลบริบทอื่น เชื่อมโยงกับ Event 4624 บนเครื่องเดียวกันได้

แต่ Event 4672 เพียงรายการเดียว ไม่ได้ยืนยันว่าเกิด Privilege Escalation เพราะบัญชีผู้ดูแลระบบ อาจได้รับสิทธิ์เหล่านี้ตามปกติ

4. Sysmon — เพิ่มความสามารถในการมองเห็นกิจกรรมระบบ

System Monitor หรือ Sysmon เป็นเทคโนโลยีสำหรับบันทึก กิจกรรมระดับระบบบน Windows

Sysmon สามารถเพิ่มรายละเอียด ที่มีประโยชน์ต่อ Threat Hunting เช่น Process GUID, Parent Process, File Hash และ Network Connections

Sysmon ไม่ใช่ Antivirus และไม่ได้ป้องกัน Malware โดยตรง แต่เป็นแหล่ง Telemetry สำหรับการวิเคราะห์และตรวจจับ

4.1 Sysmon Event IDs ที่สำคัญ

Event ID	Event
1	Process Create
3	Network Connection
5	Process Terminate
7	Image Loaded
8	CreateRemoteThread
10	Process Access
11	File Create
12–14	Registry Events
22	DNS Query
23	File Delete Archived
25	Process Tampering
26	File Delete Detected

4.2 Sysmon Event ID 1 — Process Create

ช่วยตรวจสอบการสร้าง Process และความสัมพันธ์กับ Parent Process

ตัวอย่างเช่น ถ้า Application ที่ปกติใช้เปิดเอกสาร สร้าง Command Interpreter โดยไม่คาดคิด อาจเป็นเหตุผลให้เริ่มตรวจสอบเพิ่มเติม

4.3 Sysmon Event ID 3 — Network Connection

ใช้บันทึกข้อมูลการเชื่อมต่อเครือข่าย ที่เกี่ยวข้องกับ Process ตามการตั้งค่า Sysmon

Event ID 3 ไม่ได้เปิดเก็บทุกกรณี โดยอัตโนมัติในทุกการติดตั้ง และอาจสร้าง Log จำนวนมาก

4.4 Sysmon Event ID 22 — DNS Query

ช่วยระบุว่า Process ใด มีการ Query ชื่อโดเมน ตามความสามารถและการตั้งค่าของระบบ

ข้อมูลนี้อาจช่วยในการตรวจสอบ IOC และกิจกรรมที่เชื่อมโยง กับโครงสร้างพื้นฐานภายนอก

4.5 การติดตั้ง Sysmon

Windows บางรุ่นมี Sysmon เป็นความสามารถในระบบ ขณะที่อีกแนวทางหนึ่งคือ Sysmon จาก Microsoft Sysinternals

ควรตรวจสอบรุ่น Windows และเอกสารผู้ผลิตก่อนติดตั้ง โดยไม่ควรสมมติว่า Sysmon เปิดใช้งานอยู่แล้วทุกเครื่อง

สำหรับ Sysmon จาก Sysinternals ให้ใช้เครื่องมือจาก Microsoft และ Configuration ที่ผ่านการตรวจสอบ

sysmon64.exe -accepteula -i sysmon-config.xml

คำสั่งนี้เป็นตัวอย่าง สำหรับ Sysinternals Sysmon และต้องมี Configuration File ที่ถูกต้องอยู่ในตำแหน่งที่ระบุ

ควรทดลองบน VM หรือเครื่อง Lab ก่อนใช้กับ Production และระวังการติดตั้งซ้ำ เมื่อมี Sysmon อีกชนิดใช้งานอยู่แล้ว

4.6 ตรวจสอบ Sysmon Log

Sysmon Operational Log มักอยู่ใน Channel

Microsoft-Windows-Sysmon/Operational

สำหรับระบบที่รองรับ Channel นี้ สามารถอ่าน Event ได้ด้วย

Get-WinEvent -LogName `
  "Microsoft-Windows-Sysmon/Operational" `
  -MaxEvents 20

หากไม่พบ Channel อาจยังไม่ได้ติดตั้งหรือเปิดใช้งาน Sysmon ในรูปแบบดังกล่าว

5. PowerShell Logging สำหรับ Security Investigation

PowerShell เป็นเครื่องมือสำคัญ สำหรับการดูแลระบบ Windows และงาน Automation

ในด้าน Cyber Security การบันทึกกิจกรรม PowerShell ช่วยตรวจสอบคำสั่งและ Script ที่ถูกเรียกใช้งาน

5.1 PowerShell Event ID 4104

Event ID 4104 เกี่ยวข้องกับ PowerShell Script Block Logging

เมื่อเปิด Logging ที่เกี่ยวข้อง ระบบอาจบันทึกเนื้อหา Script Block เพื่อสนับสนุนการตรวจสอบย้อนหลัง

5.2 PowerShell Log Channels

Windows PowerShell 5.1 มักใช้ Channel

Microsoft-Windows-PowerShell/Operational

สำหรับ PowerShell 7 อาจใช้ PowerShellCore/Operational ตามการลงทะเบียน Provider และการตั้งค่าระบบ

5.3 ตรวจสอบ PowerShell Events

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-PowerShell/Operational"
    Id = 4104
    StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 20 |
Select-Object TimeCreated, Id, Message

5.4 ข้อควรระวังเรื่อง Sensitive Data

Script Block Logging อาจบันทึกข้อมูลสำคัญ ที่ปรากฏอยู่ใน Script หรือ Command

ควรกำหนด Access Control, Log Retention และการจัดการข้อมูลลับ ก่อนนำ Logging ไปใช้กับองค์กร

6. Threat Hunting คืออะไร?

Threat Hunting คือกระบวนการค้นหา พฤติกรรมหรือหลักฐานของภัยคุกคาม เชิงรุก โดยไม่จำเป็นต้องรอให้ ระบบตรวจจับแจ้งเตือนก่อน

Threat Hunting ที่ดี เริ่มจากคำถามหรือสมมติฐาน ที่สามารถตรวจสอบได้ด้วยข้อมูล

6.1 Threat Hunting กับ Alert Investigation

Alert Investigation เริ่มจากสัญญาณเตือนที่ระบบตรวจพบ แล้วตรวจสอบว่าเหตุการณ์นั้น เป็นภัยคุกคามจริงหรือไม่

Threat Hunting มักเริ่มจากสมมติฐาน เกี่ยวกับพฤติกรรมที่อาจซ่อนอยู่ และค้นหาหลักฐานสนับสนุนหรือหักล้าง

6.2 ตัวอย่าง Hunting Hypothesis

อาจมีบัญชีผู้ใช้ที่ถูกพยายามเข้าสู่ระบบ หลายครั้งก่อนมีการเข้าสู่ระบบสำเร็จ จากแหล่งที่มาซึ่งไม่เคยใช้งานมาก่อน

สมมติฐานนี้สามารถทดสอบได้ ด้วย Authentication Logs และข้อมูลบริบทของผู้ใช้งาน

6.3 Hunting Workflow

Define Hypothesis
Identify Data Sources
Collect Relevant Events
Filter and Normalize
Correlate Evidence
Investigate Anomalies
Assess Findings
Document and Improve Detection

7. PowerShell Log Analysis — อ่านและกรอง Security Events

PowerShell มีคำสั่ง Get-WinEvent สำหรับอ่าน Windows Event Logs และไฟล์ Log ที่จัดเก็บไว้

7.1 ตรวจสอบ Events ล่าสุด

Get-WinEvent -LogName Security `
  -MaxEvents 20 |
Select-Object TimeCreated, Id, ProviderName

การอ่าน Security Log อาจต้องใช้สิทธิ์ที่เหมาะสม ตามการกำหนดค่าของเครื่อง

7.2 ตรวจสอบ Failed Logons

Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4625
    StartTime = (Get-Date).AddHours(-24)
} -MaxEvents 100 |
Select-Object TimeCreated, Id, Message

7.3 ตรวจสอบ Successful Logons

Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4624
    StartTime = (Get-Date).AddHours(-24)
} -MaxEvents 100 |
Select-Object TimeCreated, Id, Message

7.4 นับ Events ตาม Event ID

Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4624, 4625, 4688
    StartTime = (Get-Date).AddHours(-24)
} -MaxEvents 1000 |
Group-Object Id |
Select-Object Name, Count

การใช้ MaxEvents 1000 หมายถึงวิเคราะห์เฉพาะ Events ที่ถูกดึงออกมา ไม่ใช่จำนวนทั้งหมดของวัน หากมี Events มากกว่าขีดจำกัด

7.5 Export Events เป็น CSV

$Events = Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4624, 4625
    StartTime = (Get-Date).AddHours(-1)
} -MaxEvents 200

$Events |
Select-Object TimeCreated, Id, MachineName, RecordId |
Export-Csv -Path "$HOME\security-events.csv" `
  -NoTypeInformation -Encoding UTF8

คำสั่งนี้ส่งออกข้อมูลบางส่วน สำหรับการวิเคราะห์ใน Spreadsheet หรือ Python

Security Logs อาจมีข้อมูลส่วนบุคคล และข้อมูลเกี่ยวกับระบบภายใน จึงไม่ควรเผยแพร่โดยไม่ได้รับอนุญาต

7.6 อ่าน Named EventData จาก XML

การแยกข้อมูลจาก Event XML มีความเสถียรกว่าการค้นข้อความ จาก Message ที่อาจเปลี่ยนตามภาษา และเวอร์ชันของระบบ

$Event = Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4624
} -MaxEvents 1

[xml]$Xml = $Event.ToXml()

$Data = @{}

foreach ($Item in $Xml.Event.EventData.Data) {
    $Data[[string]$Item.Name] = $Item.'#text'
}

[PSCustomObject]@{
    Time = $Event.TimeCreated
    User = $Data["TargetUserName"]
    LogonType = $Data["LogonType"]
    SourceIP = $Data["IpAddress"]
}

หากไม่พบ Event 4624 หรือ Event Schema แตกต่างจากตัวอย่าง ต้องตรวจสอบข้อมูลจริงก่อนใช้งาน

บาง Event อาจไม่มี IpAddress หรือมีค่าเป็นเครื่องหมายขีด จึงไม่ควรสมมติว่าฟิลด์นี้ ต้องมีข้อมูลทุกครั้ง

8. Event Correlation — เชื่อมโยงเหตุการณ์เข้าด้วยกัน

Event Correlation คือการนำเหตุการณ์หลายรายการ มาเชื่อมโยงโดยใช้ข้อมูลร่วมกัน เช่น Account, Host, Source IP, Process GUID และช่วงเวลา

8.1 ตัวอย่าง Login Correlation

สมมติข้อมูลจำลองแสดงว่า

10:00:01 | 4625 | userA | 192.0.2.10
10:00:08 | 4625 | userA | 192.0.2.10
10:00:16 | 4625 | userA | 192.0.2.10
10:00:23 | 4624 | userA | 192.0.2.10

เหตุการณ์นี้แสดงการเข้าสู่ระบบ ไม่สำเร็จสามครั้ง ตามด้วยการเข้าสู่ระบบสำเร็จ

แต่ยังไม่สามารถสรุปว่า บัญชีถูกโจมตีสำเร็จ

เพราะอาจเป็นผู้ใช้งานจริง ที่พิมพ์รหัสผ่านผิด ก่อนเข้าสู่ระบบสำเร็จ

8.2 Correlation Fields

Account Name และ Domain
Source IP
Destination Host
Timestamp และ Time Zone
Logon Type
Logon ID
Process GUID

8.3 เหตุใดจึงต้องใช้ Time Window?

เหตุการณ์ที่เกี่ยวข้องกัน มักเกิดภายในช่วงเวลาที่ใกล้เคียงกัน แต่การกำหนดช่วงเวลาสั้นเกินไป อาจทำให้พลาดเหตุการณ์

ในทางกลับกัน หากช่วงเวลากว้างเกินไป ก็อาจนำเหตุการณ์ที่ไม่เกี่ยวข้อง มาเชื่อมโยงผิดพลาด

ควรพิจารณา Clock Synchronization, Time Zone, Event Ingestion Delay และพฤติกรรมปกติของระบบด้วย

8.4 Correlation ไม่เท่ากับ Causation

การเกิดเหตุการณ์ใกล้เคียงกัน ไม่ได้หมายความว่าเหตุการณ์หนึ่ง เป็นสาเหตุของอีกเหตุการณ์หนึ่งเสมอไป

ต้องใช้หลักฐานอื่น เพื่อยืนยันความสัมพันธ์จริง

9. IOC Hunting — ค้นหาร่องรอยภัยคุกคาม

Indicators of Compromise (IOC) เป็นข้อมูลที่อาจเกี่ยวข้อง กับการบุกรุกหรือกิจกรรมประสงค์ร้าย

9.1 IOC ที่ใช้กับ Windows

File SHA-256
File Path
Process Name
Command Line Pattern
IP Address
Domain Name
Registry Path
Service หรือ Scheduled Task ที่ต้องสงสัย

9.2 ตัวอย่าง IOC Investigation

สมมติ Threat Intelligence ระบุ IP ตัวอย่าง

198.51.100.25

IP นี้เป็นที่อยู่สำหรับเอกสาร ไม่ใช่ IOC อันตรายจริง

Security Analyst อาจค้นหา IP ใน Firewall Logs, DNS Logs หรือ Sysmon Network Events เพื่อระบุว่ามีการสื่อสาร ที่เกี่ยวข้องหรือไม่

9.3 ข้อจำกัดของ IOC

การพบ IOC ไม่ได้ยืนยันว่า ระบบถูกบุกรุกสำเร็จ และการไม่พบ IOC ก็ไม่ได้หมายความว่า ไม่มีภัยคุกคาม

ต้องประเมินความน่าเชื่อถือของแหล่งข้อมูล อายุของ IOC และบริบทของเหตุการณ์

9.4 IOC กับ Behavior-Based Hunting

IOC Hunting มุ่งค้นหาสิ่งบ่งชี้ ที่ทราบอยู่แล้ว

ส่วน Behavior-Based Hunting มุ่งค้นหาลำดับพฤติกรรม ที่อาจสัมพันธ์กับเทคนิคของผู้โจมตี

การใช้ทั้งสองแนวทางร่วมกัน ช่วยเพิ่มมุมมองในการตรวจสอบ

10. Detection Rules — เปลี่ยนสมมติฐานให้เป็นการตรวจจับ

Detection Rule คือชุดเงื่อนไขสำหรับระบุ เหตุการณ์หรือพฤติกรรม ที่ควรได้รับการตรวจสอบ

10.1 ส่วนประกอบของ Detection Rule

Data Source: แหล่งข้อมูล
Selection: เงื่อนไขค้นหา
Time Window: ช่วงเวลาที่พิจารณา
Threshold: จำนวนหรือระดับที่กำหนด
Exclusions: เงื่อนไขลด False Positive
Severity: ความสำคัญของ Alert
Response: ขั้นตอนเมื่อพบ Alert

10.2 ตัวอย่าง Rule: Multiple Failed Logons

สมมติว่าต้องการตรวจจับบัญชี ที่เข้าสู่ระบบไม่สำเร็จ อย่างน้อยห้าครั้งภายในสิบนาที

Data Source:
Windows Security Event 4625

Group By:
Computer + Account + Source IP

Time Window:
10 Minutes

Threshold:
Failed Logons >= 5

Output:
Suspicious Authentication Activity

ค่า Threshold เป็นเพียงตัวอย่าง สำหรับ Lab และต้องปรับให้เหมาะสม กับปริมาณ Login ปกติขององค์กร

10.3 Sigma Rule คืออะไร?

Sigma เป็นรูปแบบการเขียน Detection Rules ที่สามารถนำไปแปลงใช้กับ ระบบค้นหา Log หรือ SIEM ที่รองรับผ่านเครื่องมือที่เหมาะสม

10.4 ตัวอย่าง Sigma Rule เบื้องต้น

title: Techerest Multiple Failed Logons Base
id: 4c0d83a9-31eb-45fe-87a1-cfa98aa8db02
status: experimental
description: Select Windows failed logon events
author: Techerest

logsource:
  product: windows
  service: security

detection:
  selection:
    EventID: 4625
  condition: selection

fields:
  - TargetUserName
  - IpAddress
  - Computer

falsepositives:
  - Incorrect password entered by users
  - Misconfigured services

level: low

Rule ตัวอย่างนี้ใช้เลือก Failed Logon Events เท่านั้น ยังไม่ได้บังคับเงื่อนไข ห้าครั้งภายในสิบนาที

การนับจำนวนเหตุการณ์ตามช่วงเวลา ต้องทำด้วย Correlation Rule หรือ Query ของ SIEM ที่รองรับความสามารถดังกล่าว

ก่อนใช้งาน Production ควรตรวจสอบ Schema, Field Mapping และ Sigma Version ที่ระบบปลายทางรองรับ

11. Hands-on Safe Lab — สร้างข้อมูล Log จำลอง

Lab นี้ออกแบบให้ผู้เริ่มต้น ทดลอง Threat Hunting ได้ โดยไม่ต้องสร้างเหตุการณ์โจมตีจริง

เราจะใช้ PowerShell สร้างข้อมูลจำลองใน CSV แล้ววิเคราะห์ความสัมพันธ์ ของ Successful และ Failed Logons

11.1 Lab Objectives

สร้าง Synthetic Security Events
อ่านข้อมูล Log ด้วย PowerShell
ตรวจจับ Failed Logon Threshold
เชื่อมโยง Failed กับ Successful Logons
จัดทำ Hunting Findings
แยก Detection ออกจาก Confirmation

11.2 สร้าง Lab Directory

$Lab = Join-Path $HOME "Techerest-ThreatHunting-Lab"

New-Item -ItemType Directory `
  -Path $Lab -Force | Out-Null

11.3 สร้าง Synthetic Events

โค้ดต่อไปนี้สร้างเหตุการณ์จำลอง จำนวนหกรายการ โดยใช้ IP สำหรับเอกสาร และไม่ได้เข้าสู่ระบบจริง

$Base = [datetime]"2026-11-08T10:00:00"

$Events = @(
    [PSCustomObject]@{
        Time = $Base.AddSeconds(0)
        EventID = 4625
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    },
    [PSCustomObject]@{
        Time = $Base.AddSeconds(20)
        EventID = 4625
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    },
    [PSCustomObject]@{
        Time = $Base.AddSeconds(40)
        EventID = 4625
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    },
    [PSCustomObject]@{
        Time = $Base.AddSeconds(60)
        EventID = 4625
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    },
    [PSCustomObject]@{
        Time = $Base.AddSeconds(80)
        EventID = 4625
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    },
    [PSCustomObject]@{
        Time = $Base.AddSeconds(100)
        EventID = 4624
        Computer = "LAB-PC"
        Account = "labuser"
        SourceIP = "192.0.2.10"
    }
)

$CsvPath = Join-Path $Lab "synthetic-events.csv"

$Events |
Export-Csv -LiteralPath $CsvPath `
  -NoTypeInformation -Encoding UTF8

11.4 อ่าน CSV

$Logs = Import-Csv -LiteralPath $CsvPath

$Logs |
Format-Table Time, EventID, Account, SourceIP

Expected Result: แสดงหกเหตุการณ์ โดยเป็น Event 4625 จำนวนห้าครั้ง และ Event 4624 หนึ่งครั้ง

11.5 ตรวจจับ Failed Logon Threshold

$Failed = @(
    $Logs | Where-Object {
        [int]$_.EventID -eq 4625
    }
)

$Groups = $Failed |
Group-Object Computer, Account, SourceIP

$Findings = foreach ($Group in $Groups) {

    $Times = @(
        $Group.Group |
        ForEach-Object {
            [datetime]$_.Time
        } |
        Sort-Object
    )

    if (
        $Times.Count -ge 5 -and
        ($Times[-1] - $Times[0]).TotalMinutes -le 10
    ) {
        [PSCustomObject]@{
            Group = $Group.Name
            FailedCount = $Times.Count
            WindowMinutes = (
                $Times[-1] - $Times[0]
            ).TotalMinutes
            Alert = "Investigate"
        }
    }
}

$Findings | Format-Table -AutoSize

Expected Result: พบกลุ่มเหตุการณ์ห้าครั้ง ในช่วงเวลาไม่เกินสิบนาที

Algorithm นี้ใช้สำหรับข้อมูล Lab ที่มีจำนวนน้อยและเหตุการณ์ไม่ซับซ้อน

สำหรับข้อมูล Production ควรใช้ Sliding Window หรือ Correlation Engine ที่เหมาะสม แทนการพิจารณาเฉพาะเวลา ของ Event แรกและสุดท้ายในแต่ละกลุ่ม

11.6 ตรวจสอบ Successful Logon หลัง Failed Logons

$Success = @(
    $Logs | Where-Object {
        [int]$_.EventID -eq 4624
    }
)

$Correlated = foreach ($Login in $Success) {

    $LoginTime = [datetime]$Login.Time

    $PriorFailures = @(
        $Failed | Where-Object {

            $FailureTime = [datetime]$_.Time

            $_.Computer -eq $Login.Computer -and
            $_.Account -eq $Login.Account -and
            $_.SourceIP -eq $Login.SourceIP -and
            $FailureTime -lt $LoginTime -and
            $FailureTime -ge $LoginTime.AddMinutes(-10)
        }
    )

    if ($PriorFailures.Count -ge 5) {
        [PSCustomObject]@{
            Account = $Login.Account
            SourceIP = $Login.SourceIP
            FailedBeforeSuccess = $PriorFailures.Count
            SuccessTime = $Login.Time
            Status = "Review Required"
        }
    }
}

$Correlated | Format-Table -AutoSize

11.7 วิเคราะห์ผล

ผลจาก Lab ควรแสดงว่า มี Failed Logons ห้าครั้ง ก่อน Successful Logon หนึ่งครั้ง จากบัญชีและ IP เดียวกัน

สถานะที่เหมาะสมคือ Review Required ไม่ใช่ Confirmed Compromise

เพราะข้อมูลจำลองยังไม่มีหลักฐาน ว่าผู้เข้าสู่ระบบเป็นผู้โจมตี

12. IOC Hunting Lab — ตรวจสอบข้อมูลจำลองด้วย PowerShell

ใน Lab นี้จะใช้ข้อมูลจำลอง เพื่อตรวจสอบ IP Address โดยไม่เชื่อมต่อกับระบบภายนอก

12.1 กำหนด IOC จำลอง

$IOC = @(
    "192.0.2.10",
    "198.51.100.25"
)

IP ทั้งสองเป็นที่อยู่สำหรับเอกสาร ไม่ใช่รายการ Threat Intelligence จริง

12.2 ค้นหา IOC จาก Synthetic Events

$Matches = $Logs | Where-Object {
    $_.SourceIP -in $IOC
}

$Matches |
Select-Object Time, EventID, Account, SourceIP |
Format-Table -AutoSize

12.3 วิเคราะห์ผล IOC

ควรพบเหตุการณ์ที่ใช้ IP 192.0.2.10 ส่วน 198.51.100.25 จะไม่พบในข้อมูลจำลองชุดนี้

อย่างไรก็ตามการพบ IP เป็นเพียงการค้นพบข้อมูลตรงเงื่อนไข ไม่ใช่การพิสูจน์ว่ามีภัยคุกคามจริง

13. Threat Hunting ด้วย Sysmon Process GUID

Sysmon Process GUID ช่วยเชื่อมโยงข้อมูล Process ระหว่าง Event หลายประเภท ได้สะดวกกว่าใช้ PID เพียงอย่างเดียว

13.1 ทำไม PID อย่างเดียวไม่เพียงพอ?

Process ID สามารถถูกนำกลับมาใช้ใหม่ หลัง Process เดิมสิ้นสุด

จึงอาจทำให้การเชื่อมโยง เหตุการณ์จากช่วงเวลาห่างกัน เกิดความผิดพลาด

13.2 ตัวอย่าง Process Correlation

ในการตรวจสอบจริง อาจพบ Event ต่อไปนี้

Sysmon ID 1:
Process Created
ProcessGuid = {EXAMPLE-GUID}

Sysmon ID 22:
DNS Query
ProcessGuid = {EXAMPLE-GUID}

Sysmon ID 3:
Network Connection
ProcessGuid = {EXAMPLE-GUID}

หาก Process GUID ตรงกัน และ Timestamp สอดคล้องกัน อาจช่วยสร้าง Timeline ของ Process ที่เกี่ยวข้องได้

ตัวอย่าง GUID ข้างต้นเป็น Placeholder ไม่ใช่ GUID จริง

13.3 ข้อจำกัดในการทำ Correlation

Event อาจไม่ถูกบันทึกครบทุกประเภท เพราะ Configuration, Filtering, Retention หรือ Logging Gaps

การไม่พบ Network Event จึงไม่สามารถยืนยันได้ว่า Process ไม่เคยสื่อสารผ่านเครือข่าย

14. Verification — ตรวจสอบผลการฝึก

หลังจากทำ Lab ผู้เรียนควรสามารถตรวจสอบ ผลลัพธ์ดังต่อไปนี้

Test	Expected Result
CSV Creation	สร้าง Synthetic Events ได้ 6 รายการ
Failed Logon Detection	พบ Event 4625 จำนวน 5 ครั้ง
Success Correlation	พบ Event 4624 หลัง Failed Logons
IOC Search	พบ IP ที่กำหนดในข้อมูลจำลอง
Threat Assessment	แยก Suspicious จาก Confirmed ได้
Evidence Reporting	อธิบายผลและข้อจำกัดได้

14.1 Detection Coverage

การทดสอบ Detection Rules ต้องตรวจสอบว่ามี Telemetry เพียงพอต่อการตรวจจับหรือไม่

หากไม่ได้เปิด Audit Policy ที่จำเป็น ต่อให้ Detection Logic ถูกต้อง ก็อาจไม่มีข้อมูลให้ตรวจจับ

14.2 False Positive และ False Negative

False Positive คือการแจ้งเตือนว่าอาจมีภัยคุกคาม ทั้งที่กิจกรรมจริงเป็นเหตุการณ์ปกติ

False Negative คือระบบไม่แจ้งเตือน ทั้งที่มีภัยคุกคามเกิดขึ้นจริง

Detection Engineering จึงต้องทดสอบและปรับปรุง ทั้งความแม่นยำและ Coverage

15. Troubleshooting — ปัญหาที่พบบ่อย

15.1 Get-WinEvent แสดง Access Denied

ตรวจสอบสิทธิ์ของผู้ใช้ และนโยบายการอ่าน Security Log

ไม่ควรเพิ่มสิทธิ์แบบถาวร โดยไม่ประเมินความจำเป็น และข้อกำหนดขององค์กร

15.2 No Events Were Found

อาจเกิดจากไม่มี Event ตรงเงื่อนไขในช่วงเวลาที่กำหนด หรือ Logging ไม่ได้เปิดใช้งาน

ให้ตรวจสอบ Time Window, Event ID, Channel และ Audit Policy

15.3 ไม่พบ Sysmon Logs

ตรวจสอบว่า Sysmon ได้รับการติดตั้งหรือเปิดใช้งาน ในรูปแบบที่รองรับหรือไม่

ตรวจสอบชื่อ Channel และ Configuration ก่อนสรุปว่าระบบมีปัญหา

15.4 Sysmon Event ID 3 ไม่ปรากฏ

Network Connection Logging อาจไม่ได้เปิดใช้งาน หรือถูกกรองด้วย Configuration

การเปิดเก็บข้อมูลเพิ่มเติม ต้องคำนึงถึงปริมาณ Events และผลกระทบต่อระบบ

15.5 Event 4688 ไม่มี Command Line

ต้องตรวจสอบว่ามีการเปิด Include Command Line in Process Creation Events และ Audit Process Creation หรือไม่

15.6 Event ID 4104 ไม่ปรากฏ

ตรวจสอบ PowerShell Version, Provider Registration และ Script Block Logging Policy

ต้องตรวจสอบด้วยว่า กำลังอ่าน Channel ที่ตรงกับ PowerShell Runtime หรือไม่

15.7 Correlation จับคู่เหตุการณ์ผิด

ตรวจสอบ Time Zone, Clock Synchronization, Computer, Account Domain, Logon ID และ Source IP

การเชื่อมโยงเหตุการณ์จากหลาย Host ต้องคำนึงถึงความแตกต่าง ของ Event Schema และเวลา

15.8 Detection Rules แจ้งเตือนมากเกินไป

ควรสำรวจ Baseline และปรับ Threshold ตามพฤติกรรมจริงของระบบ

ไม่ควรปิด Detection โดยไม่วิเคราะห์สาเหตุ เพราะอาจทำให้เกิด Detection Gap

16. Security Best Practices สำหรับ Windows Logging

16.1 Logging Configuration

กำหนด Audit Policy ตามความเสี่ยง
เปิด Process Creation Logging เมื่อเหมาะสม
ใช้ Sysmon หรือ Endpoint Telemetry ตามความจำเป็น
กำหนด Log Retention และ Storage Capacity
ตรวจสอบ Logging Health อย่างต่อเนื่อง

16.2 Centralized Logging

การเก็บ Log ไว้เฉพาะเครื่อง อาจไม่เพียงพอสำหรับเหตุการณ์ร้ายแรง

องค์กรควรพิจารณา Windows Event Forwarding, SIEM หรือระบบ Log Collection ที่เหมาะสม

ควรกำหนด Authentication, Encryption, Access Control และ Retention ของ Log Infrastructure

16.3 Log Integrity

จำกัดสิทธิ์การอ่านและแก้ไข Log
ติดตาม Log Clearing และ Configuration Changes
ใช้ Centralized Storage ที่มีมาตรการป้องกัน
จัดการ Time Synchronization
มีขั้นตอนรักษาหลักฐานและ Chain of Custody

16.4 Detection Engineering

เริ่มจาก Threat Hypothesis
ระบุ Data Source และ Required Fields
ทดสอบ Rule ด้วยข้อมูลจำลอง
วิเคราะห์ False Positive
กำหนด Severity และ Triage Procedure
ทบทวน Detection Coverage เป็นระยะ

16.5 Threat Hunting Documentation

ทุก Hunting Exercise ควรมีบันทึกอย่างน้อยดังต่อไปนี้

Hunt ID และ Owner
Hypothesis
Scope และ Time Window
Data Sources
Queries และ Tools
Observed Findings
Confidence และ Limitations
Recommended Actions

17. Incident Investigation Report — ตัวอย่างรายงาน

ตัวอย่างนี้ใช้ข้อมูลจาก Safe Lab ไม่ใช่เหตุการณ์โจมตีจริง

Case ID:
TECHEREST-THREAT-HUNT-006

Case Type:
Authentication Event Correlation

Environment:
Synthetic Windows Security Log Dataset

Hypothesis:
Multiple failed logons followed by success
may warrant investigation.

Data Sources:
Locally generated CSV

Events:
4625 - Failed Logon
4624 - Successful Logon

Account:
labuser

Host:
LAB-PC

Source IP:
192.0.2.10

Observations:
5 failed logons
1 successful logon
Events occurred within 100 seconds

Detection Result:
Threshold matched

Threat Classification:
Not confirmed

Confidence:
High confidence in synthetic event pattern
No evidence of real compromise

Limitations:
No real Windows authentication performed
No EDR or network evidence
No user identity verification

Recommended Actions:
Review account activity in real investigations
Validate source context
Correlate with additional telemetry

Final Status:
Safe Lab Completed

17.1 หลักการเขียน Investigation Report

ต้องแยกระหว่าง Observed Facts และ Analyst Assessment อย่างชัดเจน

ตัวอย่างเช่น การพบ Failed Logons ห้าครั้ง เป็นข้อเท็จจริงจาก Dataset

แต่การสรุปว่าเป็นการโจมตี ต้องอาศัยหลักฐานเพิ่มเติม

18. FAQ — คำถามที่พบบ่อย

18.1 Windows Event Logs ใช้ตรวจจับ Hacker ได้หรือไม่?

สามารถใช้ตรวจสอบกิจกรรม ที่อาจเกี่ยวข้องกับการโจมตีได้ แต่ต้องมี Logging Coverage และหลักฐานสนับสนุนเพียงพอ

18.2 Sysmon จำเป็นสำหรับทุกเครื่องหรือไม่?

ไม่จำเป็นในทุกสถานการณ์ ควรประเมินความเสี่ยง ความต้องการด้าน Telemetry และความสามารถในการจัดการ Log

18.3 Event 4625 จำนวนมากแปลว่าถูก Brute Force หรือไม่?

ไม่เสมอไป อาจเกิดจาก Credentials ที่หมดอายุ ผู้ใช้พิมพ์รหัสผ่านผิด หรือบริการที่ตั้งค่าไม่ถูกต้อง

18.4 Sysmon แทน EDR ได้หรือไม่?

Sysmon เป็นแหล่ง Telemetry ส่วน EDR มักมีความสามารถเพิ่มเติม เช่น Detection, Investigation และ Response Actions

จึงไม่ควรถือว่าทั้งสองอย่าง ทำหน้าที่เหมือนกันทั้งหมด

18.5 Threat Hunting ต้องมี SIEM หรือไม่?

ไม่จำเป็นสำหรับการเริ่มต้น สามารถฝึกด้วย Event Viewer, PowerShell และไฟล์ Log ที่ได้รับอนุญาต

แต่ SIEM ช่วยเพิ่มความสามารถ ในการค้นหาและเชื่อมโยงข้อมูล จากหลายระบบ

18.6 Detection Rule สามารถใช้งาน Production ได้ทันทีหรือไม่?

ไม่ควรนำ Rule ตัวอย่าง ไปใช้งาน Production โดยไม่ทดสอบ

ต้องตรวจสอบ Schema, Field Mapping, Threshold, False Positive และประสิทธิภาพ ของระบบก่อน

18.7 ผู้เริ่มต้นควรเรียนอะไรต่อ?

แนะนำให้ต่อยอดไปสู่ Windows Event Forwarding, SIEM Fundamentals, Sigma Rules และ MITRE ATT&CK Detection Engineering

19. Conclusion — จากการอ่าน Log สู่การค้นหาภัยคุกคามอย่างเป็นระบบ

Windows Event Logs เป็นพื้นฐานสำคัญ ของงาน Defensive Security และ Digital Forensics

การเข้าใจ Event IDs, Logon Types, PowerShell Logging และ Sysmon ช่วยเพิ่มความสามารถ ในการมองเห็นพฤติกรรมของระบบ

แต่การตรวจสอบที่มีคุณภาพ ไม่ได้หยุดอยู่ที่การค้นพบ Event ที่ตรงกับเงื่อนไข

Security Analyst ต้องสามารถ เชื่อมโยงเหตุการณ์ วิเคราะห์บริบท และประเมินหลักฐานอย่างรอบคอบ

Collect the Evidence. Correlate the Events. Test the Hypothesis. Validate the Findings.

Techerest มุ่งพัฒนา Cyber Security Knowledge Base ที่ผู้อ่านสามารถเรียนรู้ ทดลอง และนำไปประยุกต์ใช้ ในงานด้าน Cyber Security จริง ได้อย่างเป็นระบบ