นโยบายการตรวจสอบความปลอดภัยของ Windows และการสอบสวนบันทึกเหตุการณ์ในทางปฏิบัติ — เป็นทีมไอทีที่อ่าน 4625 ได้

«ตั้งแต่เมื่อคืนบัญชีหนึ่งถูกล็อกซ้ำ ๆ ช่วยหาสาเหตุ» «อยากตรวจว่ามีใครลองลงชื่อเข้าใช้ด้วยบัญชีผู้ที่ลาออกหรือไม่» «เซิร์ฟเวอร์นี้ ใครทำอะไร เมื่อใด รู้ได้ไหม?» — คำขอที่เจ้าหน้าที่สารสนเทศของธุรกิจขนาดกลางและเล็ก หรือนักพัฒนาที่ส่งมอบระบบให้ลูกค้า ได้รับขึ้นมาวันหนึ่งอย่างกะทันหัน และสิ่งที่ไปพึ่งคือบันทึกเหตุการณ์ Security ของ Windows

แต่พอเปิดตัวแสดงเหตุการณ์จริง มีสองความเป็นจริงรออยู่ เหตุการณ์ที่อยากเห็นไม่ถูกบันทึก (นโยบายการตรวจสอบยังไม่เปิด) หรือ จมอยู่ใต้เหตุการณ์ปริมาณมหาศาลจนอ่านไม่ได้ (พองด้วยสัญญาณรบกวน) การตรวจสอบความปลอดภัย «เปิดแล้วบันทึกได้» แต่ถ้าไม่ออกแบบว่าจะบันทึกอะไรและถึงไหน พอถึงจังหวะที่ใช้จริงมันไม่ช่วย

flowchart TB
    accTitle: สองความเป็นจริงที่รออยู่ที่ตัวแสดงเหตุการณ์
    accDescr: เมื่อเปิดตัวแสดงเหตุการณ์ มีสองความเป็นจริง คือนโยบายการตรวจสอบยังไม่เปิดและเหตุการณ์ที่ต้องการไม่ได้ถูกบันทึก หรือบันทึกพองด้วยสัญญาณรบกวนจนเหตุการณ์จมและอ่านไม่ได้ จึงต้องออกแบบว่าจะบันทึกอะไรและถึงไหน
    open["เปิดตัวแสดงเหตุการณ์"] --> real{"ความเป็นจริงที่รอคือ?"}
    real -->|ไม่ได้บันทึก| none["เหตุการณ์ที่ต้องการยังไม่ถูกบันทึก"]
    real -->|จมอยู่| noise["อ่านไม่ได้เพราะเหตุการณ์ปริมาณมาก"]
    none -.-> cause1["นโยบายการตรวจสอบปิดอยู่"]
    noise -.-> cause2["พองด้วยสัญญาณรบกวน"]
    none --> design["ออกแบบว่าจะบันทึกอะไรและถึงไหน"]
    noise --> design

ภาพ 1: «ไม่ได้ถูกบันทึก» หรือ «จมจนอ่านไม่ได้» ทั้งสองกรณีเกิดจากการไม่ได้ออกแบบขอบเขตที่จะบันทึก

บทความนี้จัดกลไกของนโยบายการตรวจสอบ (สองระบบ — พื้นฐานและขั้นสูง) หมวดย่อยที่ควรเปิดอย่างน้อยในสภาพแวดล้อมขนาดกลางและเล็ก วิธีอ่านรหัสเหตุการณ์ที่ใช้ประจำอย่าง 4624/4625/4740/4688 การออกแบบความจุของบันทึก Security และการสอบสวนด้วย PowerShell โดยยึดแหล่งปฐมภูมิ ณ สิงหาคม 2026 หากบทความ การตรวจสอบ NTLM ลายเซ็น SMB BitLocker และ ไฟร์วอลล์ ที่ไซต์นี้เคยทำเป็นเรื่อง «ทำให้การป้องกันแน่น» บทความนี้เป็นเรื่อง «ทำให้ยืนยันย้อนหลังได้ว่าเกิดอะไรขึ้น» — ภาคต่อที่มัดเรื่องเหล่านั้นเข้าด้วยกัน

1. สรุปก่อนเลย

• นโยบายการตรวจสอบมีสองระบบ — «พื้นฐาน» และ «ขั้นสูง (Advanced Audit Policy)» — และห้ามผสม Microsoft ระบุชัดว่าการใช้ทั้งสองทำให้ผลตรวจสอบอยู่ในสถานะที่คาดไม่ได้ รวมฝั่งขั้นสูง (กว่า 40 หมวดย่อย)¹
• ตรวจสถานะปัจจุบันด้วย auditpol /get /category:* มันแสดงสิ่งที่ใช้ผลจริงตอนนี้ โดยไม่สนว่ามาจาก GPO หรือการตั้งค่าท้องถิ่น²
• ห้าม «เปิดทั้งหมด» การเปิดหมวดย่อยที่เกิดเหตุการณ์ปริมาณมหาศาลทำให้เหตุการณ์ที่สำคัญจมในสัญญาณรบกวน และกระทบประสิทธิภาพด้วย เริ่มจากคำแนะนำฐานของ Microsoft แล้วเติมเฉพาะที่ต้องการ³⁴
• ลงชื่อเข้าใช้สำเร็จคือ 4624 ล้มเหลวคือ 4625 สำหรับ 4624 อ่าน «เป็นการลงชื่อเข้าใช้ชนิดใด» จากชนิดล็อกออน (2 = Interactive, 3 = Network, 10 = RemoteInteractive เป็นต้น)⁵
• สำหรับ 4625 รหัส Status/Sub Status บอกเหตุผลที่ล้ม ที่ใช้ประจำคือ 0xC0000064 = ชื่อผู้ใช้ไม่มี, 0xC000006A = รหัสผ่านผิด, 0xC0000072 = บัญชีถูกปิด, 0xC0000234 = บัญชีถูกล็อก⁶
• ที่ที่เหตุการณ์ถูกบันทึกถูกกำหนดไว้แล้ว 4624/4625 ถูกบันทึกบนเครื่องที่ถูกเข้าถึง การตรวจข้อมูลรับรอง (4776) และความล้มเหลวของ Kerberos pre-authentication (4771) ถูกบันทึกบนตัวควบคุมโดเมน ดูเครื่องผิดแล้วจะวินิจฉัยผิดว่า «ไม่มีบันทึก»⁶⁷⁸
• ครึ่งหนึ่งของการออกแบบบันทึก Security คือภาชนะเอง — ขนาดสูงสุดและการเก็บ หากการเก็บตั้งเป็นทับ เหตุการณ์เก่าจะหายก่อน ตรวจขนาดสูงสุดและจำนวนรายการด้วย Get-WinEvent -ListLog Security แล้วขยายโดยคำนวณย้อนจากจำนวนวันที่ต้องเก็บจริง⁹¹⁰
• การบันทึกบรรทัดคำสั่งของการสร้างโพรเซส (4688) ทรงพลัง แต่แลกด้วยความเสี่ยงที่ความลับไปอยู่ในบันทึกเป็นข้อความธรรมดา ตรวจสคริปต์ก่อนเปิด¹¹¹²

2. พื้นฐานของนโยบายการตรวจสอบ — อย่าผสม «พื้นฐาน» กับ «ขั้นสูง»

นโยบายการตรวจสอบของ Windows มีสองระบบ¹

• นโยบายการตรวจสอบพื้นฐาน: การตั้งค่า 9 หมวดใต้ «นโยบายท้องถิ่น > นโยบายการตรวจสอบ» เป็นระบบเก่าที่มีมาก่อน Windows Vista
• การกำหนดค่านโยบายการตรวจสอบขั้นสูง (Advanced Audit Policy Configuration): การตั้งค่า หมวดย่อย กว่า 40 รายการใต้ «การตั้งค่าความปลอดภัย > การกำหนดค่านโยบายการตรวจสอบขั้นสูง» มันแตกแต่ละหมวดพื้นฐานเป็นหลายหมวดย่อย — ตัวอย่างเช่น หมวดพื้นฐานเดียว «Audit account logon events» ตรงกับสี่หมวดย่อยฝั่งขั้นสูง การเปิดหมวดพื้นฐานหนึ่งหมวดมีผลเท่ากับการเปิดหมวดย่อยที่คู่กันทั้งหมด จึงบันทึกเหตุการณ์ปริมาณมากที่อาจไม่ได้สนใจ¹

