Security+ Academy · บทเรียน

การโจมตี Kerberoasting และ Golden Ticket

การโจมตี Kerberoasting และ Golden Ticket เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

สถาปัตยกรรมตั๋วบริการ Kerberos

เพื่อทำความเข้าใจการโจมตี Kerberoasting และ Golden Ticket คุณจำเป็นต้องเห็นภาพที่ชัดเจนของ การออกตั๋วบริการของ Kerberos เมื่อลูกค้าต้องการเข้าถึงบริการ (เช่น เซิร์ฟเวอร์ SQL) ลูกค้าจะส่ง Ticket Granting Ticket (TGT) ให้กับ Ticket Granting Service (TGS) ของ Domain Controller จากนั้น TGS จะออก Service Ticket ที่เข้ารหัสด้วย แฮชรหัสผ่านของบัญชีบริการ ลูกค้าจะส่งตั๋วนี้ให้บริการ ซึ่งจะถอดรหัสด้วยแฮชของตนเองเพื่อตรวจสอบความถูกต้อง การออกแบบนี้หมายความว่าตั๋วบริการถูกเข้ารหัสด้วยข้อมูลรับรองของบริการเป้าหมาย — รายละเอียดสำคัญที่ Kerberoasting ใช้ประโยชน์

Kerberoasting: การถอดรหัสรหัสผ่านแบบออฟไลน์

Kerberoasting คือการโจมตีที่ใช้ประโยชน์จากข้อเท็จจริงที่ว่าผู้ใช้โดเมนที่ผ่านการยืนยันตัวตนแล้วทุกคนสามารถขอตั๋วบริการ Kerberos สำหรับบริการใดก็ได้ที่ลงทะเบียนด้วย SPN (Service Principal Name) ผู้โจมตีจะขอตั๋วบริการสำหรับบัญชีที่มี SPN เก็บข้อมูลตั๋วที่เข้ารหัสไว้ แล้วพยายามถอดรหัสรหัสผ่านของบัญชีบริการ แบบออฟไลน์ — โดยไม่ต้องโต้ตอบกับ Active Directory เพิ่มเติมและไม่มีความเสี่ยงที่บัญชีจะถูกล็อก บัญชีบริการมักมีรหัสผ่านที่ไม่รัดกุม เป็นรหัสผ่านเก่าที่ตั้งขึ้นก่อนข้อกำหนดด้านความซับซ้อนสมัยใหม่ หรือเป็นรหัสผ่านที่ไม่มีวันหมดอายุ จึงมีความเสี่ยงสูงต่อการถอดรหัสแบบออฟไลน์

# Step 1: Find accounts with SPNs (attack setup)
Get-ADUser -Filter {ServicePrincipalName -ne '$null'} -Properties ServicePrincipalName

# Step 2: Request service tickets (using Impacket GetUserSPNs.py)
# GetUserSPNs.py domain/user:password -dc-ip 192.168.1.1 -request
# Outputs $krb5tgs$ hashes ready for cracking with Hashcat

การถอดรหัสตั๋ว Kerberos แบบออฟไลน์

แฮชตั๋วบริการที่เก็บได้จาก Kerberoasting จะเข้ารหัสด้วย RC4-HMAC (แฮช NTLM) ตามค่าเริ่มต้น (เพื่อความเข้ากันได้) ซึ่งถอดรหัสได้เร็วกว่าตั๋ว Kerberos แบบ AES-256 ผู้โจมตีจะป้อนแฮช $krb5tgs$23$ ที่เก็บได้เข้าไปใน Hashcat หรือ John the Ripper เพื่อโจมตีแบบพจนานุกรมและแบบลองค่าทุกค่าที่เป็นไปได้แบบออฟไลน์ รายการคำทั่วไปอย่าง RockYou ร่วมกับชุดกฎสามารถถอดรหัสรหัสผ่านบัญชีบริการที่ไม่รัดกุมส่วนใหญ่ได้ภายในไม่กี่นาทีถึงไม่กี่ชั่วโมงบนฮาร์ดแวร์ GPU สำหรับผู้บริโภค เมื่อถอดรหัสได้แล้ว ผู้โจมตีจะมี รหัสผ่านแบบข้อความธรรมดาของบัญชีบริการ ซึ่งสามารถใช้ยืนยันตัวตนได้โดยตรง

