ITDR (identity threat detection and response) คือชุดเครื่องมือและแนวปฏิบัติสำหรับตรวจจับ สืบสวน และตอบสนองการโจมตีที่มุ่งเป้าไปที่ตัวตน ตัวตนในที่นี้หมายถึงบัญชีผู้ใช้ โทเค็น (token ข้อมูลที่ระบบออกให้หลัง login เพื่อใช้พิสูจน์ว่าผ่านการยืนยันตัวตนแล้ว) และระบบที่ออกสิทธิ์การเข้าใช้ เช่น Active Directory (ระบบบัญชีผู้ใช้ส่วนกลางขององค์กร) หรือ identity provider (ผู้ให้บริการยืนยันตัวตน) เหตุผลที่ต้องมีคือผู้โจมตีจำนวนมากไม่ได้เจาะระบบเข้ามา แต่ login ด้วยบัญชีที่ถูกต้อง เครื่องมือที่เน้นจับมัลแวร์และดูทราฟฟิกจึงอาจไม่เห็นอะไรผิดปกติ บทความนี้อธิบายการตรวจจับภัยคุกคามต่อตัวตน (ITDR) แบบไม่ผูกกับผู้ผลิตรายใด ตั้งแต่สิ่งที่ผู้โจมตีทำ สัญญาณที่ควรเฝ้าดู ไปจนถึงขั้นแรกที่เริ่มทำได้

ITDR ทำอะไรบ้าง

ITDR เป็นคำที่อุตสาหกรรมใช้กัน แหล่งข้อมูลรองส่วนใหญ่ระบุว่า Gartner ทำให้คำนี้แพร่หลายราวปี 2022 นิยามจึงต่างกันไปตามผู้ผลิตแต่ละราย เอกสารของ Microsoft Defender for Identity เป็นตัวอย่างที่เห็นภาพ เครื่องมือนี้ติดตั้ง sensor (ตัวเก็บสัญญาณ) บนระบบที่ดูแลตัวตน เพื่อเฝ้าดูสัญญาณจาก Active Directory ในองค์กร Microsoft Entra ID และระบบ IAM อื่น เช่น Okta จากนั้นวิเคราะห์ด้วยการวิเคราะห์พฤติกรรม threat intelligence (ข้อมูลข่าวกรองภัยคุกคาม) และรูปแบบการโจมตีที่รู้จัก ITDR ทำงานเสริมกับ IAM (ระบบบริหารตัวตนและสิทธิ์), PAM (ระบบควบคุมบัญชีที่มีสิทธิ์สูง), EDR (ระบบตรวจจับและตอบสนองบนเครื่องปลายทาง) และ SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) ไม่ได้มาแทนที่ระบบเหล่านี้

  • ลดพื้นที่โจมตี: ประเมินการตั้งค่าที่เสี่ยงและเส้นทางที่ผู้โจมตีใช้เคลื่อนที่ต่อภายในเครือข่าย (lateral movement) ตั้งแต่ก่อนที่จะถูกใช้จริง
  • ตรวจจับ: ใช้การวิเคราะห์พฤติกรรมและเชื่อมโยงสัญญาณหลายอย่างเข้าด้วยกัน แทนที่จะดูเหตุการณ์ครั้งเดียวแยก ๆ
  • สืบสวน: ให้บริบทประกอบ เช่น มีตัวตนใดเกี่ยวข้อง มีกิจกรรมอะไรเกิดขึ้นใกล้เคียง และผู้โจมตีใช้เทคนิคอะไร
  • ตอบสนอง: เพิกถอน session (ทำให้การ login ที่ค้างอยู่ใช้ต่อไม่ได้) รีเซ็ตรหัสผ่าน หรือปิดบัญชี ผ่านระบบตัวตนหรือคิวเหตุการณ์ของทีม SOC (ศูนย์เฝ้าระวังและตอบสนองเหตุการณ์ความปลอดภัย)

ผู้โจมตีทำอะไรกับตัวตน

