KDC — ฝ่ายต้อนรับของโรงแรม#

ในระบบ Kerberos — เคาน์เตอร์ทั้ง 2 ตัวนี้ รวมอยู่ในศูนย์เดียว ที่เรียกว่า KDC (Key Distribution Center) — แปลตรงตัวว่า “ศูนย์แจกจ่ายกุญแจ”

KDC = อาคารฝ่ายต้อนรับของโรงแรมทั้งหมด. ภายในแบ่งเป็น 2 เคาน์เตอร์ที่ผมเล่าไป — AS กับ TGS. ทั้งคู่อยู่ในอาคารเดียวกัน (ส่วนใหญ่อยู่ใน server เดียวกัน) — แต่ทำงานคนละหน้าที่

ในบริษัทที่ใช้ Active Directory — KDC = Domain Controller. คือ Windows server ที่ทำหน้าที่จัดการตัวตนของทั้ง domain. บริษัทขนาดกลางมัก 2-3 Domain Controllers ที่ replicate กันเพื่อความ resilient — ถ้าตัวนึงล่ม, ตัวอื่นทำงานต่อได้ทันที

AS (Authentication Server) — เคาน์เตอร์ check-in#

ใน KDC — เคาน์เตอร์แรกชื่อ AS (Authentication Server) — เคาน์เตอร์ check-in ของโรงแรม

หน้าที่ของ AS = ตรวจ “บัตรประชาชน” ของผู้ใช้ — ออก “บัตรแขก”. ในศัพท์ทางเทคนิค — AS รับ username + (สิ่งที่เกิดจาก) password ของผู้ใช้ — verify ว่าตรงกับที่เก็บไว้ — ออก TGT (Ticket Granting Ticket) ให้ — ซึ่งคือบัตรแขกของโรงแรม

AS = เคาน์เตอร์เดียวที่ “คุย” กับ password ของผู้ใช้. ในชีวิตหนึ่งวันของผู้ใช้คนนึง — AS ถูกเรียกครั้งเดียวเท่านั้น — ตอน login Windows ครั้งแรก. หลังจากนั้น — AS ไม่ถูกเรียกอีก จนกว่าวันรุ่งขึ้น

TGS (Ticket Granting Server) — เคาน์เตอร์แลกคีย์ห้อง#

เคาน์เตอร์ที่สองใน KDC ชื่อ TGS (Ticket Granting Server หรือ Ticket Granting Service) — เคาน์เตอร์แลกคีย์ห้อง

หน้าที่ของ TGS = รับ “บัตรแขก” (TGT) แล้วออก “คีย์ห้อง” (Service Ticket) ของบริการที่ผู้ใช้ขอ. ทุกครั้งที่ผู้ใช้จะเปิดบริการใหม่ในวันนั้น (เช่น เปิด file server, เปิด email, เปิด SAP) เครื่องของผู้ใช้คุยกับ TGS เพื่อขอ Service Ticket สำหรับบริการนั้น

TGS ไม่ต้องเห็น password ของผู้ใช้เลย เพราะมัน trust บัตรแขกที่ AS ออกให้แล้ว. นี่คือสาเหตุที่ผู้ใช้พิมพ์ password ครั้งเดียวต่อวัน — เพราะหลัง check-in เสร็จ ทุก request หลังจากนั้นใช้บัตรแขก ไม่ใช่ password

ทำไมต้องชื่อ Kerberos — หมาเฝ้านรก 3 เศียร#

ก่อนไปเรื่อง ticket — ผมอยากเล่าเรื่องชื่อนิดนึงครับ. เพราะมันสวยมาก

ในตำนานกรีก — เคอร์เบอรอส (Κέρβερος) คือหมายักษ์ 3 เศียร ที่เฝ้าทางเข้าโลกใต้พิภพ (Hades). หน้าที่ของมัน — กันคนตายไม่ให้กลับขึ้นมา, กันคนเป็นไม่ให้ลงไป. 3 เศียรของมัน = 3 ตัวที่ต้องตกลงกันถึงจะผ่านได้

นักวิจัย MIT เลือกชื่อนี้เพราะ — Kerberos protocol มี 3 ตัวละครที่ต้องตกลงกันถึงจะ authenticate ผ่านได้:

1. Client — ผู้ใช้ + เครื่องของเขา (พนักงาน + Windows notebook)
2. KDC — Domain Controller (ฝ่ายต้อนรับของโรงแรม)
3. Service — บริการปลายทาง (file server / email / SAP)

ทั้ง 3 ตัวต้องคุยกันครบ — ถึงจะ access ผ่านได้. ถ้าตัวไหนตัวหนึ่งโกหก หรือ ticket ไม่ตรง — ระบบปฏิเสธ. 3 เศียรของหมาเฝ้านรก = 3 ตัวที่ตรวจ identity — เป็น metaphor ที่สวยมากสำหรับ protocol ที่ออกแบบให้ทำงานในเครือข่ายที่ไม่ปลอดภัย

