L-Flow›Agents›Windows

Windows Agent

Agent เดียวสำหรับทั้งเครื่อง Windows ทั่วไปและ Domain Controller (ตรวจสอบบทบาทให้อัตโนมัติ) — อ่าน Windows Event Log โดยตรงผ่าน API ของ Windows เอง แยกฟิลด์ข้อมูลออกมาเป็นโครงสร้างก่อนส่งเข้า L-Flow แทนการอาศัยซอฟต์แวร์ส่งต่อ log ของบุคคลที่สาม

Restriction:อยู่ระหว่างพัฒนา — ส่วนเก็บข้อมูล (collector) และการแปลงฟิลด์เขียนเสร็จแล้วและผ่านการตรวจสอบเชิงวิศวกรรม (compile/cross-compile ครบ) แต่ ยังไม่เปิดให้ลงทะเบียนเครื่องด้วยตนเอง (self-service enrollment) และยัง ไม่ผ่านการทดสอบใช้งานจริงบนเครื่อง Windows/Active Directory จริง — ติดต่อทีมงานหากต้องการเชื่อมต่อเครื่อง Windows หรือ Domain Controller ในตอนนี้

ภาพรวม

เครื่อง Windows ทั่วไป (workstation/member server) และ Domain Controller ใช้ agent ตัวเดียวกัน — เครื่องมือจะตรวจสอบเอง ว่าเครื่องนั้นเป็น Domain Controller หรือไม่ (จากค่า registry ของ Windows เอง) แล้วเปิดการเก็บข้อมูลเฉพาะ AD เพิ่มเติม โดยอัตโนมัติ ไม่ต้องเลือกตัวติดตั้งคนละตัวสำหรับสองกรณีนี้

รุ่นก่อนหน้าของระบบใช้ซอฟต์แวร์ส่งต่อ log ของบุคคลที่สาม (NXLog) ซึ่งอ่านได้แค่ 3 log หลัก (Security/System/Application) และไม่ได้แยกฟิลด์รายละเอียดออกมาเลย — ค้นหาได้แค่แบบเทียบข้อความในบรรทัด log เท่านั้น agent รุ่นใหม่อ่าน Windows Event Log ทุกช่อง (channel) ที่รองรับโดยตรง และแยกฟิลด์ (เช่น ชื่อผู้ใช้ ที่อยู่ IP ต้นทาง คำสั่งที่ถูกเรียก) ออกมาให้ค้นหาได้ ทันทีที่หน้า Explore

ข้อกำหนดเบื้องต้น: ต้องเปิด Audit Policy ก่อนเสมอ

Windows ปิดการบันทึกเหตุการณ์ด้านความปลอดภัยที่มีประโยชน์ไว้เกือบทั้งหมดโดยค่าเริ่มต้น (เช่น เครื่องที่เพิ่งติดตั้งใหม่ จะไม่มีการบันทึกการเรียกใช้โปรแกรม (process creation) เลย และแม้เปิดแล้วก็มักไม่มีบันทึกคำสั่งที่ใช้เรียก) — ไม่ว่า agent จะทำงานถูกต้องแค่ไหน ถ้าไม่เปิดตั้งค่านี้ก่อน จะไม่มีข้อมูลอะไรให้เก็บเลย

  • ต้องเปิด Advanced Audit Policy หลายหมวด (Kerberos, Account Management, Logon/Logoff, Object Access ฯลฯ) ผ่าน Group Policy หรือ auditpol โดยตรงบนเครื่องที่ไม่ได้อยู่ใน domain
  • ต้องเปิดค่า “บันทึกคำสั่งที่ใช้เรียกโปรแกรม” (Include command line in process creation events) แยกต่างหาก — ไม่อยู่ใน Audit Policy ปกติ
  • สำหรับ Domain Controller: ต้องตั้งค่า SACL บนออบเจกต์ domain root เพื่อให้ตรวจจับการทำ DCSync ได้ (เป็นการเปลี่ยนแปลงระดับ Active Directory ทั้งโดเมน ต้องทำโดยผู้ดูแลระบบเอง ไม่ใช่สิ่งที่ agent ทำให้อัตโนมัติ)
