Active Directory Log — เก็บอะไร ดูอะไร แจ้งเตือนอะไร
คู่มือเก็บ Log จาก Active Directory — Event ID ที่ต้องเก็บ คำสั่ง auditpol และ rule จับ brute force, password spray, Kerberoasting พร้อมวิธีส่ง log เข้า SIEM
Domain Controller ส่วนใหญ่ที่เดินอยู่ในองค์กรไทยตอนนี้ ตั้งค่า audit ไว้เท่าที่ Windows ให้มาตอนติดตั้ง แล้วก็ไม่มีใครแตะอีกเลย ปัญหาจะโผล่ตอนมีเหตุจริง — บัญชีผู้บริหารถูกใช้ตอนตีสาม หรือมี user ใหม่โผล่ใน Domain Admins โดยไม่มีใบขอสิทธิ์ — แล้วไล่ย้อนไม่ได้ เพราะ event ที่ต้องใช้ไม่เคยถูกเปิดให้บันทึกตั้งแต่แรก
ทำไม log จาก Active Directory ถึงสำคัญ
กันยายน 2024 หน่วยงานความมั่นคงไซเบอร์ 6 หน่วยจาก 5 ประเทศ — ACSC ของออสเตรเลีย ร่วมกับ NSA, CISA, Canadian Centre for Cyber Security, NCSC นิวซีแลนด์ และ NCSC สหราชอาณาจักร — ออกเอกสารร่วมชื่อ Detecting and Mitigating Active Directory Compromises ที่รวบรวมเทคนิคโจมตี AD ที่พบบ่อยที่สุดไว้ 17 เทคนิค เอกสารเขียนไว้ตรง ๆ ว่าผู้โจมตีพุ่งเป้าไปที่ AD เป็นเรื่องปกติ เพื่อยกระดับสิทธิ์และเข้าถึงบัญชีที่สำคัญที่สุดขององค์กร
เหตุผลง่ายมาก AD ถือบัญชี สิทธิ์ และนโยบายของทุกเครื่องในโดเมนไว้ที่เดียว ได้บัญชี Domain Admin มาบัญชีเดียวก็เท่ากับได้ทุกเครื่อง
อีกด้านเป็นเรื่องกฎหมาย มาตรา 26 แห่ง พ.ร.บ.คอมพิวเตอร์ฯ (พ.ศ. 2550 แก้ไขเพิ่มเติม พ.ศ. 2560) กำหนดให้ผู้ให้บริการเก็บข้อมูลจราจรทางคอมพิวเตอร์ไม่น้อยกว่า 90 วัน ส่วนว่า log การ login/logout จาก AD อยู่ในข้อมูลที่ต้องเก็บหรือไม่ ขึ้นกับประเภทผู้ให้บริการตามภาคผนวก ข ของประกาศกระทรวงดิจิทัลฯ พ.ศ. 2564 (รายละเอียดข้อกำหนดอยู่ในคู่มือเก็บ Log ตาม พ.ร.บ. คอมพิวเตอร์) แต่ 90 วันคือขั้นต่ำที่กฎหมายกำหนด ยังไม่ใช่ระยะเวลาที่พอสำหรับงานสืบสวน เคสที่เจอจริงมักต้องย้อนไปไกลกว่านั้นมาก
Event ID ที่ควรเก็บ
ตารางข้างล่างจัดกลุ่มตาม audit category ของ Windows ไม่ใช่ตามหัวข้อการโจมตี เพราะแต่ละกลุ่มตรงกับคำสั่ง auditpol หนึ่งบรรทัดในหัวข้อ "วิธีส่ง AD Log เข้า SIEM" พอดี ถ้าไม่เปิด category ตรงกลุ่มไหน event ในตารางกลุ่มนั้นก็จะไม่เกิดขึ้นเลย
ชื่อในคอลัมน์ "ความหมาย" ยึดตามชื่อที่ Microsoft ใช้จริงในเอกสาร ไม่ได้ตั้งเอง จะได้ค้นหาต่อได้ตรง
กลุ่ม Logon/Logoff — ใครเข้าเครื่องไหน เมื่อไหร่
| Event ID | ความหมาย | ความสำคัญ | สิ่งที่ต้องดูคู่กัน |
|---|
| 4624 | An account was successfully logged on | สูง | Logon Type — 2 = interactive หน้าเครื่อง, 3 = network, 10 = RemoteInteractive (RDP) |
| 4625 | An account failed to log on | สูงมาก | Status / Sub Status code |
| 4634 | An account was logged off (session สิ้นสุด) | ปานกลาง | คู่กับ 4647 (ผู้ใช้กด logoff เอง) มักเห็นทั้งสองตัว |
| 4648 | A logon was attempted using explicit credentials | ปานกลาง | ต้องทำ baseline ก่อนตั้ง alert |
| 4672 | Special privileges assigned to new logon | สูง (มีเงื่อนไข) | Subject\Security ID |
สามเรื่องที่ตารางเดี่ยว ๆ ไม่ได้บอก และเป็นเหตุผลที่ rule หลายที่ยิงพลาด
4624 ไม่ได้มี IP เสมอ เอกสารของ Microsoft ระบุไว้ตรง ๆ ว่าฟิลด์ IP address/port และ workstation name จะถูกเติมหรือไม่ ขึ้นกับ authentication context และ protocol ที่ใช้ — network logon ที่ผ่าน Kerberos มักไม่มีชื่อ workstation ส่วน NTLM logon มักไม่มีข้อมูล TCP/IP ใครที่เขียน rule แบบ "นับจาก IP เดียวกัน" ต้องรู้ข้อนี้ก่อน
4634 ไม่มีเวอร์ชัน "ล้มเหลว" ชื่อที่หลายบทความใช้คือ "Logoff สำเร็จ" ซึ่งไม่ตรง เพราะ event นี้ แปลว่า logon session นั้นสิ้นสุดลงแล้วเท่านั้น
4672 เกิดบ่อยกว่าที่คิดมาก มันเกิดตอน logon ทุกครั้งที่ session ใหม่ได้ sensitive privilege ตัวใดตัวหนึ่งใน 13 ตัว (SeDebugPrivilege, SeTcbPrivilege, SeBackupPrivilege ฯลฯ) และ Microsoft เขียนไว้เอง ว่าจะเห็น event นี้เยอะมาก เพราะทุกครั้งที่บัญชี SYSTEM logon ก็ยิง 4672 คำแนะนำของ Microsoft คือให้ alert เฉพาะกรณีที่ Subject\Security ID ไม่ใช่ LOCAL SYSTEM, NETWORK SERVICE หรือ LOCAL SERVICE ถ้าตั้งดิบ ๆ โดยไม่กรอง ทีมจะปิด rule นี้ภายในสัปดาห์เดียว
กลุ่ม Account Management — ใครแก้บัญชีและกลุ่มสิทธิ์
| Event ID | ความหมาย | ความสำคัญ |
|---|
| 4720 | A user account was created | สูง |
| 4722 | A user account was enabled (ครอบคลุม computer object ด้วย) | สูง |
| 4723 | An attempt was made to change an account's password (ผู้ใช้เปลี่ยนของตัวเอง) | ปานกลาง |
| 4724 | An attempt was made to reset an account's password (admin reset ให้คนอื่น) | สูง |
| 4725 | A user account was disabled | สูง |
| 4726 | A user account was deleted | สูงมาก |
| 4740 | A user account was locked out | สูง — ดูฟิลด์ Caller Computer Name |
| 4728 | A member was added to a security-enabled global group (เช่น Domain Admins) | สูงมาก |
| 4732 | A member was added to a security-enabled local group (บน DC คือ domain-local เช่น Builtin\Administrators, Account Operators) | สูงมาก |
| 4756 | A member was added to a security-enabled universal group (เช่น Enterprise Admins, Schema Admins) | สูงมาก |
จุดที่คนพลาดบ่อยที่สุดในตารางนี้คือ 4728/4732/4756 หลายที่เขียนว่า 4728 = "เพิ่มคนเข้า security group" เฉย ๆ ซึ่งกำกวมจนใช้งานไม่ได้ ทั้งสามตัวเป็น security group เหมือนกันหมด สิ่งที่ต่างกันคือ scope ของกลุ่ม — global, domain-local, universal ตามลำดับ (Microsoft รวมทั้งสามตัวไว้ในหน้า Audit Security Group Management หน้าเดียว โดย 4728 กับ 4756 ไม่มีหน้าของตัวเอง) ผลคือถ้าเฝ้าแต่ 4728 จะเห็นแค่คนที่ถูกเพิ่มเข้า Domain Admins แต่มองไม่เห็น Enterprise Admins กับ Schema Admins (universal → 4756) และไม่เห็น Builtin\Administrators บน DC (domain-local → 4732) ซึ่งเป็นเส้นทางสู่สิทธิ์สูงสุดเหมือนกันทั้งคู่
อีกข้อ 4740 ชื่อเหมือนจะอยู่ subcategory "Audit Account Lockout" แต่จริง ๆ อยู่ใน Audit User Account Management ส่วน subcategory ชื่อ Account Lockout นั้นเก็บ 4625 สลับกันอยู่ ถ้าเปิด audit แบบเจาะ subcategory ต้องระวังข้อนี้
กลุ่ม Account Logon — สำหรับบัญชีโดเมน เกิดบน Domain Controller
| Event ID | ความหมาย | ความสำคัญ |
|---|
| 4776 | The computer attempted to validate the credentials for an account (NTLM) | สูง — ดู Error Code |
| 4771 | Kerberos pre-authentication failed | สูงมาก — ดู Failure Code |
| 4769 | A Kerberos service ticket was requested | ปานกลาง — ปริมาณสูงมากเป็นปกติอยู่แล้ว |
กลุ่มนี้คือกลุ่มที่บทความ AD ส่วนใหญ่มักไม่พูดถึง และเป็นกลุ่มที่จำเป็นที่สุดถ้าจะจับ brute force บนโดเมนจริง ๆ
4625 ไม่ได้เกิดบน DC เสมอ Microsoft ระบุ ว่า 4625 เกิดบนเครื่องที่มีการพยายาม logon ดังนั้นบัญชีโดเมนที่ล้มเหลวผ่าน Kerberos จะไปโผล่บน DC เป็น 4771 ไม่ใช่ 4625 ส่วนฝั่ง NTLM จะเป็น 4776 ที่มี Error Code ไม่เท่ากับ 0x0 ใครตั้ง rule brute force ไว้ที่ 4625 อย่างเดียวแล้วชี้ไปที่ DC ก็เท่ากับเฝ้าประตูผิดบาน
code ที่ใช้แยกพฤติกรรม คนละชุดกันระหว่างสอง event ตรงนี้พลาดกันบ่อย เพราะ 4776 กับ 4771 ใช้ namespace ของ error code คนละอันเลย
- 4776 (NTLM) ใช้ Error Code แบบ Windows — 0xC0000064 = ไม่มี username นี้ในระบบ (คนกำลังไล่เดาชื่อบัญชี), 0xC000006A = username ถูกแต่ password ผิด, 0xC0000234 = บัญชีถูกล็อกอยู่
- 4771 (Kerberos) ใช้ Failure Code ตาม RFC 4120 — 0x18 KDC_ERR_PREAUTH_FAILED ที่เอกสารอธิบายว่า "The wrong password was provided" และ 0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN ที่แปลว่า client ไม่มีอยู่ใน Kerberos database ซึ่งใช้เป็นสัญญาณของการไล่เดาชื่อบัญชีได้ รหัสอย่าง 0xC000006A ไม่มีอยู่ใน namespace นี้ ใส่ลงไปใน rule ก็ไม่มีวันแมตช์
ข้อจำกัดของแต่ละตัวที่ควรรู้ 4776 เกิดบนเครื่องที่เป็นเจ้าของ credential — บัญชีโดเมนคือ DC ส่วนบัญชี local คือเครื่องนั้นเอง มันไม่เกิดเมื่อบัญชีโดเมน logon เข้าเครื่อง DC โดยตรง และมันมีแต่ชื่อเครื่องต้นทาง (Source Workstation) ไม่มี IP และไม่มีปลายทาง ส่วน 4771 ตรงกันข้าม — มีฟิลด์ Client Address เป็น IP มาให้ และ Microsoft แนะนำให้เฝ้าฟิลด์นี้ เช่น ไล่ดู 4771 ทุกตัวที่ Client Address ไม่ได้มาจากช่วง IP ภายในองค์กร
Alert 5 แบบที่ควรตั้ง
rule ข้างล่างเขียนแบบไม่ผูกกับยี่ห้อ SIEM ใด ๆ ใช้ได้กับระบบที่ correlate event ได้ทุกตัว (ถ้ายังไม่แน่ใจว่า SIEM ต่างจาก log management ตรงไหน อ่าน SIEM คืออะไร ก่อนได้)
ก่อนอื่น มีอยู่ข้อหนึ่งที่สำคัญกว่าตัว rule เอง — ตัวเลข threshold ทุกตัวข้างล่างเป็นจุดตั้งต้น ไม่ใช่ค่ามาตรฐาน ให้รันในโหมดเฝ้าดูอย่างน้อยสองสัปดาห์เพื่อทำ baseline ก่อนปล่อยให้มันโทรปลุกคนกลางดึก องค์กรที่มี batch job เยอะกับองค์กรที่ไม่มี ตัวเลขต่างกันคนละเรื่อง
1. Brute force ใส่บัญชีเดียว
Rule (Kerberos): 4771 Failure Code = 0x18 ที่ target account เดียวกัน > 10 ครั้ง ใน 5 นาที
Rule (NTLM): 4776 Error Code = 0xC000006A ที่ target account เดียวกัน > 10 ครั้ง ใน 5 นาที
Correlate: 4771 → ใช้ Client Address ได้เลย เป็นฟิลด์มาตรฐานของ event นี้
4776 → ไม่มี IP ให้ใช้ Source Workstation (ชื่อเครื่อง) + target account + Error Code แทน
Microsoft แนะนำในหน้าเอกสารของ 4771 เองว่า Failure Code 0x18 ที่เกิดซ้ำหลายครั้งในช่วงเวลาสั้น ๆ บ่งชี้ brute force โดยเฉพาะกับบัญชีที่สำคัญ
จุดบอดที่ต้องรู้ไว้ เอกสารหน้าเดียวกันระบุว่าบัญชีที่ตั้งตัวเลือก "Do not require Kerberos preauthentication" ไว้ จะไม่เกิด 4771 เลย ซึ่งเป็นบัญชีกลุ่มเดียวกับที่เสี่ยง AS-REP roasting พอดี บัญชีพวกนี้ต้องไล่ตรวจรายชื่อแยกต่างหาก จะหวังพึ่ง rule นี้ไม่ได้
2. บัญชี admin ใหม่โผล่ขึ้นมา
Rule: 4720 (สร้าง user) ตามด้วย 4728 หรือ 4732 หรือ 4756 ภายใน 1 ชั่วโมง
โดยกลุ่มปลายทางอยู่ใน watchlist กลุ่มสิทธิ์สูง
Watchlist ขั้นต่ำ: Domain Admins, Enterprise Admins, Schema Admins,
Builtin\Administrators, Account Operators, Backup Operators
เหตุผลที่ต้องมีครบสามตัวคือเรื่อง group scope ที่อธิบายไว้ข้างบน rule ที่ดูแค่ 4720 + 4728 จะพลาดสองในสามเส้นทางสู่สิทธิ์ระดับ forest
3. Logon นอกเวลาทำงาน
Rule: 4624 ระหว่าง 22:00–06:00
กรองก่อนเสมอ:
- เอาเฉพาะ Logon Type 2 (interactive) และ 10 (RemoteInteractive/RDP)
- ตัด machine account ทิ้ง (ชื่อลงท้ายด้วย $)
- ตัด SYSTEM, NETWORK SERVICE, LOCAL SERVICE ทิ้ง
ถ้าไม่กรองสามข้อนี้ rule จะยิงใส่ backup job, scheduled task และ service ทุกคืน จนไม่มีใครอ่าน อีกข้อที่มักลืม คือช่วงเวลานี้อิงนาฬิกาและ time zone ของ DC — องค์กรที่มีทีมทำงานต่างประเทศต้องคิดเรื่องนี้ก่อนตั้ง
4. Password spray
Rule: 4771 (0x18) หรือ 4776 (0xC000006A) จาก target account ที่ไม่ซ้ำกัน
ตั้งแต่ 15 บัญชีขึ้นไป ในหน้าต่างเวลา 30–60 นาที
แยกอีกหนึ่ง rule (ไล่เดาชื่อบัญชี): 4776 Error Code 0xC0000064
หรือ 4771 Failure Code 0x6
หน้าต่าง 1 นาทีที่เห็นบ่อยตามอินเทอร์เน็ตนั้นแคบเกินไป password spray ออกแบบมาให้ช้าเพื่อไม่ให้ชน lockout policy คนโจมตีจึงยิงบัญชีละครั้งแล้วรอ ตัวแปรที่ควรนับคือ จำนวนบัญชีที่ไม่ซ้ำกัน ไม่ใช่จำนวนครั้งทั้งหมด
5. Kerberoasting
Rule: 4769 ที่เข้าเงื่อนไขทั้งสามข้อพร้อมกัน
1) Ticket Encryption Type ไม่ใช่ 0x11 หรือ 0x12 (คือไม่ใช่ AES) — 0x17 คือ RC4-HMAC
2) Service Name เป็น user account ที่มี SPN (ไม่ใช่ computer account ที่ลงท้ายด้วย $)
3) account เดียวขอ Service Name ที่ไม่ซ้ำกันหลายตัวในเวลาสั้น ๆ
ข้อนี้คือ rule ที่บทความ AD ส่วนใหญ่เขียนผิด สูตรที่เจอบ่อยคือ "4769 ปริมาณสูงผิดปกติ" ซึ่งใช้ไม่ได้ เพราะ 4769 เกิดทุกครั้งที่ KDC ได้รับคำขอ service ticket และเอกสาร Microsoft จัดปริมาณ event ของ subcategory นี้ไว้ที่ระดับ "Very High บนเครื่อง KDC" อยู่แล้ว rule แบบนับปริมาณจะยิงตอนเช้าวันจันทร์ที่ทุกคน logon พร้อมกัน และยิงอีกทีตอน reboot หลัง patch
พูดตามตรง เงื่อนไขข้อ 1 เป็นตัว จัดลำดับความสำคัญ ไม่ใช่หลักฐาน ผู้โจมตีขอ AES ก็ได้ และองค์กรที่ยังเปิด RC4 อยู่ก็มี traffic RC4 ที่ถูกต้องตามปกติเข้าเงื่อนไขนี้ด้วย ข้อ 2 กับ 3 ต่างหากที่ทำให้ rule นี้ใช้ได้จริง
เรื่องที่เพิ่งเปลี่ยนและควรรู้ Windows Server 2016 ขึ้นไปที่ลง Security Cumulative Update ของ 14 มกราคม 2025 หรือใหม่กว่า จะมีฟิลด์เพิ่มใน 4769 เช่น ClientAdvertizedEncryptionTypes, ServiceSupportedEncryptionTypes และ SessionKeyEncryptionType ซึ่งเปิดทางให้เขียนเงื่อนไขที่คมกว่าเดิมมาก — client ประกาศว่ารองรับ AES แต่ ticket ที่ออกกลับเป็น RC4 อันนั้นใกล้เคียงตัวบ่งชี้จริงมากกว่าการดู encryption type เฉย ๆ
สุดท้าย ตอนเปิดดู 4769 จริงจะเจอ Failure Code 0x20 เต็มไปหมด อันนั้นแปลว่า service ticket หมดอายุ Microsoft ระบุเองว่าเป็นแค่ข้อความแจ้งสถานะ แทบไม่มีนัยสำคัญด้านความปลอดภัย กรองทิ้งตั้งแต่ต้นทางได้เลย
วิธีส่ง AD Log เข้า SIEM
ขั้นตอนที่ 1: เปิด audit policy บน Domain Controller
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Management" /success:enable /failure:enable
auditpol /set /category:"Account Logon" /success:enable /failure:enable
รูปแบบคำสั่งตรงตามเอกสาร auditpol /set ของ Microsoft และสามบรรทัดนี้ครอบคลุม Event ID ทุกตัวในสามตารางข้างบนครบ ไม่มีตัวไหนตกหล่น — รวมถึง 4769 ที่ rule Kerberoasting ใช้ ซึ่งได้มาจากบรรทัดที่สาม (subcategory Audit Kerberos Service Ticket Operations)
สี่ข้อที่ต้องรู้ก่อนพิมพ์ตามลงเครื่องจริง
/category: เป็นเครื่องมือแบบเหวี่ยงแห เปิด Logon/Logoff ทั้ง category แปลว่าเปิด Audit IPsec Main Mode, Quick Mode, Extended Mode, Network Policy Server และ Group Membership ตามไปด้วย ซึ่งเกินกว่า event ที่ต้องการไปมาก ถ้าอยากเปิดแบบเจาะจง ใช้ /subcategory: แทน แต่ต้องเปิดให้ครบทุก subcategory ที่ตารางข้างบนอ้างถึง ซึ่งมีทั้งหมดเก้าตัว
- Logon/Logoff → Logon, Logoff, Special Logon, Account Lockout
- Account Management → User Account Management, Security Group Management
- Account Logon → Credential Validation (4776), Kerberos Authentication Service (4771), Kerberos Service Ticket Operations (4769)
จุดที่พลาดกันบ่อยคือฝั่ง Account Logon ถ้าเปิดเฉพาะ Kerberos Service Ticket Operations จะได้ 4769 มา แต่ไม่ได้ 4771 กับ 4776 ซึ่งเป็นฐานของ rule ข้อ 1 และข้อ 4 ทั้งคู่ งานตรงนี้เสียเวลาเพิ่มไม่กี่นาที แต่บน DC ที่ทำงานหนัก มันคือความต่างระหว่าง feed ที่ทีมดูแลไหว กับบิล license ที่บานปลาย
/failure:enable บน Account Management แทบไม่ได้อะไรสำหรับ event กลุ่ม group Microsoft ระบุในหน้า Audit Security Group Management ว่า subcategory นี้ไม่มี Failure event จึงไม่แนะนำให้เปิด failure auditing
บรรทัดที่แพงที่สุดคือบรรทัดที่สาม ระดับปริมาณ event ที่ Microsoft ระบุไว้คือ Audit Security Group Management = Low, Audit Logon = Low บน client และ Medium บน DC หรือ network server ส่วน Audit Kerberos Service Ticket Operations = Very High บนเครื่อง KDC วางแผนพื้นที่กับ EPS เผื่อไว้ให้ถูกตั้งแต่แรก
auditpol เขียนลง local policy ถ้าองค์กรคุมด้วย Group Policy (Advanced Audit Policy Configuration) การ refresh GPO รอบถัดไปจะทับค่าที่พิมพ์ไปทั้งหมด สำหรับอะไรที่ไม่ใช่เครื่อง lab ให้ตั้งผ่าน GPO ไปเลย จะได้ไม่ต้องมานั่งงงว่าทำไม audit หายไปเอง
ขั้นตอนที่ 2: เลือกวิธีดึง event ออกจาก Windows
Windows ส่ง syslog เองไม่ได้ ทางเลือกจริง ๆ มีสองแบบ
ติดตั้ง agent/forwarder บนเครื่อง — ตัวที่คนไทยใช้กันมากคือ NXLog, winlogbeat หรือ agent ของ SIEM เอง อ่าน Windows Event Log แล้วส่งออกเป็น syslog ตรงไปที่ collector ซึ่งเป็นเส้นทางเดียวกับที่ใช้ส่ง log เข้า zcrLog
ใช้ WEC/WEF — Windows Event Collector และ Windows Event Forwarding เป็นกลไกในตัวของ Windows ที่ให้เครื่องต่าง ๆ ในโดเมนส่ง event ไปรวมที่ Windows collector เครื่องเดียว ข้อดีคือไม่ต้องลง agent ทุกเครื่อง ข้อควรรู้คือ WEF ส่งไปจบที่ Windows collector เท่านั้น ยังต้องมี forwarder อีกตัวบน collector นั้นเพื่อส่งต่อเข้า SIEM ที่รับ syslog ไม่ใช่เส้นทางตรงเข้า SIEM ในตัวเอง
ขั้นตอนที่ 3: ตั้ง retention ให้ยาวกว่าที่กฎหมายกำหนด
90 วันคือขั้นต่ำที่กฎหมายกำหนด ไม่ใช่หน้าต่างสำหรับงานสืบสวน เวลาต้องไล่ย้อนบัญชีที่ถูกยึด งานจริงคือเทียบพฤติกรรมของบัญชีนั้นกับช่วงก่อนหน้าที่ยาวกว่านั้นมาก ว่าอะไรผิดไปจากเดิมตั้งแต่เมื่อไหร่ และเมื่อ log ถูกลบไปแล้วก็ไม่มีทางย้อนกลับ ข้อเสนอของเราคือเก็บ authentication log ไว้ 365 วัน ส่วนระยะเวลาเก็บที่ทำได้จริงขึ้นกับแพ็กเกจและความจุที่เลือก ตัวเลขที่ประกาศไว้ดูได้ที่หน้าราคา
zcrLog กับ Active Directory — ทำอะไรได้จริงบ้าง
หน้าจอและฟิลด์ที่อธิบายข้างล่างเปิดดูได้จาก demo ไม่ต้องสมัครสมาชิก แค่ล็อกอินด้วยบัญชีเดโม (demo / demo) — แต่ต้องบอกไว้ก่อนว่าข้อมูลในนั้นเป็นชุดตัวอย่างสำหรับ demo ไม่ใช่ log จริงขององค์กรใด สิ่งที่ demo พิสูจน์ได้คือหน้าตาและฟิลด์ของระบบ ไม่ใช่ผลการ parse event จาก AD ของจริง
event จาก Windows รวมถึงจาก Domain Controller เข้าไปอยู่ใน System Logs และแยกฟิลด์ให้แล้ว ในหน้า Log Viewer แท็บ System Logs คอลัมน์ Source Type มี Windows อยู่ด้วย ปนกับ Linux Syslog, Sophos Firewall, Cisco ASA, Fortinet และ Palo Alto — event ที่ส่งเข้ามาไม่ได้กองอยู่เป็นข้อความดิบให้มานั่งไล่อ่านเอง แต่ถูกถอดออกมาเป็นคอลัมน์ให้กรองได้ทีละฟิลด์
คอลัมน์ที่เกี่ยวกับงาน AD โดยตรงคือ Event, User, Source Hostname, Source IP, Protocol, Application, Severity และ Action ส่วนตัวกรองมีให้ค้นตาม Username, Event ID, Source Device, Source IP / Hostname, Application, Protocol และ Severity — พอสำหรับงานไล่ย้อนแบบ "บัญชีนี้ทำอะไรบ้างในช่วงเวลานั้น" แถบสถานะบอกจำนวน hostname ที่ resolve ได้ และแสดงเวลาเป็น Asia/Bangkok ช่วงเวลาที่เลือกได้มีตั้งแต่ 5 นาทีถึง 24 ชั่วโมงและแบบกำหนดเอง พร้อม auto-refresh และโหมด Live
ฝั่ง cloud identity แยกเป็นแท็บของตัวเอง Microsoft Entra ID มีแท็บเฉพาะใน Log Viewer แบ่งเป็น Audit Logs กับ Sign-in Logs มีปุ่ม Sync Now และตัวกรองตาม Category, Status, Actor Email, Target Type ในหน้า Log Ingestion → Custom Integrations สถานะของ Entra ID คือ Available เช่นเดียวกับ SentinelOne ส่วน Google Workspace กับ Okta ยังเป็น Coming Soon (วิธีตั้งค่าฝั่งนี้อยู่ในบทความเก็บ Log จาก Microsoft Entra ID) นอกจากนี้ zcrLog ยังเก็บ audit log ของ Microsoft 365 (Exchange, SharePoint, Teams) ผ่าน Office 365 Management API ได้ด้วย และเก็บ log จาก AWS CloudTrail กับ CrowdStrike Falcon ได้แล้วเช่นกัน
ข้อจำกัดที่ต้องพูดให้ชัด สำหรับ AD แบบ on-premises ยังไม่มีรายการ integration แบบกดปุ่มเดียวเหมือนที่ Entra ID มี การส่ง Windows event เข้ามาเป็นงาน forwarding ผ่าน syslog หรือ agent ตามขั้นตอนที่ 2 ข้างบน — Windows ปรากฏเป็น source type ใน log stream ใครกำลังเทียบ SIEM หลายเจ้าอยู่ ควรถามคำถามเดียวกันนี้กับทุกเจ้า เพราะหลายรายเรียกทั้งสองอย่างว่า "รองรับ AD" เหมือนกันหมด
ดูราคาและแพ็กเกจ zcrLog →
ติดต่อ
ถ้าต้องการให้ช่วยดูว่า audit policy กับ retention ที่ตั้งอยู่ตอนนี้ครอบคลุมพอหรือยัง คุยกับทีมได้ที่
แหล่งอ้างอิง
