วิเคราะห์ CVE-2026-54121 - CertiGhost

ช่วงปลายเดือนที่ผ่านมาหลายคนในสาย Active Directory security น่าจะได้เห็นชื่อช่องโหว่ตัวใหม่ที่ชื่อว่า CertiGhost (CVE-2026-54121) ผ่านตากันมาบ้างแล้ว จุดที่ทำให้ช่องโหว่นี้น่าสนใจมากคือ ผู้โจมตีที่เป็นเพียง domain user ธรรมดา ก็สามารถปลอมตัวเป็น Domain Controller (DC) และขยายผลไปจนถึงการยึดครองทั้ง domain ได้ ผ่านบริการที่หลายองค์กรมีอยู่แล้วอย่าง Active Directory Certificate Services (AD CS)
ช่องโหว่นี้ถูกรายงานไปยัง Microsoft ตั้งแต่เดือนพฤษภาคม 2026 ได้รับการแก้ไขใน security update รอบเดือนกรกฎาคม 2026 (14 ก.ค. 2026) และเปิดเผยรายละเอียดต่อสาธารณะเมื่อวันที่ 24 ก.ค. 2026

บทความนี้จะพาไปดูว่าเส้นทางที่เรียกว่า chase ทำงานยังไง ทำไมมันถึงถูกนำมา abuse ได้ และ patch ของ Microsoft แก้ตรงไหน

Too Long; don't read. (TL;DR)

• ต้นตอของปัญหา: ในบางเงื่อนไขของการ enroll certificate ตัว CA จะมี fallback ที่เรียกว่า chase คือไปดึงข้อมูล identity จากอีก host หนึ่ง โดยดูจาก request attribute ชื่อ cdc ปัญหาคือ CA เชื่อค่านี้ที่ผู้ร้องขอกำหนดมาเอง โดยไม่ได้พิสูจน์ก่อนว่า host นั้นเป็น DC จริงหรือเปล่า
• ผลกระทบ: ผู้โจมตีสามารถชี้ให้ CA ไปคุยกับเครื่องของตัวเอง แล้วป้อนข้อมูล identity ของ DC (objectSid + dNSHostName) กลับไป ทำให้ได้ certificate ที่ยืนยันตัวตน "เป็น DC" ออกมา จากนั้นก็ทำ DCSync ดึง krbtgt และยึด domain ได้
• เงื่อนไขที่เจอในการทดสอบ: Enterprise CA บน build ก่อน patch กรกฎาคม 2026, ใช้ template Machine ค่า default, และค่า ms-DS-MachineAccountQuota แบบ default เท่ากับ 10 ก็เพียงพอแล้ว
• วิธีแก้: ลง security update เดือนกรกฎาคม 2026 (CVE-2026-54121)

จบสำหรับคนที่ไม่อยากอ่านยาว.. แต่ถ้าใครอยากเข้าใจว่ามันทำงานยังไงจริง ๆ ตามมาได้เลย

ทำความรู้จัก "chase" fallback

ก่อนจะไปถึงตัวบั๊ก ขอปูพื้นเรื่องนึงก่อน เพราะถ้าไม่เข้าใจตรงนี้ ที่เหลือจะงงหมด

ปกติเวลา enroll certificate มันก็จบในสเต็ปเดียว แต่มีบางเคส พวกที่ enroll ข้าม Domain Controller CA จะไปค้น directory เพิ่มอีกรอบ ตัวที่ทำงานรอบสองนี้แหละที่เรียกว่า chase

chase ถูกคุมด้วย request attribute สองตัว คือ

• cdc (Client DC) : บอกว่า CA ควรไปติดต่อ host ไหน
• rmd (Remote Domain) : บอกว่า CA ควรไปค้นหา principal ตัวไหน

พอสองค่านี้ถูกส่งมา CA ก็เชื่อมไปที่ host ใน cdc ผ่าน SMB กับ LDAP แล้วไปดึง principal ตาม rmd ตรงไปตรงมา ไม่มีอะไรซับซ้อน