Note:มีสคริปต์ PowerShell (Enable-LFlowAuditPolicy.ps1) ช่วยเปิดตั้งค่าเหล่านี้ให้อัตโนมัติ (ยกเว้นขั้นตอน SACL ของ Domain Controller ซึ่งจะแสดงคำสั่งให้ผู้ดูแลระบบนำไปรันเองเพื่อยืนยันก่อนเสมอ) — ยังไม่เผยแพร่ผ่านหน้าตั้งค่าเอเจนต์ ในระบบ ติดต่อทีมงานเพื่อขอสคริปต์นี้ในระหว่างที่ยังไม่เปิดให้ดาวน์โหลดเอง

สิ่งที่ Agent เก็บ

ทุกเครื่อง Windows (ทั่วไปหรือ Domain Controller) เก็บข้อมูลจากช่อง Windows Event Log ต่อไปนี้ — ช่องที่ไม่มีอยู่จริงบนเครื่องนั้น (เช่น ไม่ได้ลง Sysmon) จะถูกข้ามไปเฉยๆ ไม่กระทบช่องอื่น

แหล่งข้อมูลในเครื่องSecurity / System / AppSysmon (ถ้าติดตั้ง)ช่อง AD เฉพาะ DCPowerShell, Defender ฯลฯEvtSubscribeL-Flow Agentแยกฟิลด์ข้อมูลจาก EventData ทันทีไม่ใช่ข้อความดิบHTTPSL-Flow Platformแปลงเป็นรูปแบบมาตรฐาน (ECS)จัดเก็บ ค้นหาและแจ้งเตือน
Windows Event Log และ Sysmon (ถ้าติดตั้ง) ถูกอ่านโดย agent ผ่าน EvtSubscribe API ของ Windows เอง แล้วส่งต่อไปยัง L-Flow ผ่าน HTTPS เท่านั้น
แหล่งข้อมูลเก็บอะไร
Securityการ logon/logoff, การเรียกใช้โปรแกรม (พร้อมคำสั่งที่ใช้เรียก เมื่อเปิดตั้งค่าไว้), การจัดการบัญชี/กลุ่มผู้ใช้, สิทธิพิเศษ, Kerberos ticket
Systemบริการที่ถูกติดตั้งใหม่ (สัญญาณการแพร่กระจายในเครือข่ายแบบ PsExec), บริการล่ม, การปิด/เปิดเครื่อง
Applicationเหตุการณ์ทั่วไปของแอปพลิเคชันบนเครื่อง
Windows Defenderผลตรวจพบมัลแวร์และการปิดระบบป้องกันไวรัส
Windows Firewallการเปลี่ยนกฎ firewall ของเครื่อง
Terminal Services (RDP)การ logon ผ่าน RDP และการเริ่ม/ต่อ session ระยะไกล
PowerShellคำสั่ง/สคริปต์ PowerShell ที่ถูกรัน (script block logging) — ตัดความยาวก่อนเก็บเพื่อจำกัดขนาด
WMI-Activity / Task Schedulerการใช้งาน WMI และตั้งเวลาโปรแกรม — ช่องทางที่มัลแวร์มักใช้ฝังตัว

Sysmon (แนะนำให้ติดตั้งเพิ่ม)

Sysmon (Sysinternals) เป็นโปรแกรมแยกต่างหากที่ agent อาศัยแทนการทำระบบตรวจจับระดับ kernel เองใหม่ — ถ้าติดตั้ง Sysmon ไว้บนเครื่อง agent จะอ่านช่อง Microsoft-Windows-Sysmon/Operational เพิ่มโดยอัตโนมัติ ได้ข้อมูลละเอียดกว่า log มาตรฐานมาก:

  • สายการเรียกโปรแกรม (process lineage) พร้อม hash ไฟล์ และโปรแกรมต้นทาง/ปลายทาง
  • การเชื่อมต่อเครือข่ายระดับ process
  • การเปิด handle ไปยัง lsass.exe — สัญญาณของการพยายามดึงรหัสผ่านจากหน่วยความจำ
  • การสร้าง/แก้ไข registry key ในตำแหน่งที่มัลแวร์มักใช้ฝังตัว (Run key, Winlogon, services)
  • การสร้าง named pipe, เหตุการณ์ WMI persistence, และการ query DNS ระดับ process