MITRE ATT&CK (ฐานความรู้ที่รวบรวมกลยุทธ์และเทคนิคของผู้โจมตี) จัดหมวด Credential Access (TA0006) ไว้เป็นกลยุทธ์ (tactic) ที่ผู้โจมตีพยายามขโมยชื่อบัญชีและรหัสผ่าน ณ ตุลาคม 2026 หมวดนี้มี 18 เทคนิคระดับบนสุด นอกจากนี้ ASD ACSC ของออสเตรเลียร่วมกับ CISA (หน่วยงานด้านความมั่นคงไซเบอร์ของสหรัฐฯ) NSA และหน่วยงานของแคนาดา สหราชอาณาจักร และนิวซีแลนด์ ได้เผยแพร่แนวทางเรื่อง 17 เทคนิคที่ใช้บ่อยในการยึด Active Directory ตัวอย่างที่พบบ่อยมีดังนี้

  • เดาหรือขโมยรหัสผ่าน: เช่น brute force (ลองรหัสผ่านไปเรื่อย ๆ) และ password spray (ลองรหัสผ่านที่พบบ่อยกับหลายบัญชี)
  • ผ่าน MFA ด้วยการรบกวนผู้ใช้: เทคนิค MFA Request Generation (T1621) คือการส่งคำขอยืนยันตัวตนผ่าน MFA (การยืนยันตัวตนหลายขั้นตอน) ซ้ำ ๆ จนผู้ใช้กดอนุมัติ MITRE ระบุว่ากลุ่ม APT29, LAPSUS$ และ Scattered Spider เคยใช้เทคนิคนี้
  • ขโมยโทเค็นหรือ session cookie: เช่น เทคนิค T1528 และ T1539 ถ้าผู้โจมตีนำ session ที่ผู้ใช้ login ไว้แล้วมาใช้ซ้ำ (replay) ได้ ก็ไม่ต้องผ่าน MFA อีก
  • ใช้ Kerberos ในทางที่ผิด: Kerberos คือโปรโตคอลยืนยันตัวตนที่ Active Directory ใช้ Kerberoasting (T1558.003) คือการขอ service ticket (ตั๋วเข้าใช้บริการ) แล้วนำไปแคร็กรหัสผ่านของ service account (บัญชีที่ระบบใช้รันบริการ) แบบออฟไลน์ DCSync (T1003.006) คือการเลียนแบบการ replicate (ซิงก์ข้อมูลบัญชี) ของ domain controller (เครื่องที่ดูแลบัญชีของทั้งโดเมน) เพื่อดึง password hash (ค่าที่แปลงจากรหัสผ่าน) ส่วน Golden Ticket (T1558.001) คือการปลอม TGT (ตั๋วใบแรกที่ใช้ขอเข้าใช้บริการอื่น) ซึ่งทำได้เมื่อผู้โจมตีรู้ hash ของบัญชี KRBTGT
  • หลอก help desk: ตามคำเตือน AA23-320A ของ CISA กลุ่ม Scattered Spider แอบอ้างเป็นพนักงานเพื่อให้ help desk รีเซ็ตรหัสผ่านและย้าย MFA ไปยังอุปกรณ์ที่ตนควบคุม นอกจากนี้ยังใช้ SIM swap (ย้ายเบอร์โทรไปยังซิมของผู้โจมตี) และลงทะเบียน MFA ของตัวเองด้วย
  • สร้างทางเข้าถาวรบนคลาวด์: ตาม ATT&CK T1078.004 ผู้โจมตีสร้างข้อมูลรับรองการเข้าใช้ (credential) ชุดเพิ่มที่ใช้ได้นานและอาจข้าม MFA ได้ อีกทั้งใช้ประโยชน์จาก role ที่กำหนดสิทธิ์ผิดพลาดเพื่อยกระดับสิทธิ์
INFOGRAPHIC
เส้นทางการโจมตีผ่านตัวตน และจุดที่ตัดวงจรได้
01
ได้บัญชีแรก
เดารหัส ฟิชชิง หลอก help desk
02
ยกระดับสิทธิ์
Kerberoasting, role ตั้งผิด
03
ยึดโดเมน
DCSync, Golden Ticket
04
อยู่ในระบบต่อ
เพิ่ม MFA และ credential ของตน
05
ITDR
ตัดวงจรได้ทุกขั้นตอน