จุดสำคัญคือ สองระบบนี้เข้ากันไม่ได้ Microsoft ระบุตรง ๆ ว่า «อย่าใช้ทั้งนโยบายพื้นฐานและขั้นสูง — จะทำให้ผลตรวจสอบอยู่ในสถานะที่ไม่คาดคิด» เมื่อนโยบายการตรวจสอบขั้นสูงถูกใช้ผ่าน Group Policy การตั้งค่าการตรวจสอบที่มีอยู่ของคอมพิวเตอร์นั้นถูกล้างก่อน แล้วจึงใช้ค่าฝั่งขั้นสูง จากนั้นควบคุมได้อย่างน่าเชื่อถือได้เฉพาะฝั่งขั้นสูง ในสภาพแวดล้อมที่ใช้ฝั่งขั้นสูง ให้เปิดตัวเลือกความปลอดภัย «Audit: Force audit policy subcategory settings to override audit policy category settings» เพื่อไม่ให้ค่าฝั่งพื้นฐานทับได้ (บนเครื่องสแตนด์อโลนเปิดโดยค่าเริ่มต้น)¹⁴

flowchart TB
    accTitle: ความสัมพันธ์ของนโยบายการตรวจสอบพื้นฐานกับขั้นสูง
    accDescr: นโยบายการตรวจสอบพื้นฐานกับขั้นสูงเข้ากันไม่ได้ และการใช้ทั้งสองทำให้ผลตรวจสอบอยู่ในสถานะไม่คาดคิด จึงรวมฝั่งขั้นสูง แล้วเปิดการบังคับการตั้งค่าหมวดย่อยเพื่อกันการทับจากฝั่งพื้นฐาน
    basic["นโยบายการตรวจสอบพื้นฐาน（9 หมวด）"] --> both{"ใช้ทั้งสอง?"}
    adv["นโยบายการตรวจสอบขั้นสูง（กว่า 40 หมวดย่อย）"] --> both
    both -->|ใช่| bad["ผลตรวจสอบอยู่ในสถานะไม่คาดคิด"]
    both -->|ไม่| unify["รวมฝั่งขั้นสูง"]
    unify --> force["เปิดการบังคับการตั้งค่าหมวดย่อย"]
    force -.-> guard["กันการทับจากการตั้งค่าฝั่งพื้นฐาน"]

ภาพ 2: สองระบบเข้ากันไม่ได้ รวมฝั่งขั้นสูง แล้วใช้ค่า «บังคับ» เพื่อกันการทับจากฝั่งพื้นฐาน

การตรวจสถานะปัจจุบันคือคำสั่งเดียว รันจากพรอมต์คำสั่งระดับผู้ดูแล²

rem แสดงการตั้งค่าการตรวจสอบที่ใช้อยู่ตอนนี้ ตามหมวดย่อย
auditpol /get /category:*

rem สำรองการตั้งค่าปัจจุบันเป็น CSV ก่อนเปลี่ยน แล้วกู้คืน
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

เอาต์พุตของ auditpol คือ «นโยบายที่ใช้ผลจริง» โดยไม่สนว่ามาจาก GPO หรือการตั้งค่าท้องถิ่น ยังใช้เทียบเมื่อค่าที่ควรถูกแจกด้วย GPO ดูเหมือนยังไม่สะท้อน โปรดทราบว่าการเปลี่ยนการตั้งค่าการตรวจสอบเองถูกบันทึกเป็นเหตุการณ์ 4719 ดังนั้น «การตรวจสอบถูกปิดโดยไม่มีใครรู้» ก็ไล่ย้อนได้¹²

flowchart TB
    accTitle: สิ่งที่ auditpol เห็นคือนโยบายผลลัพธ์
    accDescr: เอาต์พุตของ auditpol คือ นโยบายการตรวจสอบที่ใช้ผลจริง โดยไม่สนว่ามาจาก GPO หรือการตั้งค่าท้องถิ่น ใช้เทียบเมื่อค่า GPO ยังไม่สะท้อน และการเปลี่ยนการตั้งค่าการตรวจสอบเองถูกบันทึกเป็นเหตุการณ์ 4719 จึงไล่ย้อนได้
    gpo["การตั้งค่าที่แจกด้วย GPO"] --> eff["นโยบายที่ใช้ผลจริง"]
    local["การตั้งค่าท้องถิ่น"] --> eff
    eff --> get["รายการด้วย auditpol /get"]
    get -.-> diff["ใช้เทียบเมื่อ GPO ยังไม่สะท้อน"]
    change["การเปลี่ยนการตั้งค่าการตรวจสอบเอง"] -.-> e4719["บันทึก 4719 แล้วไล่ย้อนได้"]

ภาพ 3: auditpol คืน «ค่าที่ใช้ผล» โดยไม่สนที่มา การเปลี่ยนการตั้งค่าการตรวจสอบเองเหลือที่ 4719

3. ตารางตัดสินหมวดย่อยที่ควรเปิดอย่างน้อย

เหตุที่ «เปิดทั้งหมดไว้ก่อน» เป็นทางผิดชัดเจน ตัวอย่างเช่น Microsoft เตือนว่าการตรวจสอบสำเร็จของหมวดย่อยการใช้สิทธิ์พิเศษเกิดเหตุการณ์มหาศาลจนหาเหตุการณ์อื่นในบันทึกความปลอดภัยยาก และกระทบประสิทธิภาพอย่างมีนัย⁴ ภาชนะของบันทึก (หมวด 5) มีจำกัด ดังนั้นยิ่งบันทึกสัญญาณรบกวน ยิ่งกินจำนวนวันที่เก็บของเหตุการณ์ที่ต้องการจริง การออกแบบการตรวจสอบคือการตัดสินใจว่าจะไม่บันทึกอะไร

flowchart TB
    accTitle: เหตุที่เปิดทั้งหมดเป็นทางผิด
    accDescr: การเปิดหมวดย่อยทั้งหมดทำให้เกิดเหตุการณ์ปริมาณมาก เหตุการณ์สำคัญจมในสัญญาณรบกวน ประสิทธิภาพถูกกระทบ และภาชนะบันทึกที่จำกัดทำให้จำนวนวันที่เก็บของเหตุการณ์ที่ต้องการถูกตัด
    all["เปิดหมวดย่อยทั้งหมด"] --> flood["เกิดเหตุการณ์ปริมาณมาก"]
    flood --> noise["เหตุการณ์สำคัญจม"]
    flood --> perf["กระทบประสิทธิภาพ"]
    flood --> keep["จำนวนวันที่เก็บถูกตัด"]
    noise --> lesson["ออกแบบการตรวจสอบคือการตัดสินว่าไม่บันทึกอะไร"]
    perf --> lesson
    keep --> lesson

ภาพ 4: «เปิดทั้งหมด» ทำให้เหตุการณ์สำคัญจม การออกแบบการตรวจสอบคือการตัดสินว่าจะไม่บันทึกอะไร

Microsoft เผยแพร่คำแนะนำฐานและคำแนะนำที่เข้มขึ้นแยกตามเวิร์กสเตชันกับเซิร์ฟเวอร์ และนั่นคือจุดตั้งต้น³ จากนั้นตารางด้านล่างจัดจากมุมของสภาพแวดล้อมขนาดกลางและเล็ก ว่า «ตอนเกิดเหตุอยากอ่านได้อย่างน้อยอะไร»