# Crack Kerberoasted hashes with Hashcat
hashcat -m 13100 kerberoast_hashes.txt rockyou.txt \
  -r best64.rule \
  --force
# Mode 13100 = Kerberos 5, etype 23 (RC4-HMAC service ticket)
# Mode 19600 = Kerberos 5, etype 17 (AES-128) - slower
# Mode 19700 = Kerberos 5, etype 18 (AES-256) - slowest

การป้องกัน Kerberoasting

แนวทางลดความเสี่ยงจาก Kerberoasting มุ่งเน้น 4 ด้าน ได้แก่ ความแข็งแกร่งของรหัสผ่าน — บัญชีบริการควรใช้รหัสผ่านแบบสุ่มที่มีความยาวมาก (25 อักขระขึ้นไป) ซึ่งทนต่อการถอดรหัสแบบออฟไลน์ได้แม้ใช้คลัสเตอร์ GPU; Group Managed Service Accounts (gMSA) — Windows จะจัดการรหัสผ่าน gMSA โดยอัตโนมัติ (ค่าสุ่มความยาว 240 อักขระที่เปลี่ยนทุก 30 วัน) ทำให้ Kerberoasting ต้องใช้การคำนวณในระดับที่ทำได้ยากมาก; การเข้ารหัสแบบ AES เท่านั้น — กำหนดให้บัญชีบริการต้องใช้ตั๋ว AES-256 (msDS-SupportedEncryptionTypes) ซึ่งถอดรหัสได้ช้ากว่า RC4 แบบทวีคูณ; และ การตรวจจับ — แจ้งเตือนเมื่อมีการขอ TGS ในปริมาณผิดปกติ (Event ID 4769) สำหรับบัญชีบริการจากเวิร์กสเตชันที่ไม่ใช่เครื่องมาตรฐาน

# Create a Group Managed Service Account (gMSA) - Kerberoasting immune
New-ADServiceAccount -Name 'svc-sql' \
  -DNSHostName 'sqlserver.domain.com' \
  -PrincipalsAllowedToRetrieveManagedPassword 'SQLServers'

# Install on the SQL server
Install-ADServiceAccount -Identity 'svc-sql'

บัญชี KRBTGT: ผู้พิทักษ์ Kerberos

บัญชี KRBTGT เป็นบัญชี Active Directory ที่มีมาให้ในระบบและมีความพิเศษ โดยแฮชรหัสผ่านของบัญชีนี้ใช้เพื่อ ลงลายเซ็นและเข้ารหัส TGT ของ Kerberos ทั้งหมด ตัวควบคุมโดเมนใช้แฮช KRBTGT เพื่อสร้าง TGT และตรวจสอบ TGT ที่ได้รับเข้ามา ด้วยเหตุนี้ แฮช KRBTGT จึงเป็นข้อมูลรับรองที่มีค่าที่สุดเพียงรายการเดียวในสภาพแวดล้อม Active Directory — ผู้ใดก็ตามที่ครอบครองแฮชนี้สามารถสร้างตั๋ว Kerberos ที่ถูกต้องได้ตามต้องการสำหรับผู้ใช้ใดก็ได้ รวมถึงผู้ใช้ที่ไม่มีอยู่จริง พร้อมกำหนดสมาชิกกลุ่มใดก็ได้และอายุการใช้งานเท่าใดก็ได้ โดยทั่วไปหลายองค์กรแทบไม่เคยเปลี่ยนรหัสผ่าน KRBTGT เนื่องจากกระบวนการเปลี่ยนต้องประสานงานอย่างรอบคอบ

# Check when KRBTGT password was last changed
Get-ADUser -Identity KRBTGT -Properties PasswordLastSet | 
  Select-Object Name, PasswordLastSet