สัญญาณที่ ITDR มองหา

  • ระดับการลงชื่อเข้าใช้: Entra ID Protection (ฟีเจอร์ตรวจความเสี่ยงของ Microsoft Entra ID) มี risk detection (การตรวจจับความเสี่ยง) หลายแบบ เช่น password spray (แจ้งเมื่อผู้โจมตีเดารหัสผ่านถูกอย่างน้อยหนึ่งบัญชี) anomalous token (token ที่มีลักษณะผิดปกติ เช่น อายุผิดปกติ หรือถูกนำมาใช้ซ้ำจากที่ที่ไม่คุ้นเคย) suspicious MFA authentication approval (การอนุมัติ MFA ที่น่าสงสัย) และ leaked credentials (พบข้อมูลรับรองที่ใช้ได้จริงในข้อมูลที่รั่วไหล)
  • ระดับ Active Directory: Defender for Identity จัดการตรวจจับตามขั้นของการโจมตี คือ reconnaissance (สำรวจ) compromised credentials (ข้อมูลรับรองถูกยึด) lateral movement และ domain dominance (ควบคุมโดเมนได้ทั้งหมด เช่น DCShadow, malicious replication และ Golden Ticket) ส่วน MITRE เสนอแนวคิดการตรวจจับเพิ่ม สำหรับ Kerberoasting ให้ดู Event ID 4769 ที่ขอ ticket แบบ RC4 (0x17) (RC4 คือวิธีเข้ารหัสแบบเก่า) และการขอ service ticket จำนวนมากในช่วงสั้น ๆ จากบัญชีเดียว สำหรับ DCSync ให้ดูคำขอ replication ที่มาจากเครื่องที่ไม่ใช่ domain controller สำหรับ Golden Ticket ให้ดู ticket ที่มีอายุผิดปกติ การใช้ RC4 และ TGS request ที่ไม่มี TGT นำหน้า
  • ระดับพฤติกรรม: การเปลี่ยนสมาชิกของกลุ่มหรือ role ที่มีสิทธิ์สูง inbox rule (กฎในกล่องอีเมลที่ตั้งให้ส่งต่ออีเมลอัตโนมัติ) ที่ส่งต่ออีเมลออกนอกองค์กร การไล่ดูรายการข้อมูลใน directory ผ่าน Graph API แบบผิดปกติ และพฤติกรรมแปลก ๆ ของ service account

สัญญาณแต่ละแบบเชื่อถือได้ไม่เท่ากัน Microsoft ระบุว่า anomalous token ยังมีโอกาสเกิดการแจ้งเตือนผิดพลาด (false positive) สูงกว่าปกติเมื่อระดับความเสี่ยงเป็นต่ำและกลาง ส่วน leaked credentials ถูกจัดเป็นความเสี่ยงสูงเสมอ เพราะเป็นการตรวจว่าตรงกับข้อมูลจริง ไม่ใช่การคาดเดา ทีมจึงต้องจัดลำดับการสืบสวนโดยดูทั้งความน่าเชื่อถือของสัญญาณและความสำคัญของบัญชี

เมื่อตรวจพบแล้วต้องทำอะไร

เอกสารที่ตรวจมีคำแนะนำเฉพาะจุดหลายข้อ Microsoft Entra ระบุว่าการล้างความเสี่ยงแบบ attacker-in-the-middle (ผู้โจมตีแทรกกลางระหว่างผู้ใช้กับเว็บไซต์จริงเพื่อดักข้อมูล) อาจต้องรีเซ็ตรหัสผ่านอย่างปลอดภัยหรือเพิกถอน session ที่มีอยู่ MITRE แนะนำให้จำกัดผลของ Golden Ticket ที่ผู้โจมตีเคยสร้างไว้ ด้วยการรีเซ็ตรหัสผ่านบัญชี KRBTGT สองครั้งต่อหนึ่งโดเมน โดยมีขั้นตอน replication คั่นระหว่างสองครั้งนั้น AA23-320A ชี้ว่าผู้โจมตีลงทะเบียน MFA ของตัวเอง และเคยเพิ่ม federated identity provider (ผู้ให้บริการยืนยันตัวตนภายนอกที่ระบบไว้ใจ) เข้าไปใน SSO tenant (พื้นที่ login ครั้งเดียวใช้ได้หลายระบบของแต่ละองค์กร) หลังบัญชีถูกยึดจึงควรตรวจทั้งสองจุดนี้ ลำดับขั้นที่ใช้ได้กับเหตุการณ์ส่วนใหญ่แสดงในแผนภาพด้านล่าง

INFOGRAPHIC
ลำดับการตอบสนองเมื่อบัญชีถูกยึด
1
ตัดการเข้าถึง
เพิกถอน session รีเซ็ตรหัสผ่าน หรือปิดบัญชี
2
ประเมินขอบเขต
ดูว่าบัญชีเข้าถึงอะไร และไปต่อที่ไหนบ้าง
3
กำจัดทางกลับเข้ามา
ลบ MFA ที่ไม่รู้จัก ตรวจ federation และ inbox rule
4
รีเซ็ตความเชื่อใจ
หากสงสัย Golden Ticket ให้รีเซ็ต KRBTGT สองครั้ง
5
เรียนรู้และปรับปรุง
อุดช่องที่ถูกใช้ และเพิ่มการตรวจจับ