มุมผู้บริหาร: เรื่อง KDC = Domain Controller ของ Active Directory — สำคัญมากสำหรับการตัดสินใจ infrastructure ครับ. Domain Controller = หัวใจของระบบ identity ทั้งบริษัท. ถ้าทั้งบริษัทมี Domain Controller ตัวเดียว — ตัวนั้นล่ม = พนักงานเข้า Windows ไม่ได้, เปิด Outlook ไม่ได้, เปิด file share ไม่ได้ = ทั้งบริษัทหยุดทำงาน. มาตรฐาน enterprise — ต้องมี Domain Controller อย่างน้อย 2 ตัวที่ replicate กัน, ในศูนย์ข้อมูลคนละจุด, มี backup ที่ recover ได้ใน 4 ชั่วโมง. ถามทีม IT ของคุณว่า — “Domain Controller ของเรามีกี่ตัว, อยู่ที่ไหนบ้าง, ครั้งสุดท้ายที่ test recovery คือเมื่อไหร่?“

TGT (Ticket Granting Ticket) — บัตรแขกของโรงแรม#

TGT (Ticket Granting Ticket) = บัตรแขกของโรงแรม. คือตั๋วใบแรกที่ผู้ใช้ได้รับหลัง check-in สำเร็จ — และคือ “ตัวตน” ของผู้ใช้ทั้งวันในระบบ Kerberos

คุณสมบัติของ TGT:

• ออกโดย AS หลังจาก verify password — เป็น “proof of identity” ของผู้ใช้
• ใช้ขอ Service Ticket ได้หลายครั้ง — ทุกครั้งที่ผู้ใช้เปิดบริการใหม่ ใช้ TGT เป็น input ของ TGS
• อายุ 8-10 ชั่วโมง (1 working day) — default ของ Active Directory คือ 10 ชั่วโมง
• เก็บใน memory ของเครื่อง client — ไม่เขียนลง disk (ปกติ). ถ้าปิดเครื่อง = TGT หาย
• encrypted ด้วย “ความลับ” ที่เฉพาะ KDC รู้ — เครื่อง client ถือ TGT ได้ แต่อ่านข้างในไม่ได้ (เหมือนบัตรแขกที่มี chip ที่อ่านได้แค่เครื่องของพนักงานโรงแรม)

ส่วน “ความลับ” ที่ใช้ encrypt TGT ทุกใบ — นี่คือเรื่องสำคัญมากที่ผมจะกลับมาในหัวข้อ Golden Ticket. ใน Active Directory — ความลับนี้คือ password hash ของ account พิเศษชื่อ KRBTGT — account ที่สร้างอัตโนมัติตอนตั้ง domain — ไม่มีใครใช้ login — มีหน้าที่เดียวคือ encrypt TGT ทุกใบในระบบ

คุณภาพของ TGT = บัตรแขกที่ถ้าโจรขโมยได้ = โจรปลอมตัวเป็นเจ้าของบัตรได้ทั้งวัน. นี่คือสาเหตุที่ Kerberos attacks ส่วนใหญ่ — เป้าหมายคือ TGT

Service Ticket — คีย์ห้องของแต่ละห้อง#

Service Ticket = คีย์การ์ดของห้องเฉพาะ. คือตั๋วใบที่สอง — ออกโดย TGS — ใช้เข้าบริการปลายทางเฉพาะตัวเท่านั้น

คุณสมบัติของ Service Ticket:

• ออกโดย TGS หลังจาก verify TGT — ใบนึงต่อบริการ
• ใช้ครั้งเดียว ต่อ session ของบริการนั้น — ถ้าจะเข้าบริการเดิมรอบใหม่ ขอใบใหม่
• อายุสั้นมาก — ตามมาตรฐาน 5-10 นาที (แต่ session ที่เปิดอยู่ใช้ต่อได้แม้ ticket หมดอายุ — ticket แค่ใช้ตอน “เริ่ม” connection)
• encrypted ด้วยความลับของบริการปลายทาง — เช่น Service Ticket สำหรับ file server, encrypt ด้วย password hash ของ computer account ของ file server. file server เท่านั้นที่อ่านได้ — TGS เองอ่านไม่ได้ (TGS แค่สร้าง — แล้วส่งกลับให้ client เอาไปยื่นเอง)

ผลที่สำคัญ — file server ไม่ต้องเก็บ password ของผู้ใช้ทุกคน. file server แค่เก็บ “ความลับของตัวเอง” — เพื่อ decrypt Service Ticket ที่ client ยื่นมา. ถ้า decrypt ได้ + ข้างในบอกว่าเป็น “พนักงาน ABC, แผนกบัญชี, มี role X” — file server เชื่อ. password ของพนักงาน ไม่เคยถึง file server เลย แม้แต่ครั้งเดียว — นี่คือเป้าหมายดั้งเดิมของ Project Athena ที่ MIT ตั้งใจไว้

ทำไมการแยก TGT กับ Service Ticket = design ที่สวยมาก#

เหตุผลที่ Kerberos แยก 2 ตั๋ว — ไม่ใช่ใช้บัตรเดียวจบเลย — มีเหตุผลทางวิศวกรรม 4 ข้อ:

1. Performance — TGT ออกครั้งเดียวต่อวัน (เคาน์เตอร์ check-in ทำงานหนักครั้งเดียว). Service Ticket ออกเร็วและบ่อย (เคาน์เตอร์แลกคีย์ทำงานเร็วเพราะแค่ verify TGT). ถ้ารวมกัน — ทุกครั้งที่ขอเข้าบริการต้องตรวจ password = ช้า + load หนัก
2. อายุต่างกัน — TGT อายุยาว (วันละครั้งพอ). Service Ticket อายุสั้น (5-10 นาที — กัน replay attack). ถ้าใช้บัตรเดียว — ต้องเลือกอายุเดียว = trade-off แย่ไม่ว่าทางไหน
3. ความลับแยกกัน — TGT encrypt ด้วย KRBTGT secret (1 ตัวสำหรับทั้ง domain). Service Ticket encrypt ด้วย secret ของแต่ละบริการ. ถ้าบริการตัวนึงโดน hack (เช่น secret ของ file server หลุด) — แค่ Service Ticket ของ file server เสี่ยง — TGT ไม่กระทบ — ไม่เสียทั้ง domain. นี่คือ Defense in Depth ระดับ protocol
4. Auditability — TGS log ทุก Service Ticket ที่ออก — บอกได้ว่าผู้ใช้คนไหนเข้าบริการไหนตอนกี่โมง = audit trail ที่ดีเยี่ยม