# If PasswordLastSet is years ago, the domain is vulnerable to persistent Golden Tickets

การโจมตี Golden Ticket: การปลอมแปลง TGT

การโจมตี Golden Ticket จะสร้าง TGT ของ Kerberos ที่ปลอมแปลงแต่ถูกต้องสมบูรณ์ โดยใช้แฮชรหัสผ่านของบัญชี KRBTGT ที่ถูกบุกรุก ผู้โจมตีใช้คำสั่ง kerberos::golden ของ Mimikatz เพื่อสร้าง TGT สำหรับผู้ใช้ใดก็ได้ (มักเป็นบัญชีปลอมที่มีลักษณะคล้าย Administrator) พร้อมสมาชิกกลุ่มใดก็ได้ (โดยทั่วไปจะรวม Domain Admins) และกำหนดอายุการใช้งานเท่าใดก็ได้ (มักกำหนดเป็น 10 ปี) ตัวควบคุมโดเมนไม่สามารถแยกตั๋วที่ปลอมแปลงนี้ออกจากตั๋วที่ถูกต้องได้ เนื่องจากตั๋วมีความถูกต้องทางการเข้ารหัส — ตั๋วนี้ลงลายเซ็นด้วยแฮช KRBTGT จริง Golden Ticket จึงมอบ การควบคุมโดเมนอย่างสมบูรณ์ ต่อเนื่อง และไม่จำกัด

# Mimikatz Golden Ticket creation (attacker perspective - for defender awareness)
# Requires: domain name, domain SID, KRBTGT hash, target username
# mimikatz# kerberos::golden \
#   /domain:corp.example.com \
#   /sid:S-1-5-21-1234567890-1234567890-1234567890 \
#   /krbtgt:aabbccddeeff00112233445566778899 \
#   /user:GoldenTicketUser \
#   /groups:512,519 \
#   /ticket:golden.kirbi

เหตุผลที่ Golden Ticket อยู่ได้นานมาก

Golden Ticket อันตรายเป็นพิเศษเนื่องจากยังคงใช้งานได้แม้ค้นพบและจัดการการโจมตีต้นเหตุแล้ว การเปลี่ยนรหัสผ่านของผู้ใช้เป้าหมายไม่ช่วยอะไร — ตั๋วนี้ถูกปลอมแปลงขึ้น ไม่ได้สร้างจากข้อมูลรับรองจริงของผู้ใช้ วิธีแก้ไขเพียงอย่างเดียวคือ เปลี่ยนรหัสผ่าน KRBTGT สองครั้ง (ครั้งแรกเพื่อทำให้ตั๋วที่มีอยู่ใช้ไม่ได้ และครั้งที่สองเนื่องจากในช่วงเวลาใดเวลาหนึ่งจะมีคีย์ KRBTGT อยู่สองรายการเพื่อรองรับการหมุนเวียนคีย์) อย่างไรก็ตาม การเปลี่ยนรหัสผ่าน KRBTGT ต้องประสานงานอย่างรอบคอบ หากเปลี่ยนไม่ถูกต้อง จะทำให้การยืนยันตัวตนด้วย Kerberos เสียหายทั่วทั้งโดเมน หลายองค์กรไม่เต็มใจดำเนินการแก้ไขนี้ จึงปล่อยให้ Golden Ticket ใช้งานได้โดยไม่มีกำหนด

# KRBTGT password reset procedure (Microsoft New-KrbtgtKeys.ps1)
# Step 1: Reset KRBTGT password on primary DC
# Step 2: Wait for AD replication (typically 24-48 hours)
# Step 3: Reset KRBTGT password again to invalidate all old tickets
# Step 4: Verify Kerberos authentication working across all sites
# This invalidates ALL existing Kerberos tickets domain-wide

การโจมตี Silver Ticket: การปลอมแปลงเฉพาะบริการ