คำถามคือ... แล้ว CA รู้ได้ยังไงว่า host ที่เราบอกให้ไปคุยด้วยเนี่ย มันเป็น DC จริง ๆ

ช่องโหว่ CertiGhost

ปัญหาหลักคือ CA ยอมรับ chase target ที่ผู้ร้องขอกำหนดมาเอง โดยไม่ได้พิสูจน์ก่อนว่า host นั้นเป็น Domain Controller ตัวจริงตามที่อ้าง พอเป็นแบบนี้ ผู้โจมตีก็แค่:

1. รันบริการ LDAP และ LSA ปลอม บนเครื่องที่ตัวเองคุม
2. ชี้ให้ CA วิ่งมาที่เครื่องนั้นผ่าน cdc
3. ป้อนข้อมูล identity อะไรก็ได้ที่ต้องการ กลับไปให้ CA สำหรับ principal ที่ระบุใน rmd

ประเด็นไม่ได้อยู่แค่ที่ "CA วิ่งออกไปข้างนอก" เท่านั้น แต่อยู่ที่ CA เอา response จาก host นั้นมาใช้เป็นข้อมูล directory จริง ๆ ในการสร้าง certificate

ทำไมถึงขยายผลไปยึด Domain ได้

ในเชนที่ถูกทดสอบ ผู้โจมตีสามารถส่งค่า objectSid และ dNSHostName ของ Domain Controller กลับไปให้ CA ค่าทั้งสองนี้จะไปมีอิทธิพลต่อข้อมูล identity ใน certificate ที่ CA ออกให้ รวมถึง strong-mapping SID และฟิลด์ DNS identity ที่ใช้ระหว่างการ authenticate

แล้วทำไมเครื่องปลอมของผู้โจมตีถึงผ่านการตรวจของ CA ได้? คำตอบอยู่ที่ machine account

machine account ที่ถูกสร้างผ่านค่า default ms-DS-MachineAccountQuota ถือเป็น domain principal

ด้วยเหตุนี้ endpoint ปลอมของผู้โจมตี (ที่มี LSA/LDAP service คอย relay authentication challenge ของ CA ไปยัง DC จริง) จึงผ่านการตรวจสอบที่จำเป็น ทำให้ CA เดินหน้าออก certificate ต่อ ทั้งที่มันไม่ใช่ DC ที่กำลังถูกปลอมตัวเลย

ผลลัพธ์คือ CA ออก certificate ที่มี identity เท่ากับ DC เป้าหมายให้เรามาถือครอง

ภาพรวมขั้นตอนการโจมตีทั้งหมด

ผู้โจมตีเตรียม machine account ที่ถูกต้อง + รัน service ปลอม → CA ตาม cdc ไปเชื่อข้อมูลที่ผู้โจมตีป้อน → DC ถูกปลอมตัวผ่าน certificate-based authentication และสิทธิ์ replication

Attack Flow

Lab

ทฤษฎีมาเยอะแล้ว มาลองของจริงบน lab กันดีกว่า

Lab environment

• AD forest ที่ functional level Windows Server 2016 ขึ้นไป (lab นี้ Windows Server 2025 functional level)
• Domain Controller: CITY-CENTER.NIGHT.CITY 10.40.0.5
• Enterprise CA: NCPD-CA บน ARASAKA.NIGHT.CITY 10.40.0.67
• ค่า ms-DS-MachineAccountQuota เป็นค่า default = 10
• template Machine ค่า default พร้อม ACL default
• เครื่องผู้โจมตี: 10.40.0.9
• account Domain Users สิทธิ์ต่ำ 1 user: silver

PoC Exploitation

รัน PoC script จาก repo aniqfakhrul/CVE-2026-54121 โดยที่ใช้ faketime ปรับเวลาให้ โดยดึงเวลาจาก DC (ผ่าน ntpdate) มาตั้งให้ตรงกัน เพื่อกันปัญหา clock skew ของ Kerberos ที่ถ้าเวลาเครื่องเราต่างกับ DC เกินไป ticket จะใช้ไม่ได้