ITDR กับเครื่องมืออื่น

ITDR ตรวจจับได้เอง แต่การตอบสนองมักต้องทำผ่านระบบอื่น Microsoft Defender for Identity ส่งสัญญาณเข้า Defender portal เดียวกับข้อมูลจาก endpoint อีเมล และคลาวด์ เพื่อให้เชื่อมโยงกันเป็นเหตุการณ์ (incident) เดียว ภาพรวมของ SOAR (ระบบสั่งงานตอบสนองอัตโนมัติ) และ XDR (แพลตฟอร์มที่รวมสัญญาณจากหลายด้านเข้าด้วยกัน) รวมถึง SIEM อ่านได้ใน SIEM, SOAR และ XDR ต่างกันอย่างไร ส่วนเครื่องมือที่ใช้ตัดการโจมตี เช่น เพิกถอน session หรือลดสิทธิ์ อยู่ในระบบ IAM และ PAM ซึ่งเปรียบเทียบไว้ใน IAM, IGA, PAM และ CIEM ต่างกันอย่างไร บางผู้ผลิตขาย ITDR เป็นโมดูลหนึ่งของแพลตฟอร์ม XDR บางรายขายแยก ตอนเลือกซื้อจึงควรถามว่ามี sensor บน domain controller หรือไม่ และรองรับ identity provider ที่องค์กรใช้อยู่หรือไม่

INFOGRAPHIC
ITDR เชื่อมกับระบบอื่นอย่างไร
ITDR
ตรวจจับเอง แต่ลงมือผ่านระบบอื่น
แหล่งสัญญาณ
AD, Entra, identity provider
XDR / EDR
รวมสัญญาณเป็นเหตุการณ์เดียว
SIEM / SOAR
เก็บหลักฐาน รัน playbook
IAM / PAM
เพิกถอน session ลดสิทธิ์

วิธีนำไปใช้เป็นขั้น

  • เริ่มจากสุขอนามัยตัวตน: CISA แนะนำ MFA ที่ต้านฟิชชิง (phishing) เช่น FIDO/WebAuthn หรือแบบ PKI (ใช้ใบรับรองดิจิทัล) ซึ่งต้านได้ทั้ง push bombing (การส่งคำขออนุมัติรัว ๆ จนผู้ใช้กดยอม) และ SIM swap ส่วน ATT&CK แนะนำให้ปิด legacy authentication (วิธียืนยันตัวตนแบบเก่า) ดู MFA แบบไหนปลอดภัยกว่า
  • เก็บ log ตัวตนให้ครบ: เก็บ security log ของ domain controller รวมถึง sign-in log และ audit log ของ Entra หรือ identity provider แล้วส่งเข้า SIEM หรือแพลตฟอร์ม XDR
  • เริ่มจากกรณีตรวจจับที่ชัดเจนไม่กี่เรื่อง: กำหนดกรณีตรวจจับ (use case) โดยเทียบกับหมวด Credential Access ของ ATT&CK เช่น password spray, token replay (นำ token เดิมมาใช้ซ้ำ), Kerberoasting และ DCSync
  • กำหนดการตอบสนองล่วงหน้า: ตกลงกันไว้ก่อนว่าใครมีสิทธิ์เพิกถอน session หรือปิดบัญชี ให้ระบบทำอัตโนมัติเฉพาะขั้นที่เสี่ยงต่ำ ส่วนการปิดบัญชีสำคัญให้มีคนอนุมัติก่อน
  • ดูแลบัญชีที่ไม่ใช่คน: service account เป็นเป้าของ Kerberoasting MITRE แนะนำให้ตั้งรหัสผ่านที่ยาวและซับซ้อน (ระบุไว้ว่า 25 ตัวอักษรขึ้นไป) ใช้ group managed service account (บัญชีบริการที่ระบบช่วยจัดการรหัสผ่านให้) และให้สิทธิ์เท่าที่จำเป็น (least privilege) ดู บัญชีบริการและตัวตนที่ไม่ใช่คน
  • ซ้อมและวัดผล: จำลองกรณีบัญชีถูกยึด แล้ววัดว่าใช้เวลานานเท่าไรกว่าจะตรวจพบและตัดการเข้าถึงได้
INFOGRAPHIC
วุฒิภาวะการตรวจจับภัยต่อตัวตน
ไม่เห็น
log ตัวตนกระจัดกระจายหรือไม่ได้เก็บ
เก็บ log แล้ว
แต่ยังไม่มีกรณีตรวจจับ (use case)
มีการตรวจจับหลัก
spray, token replay, DCSync
มี playbook ตอบสนอง
รู้ว่าใครทำอะไร เมื่อไร
ซ้อมและวัดผลสม่ำเสมอ
ปรับปรุงจากผลการซ้อม
มองไม่เห็น เสี่ยงกว่าตรวจพบและตัดวงจรเร็ว

ข้อควรระวัง

  • เชื่อว่าเครื่องมือเห็นทุกอย่าง: ถ้าไม่มี sensor หรือ log จาก domain controller และ identity provider เครื่องมือก็มองไม่เห็นเลย
  • ไล่ตามทุกการแจ้งเตือนเท่ากัน: สัญญาณที่แจ้งผิดพลาดบ่อย (false positive สูง) ควรได้ลำดับต่ำกว่าสัญญาณที่ยืนยันแล้ว
  • ตรวจจับแต่ไม่แก้จุดอ่อน: service account ที่แคร็กรหัสผ่านได้ง่ายและสิทธิ์ผู้ดูแลที่เกินจำเป็นยังคงอยู่เหมือนเดิม
  • ตอบสนองอัตโนมัติผิดบัญชี: การปิดบัญชีฉุกเฉินหรือ service account ที่สำคัญอาจทำให้ระบบหยุดทำงาน จึงควรมีรายการยกเว้นและขั้นตอนอนุมัติ
  • ลืมช่องทางที่เป็นคน: help desk ที่รีเซ็ตรหัสผ่านหรือ MFA โดยไม่ยืนยันตัวตนอย่างเข้มงวดเป็นช่องโหว่ที่เครื่องมือตรวจจับมองไม่เห็น
  • ไม่มีแผนกู้คืน Active Directory: การรีเซ็ต KRBTGT สองครั้งและการเปลี่ยนข้อมูลลับ (secret) ที่เกี่ยวข้องกระทบทั้งโดเมน จึงควรวางแผนและซ้อมไว้ล่วงหน้า

ขั้นแรกที่ทำได้ทันที

  • ตรวจว่า log ตัวตนครอบคลุมแค่ไหน: security event ของ domain controller และ sign-in log ของ identity provider ถูกเก็บและค้นหาได้หรือไม่
  • หา service account ที่เสี่ยง: คือบัญชีที่มี service principal name (ชื่อที่ใช้ระบุบริการใน Kerberos) รหัสผ่านเก่าหรือสั้น และมีสิทธิ์เกินกว่าที่ต้องใช้
  • ปิด legacy authentication: ถ้ายังเปิดอยู่ให้ปิด เพราะ Microsoft ระบุว่าการตรวจจับ unfamiliar sign-in (การ login จากสภาพแวดล้อมที่ไม่คุ้นเคย) บนโปรโตคอลเหล่านี้มีข้อมูลให้วิเคราะห์น้อย และแนะนำให้ย้ายไปใช้ modern authentication (วิธียืนยันตัวตนแบบใหม่)
  • เขียน playbook หนึ่งหน้าสำหรับกรณีบัญชีถูกยึด: playbook คือคู่มือขั้นตอนปฏิบัติ ให้ระบุว่าต้องเพิกถอน session รีเซ็ตรหัสผ่าน ลบวิธี MFA ที่ไม่รู้จัก และตรวจว่ามี inbox rule ส่งต่ออีเมลออกนอกองค์กรหรือไม่
  • ปรับขั้นตอนของ help desk: ยืนยันตัวตนให้เข้มงวดก่อนรีเซ็ตรหัสผ่านหรือ MFA
  • ซ้อมหนึ่งสถานการณ์: เช่น MFA fatigue (ถูกส่งคำขออนุมัติซ้ำจนผู้ใช้ยอมกด) แล้วจดว่าใครตรวจพบ ใครตัดสินใจ และใช้เวลานานเท่าไร

หากอยากรู้ว่าองค์กรควรแก้ช่องว่างด้านใดก่อน ลองใช้ แบบประเมินตนเอง เป็นจุดเริ่มต้น

แหล่งอ้างอิงและข้อมูลเพิ่มเติม