Silver Ticket มีลักษณะคล้าย Golden Ticket แต่มีขอบเขตจำกัดกว่า โดยใช้ แฮชของบัญชีบริการเป้าหมาย (แทน KRBTGT) เพื่อปลอมแปลง ตั๋วบริการสำหรับบริการนั้นเพียงบริการเดียว ตัวอย่างเช่น หากมีแฮชของบัญชีบริการเซิร์ฟเวอร์ SQL ผู้โจมตีสามารถปลอมแปลงตั๋วบริการที่ให้สิทธิ์เข้าถึงเซิร์ฟเวอร์ SQL ดังกล่าวได้ตามต้องการ Silver Ticket ตรวจจับได้ยากกว่า Golden Ticket เพราะข้ามตัวควบคุมโดเมนทั้งหมด — ตั๋วที่ปลอมแปลงจะส่งโดยตรงจากผู้โจมตีไปยังบริการโดยไม่มีการติดต่อ KDC การลดความเสี่ยงจำเป็นต้องปกป้องแฮชของบัญชีบริการและเฝ้าติดตามรูปแบบการเข้าถึงที่ผิดปกติบนบริการสำคัญ

การ取得แฮช KRBTGT: การโจมตี DCSync

ผู้โจมตีจะ取得แฮช KRBTGT ด้วย การโจมตี DCSync ซึ่งใช้ประโยชน์จากโพรโทคอล replication ของโดเมน Active Directory ที่ถูกต้องตามปกติ Directory Replication Service (DRS) ช่วยให้ตัวควบคุมโดเมนซิงค์ข้อมูล AD รวมถึงแฮชรหัสผ่านระหว่างกันได้ ผู้โจมตีที่มี สิทธิ์ DCSync (โดยทั่วไปคือ Domain Admin, Enterprise Admin หรือบัญชีใดก็ตามที่มีสิทธิ์ Replicating Directory Changes All) สามารถปลอมเป็นตัวควบคุมโดเมนและขอ replication ของแฮชสำหรับบัญชีใดก็ได้ คำสั่ง lsadump::dcsync ของ Mimikatz ดำเนินการโจมตีนี้ผ่านเครือข่ายทั้งหมด — ไม่จำเป็นต้องให้โค้ดทำงานบนตัวควบคุมโดเมนเอง

# DCSync to extract KRBTGT hash (attacker perspective)
# mimikatz# lsadump::dcsync /domain:corp.example.com /user:KRBTGT
# Output includes:
# Hash NTLM: <krbtgt NT hash>
# Hash SHA1: <krbtgt SHA1 hash>
# Key: <AES-256 key>

# Detection: Event ID 4662 from a non-DC source (replication event from workstation = suspicious)

การตรวจจับกิจกรรม Golden และ Silver Ticket

การตรวจจับการใช้งาน Golden Ticket เป็นเรื่องท้าทายแต่ทำได้ โดยค้นหาความผิดปกติในข้อมูลกำกับของตั๋ว Kerberos ได้แก่ ตั๋วที่มีอายุการใช้งานยาวผิดปกติ (ตั๋วจริงมีอายุ TGT 10 ชั่วโมง ส่วน Golden Ticket มักกำหนดเป็น 10 ปี); Event ID 4769 ที่ชนิดการเข้ารหัสตั๋วเป็น RC4 (0x17) ทั้งที่ค่าเริ่มต้นของโดเมนคือ AES-256 (0x12); ชื่อบัญชีในตั๋วที่ไม่มีอยู่ใน AD; และ การขาดหายไปของ Event ID 4768 (การขอ TGT) ก่อน Event ID 4769 (การขอตั๋วบริการ) — Golden Ticket ข้ามขั้นตอนการขอ TGT เนื่องจากตัว TGT ถูกปลอมแปลงขึ้นเอง กฎของ Microsoft Sentinel หรือ Defender for Identity สามารถตรวจจับรูปแบบเหล่านี้และแจ้งเตือนได้โดยอัตโนมัติ