faketime "$(ntpdate -q 10.40.0.5 | cut -d ' ' -f 1,2)" python3 certighost.py -d night.city -u silver -p •••••••• --dc-ip 10.40.0.5

Running the PoC script

ถึงจุดนี้ผู้โจมตีได้รับ certificate ที่ CA sign ให้ (city-center.pfx) ซึ่ง authenticate เป็น DC เป้าหมายได้ พร้อม hash และ Kerberos credential cache ของ account นั้น (city-center.ccache) เรียบร้อย

DCSync

account ของ Domain Controller มีสิทธิ์ directory replication ดังนั้นเมื่อได้ Kerberos credential มาแล้ว ผู้โจมตีก็ขอ secret ของ account ต่าง ๆ ได้

faketime "$(ntpdate -q 10.40.0.5 | cut -d ' ' -f 1,2)" impacket-secretsdump -k -no-pass -dc-ip 10.40.0.5 '@CITY-CENTER.NIGHT.CITY'

DCSync with the cache credential

ล่าร่องรอย จุดที่ใช้ตรวจหาการโจมตี CertiGhost

ถ้าสงสัยว่าองค์กรอาจโดน CertiGhost ไปแล้ว ต่อไปนี้คือจุดที่เข้าไปไล่ดูได้ ย้ำก่อนว่านี่คือไอเดียที่ได้มาจาก public PoC, writeup และพฤติกรรมปกติของ Windows/AD CS ยังไม่ใช่ IoC ที่คอนเฟิร์มแล้ว ให้ใช้เป็นจุดตั้งต้นในการหา ไม่ใช่ checklist สำเร็จรูป

1. บน DC ให้ดู Security Event ID 4741 (computer account created) โดยเฉพาะ account ที่ถูกสร้างโดย user สิทธิ์ต่ำ และยิ่งน่าสงสัยถ้าเกิดขึ้นไม่นานก่อนจะมี activity แปลก ๆ ที่ฝั่ง CA ตัว PoC ตั้งชื่อ machine account แบบสุ่มโดยขึ้นต้นด้วย GHOST เช่น GHOSTKFXJXIMA$ ซึ่ง match กับ regex: ^GHOST[A-Z]{8}\$$

แต่ให้ถือว่าเป็น quick check เท่านั้น เพราะชื่อนี้ผู้โจมตีแก้เองได้ง่าย ๆ และยังสามารถนำ machine account ที่มีอยู่แล้วมา reuse ได้ด้วย การไล่ดูที่ใครเป็นคนสร้างสำคัญกว่าตัวชื่อ

Computer account created in Event Viewer

2. ค้นใน Attributes หา request attribute สองตัวที่ใช้ในการโจมตีนี้คือ cdc และ rmd ใน Issued Certificates เพราะ cdc และ rmd ไม่ใช่ attribute ที่โผล่มาใน enrollment ปกติทั่วไป

Issued Certificates

โดย PoC จะส่งค่า:
cdc: <IP ของผู้โจมตี>
rmd: <FQDN ของ DC เป้าหมาย>
CertificateTemplate: Machine

Issued certificate properties

3. หา traffic ที่ CA เชื่อมต่อออกไปยัง TCP445 และ TCP389 ของเครื่องที่ ไม่ใช่ Domain Controller ตัวจริง เพราะ PoC จะเปิด rogue SMB/LSA และ LDAP listener รอไว้บน port เหล่านี้
4. ถ้า account DC ทำ PKINIT authentication มาจาก address ที่ไม่ใช่ของ DC ตัวนั้น ถือว่าน่าสงสัยอย่างยิ่ง
5. Replication / DCSync การ replicate โดย DC เป็นเรื่องปกติอยู่แล้ว ประเด็นที่น่าสนใจคือการที่ identity ของ DC ถูกใช้จากเครื่องที่ไม่ใช่ DC ฉะนั้นต้องเอาไป correlate กับ logon และ network telemetry ประกอบด้วย

วิธีการแก้ไข

1. ติดตั้ง patch

ดูรายละเอียดและดาวน์โหลด update ได้ที่ Microsoft Security Update Guide: CVE-2026-54121

2. Hot fix (กรณีลง update ทันทีไม่ได้): ปิด chase fallback
   เราสามารถปิด code path ที่มีช่องโหว่ทิ้งไปทั้งหมดได้ด้วย policy flag เพราะ chase ที่ใช้ cdc เป็นแค่ fallback feature ที่เป็น optional ไม่ใช่โค้ดที่รันทุก request อยู่แล้ว:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

ย้ำว่านี่คือ mitigation ไม่ใช่ patch ถ้า EDITF_ENABLECHASECLIENTDC ถูกเปิดกลับมาบน CA ที่ยังไม่ได้ patch ไม่ว่าจะโดย admin หรือจาก group policy ช่องโหว่นี้ก็จะ exploit ได้อีกครั้ง

หมายเหตุ: hot fix นี้ถูกทดสอบเฉพาะใน lab ที่ควบคุมได้เท่านั้น ยังไม่ได้ทดสอบบน production CA จริง ก่อนนำไปใช้จริงควรลองบน staging CA ที่จำลอง environment จริงก่อน และยืนยันให้แน่ใจว่าไม่มี enrollment ปกติตัวไหนที่พึ่ง chase fallback อยู่ เพราะ request เหล่านั้นจะ fail ทันทีเมื่อ flag ถูกเคลียร์ออก สุดท้ายแล้ว July update ยังเป็นวิธีแก้ที่แนะนำอยู่ดี

3. Hardening เพิ่มเติม

• ตั้งค่า ms-DS-MachineAccountQuota เป็น 0 เพื่อไม่ให้ user ทั่วไปสร้าง machine account เองได้ ซึ่งเป็นส่วนสำคัญของการโจมตีนี้
• รัดกุม ACL / สิทธิ์ enroll ของ certificate template โดยเฉพาะ template Machine และ template ที่ใช้ client authentication ได้
• Monitor การ enroll certificate ที่ผิดปกติ และการสร้าง machine account โดย user สิทธิ์ต่ำ

ปิดท้าย

จบไปแล้วสำหรับการชำแหละ CertiGhost ในครั้งนี้ จะเห็นว่า idea หลักของช่องโหว่ตรงไปตรงมามาก "เชื่อ input จากผู้ร้องขอโดยไม่พิสูจน์" แต่พอมันไปอยู่ในตำแหน่งที่ถูกต้อง (identity material ของ certificate) ผลลัพธ์กลับรุนแรงถึงขั้นยึด domain ได้

สิ่งที่อยากฝากไว้คือ ช่องโหว่ที่อันตรายที่สุดหลายตัวไม่ได้มาจากเทคนิคซับซ้อน แต่มาจากการที่ระบบ "เชื่อ" ในจุดที่ควรจะ "ตรวจสอบ" การไล่ดูว่าค่าไหนในระบบที่ผู้ร้องขอกำหนดเองได้ แล้วมันถูกตรวจสอบมากพอหรือยัง จึงเป็นมุมมองที่คุ้มค่ากับการเอาไปปรับใช้กับระบบอื่น ๆ ต่อ

References

• certighost.py PoC https://github.com/aniqfakhrul/CVE-2026-54121
• Certipy (AD CS toolkit) https://github.com/ly4k/Certipy
• Microsoft Security Update Guide: CVE-2026-54121 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121
• MS-WCCE: Windows Client Certificate Enrollment Protocol https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/
• Original writeup โดย @h0j3n และ @aniqfakhrul

Advertorial

นอกจาก CertiGhost ตัวนี้แล้ว ยังมีช่องโหว่อีกมากมายที่ทำให้ Active Directory และ AD CS ขององค์กรมีความเสี่ยง แล้วจะหาความเสี่ยงเหล่านั้นเจอได้อย่างไร? หนึ่งในวิธีที่ได้ผลคือการทำ VA/Pentest

หากต้องการคำแนะนำเพิ่มเติม ทีมงานของเรายินดีให้คำปรึกษา ติดต่อเราได้เลยครับ