มุมผู้บริหาร: ตรงนี้สำคัญสำหรับ audit + forensics ครับ. ในกรณีที่บริษัทโดน breach — ทีม IT จะต้องตอบคำถามว่า “โจรเข้าได้ที่บริการไหนบ้าง ตั้งแต่กี่โมง”. Active Directory + Kerberos log ทุก Service Ticket ที่ออก = ถ้าเปิด logging ครบ + ส่งไป SIEM (ระบบรวม log) = ทีมตอบได้ภายใน ชั่วโมง ไม่ใช่สัปดาห์. คำถามให้ผู้บริหารถามทีม IT — “เรา log Kerberos events (4768, 4769, 4771) ครบไหม + ส่งไป SIEM ไหม + เก็บไว้นานเท่าไหร่?” คำตอบที่ดี = “ครบ, ส่งไป Splunk/Sentinel, เก็บอย่างน้อย 1 ปี”

9 โมงเช้า — login Windows (AS Exchange)#

คุณสมชายเดินเข้าออฟฟิศ 9 โมงเช้า. เปิด Windows notebook — หน้า login ขึ้น — พิมพ์ username somchai + password MyPassphrase2026!

ในเวลาเสี้ยววินาทีนั้น — Windows ของเขาทำสิ่งนี้:

1. ไม่ส่ง password ตรงๆ ไป KDC — แต่ใช้ password คำนวณ hash (ตัวเลขที่เกิดจาก password ผ่านสมการเฉพาะ — ทางเดียวที่ย้อนกลับไม่ได้). hash นี้ใช้เป็น “กุญแจ” สำหรับการคุยกับ KDC ในขั้นต่อไป
2. ส่ง request ไป AS (Authentication Server) — พร้อมข้อมูลที่ encrypt ด้วย hash ของ password — เพื่อพิสูจน์ว่า “ผมรู้ password ของคุณสมชาย”
3. AS ตรวจสอบ — เปรียบเทียบกับ password hash ของคุณสมชายที่เก็บใน Active Directory database. ถ้า decrypt request ของ client ได้ = client ต้องรู้ password จริง = ผ่าน
4. AS ออก TGT — บรรจุข้อมูล: ชื่อคุณสมชาย, เวลาออก, อายุ (10 ชั่วโมง), groups ที่อยู่ — encrypt ด้วย KRBTGT secret (ความลับของทั้ง domain)
5. AS ส่ง TGT กลับให้ client — Windows เก็บ TGT ใน memory (LSASS process). password ของคุณสมชาย — หายไปจาก memory หลังจากนี้ (ทฤษฎี)

หน้า desktop ของคุณสมชายขึ้น. ตอนนี้ — Windows ของเขามี บัตรแขกสีทอง อายุ 10 ชั่วโมง. ยังไม่ได้ทำอะไรพิเศษเลย — แค่ login Windows สำเร็จ

จุดที่ผมอยากเน้นในขั้นนี้ — password ของคุณสมชาย เดินทางในเครือข่ายเพียง “ทางอ้อม” — ผ่าน hash ที่ใช้ encrypt request เท่านั้น — และไม่เคยส่งเป็น plain text เลย. คนที่ดักจับ network packet — ได้แค่ข้อมูล encrypted ที่ไม่มีกุญแจ — ดูไม่ออก. นี่คือเป้าหมายข้อหนึ่งของ Project Athena ที่ผมเล่าในหัวข้อ 1 — สำเร็จแล้ว

9:15 — เปิด file server (TGS Exchange ครั้งแรก)#

คุณสมชายต้องการเปิด file share ของฝ่ายบัญชี. เขาคลิก \\fileserver\accounting. Windows ของเขาทำสิ่งนี้:

1. ส่ง request ไป TGS — แนบ TGT + บอก “ผมต้องการคุยกับ file server ชื่อ fileserver”
2. TGS ตรวจสอบ TGT — decrypt ด้วย KRBTGT secret — ดู: TGT ของจริงไหม, หมดอายุยัง, ผู้ใช้ที่อยู่ในนี้คือใคร
3. TGS ออก Service Ticket สำหรับ file server — บรรจุ: ชื่อคุณสมชาย, groups ของเขา, เวลา. encrypt ด้วย password hash ของ computer account ของ file server (ความลับที่มีแค่ TGS กับ file server รู้)
4. TGS ส่ง Service Ticket กลับให้ client — แต่ตัว TGS เองอ่านข้างในไม่ออก (มันแค่สร้างแล้วส่ง)
5. Windows ของคุณสมชาย ยื่น Service Ticket ไปที่ file server
6. file server decrypt Service Ticket ด้วย secret ของตัวเอง — เห็นว่า “นี่คือสมชาย, แผนกบัญชี” — เช็คว่า somchai มีสิทธิ์เข้า folder ของบัญชีไหม — มี — ให้เข้า

จุดเด่นของขั้นนี้ — file server ไม่เคยเห็น password ของคุณสมชาย, ไม่เคยคุยกับ AS โดยตรง, ไม่เคยเก็บ user database เลย. file server แค่ trust TGS — ถ้า TGS ออก Service Ticket มาแล้ว = เชื่อ. นี่คือ Single Sign-On (SSO) ระดับ protocol — ผู้ใช้พิมพ์ password ครั้งเดียว, server ปลายทางไม่ต้องรู้ password เลย

9:30 — เปิด email (TGS Exchange ครั้งที่ 2)#

คุณสมชายเปิด Outlook. Windows ของเขาเห็นว่า Outlook ต้องคุยกับ email server (exchange.company.local) — แต่ยังไม่มี Service Ticket ของ email server. ก็เลย:

1. ส่ง request ไป TGS — แนบ TGT (ยังอายุเหลือ 9 ชั่วโมง) + บอก “ขอ Service Ticket ของ email server”
2. TGS verify TGT + ออก Service Ticket ของ email server — encrypt ด้วย secret ของ email server
3. Windows ยื่น Service Ticket ไปที่ email server — email server decrypt — เห็นว่าเป็นสมชาย — ให้เข้า mailbox ของเขา

Outlook เปิดขึ้น — โหลด email — โดยที่คุณสมชายไม่ต้องพิมพ์ password อีกครั้ง. นี่คือ SSO ในระดับ enterprise ที่ทำให้พนักงานทั่วบริษัทไม่ต้องจำ password ของ 50 ระบบ — พิมพ์ครั้งเดียวต่อวัน

10:00, 11:00, 14:00, 15:30 — เปิดบริการต่างๆ ตลอดวัน#

ทุกครั้งที่คุณสมชายเปิดบริการใหม่ — SAP, intranet, printer share, share drive ของอีกแผนก — flow เดิมซ้ำ:

• client มี TGT อยู่แล้ว → ไป TGS → ขอ Service Ticket ของบริการนั้น → ยื่นไปที่บริการ → ผ่าน

ผู้ใช้ไม่รู้สึกอะไรเลย — สำหรับเขา คือคลิกแล้วเปิด. แต่ background — Kerberos กำลังทำงานนับสิบครั้งต่อชั่วโมง

5 โมงเย็น — TGT หมดอายุ / logout#

ตอน 7 โมงเย็น (10 ชั่วโมงหลัง login) — TGT ของคุณสมชายจะหมดอายุ. ถ้าเขายังนั่งทำงานอยู่ — Windows จะพยายาม renew TGT อัตโนมัติ (ถ้าตั้ง config ให้ renew ได้) — หรือถ้าไม่ได้ — Windows อาจถาม password อีกครั้ง

ถ้าเขา logout / shutdown — TGT + Service Tickets ทั้งหมดในเครื่อง = หาย (เพราะเก็บใน memory). พรุ่งนี้เช้า login ใหม่ = flow ใหม่ตั้งแต่ AS Exchange

ข้อดีของระบบนี้ที่ผมอยากสรุปครับ:

• password ผู้ใช้ = ใส่ครั้งเดียวต่อวัน + ไม่เคยส่งเป็น plain text บน network เลย
• service ปลายทาง = ไม่ต้องเก็บ password ของผู้ใช้ + แค่เก็บ secret ของตัวเอง
• ทุก ticket = มี digital signature (encrypted ด้วย secret ที่เฉพาะรู้) + อายุสั้น (Service Ticket 5-10 นาที, TGT 10 ชั่วโมง)
• audit trail = TGS log ทุกครั้งที่ออก Service Ticket = ตรวจสอบย้อนหลังได้

มุมผู้บริหาร: เรื่อง ticket lifetime สำคัญสำหรับ security policy ของบริษัทครับ. default ของ Active Directory คือ TGT 10 ชั่วโมง + Service Ticket 600 นาที (10 ชั่วโมง). ในบริษัทที่ security strict — มักลด TGT เหลือ 8 ชั่วโมง + Service Ticket เหลือ 30-60 นาที. ผลที่ตามมา — ถ้าโจรขโมย ticket ได้ — เขามีเวลาใช้น้อยลงมาก. ถามทีม IT — “Maximum lifetime ของ user ticket ในบริษัทเราคือเท่าไหร่?” ค่าที่ดี = TGT ≤ 8 ชม., Service Ticket ≤ 60 นาที, renewal ≤ 7 วัน

Mimikatz — ของขวัญจากคุณ Benjamin Delpy ที่เปลี่ยนวงการ#

ก่อนเข้าเรื่อง attack — ผมต้องเล่าเรื่องเครื่องมือนึงก่อนครับ — เพราะมันคือจุดเปลี่ยนของวงการ red team

ในปี 2007 — นักวิจัย security ชาวฝรั่งเศสคนหนึ่งชื่อ Benjamin Delpy ค้นพบเรื่องน่าตกใจ — Windows เก็บ credentials (รวมถึง password / TGT / NTLM hash) ใน memory ของ process ที่ชื่อ LSASS — และ memory นั้น อ่านได้ถ้ามี admin privilege

ใน 2011 — เขาเขียนเครื่องมือ proof-of-concept มาแชร์ open source — ตั้งชื่อว่า mimikatz (มาจากคำว่า “mimi” = น่ารักในภาษาฝรั่งเศส + katz). เครื่องมือนี้ — เปิด LSASS memory — ดึง credentials ทั้งหมดออกมาเป็น plain text. password ของผู้ใช้, TGT, NTLM hash, Kerberos session keys — ทุกอย่างหลุดออกมาในไม่กี่วินาที

Delpy ตั้งใจให้เป็น research tool — แต่ผลคือ — mimikatz กลายเป็นเครื่องมือมาตรฐานของ red team + ransomware gang ทั่วโลกตั้งแต่นั้นมา. ทุก attack ที่ผมจะเล่าต่อไป — ส่วนใหญ่เริ่มจาก mimikatz บนเครื่องที่โจร compromise ได้

Microsoft ใช้เวลาหลายปีในการป้องกัน mimikatz — เพิ่ม feature ชื่อ LSA Protection (Windows 8.1), Credential Guard (Windows 10) — แยก LSASS ออกไปอยู่ใน hypervisor ที่อ่านไม่ได้แม้มี admin privilege. แต่ — บริษัทส่วนใหญ่ในปี 2026 — ยังไม่ได้เปิด feature เหล่านี้ เพราะ compatibility issues. mimikatz ยังทำงานได้ในบริษัทไทยส่วนใหญ่จนถึงทุกวันนี้

ในวงการ — มีคำกล่าวว่า “ถ้าคุณยังไม่เปิด Credential Guard — คุณยังอยู่ในยุค 2011”. รุนแรงแต่จริง

Pass-the-Ticket — เอา TGT ของคนอื่นไปใช้#

เริ่ม attack ตัวแรก — Pass-the-Ticket (PtT)

สถานการณ์: โจร compromise เครื่องของพนักงานคนนึงในบริษัท (เช่น ผ่าน phishing). โจรได้ admin privilege บนเครื่องนั้น ใช้ mimikatz ดึง TGT ของพนักงานคนนั้นจาก memory

ขั้นต่อไป: โจรเอา TGT ที่ขโมยมา ไปใช้บนเครื่องอื่น (เครื่องของโจรเอง). เครื่องของโจร ปลอมตัวเป็นพนักงานคนนั้นได้ทั้งวัน โดยไม่ต้องรู้ password ของพนักงานเลย. TGT คือบัตรแขก — ใครก็ตามที่ถือบัตรแขกในมือ = ระบบเชื่อว่าเขาคือเจ้าของบัตร

ทำไม TGT ถูกขโมยได้ทั้งที่ encrypt? — เพราะใน memory ของ LSASS — TGT อยู่ใน structure ที่ Windows ใช้งานได้ (encrypted ด้วย KRBTGT secret แต่ใช้งานในระบบได้). mimikatz ดึงออกมาทั้งดุ้น — เครื่องอื่นเอาไปใส่ใน LSASS ของตัวเอง = ใช้ได้ทันที. ไม่ต้อง decrypt — แค่ replay

ผลที่ตามมา — ถ้าโจรขโมย TGT ของ Domain Admin ได้ — โจรเข้าทุก server ในบริษัทได้ทันที. นี่คือ lateral movement ที่ ransomware ใช้กระจายตัวเองในเครือข่ายบริษัท

Golden Ticket — ฝันร้ายของ Domain Admin#

attack ตัวที่ทำให้ทีม IT ของบริษัทใหญ่นอนไม่หลับ — Golden Ticket

สถานการณ์ที่เลวร้ายที่สุด: โจร compromise ระดับสูงพอที่จะดึง password hash ของ KRBTGT account จาก Domain Controller ออกได้. KRBTGT account คืออะไร — ผมเล่าไว้แล้วในหัวข้อ 3 — มันคือ account พิเศษที่ KDC ใช้ encrypt TGT ทุกใบในระบบ

ขั้นต่อไป: เมื่อโจรได้ KRBTGT hash — โจรใช้ mimikatz ปลอม TGT ขึ้นมาเอง ที่:

• บอกว่าตัวเองคือใครก็ได้ — เป็น Domain Admin, เป็น CEO, เป็นใครก็ตามที่ต้องการ
• มี groups อะไรก็ได้ — Enterprise Admins, Domain Admins
• อายุยาวเท่าไหร่ก็ได้ — 10 ปีก็ได้ (ปกติ default คือสูงสุด 10 ชั่วโมง — โจรปลอม = 10 ปี)
• ไม่ต้องคุยกับ AS เลย — เพราะปลอม TGT เองโดยใช้ KRBTGT hash

นี่คือเรียกว่า Golden Ticket — บัตรแขกที่โจรปลอมขึ้นเอง — มีอำนาจสูงสุดในระบบ

ผลที่น่ากลัวที่สุด — แม้บริษัทจะตรวจพบการ breach + รีเซ็ต password ของทุก user ในบริษัท + ปิด account ที่ compromise — โจรยังใช้ Golden Ticket ได้อยู่. เพราะ TGT ที่โจรปลอม — ไม่ผูกกับ password ของใครเลย. ผูกกับ KRBTGT hash อย่างเดียว

วิธีกำจัด Golden Ticket: ต้อง rotate KRBTGT account password — และ ต้อง rotate 2 ครั้งติดกัน (ห่างกันมากกว่าระยะเวลา replication ของ Domain Controllers). เพราะ — ระบบ Active Directory เก็บ password history 2 versions — ถ้า rotate ครั้งเดียว — version เก่ายังใช้ได้ — Golden Ticket ยังทำงานได้

ในความเป็นจริงของบริษัทไทยส่วนใหญ่ — KRBTGT password ไม่เคย rotate ตั้งแต่ตั้ง domain มา. หลายบริษัทตั้ง domain ตอนปี 2005 — KRBTGT password เป็นค่าเดิมยาวกว่า 20 ปี. ถ้าโจรเคยขโมย hash ตัวนี้ในอดีต = วันนี้ยังใช้ Golden Ticket ได้

Microsoft แนะนำให้ rotate KRBTGT ทุก 6 เดือน. ในวงการ enterprise — มีเครื่องมือ script ที่ Microsoft แจกฟรี (New-KrbtgtKeys.ps1) — สำหรับ rotate อย่างปลอดภัย

Silver Ticket — ปลอม Service Ticket ของบริการเดียว#

attack ที่แคบกว่า Golden Ticket แต่ตรวจจับยากกว่า — Silver Ticket

สถานการณ์: โจรไม่ได้ KRBTGT hash — แต่ได้ password hash ของ computer account ของบริการเดียว (เช่น file server, SQL server). อันนี้ทำได้ง่ายกว่า — แค่ compromise เครื่อง server นั้น

ขั้นต่อไป: โจรใช้ secret ของ service นั้น — ปลอม Service Ticket ของ service นั้นได้เอง — โดยไม่ต้องคุยกับ TGS เลย. ปลอม Service Ticket ที่บอกว่า “นี่คือ Domain Admin มาเข้า file server ของคุณ” — file server ตรวจไม่ได้ว่าปลอม เพราะ encrypted ด้วย secret ของตัวเอง

ทำไม Silver Ticket ตรวจจับยาก — เพราะมัน ไม่ผ่าน TGS เลย. log ของ KDC ไม่บันทึก. มี log แค่ที่ service ปลายทาง — ซึ่งบอกแค่ว่า “user X เข้ามา” — แต่ไม่รู้ว่า “ไม่มีการขอ TGS Service Ticket ของ user X ครั้งนี้”. ต้อง correlation log จาก 2 แห่งถึงตรวจได้

ขอบเขตของ Silver Ticket — แคบกว่า Golden Ticket (แค่ 1 service) — แต่เพียงพอสำหรับ attack เป้าหมายเฉพาะเจาะจง

Kerberoasting — ลอก Service Account hash ออกมา crack offline#

attack ที่ใช้ feature ปกติของ Kerberos — Kerberoasting

สถานการณ์: ในบริษัทมี Service Account จำนวนมาก — account พิเศษที่ใช้รัน service (เช่น MSSQL service, Exchange service, IIS app pool). Service Account มักตั้ง password อ่อน + ไม่เคยเปลี่ยน + อายุ password เป็นปีๆ (เพราะเปลี่ยนทีต้องปิด service)

ขั้นต่อไป: โจรที่อยู่ในเครือข่าย (แม้เป็นพนักงานธรรมดา) — ขอ Service Ticket ของ Service Account เหล่านี้จาก TGS อย่างปกติ. Service Ticket = encrypted ด้วย password hash ของ Service Account. โจรเอา Service Ticket นี้ออกไป — crack offline ด้วย hashcat — ลองทุก password ที่เป็นไปได้

ถ้า password ของ Service Account คือ “Password123” หรือ “Company2020!” — โจร crack ได้ใน 5 นาที. ได้ password = login เป็น Service Account นั้น = ใช้สิทธิ์ของมัน (มักเป็น admin บางอย่าง)

นี่คือเหตุผลที่ Service Account ในบริษัทใหญ่ — ต้องตั้ง password ยาว + สุ่ม + เปลี่ยนทุก 6 เดือน. หรือดีกว่านั้น — ใช้ gMSA (Group Managed Service Account) ที่ Active Directory จัดการ password อัตโนมัติ — เปลี่ยนทุก 30 วัน — ไม่มีใครรู้ password เลย — ปิดประตู Kerberoasting

มุมผู้บริหาร: Kerberoasting คือ attack ที่ “คุ้มที่สุด” สำหรับโจรครับ — เพราะใช้ feature ปกติของ Kerberos, ไม่ต้องสิทธิ์ admin บนเครื่องไหน, ตรวจจับยาก. ถามทีม IT ของคุณ — “Service Account ในบริษัทเรามีกี่ตัว, ตัวไหนใช้ password ที่อ่อนหรือเก่า, เราใช้ gMSA แทนได้ตัวไหนบ้าง”. migrate Service Account ไปเป็น gMSA = 0 บาท (เป็น feature ของ Windows Server). ผลที่ปิด = Kerberoasting attack ทั้งหมด

Mitigation รวม — สรุปสำหรับ Kerberos attacks#

ทั้ง 4 attacks ข้างต้น — มี defense layer ที่บริษัทควรทำ:

1. เปิด LSA Protection + Credential Guard บน Windows — กัน mimikatz ดึง credentials จาก memory
2. rotate KRBTGT password ทุก 6 เดือน + rotate 2 ครั้งติดกัน — กัน Golden Ticket ที่ใช้ hash เก่า
3. ลด ticket lifetime — TGT 8 ชั่วโมง, Service Ticket 30-60 นาที — ลดเวลาที่ ticket ที่ขโมยมาใช้ได้
4. migrate Service Account ไป gMSA — ปิด Kerberoasting
5. monitor Kerberos events (4768 = TGT issued, 4769 = Service Ticket issued, 4771 = pre-auth failure) — ใน SIEM — alert pattern ผิดปกติ
6. Tier 0 isolation — Domain Admin / Enterprise Admin ต้อง login เฉพาะเครื่อง dedicated สำหรับ admin work — ไม่เปิด email / browser บนเครื่องนั้น — ลดโอกาส compromise

Active Directory คืออะไร — ฐานข้อมูลตัวตนของบริษัท#

Active Directory (AD) = ฐานข้อมูล identity ของ Microsoft. เปิดตัวพร้อม Windows 2000 — ตั้งแต่นั้นมา — ครองตลาด enterprise IT มากกว่า 90% ทั่วโลกในปี 2026. 90% ของบริษัทใหญ่ใน Fortune 500 — ใช้ Active Directory เป็น identity backbone

ใน AD — เก็บข้อมูลของ:

• User accounts — พนักงานทุกคนในบริษัท
• Computer accounts — เครื่อง Windows ทุกเครื่องในบริษัท
• Groups — กลุ่มสิทธิ์ — Domain Admins, Sales Team, Accounting, ฯลฯ
• Service accounts — account สำหรับ run services
• Policies (GPO — Group Policy Object) — config + security setting ที่ push ไปเครื่อง Windows ทุกตัว

AD ใช้ 2 protocol หลัก:

• LDAP — สำหรับ query / search ข้อมูลใน directory (ใครอยู่กลุ่มไหน, เครื่องไหน online)
• Kerberos — สำหรับ authentication (ทุกอย่างที่เราเล่ามาในหัวข้อ 1-5)

โครงสร้าง — Domain / Forest / OU#

Domain = ขอบเขต identity 1 ชุด. บริษัทขนาดกลางมัก 1 domain. ชื่อ domain มัก company.local หรือ corp.company.com

Forest = กลุ่มของ domains ที่ trust กัน. บริษัทใหญ่ที่ merger หลายๆ องค์กรเข้ามา — มักมีหลาย domain ใน 1 forest. trust ระหว่าง domains = แต่ละ domain authenticate ของกันได้

OU (Organizational Unit) = กล่องย่อยใน domain — สำหรับจัดกลุ่ม users / computers ตามแผนก / สาขา / ภูมิภาค. ใช้สำหรับ apply policy แตกต่างกัน — เช่น OU ของ Marketing ให้ลง software อันนึง, OU ของ Finance ห้ามลง

ทำไม Domain Admin = crown jewel#

ใน AD มี role พิเศษที่ทรงพลังที่สุด — Domain Admin. Domain Admin = ผู้ดูแล domain ทั้งหมด — มีสิทธิ์:

• Login เครื่อง Windows ทุกเครื่องในบริษัท (เป็น local admin บนทุกเครื่อง)
• อ่าน password hash ของทุก user ในบริษัท (รวม CEO + ผู้บริหารทุกคน)
• ดึง KRBTGT hash = ทำ Golden Ticket ได้
• เปลี่ยน password ของทุก user
• เพิ่ม / ลบ user
• push GPO ไปทุกเครื่อง = ลง software / config ทุกเครื่องในวินาทีเดียว

ผลที่ตามมา — ถ้าโจรครอบครอง Domain Admin account ได้ = ครอบครองทั้งบริษัท IT. เครื่องทุกเครื่อง, ข้อมูลทุกอย่าง, mail ของทุกคน — เปิดดูได้หมด

นี่คือสาเหตุที่ ransomware gang ระดับโลก — Conti, LockBit, BlackCat, Cl0p — เป้าหมายแรกเสมอ = Domain Admin. flow มาตรฐานของ ransomware attack ในปี 2026:

1. Initial access — phishing email + macro ใน Word — ได้ shell บนเครื่องพนักงาน 1 คน
2. Privilege escalation บนเครื่องนั้น — local exploit / mimikatz — ได้ local admin
3. Lateral movement — Pass-the-Ticket / Pass-the-Hash — กระจายไปเครื่องอื่นในเครือข่าย
4. Compromise Domain Controller — หา Domain Admin token / hash — ทำ Golden Ticket
5. Push ransomware ผ่าน GPO ไปทุกเครื่องในบริษัท — encrypt ทุก file ในเสี้ยววินาที
6. เรียกค่าไถ่ — มักเป็น Bitcoin/Monero — หลักล้านดอลลาร์

flow ทั้งหมดนี้ — ใช้เวลาเฉลี่ย 2-10 วันในบริษัทที่ไม่มี EDR + ไม่มี Tier 0 protection. ในกรณีที่เลวร้ายที่สุด — Colonial Pipeline 2021 หรือ MGM Resorts 2023 — ทำเสร็จในไม่กี่ชั่วโมง

มุมผู้บริหาร: เรื่องนี้คือเหตุผลที่ในวงการ — มี practice ที่เรียกว่า Tier 0 / Tier 1 / Tier 2 model. Tier 0 = Domain Admin / Enterprise Admin / Forest Admin + Domain Controllers + ระบบ identity backbone. กฎ — Tier 0 admin ต้องใช้เครื่องคนละเครื่องกับเครื่องที่เปิด email / browser ปกติ. แยก physically. ถ้า admin ทำงาน admin บนเครื่องเดียวกับที่เปิด phishing email = ทั้งบริษัทพร้อมพัง. ถามทีม IT ของคุณ — “Domain Admin ของบริษัทเราใช้เครื่อง dedicated ไหม?” ถ้าตอบ “ไม่” = ความเสี่ยงสูงสุดของบริษัท

สิ่งที่ผู้นำต้องจำ — 2 ข้อ#

ข้อแรก — ถ้าบริษัทใช้ Windows Active Directory — Kerberos คือ backbone. ถามทีม IT 4 คำถามนี้

นี่คือข้อที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. ในปี 2026 — บริษัทไทยขนาดกลาง-ใหญ่ส่วนใหญ่ใช้ Windows + Active Directory. นั่นแปลว่า Kerberos กำลังทำงานเงียบๆ ในบริษัทคุณตลอด 24 ชั่วโมง — และจุดอ่อนของ Kerberos = จุดอ่อนของทั้งบริษัท

4 คำถามที่ผู้บริหารควรถามทีม IT — แล้วฟังคำตอบ:

1. “เรา rotate KRBTGT account password ครั้งล่าสุดเมื่อไหร่?” — คำตอบที่ดี = “ภายใน 6 เดือนล่าสุด, rotate 2 ครั้งติด ตามคำแนะนำของ Microsoft”. คำตอบที่อันตราย = “ไม่เคย” / “ไม่รู้” — แปลว่าถ้า attacker เคยได้ KRBTGT hash ในอดีต = วันนี้ยังใช้ Golden Ticket ได้
2. “Domain Controller ของบริษัทเรามีกี่ตัว + อยู่ที่ไหน + มี backup ที่ test recovery แล้วเมื่อไหร่?” — คำตอบที่ดี = “อย่างน้อย 2 ตัว, คนละศูนย์ข้อมูล, test recovery ภายในปีที่ผ่านมา”
3. “เราเปิด LSA Protection + Credential Guard บนเครื่อง endpoint ของพนักงานทั้งหมดไหม?” — คำตอบที่ดี = “เปิดทุกเครื่องที่รองรับ — กัน mimikatz ดึง credentials จาก memory”
4. “Service Account ในบริษัทเรา — ใช้ gMSA กี่ตัว, ใช้ password manual กี่ตัว, ตัวที่ manual password ตั้งล่าสุดเมื่อไหร่?” — คำตอบที่ดี = “ส่วนใหญ่ migrate ไป gMSA แล้ว, ตัวที่เหลือเป็น legacy ที่ rotate ทุก 6 เดือน”

ถ้าคำตอบทั้ง 4 ข้อคือ “ไม่รู้” / “ไม่เคย” / “ทีมเก่าทำไว้ไม่มี doc” — บริษัทคุณเปราะมากต่อ ransomware ในปี 2026. ต้นทุนของการแก้ — ส่วนใหญ่ฟรี (เป็น feature ที่มีอยู่แล้วใน Windows Server) — แค่ต้องเสียเวลา IT จัดทีมทำ

ข้อสอง — Domain Admin account = crown jewel ที่สำคัญที่สุดในบริษัท. ทุก security control สุดท้ายปกป้องตัวนี้

ข้อนี้เป็น mindset shift ที่ผู้บริหารหลายคนยังไม่เห็นภาพครับ. ในมุมของ attacker — Domain Admin = วัตถุประสงค์สุดท้าย. เมื่อ attacker ได้ Domain Admin = ครอบครองบริษัท IT ทั้งหมด. ทุก control ของ security ก่อนหน้านั้น (firewall, EDR, MFA ของพนักงาน) = สุดท้ายปกป้องไม่ให้ attacker ถึง Domain Admin

หลักการที่ต้องยึด:

• แยก Tier 0 จาก Tier 1, Tier 2 — Domain Admin ต้อง ทำงาน admin บนเครื่อง dedicated ที่ไม่เปิด email / browser ปกติ. ลดโอกาส phishing ถึง Domain Admin
• Domain Admin ต้องใช้ MFA + Hardware Key (กลับไปที่ EP.13) — ไม่ใช่ SMS OTP. password อย่างเดียว = ไม่พอ
• เปิด PAM (Privileged Access Management) สำหรับ Domain Admin — EP.17 จะลึก — แต่หลักการพื้นฐาน — Domain Admin ต้องไม่ได้สิทธิ์ตลอดเวลา — ต้อง JIT (Just-In-Time) — ขอสิทธิ์เมื่อจะใช้ — ใช้เสร็จ สิทธิ์หาย. ลดเวลา attack ที่โจรมีหลัง compromise account นั้น
• Audit ทุก action ของ Domain Admin — ส่ง log ไป SIEM — ถ้า Domain Admin login ตอน ตี 3 จากเครื่องที่ไม่เคยใช้ = alert ทันที

ในวงการ security ปี 2026 — ความเสียหายเฉลี่ยของ ransomware attack ในบริษัทไทยขนาดกลาง = หลายสิบล้านบาท (ค่าไถ่ + downtime + กู้ระบบ + ค่าปรับ + ความเสียหายต่อ brand). การลงทุนในการป้องกัน Domain Admin = เครื่อง dedicated 5 เครื่อง (~500,000 บาท) + setup gMSA + setup Tier 0 (เวลา IT ~ 1-2 เดือน) + setup PAM (ระบบราคา 1-3 ล้าน). ROI ของการลงทุนนี้ — มหาศาล. ROI ของการไม่ลงทุน — บริษัทคุณเป็น lottery ticket ของ ransomware gang ทุกวัน