ในทางกลับกัน โดยทั่วไปปลอดภัยที่สุดที่ ไม่แตะการตรวจสอบการเข้าถึงวัตถุของระบบไฟล์หรือรีจิสทรี การใช้สิทธิ์พิเศษ หรือหมวดย่อยตัวกรองแพ็กเก็ต (5152 เป็นต้น) โดยค่าเริ่มต้น สิ่งเหล่านี้มีประโยชน์เมื่อจำกัดด้วย SACL ที่เจาะเป้าหมาย หรือช่วงสอบสวนที่มีกำหนด ไม่ใช่เปิดเต็มตลอดเวลา — ทำเช่นนั้นจะกินบันทึกจนหมด⁴

flowchart TB
    accTitle: วิธีจัดการหมวดย่อยที่เกิดเหตุการณ์ปริมาณมาก
    accDescr: การตรวจสอบการเข้าถึงวัตถุของระบบไฟล์หรือรีจิสทรี การใช้สิทธิ์พิเศษ และตัวกรองแพ็กเก็ต หากเปิดเต็มตลอดเวลาจะกินบันทึกจนหมด จึงมีประโยชน์เมื่อจำกัดด้วย SACL ที่เจาะเป้าหมาย หรือจำกัดช่วงแยกปัญหา
    heavy["หมวดย่อยที่เกิดเหตุการณ์ปริมาณมาก"] --> use{"เปิดอย่างไร?"}
    heavy -.-> ex1["การตรวจสอบการเข้าถึงวัตถุ"]
    heavy -.-> ex2["การใช้สิทธิ์พิเศษและตัวกรองแพ็กเก็ต"]
    use -->|เปิดเต็มตลอดเวลา| eat["กินบันทึกจนหมด"]
    use -->|SACL ที่จำกัดเป้าหมาย| ok1["มีประโยชน์"]
    use -->|จำกัดช่วงแยกปัญหา| ok2["มีประโยชน์"]

ภาพ 5: อย่าเปิดการเข้าถึงวัตถุหรือการใช้สิทธิ์พิเศษเต็มตลอดเวลา มีประโยชน์เมื่อจำกัดเป้าหมายและช่วงเวลา

4. วิธีอ่านรหัสเหตุการณ์ที่ใช้ประจำ

4.1. 4624 — การลงชื่อเข้าใช้สำเร็จแยกด้วยชนิดล็อกออน

4624 «An account was successfully logged on» ถูก บันทึกบนเครื่องที่สร้างเซสชันล็อกออน (เครื่องที่ถูกเข้าถึง)⁵ เพราะเป็นเหตุการณ์ปริมาณมาก ขั้นแรกของการอ่านคือแยกด้วย ชนิดล็อกออน (Logon Type)⁵

ฟิลด์อื่นที่ควรดูคู่กันคือชื่อบัญชีใต้ «New Logon» ที่อยู่ต้นทางใต้ «Network Information» «Authentication Package» (NTLM หรือ Kerberos) และ «Elevated Token» (ว่าเซสชันมีสิทธิ์ผู้ดูแลหรือไม่) หากอยากติดตามเฉพาะการลงชื่อเข้าใช้ที่มีสิทธิ์ผู้ดูแล เหตุการณ์ 4672 (Special privileges assigned to new logon) ที่บันทึกด้วย Logon ID เดียวกันก็ใช้ได้⁵

flowchart TB
    accTitle: ขั้นตอนการแยกอ่าน 4624
    accDescr: 4624 ที่ถูกบันทึกปริมาณมากให้แยกด้วยชนิดล็อกออนก่อน แล้วตรวจชื่อบัญชีกับต้นทาง แพ็กเกจการรับรอง และโทเค็นที่ยกระดับ และการลงชื่อเข้าใช้ที่มีสิทธิ์ผู้ดูแลให้เทียบกับ 4672 ของ Logon ID เดียวกัน
    ev["4624 ลงชื่อเข้าใช้สำเร็จ"] --> type["แยกด้วยชนิดล็อกออน"]
    type --> fields["ตรวจฟิลด์หลัก"]
    fields -.-> f1["ชื่อบัญชีและต้นทาง"]
    fields -.-> f2["แพ็กเกจการรับรอง"]
    fields -.-> f3["โทเค็นที่ยกระดับ"]
    fields --> admin["ติดตามสิทธิ์ผู้ดูแล"]
    admin -.-> e4672["4672 ของ Logon ID เดียวกัน"]

ภาพ 6: 4624 ให้แยกด้วยชนิดล็อกออนก่อนแล้วอ่านฟิลด์ การลงชื่อเข้าใช้ที่มีสิทธิ์พิเศษให้เทียบกับ 4672

4.2. 4625 — ยืนยันเหตุผลที่ล้มด้วยรหัส Status/Sub Status

4625 «An account failed to log on» ถูก บันทึกบนเครื่องที่ถูกลองล็อกออน⁶ แทนที่จะเชื่อข้อความในฟิลด์ «Failure Reason» วิธีที่ชัวร์คืออ่านจากรหัสฐานสิบหก Status/Sub Status ที่ใช้ประจำมีดังนี้⁶

• 0xC0000064: ชื่อผู้ใช้ไม่มี หากเกิดต่อเนื่องในหน้าต่างสั้น อาจเป็นสัญญาณการโจมตีแบบไล่ชื่อบัญชี
• 0xC000006A: รหัสผ่านผิด ความล้มเหลวซ้ำต่อบัญชีเฉพาะอาจเป็นสัญญาณการเดารหัสผ่าน
• 0xC000006D: ชื่อผู้ใช้หรือข้อมูลการรับรองไม่ถูกต้อง
• 0xC000006F: นอกช่วงเวลาที่อนุญาตให้ล็อกออน
• 0xC0000070: จากเวิร์กสเตชันที่ไม่อนุญาต
• 0xC0000072: บัญชีถูกผู้ดูแลปิด (การลองบัญชีผู้ที่ลาออกโผล่ที่นี่)
• 0xC000015B: ชนิดล็อกออนที่ขอไม่อนุญาตบนเครื่องนี้
• 0xC0000193: บัญชีหมดอายุ
• 0xC0000234: ถูกล็อก

«ใคร จากที่ไหน ทำไมจึงล้ม» ยืนยันด้วยชุดสามจุดของบัญชีเป้าหมาย ต้นทาง (ชื่อเวิร์กสเตชัน / ที่อยู่ IP) และรหัสนี้ หมวด 6 มี PowerShell ที่ดึงทั้งสามพร้อมกันในครั้งเดียว