# Detection: Golden Ticket indicator - no corresponding TGT request
# Normal flow: Event 4768 (TGT requested) -> Event 4769 (service ticket)
# Golden Ticket: Event 4769 WITHOUT preceding 4768 from same host

# Also alert on: TGT encryption type = RC4 in AES-only environments
# Splunk: index=windows EventCode=4769 TicketEncryptionType=0x17
#   NOT [expected legacy systems]

การป้องกันการโจมตีที่ใช้ Kerberos

การป้องกันแบบหลายชั้นสำหรับการโจมตี Kerberos ประกอบด้วย ใช้ gMSA กับบัญชีบริการทั้งหมดเพื่อทำให้ Kerberoasting ทำได้ยากมาก; เปิดใช้การเข้ารหัสแบบ AES เท่านั้นกับบัญชีทั้งหมด โดยเฉพาะบัญชีบริการที่มีมูลค่าสูง เพื่อเพิ่มความยากในการถอดรหัส; จำกัดสิทธิ์ DCSync — ตรวจสอบบัญชีที่มีสิทธิ์ replication และนำสิทธิ์ออกจากบัญชีที่ไม่ควรมี; เปิดใช้ Microsoft Defender for Identity (เดิมคือ ATA) ซึ่งมีการตรวจจับภัยคุกคามที่เข้าใจ Kerberos รวมถึงการแจ้งเตือน Golden Ticket, Kerberoasting และ DCSync แบบเรียลไทม์; และ นำรูปแบบการดูแลระบบแบบแบ่งระดับมาใช้ เพื่อให้แม้บัญชี Tier 2 ถูกบุกรุก ก็ไม่สามารถใช้เข้าถึงข้อมูลรับรองระดับตัวควบคุมโดเมนได้

# Audit DCSync-capable accounts (these should be very few)
Get-ADUser -Filter * -Properties 'msDS-AllowedToDelegateTo' |
  Where {$_.DistinguishedName -notlike '*Domain Controllers*'}

# Check replication permission holders using PowerView:
# Get-ObjectAcl -DistinguishedName 'DC=domain,DC=com' \
#   -ResolveGUIDs | \
#   Where {$_.ActiveDirectoryRights -like '*ExtendedRight*'}

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

ทบทวนบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Kerberoasting จะขอตั๋วบริการสำหรับบัญชีที่ลงทะเบียน SPN แล้วถอดรหัสแบบออฟไลน์ — ป้องกันได้ด้วย gMSA รหัสผ่านที่รัดกุม และการเข้ารหัสแบบ AES เท่านั้น, การโจมตี Golden Ticket ใช้แฮช KRBTGT เพื่อปลอมแปลง TGT ได้ไม่จำกัด ทำให้ควบคุมโดเมนได้อย่างต่อเนื่องจนกว่าจะรีเซ็ตรหัสผ่าน KRBTGT สองครั้ง และ การโจมตี DCSync จะ replication แฮช KRBTGT ผ่านเครือข่ายโดยไม่ต้องให้โค้ดทำงานบนตัวควบคุมโดเมน — จึงต้องตรวจสอบสิทธิ์ DCSync อย่างเข้มงวด บทถัดไปเราจะสำรวจเฟรมเวิร์ก MITRE ATT&CK สำหรับจับคู่เทคนิคของผู้โจมตีกับแนวทางป้องกัน

คำถามที่พบบ่อย

บทเรียน “การโจมตี Kerberoasting และ Golden Ticket” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การโจมตี Kerberoasting และ Golden Ticket” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การโจมตี Kerberoasting และ Golden Ticket”

เรียนรู้ว่า Kerberoasting ดึงแฮชตั๋วบริการที่สามารถถอดรหัสได้มาโจมตีแบบออฟไลน์อย่างไร และการโจมตี Golden Ticket มอบสิทธิ์เข้าถึง Kerberos ได้ไม่จำกัดโดยใช้แฮช KRBTGT ที่ถูกบุกรุกได้อย่างไร คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การโจมตี Kerberoasting และ Golden Ticket” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม

ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Security+ Academy