Note:Sysmon ไม่ใช่ข้อบังคับ — เครื่องที่ไม่ได้ติดตั้งจะยังคงได้ข้อมูลจาก Security/System/Application ตามปกติ เพียงแต่จะไม่มี รายละเอียดระดับ process/registry/DNS ข้างต้น

เฉพาะ Domain Controller

เมื่อ agent ตรวจพบว่าเครื่องเป็น Domain Controller จะเปิดการเก็บข้อมูลเพิ่มเติมโดยอัตโนมัติ (เปลี่ยนค่าบังคับเปิด/ปิดเองได้ ภายหลังจากหน้าตั้งค่าเครื่อง หากต้องการ):

แหล่งข้อมูลใช้ตรวจจับอะไร
Directory Service / DFS Replicationสุขภาพโครงสร้างพื้นฐาน AD และการทำงานของ SYSVOL
DNS Server (Analytical/Audit)ความผิดปกติของ DNS ที่ผูกกับ AD
Security (4768/4769)Kerberoasting และ AS-REP roasting — จากรูปแบบการขอ ticket ที่ผิดปกติ
Security (4662 พร้อม SACL)DCSync — การพยายามคัดลอกฐานข้อมูล AD ทั้งหมดผ่านสิทธิ replication
Security (4728/4729/4732/4733/4756/4757)การเปลี่ยนสมาชิกกลุ่มสิทธิ์สูง เช่น Domain Admins

การตรวจจับที่เตรียมไว้ให้แล้ว

เมื่อข้อมูลไหลเข้าระบบแล้ว มีชุดกฎแจ้งเตือนสำเร็จรูปให้เลือกใช้ได้ทันทีจากหน้า Alert Rules → สร้างกฎใหม่ (หมวด Windows ในตัวเลือก Sigma catalog และหมวด Correlation/Baseline ในตัวเลือก preset) — ไม่ต้องเขียนเงื่อนไขเอง:

กฎตรวจจับอะไรระดับความรุนแรง
Kerberoastingจำนวนคำขอ service ticket แบบเข้ารหัส RC4 ต่อบัญชีสูงผิดปกติในเวลาสั้นๆสูง
AS-REP Roastingบัญชีที่ปิด Kerberos pre-authentication ถูกขอ TGT ซ้ำหลายครั้งสูง
DCSyncมีการใช้สิทธิ replication ของ AD นอกรูปแบบการ replicate ปกติวิกฤต
เปลี่ยนสมาชิกกลุ่มสิทธิ์สูงมีผู้ถูกเพิ่มเข้ากลุ่ม Domain Admins/Enterprise Admins/Schema Admins/Administratorsวิกฤต
Password Sprayหนึ่ง IP พยายาม logon ผิดกับหลายบัญชีในเวลาสั้นๆสูง
เปิด process ตรวจสอบ LSASSมีการเปิด handle ไปยัง lsass.exe (ต้องมี Sysmon)วิกฤต
PowerShell ที่น่าสงสัยscript block มีคำสำคัญที่เจอบ่อยใน offensive tooling (DownloadString, IEX, EncodedCommand ฯลฯ)กลาง
Brute-force แล้วสำเร็จ (correlation)บัญชีเดียวกัน logon ผิดหลายครั้ง แล้วสำเร็จจาก IP อื่นในเวลาไม่นานสูง
ติดตั้งบริการใหม่ผิดปกติ (baseline)อัตราการติดตั้งบริการใหม่ของเครื่องหนึ่งสูงกว่าค่าปกติของเครื่องนั้นเองมากสูง
Note:กฎเหล่านี้เป็นจุดเริ่มต้นที่ดี ไม่ใช่การตรวจจับที่สมบูรณ์แบบในตัวเอง — เช่น กฎ PowerShell ตรวจจากคำสำคัญ อาจพลาด script ที่ถูกทำให้อ่านยาก (obfuscate) และกฎ DCSync/สมาชิกกลุ่มสิทธิ์สูงต้องเปิด Audit Policy ตามหัวข้อด้านบนก่อนจึงจะมีข้อมูลให้ตรวจจับ

หน้าจัดการเครื่องในระบบ

เมื่อเครื่อง Windows ลงทะเบียนแล้ว จะมีหน้าจัดการชุดเดียวกับที่ Linux agent มีอยู่แล้ว เข้าถึงได้จากเมนู คอมพิวเตอร์และเซิร์ฟเวอร์ → Windows:

  • รายชื่อเครื่อง— สถานะออนไลน์/ล่าช้า/ขาดการติดต่อของแต่ละเครื่อง เวอร์ชัน agent ที่รายงานล่าสุด ป้าย “Domain Controller” เมื่อเครื่องนั้นตรวจพบบทบาทจริง (ไม่ใช่แค่ตั้งค่าไว้) และปุ่มบังคับเปิด/ปิดการเก็บข้อมูล เฉพาะ AD รายเครื่อง สำหรับกรณีที่การตรวจสอบอัตโนมัติผิดพลาด
  • สถานะ collector รายเครื่อง — เทียบสิ่งที่ตั้งค่าไว้ (เช่น เปิดเก็บช่อง Sysmon) กับสิ่งที่ agent รายงานว่า กำลังทำงานจริงในการ poll ล่าสุด เห็นทันทีถ้าช่องไหนตั้งใจเปิดไว้แต่ไม่ได้ทำงานจริง (เช่น เครื่องยังไม่ได้ลง Sysmon)

ความปลอดภัยและความน่าเชื่อถือของเครื่อง

  • Agent รันเป็น Windows Service จริง ไม่ใช่โปรแกรมที่ต้องเปิดค้างไว้ — พร้อมระบบ รีสตาร์ตอัตโนมัติ เมื่อล่ม โดยเว้นระยะเวลาเพิ่มขึ้นทีละครั้ง (5 วินาที, 30 วินาที, 60 วินาที) เพื่อไม่ให้วนซ้ำถี่เกินไปหากมีปัญหาต่อเนื่อง
  • ไม่ว่า log จะเยอะแค่ไหน agent ใช้หน่วยความจำเกิน 256 MB และมี process ในตัวเกิน 128ไม่ได้ — เพดานถูกบังคับโดย Windows Job Object ระดับ OS เดียวกับที่ container runtime ใช้ ดูรายละเอียดที่หัวข้อ “การใช้ ทรัพยากรของเครื่อง” ด้านล่าง
  • เนื่องจากต้องการสิทธิ์อ่าน log ความปลอดภัยแบบเต็มรูปแบบและติดตั้ง/แก้ไขบริการของเครื่อง agent จึงรันด้วยสิทธิ์ LocalSystem (สิทธิ์สูงสุดของเครื่อง) ตลอดเวลา — ระบุไว้ตรงนี้อย่างชัดเจนแทนที่จะละไว้ เนื่องจากต่างจาก Linux agent ที่จำกัดสิทธิ์เฉพาะสิ่งที่จำเป็นในการทำงานปกติ และใช้สิทธิ์เต็มรูปแบบเฉพาะตอนติดตั้ง/อัปเดตเท่านั้น

การอัปเดต

ปัจจุบันการอัปเดตอัตโนมัติ (self-update) ปิดไว้เป็นค่าเริ่มต้นจนกว่าจะผ่านการทดสอบใช้งานจริงบนเครื่อง Windows — เมื่อเปิดใช้ งานแล้ว ขั้นตอนจะเป็นดังนี้:

Agent (เวอร์ชันเดิม)ตัวช่วยสลับไฟล์Windows Service1. ดาวน์โหลดไฟล์ใหม่2. สร้างตัวช่วยสลับไฟล์3. แจ้งหยุดทำงานตามปกติ (ไม่ใช่ล่ม)4. รอจนกระบวนการเดิมออกจากหน่วยความจำหมด5. สลับไฟล์เก่า/ใหม่ (เก็บไฟล์เก่าไว้เผื่อย้อนกลับ)6. สั่งเริ่มบริการใหม่7. เวอร์ชันใหม่เริ่มทำงาน8. ตรวจสอบตัวเอง
Windows ล็อกไฟล์ที่กำลังรันอยู่ จึงต้องใช้ตัวช่วยแยกกระบวนการสลับไฟล์แทนการเขียนทับตัวเองตรงๆ แบบ Linux — ทุกไฟล์ที่ดาวน์โหลดมาต้องผ่านการตรวจสอบก่อนใช้งานเสมอ เหมือนฝั่ง Linux

Windows ล็อกไฟล์ของโปรแกรมที่กำลังรันอยู่ ทำให้ agent เขียนทับตัวเองตรงๆ แบบที่ Linux agent ทำไม่ได้ — จึงต้องใช้ตัวช่วย แยกกระบวนการทำหน้าที่สลับไฟล์แทน แต่หลักการตรวจสอบยังเหมือนกันทุกประการ: ไฟล์ที่ดาวน์โหลดมาต้องผ่านการตรวจสอบ checksum และลายเซ็นดิจิทัลก่อนใช้งานเสมอ และถ้าเวอร์ชันใหม่เริ่มทำงานไม่สำเร็จ ระบบจะย้อนกลับไปเวอร์ชันเดิมโดยอัตโนมัติ

Note:Agent เชื่อมต่อกลับหา L-Flow ผ่าน HTTPS เท่านั้น เพื่อป้องกันไม่ให้ค่าที่ได้รับระหว่างทางถูกดักเปลี่ยน — เหมือนกับ Linux agent

ข้อกำหนดของเครื่อง

  • สถาปัตยกรรม amd64 (ยังไม่รองรับ arm64 สำหรับ Windows)
  • Windows Server 2016 ขึ้นไป หรือ Windows 10/11 — มาพร้อม PowerShell 5.1 ขึ้นไปอยู่แล้วทุกเวอร์ชันที่รองรับ
  • สิทธิ์ Administrator สำหรับการติดตั้งและรันบริการ
  • เชื่อมต่ออินเทอร์เน็ตออกไปยังโดเมนของ L-Flow ได้ (HTTPS)
  • เปิด Advanced Audit Policy ตามหัวข้อ “ข้อกำหนดเบื้องต้น” ด้านบนก่อนติดตั้งเสมอ — ข้ามขั้นตอนนี้แล้วจะไม่มีข้อมูล อะไรให้เก็บเลยไม่ว่า agent จะทำงานถูกต้องแค่ไหน

ซอฟต์แวร์ที่ต้องมีบนเครื่อง

Agent เป็นไฟล์ปฏิบัติการเดียว — ไม่ต้องติดตั้ง runtime หรือไลบรารีเพิ่มเพื่อให้ agent เองทำงาน มีเพียงสิ่งที่ตัวติดตั้ง (installer) เองต้องใช้หรือจะติดตั้งให้:

ซอฟต์แวร์ใช้ทำอะไร
PowerShell 5.1 ขึ้นไปมาพร้อมทุกเวอร์ชัน Windows ที่รองรับอยู่แล้ว — ใช้รันตัวติดตั้งเท่านั้น ไม่จำเป็นต้องมีขณะ agent ทำงานปกติ
Sysmon (Sysinternals)ไม่บังคับ แต่แนะนำอย่างยิ่ง — ตัวติดตั้งดาวน์โหลดและติดตั้งให้อัตโนมัติจาก Microsoft Sysinternals พร้อมคอนฟิกที่ปรับแต่งมาให้แล้ว เว้นแต่จะสั่งข้ามขั้นตอนนี้

การใช้ทรัพยากรของเครื่อง

ค่าเพดานด้านล่างถูกบังคับโดย Windows Job Object ระดับ OS — agent ใช้ทรัพยากรเกินนี้ไม่ได้ไม่ว่ากรณีใด

เครื่อง Windows เดียวกันL-Flow AgentRAM ≤ 256 MBProcess ในตัว ≤ 128ยังไม่มีเพดาน CPU บังคับบริการอื่นบนเครื่องเดียวกันเช่น Active Directory, ไฟล์เซิร์ฟเวอร์, แอปพลิเคชันของคุณใช้ทรัพยากรที่เหลือได้ตามปกติ ไม่ถูกแย่งหน่วยความจำไปโดย agent
เพดานถูกบังคับโดย Windows Job Object ระดับ OS เดียวกับที่ container runtime ใช้ — agent ข้ามเพดานนี้ไม่ได้ไม่ว่าปริมาณ log จะมากแค่ไหน
ทรัพยากรเพดาน
หน่วยความจำ (RAM)256 MB
จำนวน process ในตัว (Tasks)128
CPUยังไม่มีเพดานบังคับในรุ่นนี้ — Windows เก็บค่านี้ไว้ในโครงสร้างข้อมูลที่ซับซ้อนกว่าหน่วยความจำ/จำนวน process มาก จึงยังไม่ทำในรอบนี้ (ดูรายละเอียดทางเทคนิคใน to-do/windows-ad-agent.md)
ดิสก์ (log สำรองในเครื่อง)ไม่เกินประมาณ 30 MB — หมุนเวียนอัตโนมัติที่ 10 MB × 3 ชุด และเก็บไม่เกิน 7 วัน เหมือนกับ Linux agent

การใช้งานจริงต่ำกว่าเพดานมากในสภาวะปกติ ตัวเลขข้างต้นคือค่าสูงสุดที่เป็นไปได้เท่านั้น ไม่ใช่การใช้งานทั่วไป

ฟิลด์ ECS และตัวอย่างการค้นหา

Event ทุกช่องถูกแปลงเป็นชื่อ field มาตรฐานเดียวกัน (ECS) ก่อนเก็บ เหมือนกับ log จากอุปกรณ์อื่นทั้งหมดในระบบ — นำชื่อ field ในตารางด้านล่างไปกรองต่อได้ทันทีที่หน้า Explore

ที่มาฟิลด์ ECS หลักตัวอย่างการค้นหา
Logon สำเร็จ/ล้มเหลว (4624/4625)user.name, source.ip, winlog.logon.typetype:auth AND event.action:logon_failed
การเรียกโปรแกรม (4688)process.executable, process.command_line, process.parent.executableevent.action:process_start
บริการติดตั้งใหม่ (7045)service.name, file.pathevent.action:service_installed
Sysmon — process/networkprocess.command_line, file.hash.sha256, destination.iptags:lsass_access
PowerShell script block (4104)powershell.script_block_texttype:winevent AND event.action:powershell_script_block

รายการฟิลด์ทั้งหมดตาม Event ID และความหมายของแต่ละค่า ดูที่ ฟิลด์ของ Windows

ลำดับการเปิดใช้งาน (สำหรับผู้ที่ติดต่อทีมงานล่วงหน้า)

เมื่อเปิดให้ใช้งานจริง ลำดับขั้นตอนจะเป็นดังนี้ — เรียงตามลำดับ เพราะข้ามขั้นตอนแรกแล้วขั้นตอนหลังจะไม่มีข้อมูลให้เก็บ:

  1. เปิด Audit Policy บนเครื่องรันสคริปต์ที่ทีมงานให้มา หรือปรับผ่าน Group Policy เอง ตามหัวข้อ “ข้อกำหนดเบื้องต้น” ด้านบน
  2. (แนะนำ) ติดตั้ง Sysmonให้รายละเอียดระดับ process/registry/DNS เพิ่มเติมตามหัวข้อ “Sysmon” ด้านบน
  3. ติดตั้งและลงทะเบียน agentยังไม่เปิดให้ทำเองในตอนนี้ — ทีมงานจะติดต่อกลับพร้อมขั้นตอนเมื่อพร้อมใช้งาน