flowchart TB
    accTitle: ไหลการยืนยันเหตุผลที่ล้มของ 4625
    accDescr: เหตุผลที่ล้มของ 4625 ยืนยันด้วยรหัสฐานสิบหก Status/Sub Status อ่านสัญญาณการโจมตีจากแนวโน้มของรหัส แล้วระบุด้วยชุดสามจุดของบัญชีเป้าหมายกับต้นทาง
    ev["4625 ลงชื่อเข้าใช้ล้มเหลว"] --> code["ตรวจรหัส Sub Status"]
    code --> sign{"แนวโน้มของรหัสคือ?"}
    sign -->|0xC0000064 ต่อเนื่อง| enum["สัญญาณการไล่ชื่อบัญชี"]
    sign -->|0xC000006A ต่อเนื่อง| guess["สัญญาณการเดารหัสผ่าน"]
    sign -->|0xC0000072| disabled["ลองบัญชีผู้ที่ลาออก"]
    enum --> triple["ยืนยันด้วยชุดสามจุด"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["บัญชีเป้าหมาย+ต้นทาง+รหัส"]

ภาพ 7: ยืนยันเหตุผลที่ล้มด้วยรหัส แล้วอ่านเป็นชุดสามจุดคู่บัญชีเป้าหมายและต้นทาง

4.3. 4740 — ต้นทางของการล็อกบัญชีอยู่ที่ «ชื่อคอมพิวเตอร์ที่เรียก»

4740 «A user account was locked out» (หมวดย่อย: User Account Management) ฟิลด์หลักของเหตุการณ์นี้คือ «Caller Computer Name» ซึ่งบันทึก คอมพิวเตอร์ที่เป็นต้นทางของการลองล็อกออนที่ทำให้เกิดการล็อก¹⁶ ขั้นตอนมาตรฐานคือระบุเครื่องต้นทางจากฟิลด์นี้ แล้ว ไล่ข้อมูลรับรองเก่าที่ยังค้างบนเครื่องนั้น ในกรณีส่วนใหญ่สาเหตุคือสิ่งที่ยังใช้ข้อมูลรับรองเก่าหลังเปลี่ยนรหัสผ่าน — ข้อมูลรับรองที่บันทึกไว้ เซสชัน RDP ที่ตัดค้าง หรือบริการหรืองานตามกำหนดเวลาที่ตั้งด้วยรหัสผ่านเก่า

flowchart TB
    accTitle: วิธีมาตรฐานในการสอบสวนการล็อกบัญชี
    accDescr: ชื่อคอมพิวเตอร์ที่เรียกของ 4740 ระบุเครื่องต้นทาง แล้วไล่ข้อมูลรับรองที่บันทึกไว้ เซสชัน RDP ที่ตัดค้าง และบริการหรืองานที่ใช้รหัสผ่านเก่าบนเครื่องนั้น
    ev["4740 เกิดการล็อกบัญชี"] --> caller["ตรวจชื่อคอมพิวเตอร์ที่เรียก"]
    caller --> src["ระบุเครื่องต้นทาง"]
    src --> sweep["ไล่ข้อมูลรับรองเก่า"]
    sweep -.-> c1["ข้อมูลรับรองที่บันทึกไว้"]
    sweep -.-> c2["เซสชัน RDP ที่ตัดค้าง"]
    sweep -.-> c3["บริการหรืองานที่ใช้รหัสผ่านเก่า"]

ภาพ 8: ระบุต้นทางจาก «ชื่อคอมพิวเตอร์ที่เรียก» ของ 4740 แล้วไล่ข้อมูลรับรองเก่าบนเครื่องนั้น

มีข้อควรระวังข้อหนึ่ง 4625 ถูกบันทึกบน คอมพิวเตอร์ที่รับการลองล็อกออน หากสาเหตุคือล็อกออนเครือข่ายจากเครื่องต้นทางไปยังไฟล์เซิร์ฟเวอร์ เป็นต้น บันทึก Security ของเครื่องต้นทางเองจะไม่มี 4625 ร่องรอยอยู่ที่ 4625 ของเซิร์ฟเวอร์ปลายทาง หรือถ้าเป็นบัญชีโดเมน ที่ 4776 (NTLM) หรือ 4771 (ความล้มเหลวของ Kerberos pre-authentication) บน DC⁷⁸ เมื่อ «ไม่มีอะไรในบันทึกของเครื่องต้นทาง» ให้ไปดูฝั่งที่รับ

flowchart TB
    accTitle: เครื่องที่เหลือร่องรอยความล้มเหลว
    accDescr: ความล้มเหลวของล็อกออนเครือข่ายไม่เหลือบนเครื่องต้นทางเอง แต่ถูกบันทึกที่ 4625 ของเซิร์ฟเวอร์ปลายทางที่รับการลอง และถ้าเป็นบัญชีโดเมน ร่องรอยยังเหลือที่ 4776 หรือ 4771 ของ DC
    src["เครื่องต้นทาง（ตัวเองไม่มี 4625）"] -->|ล็อกออนเครือข่าย| target["เซิร์ฟเวอร์ปลายทาง"]
    target -.-> e4625["บันทึก 4625"]
    src -->|การรับรองบัญชีโดเมน| dc["ตัวควบคุมโดเมน"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

ภาพ 9: 4625 เหลือฝั่งที่รับ หากเครื่องต้นทางไม่มีอะไร ให้ดูเซิร์ฟเวอร์ปลายทางและฝั่ง DC

4.4. ตระกูล 4720 — การสร้าง แก้บัญชี และการเพิ่มเข้ากลุ่ม

เหตุการณ์การจัดการบัญชีเรียงหมายเลขติดกัน: 4720 (สร้างบัญชีผู้ใช้)¹⁷, 4726 (ลบ), 4738 (แก้) และฝั่งกลุ่มคือการเพิ่ม/เอาสมาชิกออก โปรดทราบว่า รหัสเหตุการณ์ของการเปลี่ยนสมาชิกกลุ่มขึ้นกับชนิดของกลุ่ม เป็น 4732/4733 สำหรับกลุ่มท้องถิ่น, 4728/4729 สำหรับกลุ่มโกลบอล และ 4756/4757 สำหรับกลุ่มยูนิเวอร์แซล¹⁴ Domain Admins เป็นกลุ่มโกลบอล ดังนั้นการเพิ่มเข้ากลุ่มนั้นโผล่เป็น 4728 — หากเตือนเฉพาะ 4732 จะพลาดพอดีเหตุการณ์ที่อยากจับที่สุด ในงานประจำส่วนใหญ่เป็นบันทึกงานเฮลป์เดสก์ แต่ «ผู้ใช้มาตรฐานถูกเพิ่มเข้ากลุ่มผู้ดูแลกะทันหัน» หรือ «บัญชีที่ไม่มีใครรู้จักเพิ่งถูกสร้าง» แม้เกิดครั้งเดียวก็สมควรสอบสวนทันที Microsoft เองยกการเพิ่มสมาชิกที่ไม่คาดคิดเข้ากลุ่มที่มีสิทธิ์พิเศษเป็นตัวอย่างของเหตุการณ์ที่ควรเตือนเป็นรายครั้ง³

flowchart TB
    accTitle: ชนิดกลุ่มกับเหตุการณ์เพิ่มสมาชิก
    accDescr: การเพิ่มสมาชิกเข้ากลุ่มมีรหัสเหตุการณ์ต่างกันตามชนิดกลุ่ม ท้องถิ่นบันทึกที่ 4732 โกลบอลที่ 4728 ยูนิเวอร์แซลที่ 4756 ดังนั้นการเพิ่มเข้ากลุ่มโกลบอล Domain Admins ดูที่ 4728
    add["เพิ่มสมาชิกเข้ากลุ่ม"] --> kind{"ชนิดของกลุ่มคือ?"}
    kind -->|ท้องถิ่น| lg["บันทึกที่ 4732"]
    kind -->|โกลบอล| gg["บันทึกที่ 4728"]
    kind -->|ยูนิเวอร์แซล| ug["บันทึกที่ 4756"]
    gg -.-> da["การเพิ่มเข้า Domain Admins อยู่ที่นี่"]
    lg -.-> miss["เฝ้าแค่ 4732 จะพลาด"]

ภาพ 10: รหัสเหตุการณ์ของการเพิ่มสมาชิกแยกตามชนิดกลุ่ม การเพิ่มเข้า Domain Admins คือ 4728

4.5. 4688 — การสร้างโพรเซส การบันทึกบรรทัดคำสั่งเป็นสวิตช์แยก

4688 «A new process has been created» บันทึกบัญชีที่สร้าง เส้นทางไฟล์ปฏิบัติการของโพรเซสใหม่ โพรเซสแม่ และชนิดการยกระดับโทเค็นทุกครั้งที่มีการสร้างโพรเซส¹¹ เป็นเหตุการณ์ที่มีคุณค่าต่อการสอบสวนสูง เพราะตอบได้ว่า «ใครรันอะไรบนเซิร์ฟเวอร์นี้»

อย่างไรก็ตามโดยค่าเริ่มต้น อาร์กิวเมนต์บรรทัดคำสั่งไม่ถูกบันทึก เฉพาะเมื่อเปิดค่า Group Policy «Include command line in process creation events» (Administrative Templates > System > Audit Process Creation) แยกต่างหาก ฟิลด์ «Process Command Line» ของ 4688 จึงมีอาร์กิวเมนต์¹¹¹² ค่านี้แทบจำเป็นสำหรับการไล่การเปิดที่น่าสงสัยอย่าง powershell -EncodedCommand ... แต่เปิดเมื่อเข้าใจความเสี่ยงที่ความลับปน ตามที่กล่าวในหมวด 7

flowchart TB
    accTitle: ความสัมพันธ์ของ 4688 กับการบันทึกบรรทัดคำสั่ง
    accDescr: เมื่อเปิดการตรวจสอบการสร้างโพรเซส 4688 บันทึกบัญชี เส้นทางไฟล์ปฏิบัติการ และโพรเซสแม่ แต่อาร์กิวเมนต์บรรทัดคำสั่งถูกบันทึกเมื่อเปิด Group Policy แยก และมีความเสี่ยงที่ความลับอยู่ในข้อความธรรมดา
    audit["เปิดการตรวจสอบการสร้างโพรเซส"] --> ev["บันทึก 4688"]
    ev -.-> base["บัญชี เส้นทาง และโพรเซสแม่"]
    ev --> args{"อยากเห็นอาร์กิวเมนต์ด้วย?"}
    args -->|คงค่าเริ่มต้น| none["บรรทัดคำสั่งว่าง"]
    args -->|เปิด GPO เพิ่ม| cmd["บันทึกอาร์กิวเมนต์"]
    cmd -.-> risk["ความเสี่ยงที่ความลับอยู่ในข้อความธรรมดา"]

ภาพ 11: การบันทึกบรรทัดคำสั่งของ 4688 เป็นสวิตช์แยก ก่อนเปิดให้ตรวจความเสี่ยงที่ความลับปนก่อน

4.6. 4698 — การสร้างงานตามกำหนดเวลา

4698 «A scheduled task was created» บันทึกชื่องานและ XML ทั้งก้อนของนิยามงาน (รวมคำสั่งที่รัน) เพราะการลงทะเบียนงานตามกำหนดเวลาเป็นเทคนิคที่มัลแวร์ใช้เพื่ออยู่รอดหลังรีบูต Microsoft จึงแนะนำให้เฝ้าเหตุการณ์การสร้างงาน¹⁵ แม้ในสภาพแวดล้อมที่ใช้งานตามกำหนดเวลาหนักเพื่อธุรกิจ การสร้างเองไม่ใช่เรื่องที่เกิดทุกวัน ดังนั้นระดับสัญญาณรบกวนค่อนข้างต่ำ

flowchart TB
    accTitle: การคงอยู่ด้วยการลงทะเบียนงานกับ 4698
    accDescr: มัลแวร์ลงทะเบียนงานตามกำหนดเวลาเป็นวิธีประจำเพื่ออยู่รอดหลังรีบูต ดังนั้นการเฝ้า 4698 ที่บันทึกตอนสร้างงานทำให้ไล่ได้ถึงนิยามงานรวมคำสั่งที่รัน
    mal["การคงอยู่ของมัลแวร์"] --> task["ลงทะเบียนงานเพื่ออยู่รอด"]
    task --> ev["บันทึก 4698"]
    ev -.-> xml["XML ทั้งก้อนรวมคำสั่งที่รัน"]
    ev --> watch["ตรวจจับด้วยการเฝ้าการสร้างงาน"]
    watch -.-> low["การสร้างไม่ใช่เรื่องประจำวัน สัญญาณรบกวนน้อย"]

ภาพ 12: การลงทะเบียนงานซึ่งเป็นวิธีคงอยู่ที่ใช้ประจำเหลือที่ 4698 XML ทั้งก้อนไล่ได้ถึงคำสั่งที่รัน

อีกอันที่ควรจำคือ 1102 «The audit log was cleared» การล้างบันทึก Security ต้องเหลือเหตุการณ์นี้เสมอ ดังนั้นเมื่อพบว่า «บันทึกว่าง» จะแยกได้ว่าเป็นอุบัติเหตุหรือการดำเนินการ¹⁸

flowchart TB
    accTitle: การแยกการลบบันทึกด้วย 1102
    accDescr: การล้างบันทึก Security ต้องเหลือ 1102 เสมอ ดังนั้นเมื่อบันทึกว่าง การตรวจว่ามี 1102 หรือไม่ช่วยแยกได้ว่าเป็นการดำเนินการลบหรืออุบัติเหตุ
    empty["บันทึกว่าง"] --> rule["การล้างต้องเหลือ 1102 เสมอ"]
    rule --> check{"มี 1102 หรือไม่?"}
    check -->|มี| op["มีการดำเนินการลบ"]
    check -->|ไม่มี| acc["สงสัยว่าเป็นอุบัติเหตุ"]

ภาพ 13: การล้างบันทึก Security ต้องเหลือ 1102 เสมอ บันทึกว่างแยกอุบัติเหตุกับการดำเนินการด้วยว่ามี 1102 หรือไม่

5. การออกแบบภาชนะของบันทึก — ขนาดสูงสุดและการเก็บ

ก่อนเพิ่มนโยบายการตรวจสอบ ให้ตรวจภาชนะรับ บันทึก Security มีขนาดสูงสุดและโหมดการเก็บ: ในโหมดทับ (โครงที่ใช้ทั่วไป) เมื่อถึงขนาดสูงสุด เหตุการณ์ใหม่จะทับเหตุการณ์เก่าสุด ในทางกลับกัน ในโหมดเก็บ (ไม่ทับ) เมื่อบันทึกเต็ม เหตุการณ์ใหม่ถูกทิ้งแทน¹⁰ ทั้งสองพฤติกรรมเป็นสาเหตุของ «พอบันทึกที่ต้องการก็ไม่มี» ดังนั้นการรู้สถานะปัจจุบันมาก่อน

# ตรวจภาชนะของบันทึก Security: โหมดเก็บรักษา ขนาดสูงสุด จำนวนระเบียนปัจจุบัน
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# ตอนนี้เหลือจริงกี่วัน (เวลาของเหตุการณ์เก่าสุด)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog คืนโครงของบันทึกและจำนวนรายการพร้อมกัน⁹ ผลต่างระหว่าง «เวลาของเหตุการณ์เก่าสุด» กับเวลาปัจจุบันคือช่วงเก็บจริง หากไม่พอต่อความต้องการ (อยากย้อนสอบสวนกี่วัน) ให้ขยายขนาดสูงสุด ตั้งค่าได้ด้วย wevtutil sl Security /ms:<byte count> หรือแจกผ่าน Group Policy¹⁰

flowchart TB
    accTitle: การออกแบบความจุโดยคำนวณย้อนจากจำนวนวันที่เก็บ
    accDescr: ตรวจโครงและจำนวนด้วย ListLog ของ Get-WinEvent หาจำนวนวันที่เก็บจริงจากเวลาของเหตุการณ์เก่าสุด หากไม่พอต่อวันที่อยากย้อนตอนสอบสวนเหตุ ให้ขยายขนาดสูงสุด
    check["ตรวจโครงและจำนวนด้วย ListLog"] --> oldest["ตรวจเวลาของเหตุการณ์เก่าสุด"]
    oldest --> days["คำนวณจำนวนวันที่เก็บจริง"]
    days --> enough{"พอต่อความต้องการ?"}
    enough -->|พอ| keep["คงขนาดปัจจุบัน"]
    enough -->|ไม่พอ| grow["ขยายขนาดสูงสุด"]
    grow -.-> how["ตั้งด้วย wevtutil sl หรือ GPO"]

ภาพ 14: ตรวจจำนวนวันที่เหลือจริง แล้วคำนวณย้อนจากวันที่อยากย้อนเพื่อกำหนดขนาดสูงสุด

นอกจากนี้ยังมีตัวเลือกความปลอดภัยชื่อ «Audit: Shut down system immediately if unable to log security audits» (ที่เรียกกันว่า CrashOnAuditFail) เมื่อเปิด หากระบบบันทึกเหตุการณ์ตรวจสอบไม่ได้ มันจะหยุดด้วย STOP error C0000244 มีไว้สำหรับข้อกำหนดการรับรองที่ขาดร่องรอยการตรวจสอบไม่ได้เลย และปิดโดยค่าเริ่มต้น Microsoft เองเตือนว่าอาจถูกพลิกเป็น DoS โดยผู้โจมตีจงใจทำให้เกิดเหตุการณ์ท่วมเพื่อหยุดเซิร์ฟเวอร์ — จึงไม่ใช่สิ่งที่ควรเปิดง่าย ๆ ในสภาพแวดล้อมขนาดกลางและเล็กทั่วไป¹⁹

flowchart TB
    accTitle: พฤติกรรมเมื่อบันทึกเต็ม
    accDescr: โครงการเก็บมีสองแบบคือโหมดทับกับโหมดไม่ทับ และเมื่อโหมดไม่ทับทำให้บันทึกการตรวจสอบไม่ได้ หาก CrashOnAuditFail ซึ่งเป็นการตั้งค่าอีกกรอบเปิดอยู่ ระบบจะหยุดด้วย STOP error C0000244
    full["บันทึก Security ถึงขนาดสูงสุด"] --> mode{"โครงเก็บคือ?"}
    mode -->|โหมดทับ| ow["เหตุการณ์เก่าสุดถูกทับ"]
    mode -->|ไม่ทับ| drop["เหตุการณ์ใหม่ถูกทิ้ง"]
    ow -.-> lost["ทั้งคู่เป็นสาเหตุที่พอบันทึกที่ต้องการก็หาย"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail เปิดด้วย?"}
    caf -->|ใช่| crash["หยุดด้วย STOP C0000244"]

ภาพ 15: โครงการเก็บมีสองทาง คือทับหรือทิ้ง CrashOnAuditFail เป็นค่าอีกกรอบ ที่หยุดระบบเมื่อบันทึกไม่ได้

6. การสอบสวนในทางปฏิบัติ — กรอง Get-WinEvent และการส่งออก

6.1. การจำกัดในตัวแสดงเหตุการณ์

สำหรับการสอบสวนครั้งเดียว ตัวแสดงเหตุการณ์ก็พอ เปิดบันทึก Security แล้วระบุรหัสเหตุการณ์ (เช่น 4625) และช่วงเวลาด้วย «Filter Current Log» เงื่อนไขที่ตรวจซ้ำให้บันทึกเป็น «Custom View» เพื่อคลิกครั้งเดียวครั้งหน้า หากอยากจำกัดด้วยบัญชีเฉพาะ ไม่ใช่แค่รหัสเหตุการณ์ แก้คิวรี XPath โดยตรงที่แท็บ XML ของกล่องกรองได้

6.2. การดึงด้วย Get-WinEvent

สำหรับการสอบสวนที่มีจำนวนรายการมาก หลายเงื่อนไข หรือรันเป็นระยะ ให้สลับไป Get-WinEvent ของ PowerShell จุดสำคัญคือใช้ -FilterHashtable ซึ่งให้ตัวกรองทำงานฝั่งเซิร์ฟเวอร์⁹

flowchart TB
    accTitle: การเลือกเครื่องมือสอบสวน
    accDescr: การสอบสวนครั้งเดียวใช้ตัวกรองของตัวแสดงเหตุการณ์ก็พอ เงื่อนไขที่ดูซ้ำให้บันทึกเป็นมุมมองกำหนดเอง และการสอบสวนที่จำนวนมาก หลายเงื่อนไข หรือรันเป็นระยะ ให้สลับไป Get-WinEvent
    q{"เป็นการสอบสวนแบบใด?"}
    q -->|ครั้งเดียว| viewer["กรองด้วยตัวแสดงเหตุการณ์"]
    q -->|เงื่อนไขที่ดูซ้ำ| view["บันทึกเป็นมุมมองกำหนดเอง"]
    q -->|ปริมาณมาก หลายเงื่อนไข เป็นระยะ| ps["สลับไป Get-WinEvent"]
    ps -.-> hash["กรองด้วย FilterHashtable"]

ภาพ 16: ครั้งเดียวใช้ตัวแสดงเหตุการณ์ ซ้ำแล้วใช้มุมมองกำหนดเอง จำนวนมากใช้ Get-WinEvent

# ดึงความล้มเหลวของการลงชื่อเข้า (4625) ใน 24 ชั่วโมงล่าสุด
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# จัด «ใคร จากไหน ทำไม» เป็นตาราง
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

พอมีแบบดึง EventData จากนิพจน์ XML ของเหตุการณ์แบบนี้แล้ว ใช้ซ้ำกับ 4624 หรือ 4688 ได้ตามที่เป็น การออกแบบการกรองของ Get-WinEvent — เมื่อใดใช้ FilterHashtable เมื่อใดใช้ XPath และวิธีแก้คิวรีที่ช้า — ครอบคลุมละเอียดใน «สอบสวนบันทึกเหตุการณ์ในทางปฏิบัติด้วย Get-WinEvent — ความเร็วของการกรองกำหนดเวลาสอบสวน»

flowchart TB
    accTitle: แบบดึง EventData แล้วจัดรูป
    accDescr: แปลงเหตุการณ์ที่ได้จาก Get-WinEvent เป็นนิพจน์ XML ดึงแต่ละฟิลด์ของ EventData แล้วจัดเป็นตาราง แบบนี้ใช้ซ้ำกับ 4624 หรือ 4688 ได้ด้วยวิธีเดียวกัน ไม่จำกัดที่ 4625
    get["ดึงด้วย Get-WinEvent"] --> xml["แปลงเหตุการณ์เป็น XML"]
    xml --> pull["ดึง EventData"]
    pull --> shape["จัดเป็นตารางแล้วรวม"]
    shape -.-> reuse["ใช้แบบเดียวกันกับ 4624 และ 4688"]

ภาพ 17: แบบดึง EventData จากนิพจน์ XML แล้วจัดเป็นตารางใช้ซ้ำได้แม้รหัสเหตุการณ์เปลี่ยน

6.3. การส่งออกด้วย wevtutil

หลักของบันทึกบนเครื่องที่สอบสวนคือ ส่งออกแล้วเก็บสำเนาก่อน จะถูกทับ¹⁰

rem รักษาบันทึก Security ทั้งก้อนเป็น evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem ส่งออกเฉพาะเหตุการณ์ 4625 จำกัดด้วย XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

ไฟล์ .evtx ที่ส่งออกวิเคราะห์บนเครื่องอื่นได้แบบเดียวกันด้วย Get-WinEvent -Path C:\logs\security-20260801.evtx⁹ นิสัยเก็บก่อนแล้วค่อยวิเคราะห์ คือชุดความคิดเดียวกับ «เก็บดัมป์ก่อน» ตอนสอบสวนแครช (ดู «แนะนำการเก็บดัมป์แครชของ Windows - WER/ProcDump/WinDbg»)

flowchart TB
    accTitle: ไหลการเก็บก่อนแล้วค่อยวิเคราะห์
    accDescr: ส่งออกบันทึก Security ของเครื่องที่สอบสวนเป็นไฟล์ evtx ด้วย wevtutil epl เพื่อเก็บไว้ แล้ววิเคราะห์แบบเดียวกันบนเครื่องอื่นด้วยการระบุ Path ของ Get-WinEvent
    target["เครื่องที่สอบสวน"] --> export["เก็บเป็น evtx ด้วย wevtutil epl"]
    export --> copy["นำไปเครื่องอื่น"]
    copy --> analyze["วิเคราะห์ด้วย Get-WinEvent -Path"]
    export -.-> note["เก็บก่อนถูกทับ"]

ภาพ 18: เก็บก่อน แล้วค่อยวิเคราะห์ เก็บเป็น evtx แล้วสอบสวนบนเครื่องอื่นได้แบบเดียวกัน

7. กับดัก — สี่ข้อที่เหยียบง่ายในสนาม

(1) ความลับไปอยู่ในบรรทัดคำสั่งของ 4688 การเปิดการบันทึกบรรทัดคำสั่งใส่ อาร์กิวเมนต์ของทุกโพรเซสเข้าบันทึก Security เป็นข้อความธรรมดา Microsoft ระบุชัดว่า «ผู้ใช้ทุกคนที่มีสิทธิ์อ่านเหตุการณ์ความปลอดภัยจะอ่านอาร์กิวเมนต์บรรทัดคำสั่งของทุกโพรเซสที่สร้างสำเร็จได้ อาร์กิวเมนต์บรรทัดคำสั่งอาจมีความลับหรือข้อมูลส่วนตัวอย่างรหัสผ่าน» ¹² หากมีแอปธุรกิจหรือสคริปต์แม้ตัวเดียวที่เปิดแบบ myapp.exe /user:admin /password:P@ssw0rd นั่นคือการเปิดเผยความลับต่อทุกคนที่ดูบันทึกได้ ก่อนเปิด ให้ไล่จุดที่ส่งความลับเป็นอาร์กิวเมนต์บรรทัดคำสั่งแล้วแก้ ที่ส่งออกหรือส่งต่อบันทึกไปก็ต้องจัดการในระดับความลับเดียวกัน

flowchart TB
    accTitle: ลำดับการเปิดการบันทึกบรรทัดคำสั่ง
    accDescr: การบันทึกบรรทัดคำสั่งของ 4688 ต้องไล่แอปธุรกิจและสคริปต์ที่ส่งความลับเป็นอาร์กิวเมนต์ก่อนเปิด แก้จุดที่ตรง แล้วค่อยเปิดตามลำดับนั้น และที่เก็บกับที่ส่งต่อต้องใช้ระดับเดียวกัน
    audit["ไล่การส่งความลับเป็นอาร์กิวเมนต์"] --> found{"มีรายการที่ตรง?"}
    found -->|มี| fix["แก้จุดที่ส่ง"]
    found -->|ไม่มี| on["เปิดการบันทึกบรรทัดคำสั่ง"]
    fix --> on
    on -.-> dest["ที่เก็บและที่ส่งต่อใช้ระดับเดียวกัน"]

ภาพ 19: การบันทึกบรรทัดคำสั่งให้ «ไล่แล้วแก้ แล้วค่อยเปิด» ลำดับกลับคือการเปิดเผยความลับ

(2) ดำเนินงานโดยไม่รู้ว่าเกิดอะไรเมื่อบันทึกเต็ม ในโหมดทับ หลักฐานเก่าหายเงียบ ในโหมดไม่ทับ เหตุการณ์ใหม่ถูกทิ้ง และถ้า CrashOnAuditFail เปิด ระบบทั้งก้อนหยุด (หมวด 5)¹⁰¹⁹ ทางที่ถูกคือรู้ว่าเลือกพฤติกรรมใด และมีกลไก — ส่งออกตามกำหนด หรือแพลตฟอร์มเก็บบันทึก — ที่เก็บข้อมูลก่อนถูกทับ

(3) ตัวควบคุมโดเมนกับเครื่องปลายทางต้องดูบันทึกคนละชุด 4624/4625 ถูกบันทึกบน เครื่องที่ถูกเข้าถึง⁵⁶ ในทางกลับกัน การตรวจข้อมูลรับรองของบัญชีโดเมน (4776 ของ NTLM) ถูกบันทึกบน เครื่องที่มีอำนาจเหนือข้อมูลรับรองนั้น — สำหรับบัญชีโดเมนคือ DC⁷ — และความล้มเหลวของ Kerberos pre-authentication (4771) ถูกบันทึก เฉพาะบน DC⁸ «ไฟล์เซิร์ฟเวอร์ไม่มี 4625» ไม่ได้แปลว่า «ไม่มีการโจมตี» ภาพรวมได้เมื่อเทียบ 4776/4771 บน DC ด้วย ดู «อธิบาย NTLM และ Kerberos ด้วยแผนภาพ — ทำไมการรับรองจึง «ตก» ไป NTLM» สำหรับไหลจริงของแต่ละโพรโทคอลการรับรอง

(4) นาฬิกาคลาดแล้วเทียบไม่ได้ การเรียงบันทึกจากหลายเครื่องเพื่อไล่ «เครื่องใดเกิด 4625 ก่อน 4740 นี้» ใช้ได้ก็ต่อเมื่อนาฬิกาของทุกเครื่องตรงกัน ในสภาพแวดล้อมโดเมน Kerberos เองกำหนดเพดานความคลาดของนาฬิกา (ค่าเริ่มต้น 5 นาที) เกินนั้นการรับรองเองเริ่มล้ม²⁰ จากมุมสอบสวน ความคลาดแค่ไม่กี่วินาที — ไม่ต้องถึงห้านาที — ก็ทำให้อ่านลำดับเหตุการณ์ผิดได้ ดังนั้นการตรวจสถานะซิงค์ของ w32time ควรเป็นขั้นแรกสุดของขั้นตอนสอบสวน อีกอย่าง เวลาที่บันทึกของเหตุการณ์ถูกเก็บเป็น UTC และการแสดงตามเขตเวลาของเครื่องที่ดู ดังนั้นเมื่ออ่าน .evtx ที่นำกลับจากสาขาต่างประเทศหรือเซิร์ฟเวอร์ที่ตั้งเป็น UTC อย่าลืมแปลงเขตเวลา

flowchart TB
    accTitle: ข้อสมมติของการซิงค์เวลาและการสอบสวนแบบเทียบ
    accDescr: การสอบสวนที่เทียบบันทึกหลายเครื่องตามลำดับเวลาสมมติว่านาฬิกาของแต่ละเครื่องตรงกัน ความคลาดไม่กี่วินาทีก็ทำให้อ่านลำดับก่อนหลังผิด และหากคลาดเกินค่าเริ่มต้น 5 นาที การรับรอง Kerberos เองล้ม จึงใส่การตรวจซิงค์ของ w32time เป็นขั้นแรกของขั้นตอนสอบสวน
    merge["เทียบบันทึกหลายเครื่อง"] --> pre["นาฬิกาตรงกันเป็นข้อสมมติ"]
    pre --> skew{"นาฬิกาคลาดแค่ไหน?"}
    skew -->|ตรงกัน| ok["ไล่ตามลำดับเวลาได้"]
    skew -->|คลาดไม่กี่วินาที| misread["อ่านลำดับก่อนหลังผิด"]
    skew -->|เกินค่าเริ่มต้น 5 นาที| kerb["การรับรอง Kerberos ล้ม"]
    pre -.-> first["ตรวจ w32time เป็นขั้นแรกของขั้นตอน"]

ภาพ 20: การเทียบหลายเครื่องสมมติว่านาฬิกาตรงกัน ความคลาดไม่กี่วินาทีก็นำไปสู่การอ่านลำดับก่อนหลังผิด

8. สรุป

• นโยบายการตรวจสอบมีสองระบบ «พื้นฐาน» และ «ขั้นสูง» การผสมทำให้ผลคาดไม่ได้ รวมฝั่งขั้นสูง ตรวจสถานะปัจจุบันด้วย auditpol /get /category:* แล้วออกแบบจากตรงนั้น
• «เปิดทั้งหมด» ฆ่าการสอบสวนด้วยสัญญาณรบกวนและความพอง เริ่มจากคำแนะนำฐานของ Microsoft แล้วเดินตามตารางตัดสินในหมวด 3 ที่ยึดล็อกออน การจัดการบัญชี และการสร้างโพรเซส
• 4624 อ่านด้วยชนิดล็อกออน 4625 ด้วยรหัส Status/Sub Status 4740 ด้วย Caller Computer Name และ 4688 ด้วยโพรเซสแม่กับบรรทัดคำสั่ง — แต่ละเหตุการณ์มีฟิลด์เฉพาะที่ต้องดู
• ภาชนะของบันทึก (ขนาดสูงสุดและโหมดการเก็บ) คือครึ่งหนึ่งของการออกแบบการตรวจสอบ ตรวจจำนวนวันที่เก็บจริง กำหนดขนาดโดยคำนวณย้อนจากความต้องการ และส่งออกหรือรวบก่อนถูกทับ
• ตรวจความเสี่ยงที่ความลับปนก่อนเปิดการบันทึกบรรทัดคำสั่งของ 4688 ที่ที่แต่ละเหตุการณ์ถูกบันทึก และการซิงค์นาฬิกา เป็นข้อสมมติของการเทียบข้ามเครื่อง
• เริ่มสอบสวนด้วยตัวกรองของตัวแสดงเหตุการณ์ สลับไป Get-WinEvent -FilterHashtable เมื่อทำซ้ำ เก็บด้วย wevtutil epl อย่าพังลำดับ «เก็บก่อน แล้วค่อยวิเคราะห์»

บทความที่เกี่ยวข้อง

• สอบสวนบันทึกเหตุการณ์ในทางปฏิบัติด้วย Get-WinEvent — ความเร็วของการกรองกำหนดเวลาสอบสวน
• การเลิก NTLM จะทำแอปธุรกิจหยุดไหม — วิธีเก็บบันทึกการตรวจสอบ และลำดับการตัดการพึ่ง
• อธิบาย NTLM และ Kerberos ด้วยแผนภาพ — ทำไมการรับรองจึง «ตก» ไป NTLM
• ลายเซ็น SMB และ LDAP channel binding — ปิด «อีกครึ่ง» ของการป้องกัน NTLM ในทางปฏิบัติ
• แนะนำ Windows Event Log และ ETW — วางบันทึกแอปธุรกิจบนกลไกมาตรฐานของ OS
• แนะนำการเก็บดัมป์แครชของ Windows - WER/ProcDump/WinDbg

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับคำปรึกษาเรื่องนโยบายการตรวจสอบและการออกแบบบันทึกในสภาพแวดล้อม Windows การสอบสวน «เมื่อใด ใคร ทำอะไร» จากบันทึกเหตุการณ์ และการวิเคราะห์สาเหตุของปัญหาที่แอปธุรกิจเจอรอบการรับรองและการตรวจสอบ เริ่มจากขั้น «ถูกบอกให้ดูบันทึก แต่ไม่รู้จะเริ่มตรงไหน» ก็ได้

• ตรวจสอบบั๊กและหาสาเหตุ
• ที่ปรึกษาเทคนิคและรีวิวการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ไม่ได้ตั้งนโยบายการตรวจสอบเลย ทำไมบันทึก Security ยังมี 4624 และ 4625?

เพราะ Windows มีหมวดย่อยการตรวจสอบที่เปิดโดยค่าเริ่มต้น หมวดย่อย «ล็อกออน» ตัวอย่างเช่น เปิดทั้งสำเร็จและล้มเหลวโดยค่าเริ่มต้นตั้งแต่ Windows 10 เวอร์ชัน 1809 ดังนั้น 4624 (สำเร็จ) และ 4625 (ล้มเหลว) ถูกบันทึกแม้คุณไม่ได้ตั้งอะไรเอง แต่ถ้าปล่อยค่าเริ่มต้นไว้ เหตุการณ์จำนวนมากที่อยากได้ตอนสอบสวน — การตรวจข้อมูลรับรอง (4776) หรือการสร้างโพรเซส (4688) เป็นต้น — จะไม่ถูกบันทึก ตรวจว่าอะไรเปิดในสภาพแวดล้อมของตนเองด้วย `auditpol /get /category:*` จากนั้นแนวปฏิบัติคือเปิดหมวดย่อยที่ขาดอย่างชัดเจนฝั่งนโยบายการตรวจสอบขั้นสูง

อยากสอบสวนการลงชื่อเข้าใช้ที่ล้ม แต่หา 4625 ในบันทึก Security ของเซิร์ฟเวอร์เป้าหมายไม่เจอ ควรดูที่ไหน?

ยืนยันหลักก่อน: 4625 ถูกบันทึกบน «คอมพิวเตอร์ที่ถูกลองล็อกออน» การลงชื่อเข้าใช้ที่เครื่องผู้ใช้ล้ม ให้ดูเครื่องนั้น การเข้าถึงไฟล์เซิร์ฟเวอร์ล้ม ให้ดูไฟล์เซิร์ฟเวอร์ ต่อมาใช้ `auditpol /get /category:*` ตรวจว่าการตรวจสอบความล้มเหลวของหมวดย่อย «ล็อกออน» เปิดอยู่หรือไม่ สำหรับบัญชีโดเมน ร่องรอยมักไปอยู่ที่การตรวจข้อมูลรับรอง (4776) หรือความล้มเหลวของ Kerberos pre-authentication (4771) บนตัวควบคุมโดเมน และเมื่อระบุเครื่องไม่ได้ การเริ่มจากฝั่ง DC มักเร็วกว่า หากยังไม่เจอ ให้ตรวจว่าเหตุการณ์เก่าถูกทับไปแล้วหรือไม่ (เทียบขนาดสูงสุดของบันทึกกับเวลาของเหตุการณ์เก่าสุด)

ควรเปิดการบันทึกบรรทัดคำสั่งของการสร้างโพรเซส (4688) หรือไม่?

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

ขนาดสูงสุดของบันทึก Security ควรเท่าไร?

วิธีที่ถูกคือคำนวณย้อนจาก «อยากเก็บกี่วันไว้ในมือ» ไม่มีตัวเลขที่ใช้ได้ทุกที่ ตรวจค่าปัจจุบันและพฤติกรรมจริงด้วย `Get-WinEvent -ListLog Security` ผลต่างระหว่างเวลาของเหตุการณ์เก่าสุดกับเวลาปัจจุบันคือ «จำนวนวันที่เก็บจริงตอนนี้» การเพิ่มหมวดย่อยการตรวจสอบเพิ่มปริมาณเหตุการณ์ด้วย จึงต้องตรวจช่วงเก็บจริงนี้อีกครั้งหลังเปลี่ยนค่า การรับมือเหตุไม่ใช่เรื่องแปลกที่จะต้องการบันทึกหลายสัปดาห์ถึงหลายเดือนก่อน ดังนั้นการส่งออกเป็นระยะก่อนถูกทับ หรือรวบไปเครื่องอื่นด้วยกลไกเก็บบันทึก จะทำให้สบายใจกว่า

สอบสวนสาเหตุของการล็อกบัญชี (4740) อย่างไร?

เบาะแสแรกคือฟิลด์ «Caller Computer Name» ในเหตุการณ์ 4740 มันบันทึกคอมพิวเตอร์ที่เป็นต้นทางของการล็อกออนที่ล้มซึ่งทำให้เกิดการล็อก อย่างไรก็ตาม บันทึกความล้มเหลวเอง (4625) อยู่ฝั่งที่รับการลองล็อกออน ไม่ใช่เครื่องต้นทาง หากมาจากล็อกออนเครือข่าย ให้ไล่ตามเวลาผ่าน 4625 บนเซิร์ฟเวอร์ปลายทาง หรือถ้าเป็นบัญชีโดเมน ผ่าน 4776/4771 บนตัวควบคุมโดเมน พอระบุเครื่องต้นทางแล้ว ให้ไล่สิ่งที่ยังถือข้อมูลรับรองเก่าหลังเปลี่ยนรหัสผ่าน — ข้อมูลรับรองที่บันทึกไว้ เซสชัน Remote Desktop ที่ตัดค้าง หรือบริการหรืองานตามกำหนดเวลาที่ตั้งด้วยรหัสผ่านเก่า หากการล็อกเกิดซ้ำ ให้ตรวจด้วยว่าการซิงค์นาฬิกาคลาดหรือไม่

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก