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 ทุกวัน