content-image
ARTICLES | 05 January 2026

Introduction to Active Directory Certificate Services (AD CS)

author-image

Wisawa Ploypradub

Introduction

ไม่ว่ากาลเวลาจะผันเปลี่ยนไปสักเท่าไร การโจมตีองค์กรต่าง ๆ เหล่า attacker มักจะมีเป้าหมายในการโจมตีและยึดครองระบบ Active Directory (AD) โดยอาศัยเทคนิคมากมายในการขยายผลและยกระดับสิทธิของตัวเองให้สามารถควบคุมทั้งองค์กรให้ได้ ซึ่งก่อนหน้านี้เองทาง Incognito Lab ได้มีการนำเสนอบทความเทคนิคในการโจมตีหลายรูปแบบ หากท่านผู้อ่านสนใจ สามารถย้อนอ่านบทความต่าง ๆ ได้ที่ลิงก์ด้านล่างนี้ได้เลย

Blog preview image

Attacking Kerberos in Windows Domain Environment

บทความชุดนี้ตั้งใจเขียนอธิบายเรื่อง Kerberos ใน Windows Domain Environment และวิธีการโจมตีเหมาะสำหรับนักทดสอบเจาะระบบ อาจเป็นประโยชน์กับผู้ดูแลระบบบ้างแต่ไม่ได้มากนักเพราะไม่ได้เน้นเนื้อหาส่วน detection และ prevention สักเท่าไรเมื่อเทียบกับการอธิบายที่มาที่ไปและวิธีการโจมตี

ในปัจจุบันเองก็ได้มีการเผยแพร่วิธีการโจมตีใหม่ ๆ มาหลายรูปแบบ หนึ่งในนั้นที่น่าสนใจและน่าหยิบจับมาเล่าให้ทุกท่านได้ทำความรู้จักกันก็คือเรื่องของการโจมตี Active Directory Certificate Service (AD CS) ที่นอกจากจะสามารถยกระดับสิทธิของตัว attacker เองได้แล้ว ยังมีวิธีการที่สามารถจะมีการฝังตัวอยู่ภายในองค์กรต่อไปได้อีกด้วย

เนื้อหาต่าง ๆ ภายในบทความนี้ ทางทีมงาน Incognito Lab ได้มีการเรียบเรียงมาจาก research paper ของทางทีม SpecterOps เป็นหลัก ซึ่งทาง SpecterOps จะมีการแบ่งเทคนิคในการโจมตี Active Directory Certificate Service (AD CS) จะแบ่งออกเป็น 4 รูปแบบหลัก ๆ ดังนี้

  • Credential Theft : การขโมย certificate และ private key ที่เกี่ยวข้องของผู้ใช้งานและเครื่องคอมพิวเตอร์เพื่อนำไปใช้ในการยืนยันตัวตนบน Active Directory
  • Account Persistence : การฝังตัวของการเข้าถึงบัญชีผู้ใช้งานหรือเครื่องคอมพิวเตอร์อย่างต่อเนื่อง โดยอาศัยการยืนยันตัวตนด้วย certificate
  • Domain Escalation : การยกระดับสิทธิการใช้งานให้สูงขึ้นบน Active Directory โดยอาศัยการตั้งค่าที่ไม่ปลอดภัยของ certificate และ Certificate Authority (CA)
  • Domain Persistence : การฝังตัวบน Active Directory เพื่อใช้ในการเข้าถึงระบบหรือเครือข่ายได้อย่างต่อเนื่อง โดยการสร้าง golden certificate และการแก้ไขการตั้งค่าของ Certificate Authority (CA)

นอกจากนี้ทาง SpecterOps ได้มีการนำเสนอการป้องกันและตรวจจับการโจมตีที่เกิดขึ้นอีกด้วย

  • Preventive Guidance
  • Detective Guidance

ทางทีมงาน Incognito Lab จึงตั้งใจจะทยอยลงบทความที่เกี่ยวข้องกับ AD CS ในรูปแบบ series โดยเริ่มต้นจากบทความนี้ที่จะพาทุกท่านไปรู้จักกับ AD CS กันก่อนว่าตัวมันเองเป็น service เกี่ยวกับอะไร มีส่วนประกอบภายในอะไรที่ควรรู้จักบ้าง

A meme made from TVアニメ「しかのこのこのここしたんたん」第2弾PV

A meme made from TVアニメ「しかのこのこのここしたんたん」第2弾PV

Quick Recap of Active Directory

ก่อนที่จะเข้าสู่เนื้อหาหลักกัน เรามาทำความรู้จักกับ Active Directory กันแบบคร่าว ๆ กันสักเล็กน้อย หลาย ๆ คนจะเรียกกันสั้น ๆ ว่า AD ซึ่งสิ่งที่เป็น core หลักของมันเลยก็คือตัว Active Directory Domain Services (AD DS) ที่เอาไว้ใช้ในการจัดการกับผู้ใช้งานและคอมพิวเตอร์ต่าง ๆ ภายในเครือข่ายขององค์กร โดยข้อมูลต่าง ๆ ที่เก็บเอาไว้ภายใน AD DS จะอยู่ในรูปแบบของ object ที่ภายในนั้นจะมีรายละเอียดของ object นั้น ๆ เก็บเอาไว้ เช่น ชื่อ สิทธิการใช้งาน เป็นต้น ทั้งนี้ทั้งนั้นข้อมูลเหล่านี้จะทำให้ถูกเข้าถึงได้ด้วยผู้ใช้งานทุกคนที่อยู่ภายในองค์กร

Scenario

ทางทีมได้จัดทำตัวอย่างคร่าว ๆ ของการใช้งาน AD ขององค์กรที่ชื่อว่า vault.tec ขึ้นมา โดยภายในองค์กรจะประกอบไปด้วยกลุ่มผู้ใช้งานต่าง ๆ รวมถึงตัว Domain Controller ซึ่งจะเป็นเครื่องศูนย์กลางที่เอาไว้ใช้ในการจัดการกับสิ่งต่าง ๆ ภายในองค์กร

Forest Root Domain of vault.tec

Forest Root Domain of vault.tec

Forest Root Domain of vault.tec

Scenario Details

Domain:
    |_ vault.tec

Domain Controller:
    |_ vault.tec\santa-monica$

Enterprise Certificate Authority (CA):
    |_ vault.tec\santa-monica$

Domain Groups
    |_ Vault Overseers
    |_ Vault Dwellers
    |_ Mister Handies

Domain Admins
    |_ Hank MacLean
    |_ Betty Pearson

Domain Users
    |_ Codsworth
    |_ Lucy Maclean
    |_ Norm Maclean
    |_ Chet

Group Policies
    |_ The Vault Policies

Active Directory Certificate Service (AD CS)

AD CS เป็นหนึ่งใน Windows Server role service ที่ประยุกต์ใช้หลักการของ Public Key Infrastructure (PKI) เพื่อใช้ในการสร้างและจัดการกับ digital certificate ต่าง ๆ ภายในองค์กร โดยตัวมันเองก็จะมี feature อยู่ด้วยกันหลายส่วน แต่สิ่งที่จะนำมาพูดถึงกันในบทความนี้และบทความต่อ ๆ ไปมีดังนี้

  • Certificate Authorities (CA): เครื่องที่ใช้ในการสร้างและจัดการกับ digital certificate ทั้งหมด โดยจะมีด้วยกัน 2 ประเภทคือ Standalone CA และ Enterprise CA
    • Standalone CA: เป็นเครื่อง server ที่ไม่จำเป็นต้องเชื่อมต่อกับ AD หรือเครือข่ายใด ๆ จะมีอยู่ด้วยกัน 2 รูปแบบคือ Standalone Root CA และ Standalone Subordinate CA
    • Enterprise CA: เป็นเครื่อง server ที่เป็น member server ภายใน AD เนื่องจากจำเป็นที่จะต้องใช้ในการสร้างและจัดการกับ certificate ต่าง ๆ ภายในองค์กร
  • Web Enrollment: เว็บไซต์ที่ใช้สำหรับให้ผู้ใช้งานส่งคำขอเพื่อสร้าง certificate ที่ต้องการไปยังเครื่อง CA รวมถึงยังสามารถใช้ในการดาวน์โหลด certificate ที่ได้รับการอนุมัติจาก CA มาแล้วได้อีกด้วย หลังจากที่เปิดใช้งาน feature นี้แล้ว เราสามารถเข้าไปที่ http://<server_name>/certsrv เพื่อใช้งานได้เลย

AD CS — Web Enrollment Interface

AD CS — Web Enrollment Interface

CA Hierarchy

ในการจะใช้งาน AD CS เราจำเป็นที่จะต้องออกแบบโครงสร้างของ CA ให้ตรงกับความความต้องการที่จะใช้งานของเราก่อน โดยทาง Microsoft ได้มีการจัดทำตัวอย่างโครงสร้างขึ้นมา 3 รูปแบบด้วยกัน

1) One-tier Hierarchy

One-tier Hierarchy Architecture from Microsoft

One-tier Hierarchy Architecture from Microsoft

โครงสร้างนี้จะเป็นการใช้งานเครื่อง server เครื่องเดียวที่ทำหน้าที่ทั้งการเป็น Root CA และเป็นเครื่องที่ใช้สร้าง certificate ทั้งนี้ทั้งนั้นทางทาง Microsoft ไม่แนะนำให้มีการใช้งานโครงสร้างนี้เท่าไรนัก เนื่องด้วยปัญหาทางด้านความปลอดภัยที่ว่าหากเครื่อง server ถูกโจมตีและถูกยึดครองไปได้ ก็จะกลายเป็นว่าผู้โจมตีจะสามารถจัดการ PKI ของทั้งองค์กรได้เลย ซึ่งจะนำไปสู่การขยายผลและฝังตัวต่อภายในองค์กร ผู้โจมตีจะใช้เทคนิคที่เรียกว่า Golden Certificates เพื่อสร้าง certificate ที่ใช้ในการยืนยันตัวตนผ่านทาง Kerberos มาเก็บเอาไว้

2) Three-tier Hierarchy

Three-tier Hierarchy Architecture from Microsoft

Three-tier Hierarchy Architecture from Microsoft

วิธีการนี้จะเป็นการแบ่งชั้นออกเป็นทั้งหมด 3 ส่วนด้วยกัน

  • Offline Root CA
  • Offline Intermediate CA
  • Online Issuing CA

โดยวิธีการนี้จะเป็นการออกแบบให้เครื่อง Root CA สร้าง certificate ขึ้นมาและนำไปติดตั้งที่เครื่อง offline intermediate CA จากนั้นเครื่อง offline intermediate CA จะสร้าง certificate ให้เครื่อง online CA ไปติดตั้ง เวลาที่ user มา request certificate จะต้องมีการ request ที่เครื่อง online CA แทน

สำหรับโครงสร้างรูปแบบนี้จะมีการเพิ่มเครื่อง server ขึ้นมาเป็น Intermediate CA กับเครื่องที่ไว้ใช้สำหรับสร้างและจัดการกับ certificate โดยการใช้งานโครงสร้างนี้จะมีความปลอดภัยที่สูงขึ้นเมื่อเทียบกับของ One-tier เพราะหาก private key ของเครื่อง root CA หรือ intermediate CA รั่วไหลออกไปก็จะไม่สามารถนำไปใช้งานต่อได้ แต่ทั้งนี้ทั้งนั้นก็จะแลกมากับ cost ที่เพิ่มขึ้นอีกด้วย

3) Two-tier Hierarchy

Two-tier Hierarchy Architecture from Microsoft

Two-tier Hierarchy Architecture from Microsoft

เป็นการผสมผสานกันของ one-tier + three-tier โดยจะใช้เครื่อง offline Root CA + online intermediate certificate โดยหน้าที่ของเครื่อง offline root ca จะใช้ในการสร้างและ sign certificate ให้กับเครื่อง online intermediate CA เท่านั้นและปิดเครื่องไป ส่วนหน้าที่ในการสร้าง certificate ต่าง ๆ ให้กับผู้ใช้งานจะเป็นหน้าที่ของเครื่อง online intermediate CA

AD CS Elements

ก่อนที่เราจะไปลงรายละเอียดของเทคนิคการโจมตีกัน ทางผู้เขียนอยากจะพาผู้อ่านทุกท่านไปทำความรู้จักกับองค์ประกอบที่เกี่ยวข้องกับ AD CS กันสักก่อนเล็กน้อยก่อน

Certificate Templates

ท่านผู้อ่านหลาย ๆ ท่านอาจจะคุ้นเคยกับ SSL certificate ที่ใช้ใน HTTPS กันดีอยู่แล้ว แต่ทราบหรือไม่ว่าเราสามารถใช้ certificate เพื่อวัตถุประสงค์อื่นได้ด้วย เช่น ใช้ในการยืนยันตัวตน (client authentication), digital signature, smart card logon เป็นต้น

ในการสร้าง certificate ขึ้นมาในแต่ละครั้งนั้น Enterprise Certificate Authority (CA) จะนำการตั้งค่าของ certificate มาจาก Certificate Templates ซึ่งเป็นรูปแบบที่เรากำหนดเอาไว้แล้ว เช่น certificate นี้ใช้ทำอะไร อายุของ certificate มีระยะเวลาเท่าไร ใครสามารถ enroll certificate นี้ได้บ้าง เป็นต้น

ตัวอย่างด้านล่างนี้จะเป็นการตั้งค่าของ template ที่ชื่อว่า Visitors โดยรายละเอียดของ template จะเป็นดังนี้

  • Certificate นี้ใช้สำหรับการทำ document signing เท่านั้น
  • ผู้ใช้งานที่อยู่ใน group Vault_Visitor เท่านั้นจึงจะสามารถ enroll ได้
  • enrollment request จะต้องได้รับการอนุมัติจาก CA manager ก่อน

Certificate Template Properties: Vault Visitor

Certificate Template Properties: Vault Visitor

Permissions of Certificate Template

ในแต่ละ template นั้น เราจะสามารถกำหนด permission ได้ว่าจะให้ Domain Group และ Domain User สามารถทำอะไรกับ certificate นั้น ๆ ได้บ้าง จากตัวอย่างด้านล่างจะเป็นตัวอย่างการตั้งค่าสิทธิการใช้งานของผู้ใช้งานในกลุ่ม Authenticated Users ซึ่งจะเป็นผู้ใช้งานทั้งหมดบน Active Directory จะสามารถเห็น certificate template ที่ชื่อว่า Visitors ได้ แต่จะไม่สามารถ enroll หรือแก้ไขการตั้งค่าใด ๆ ได้

Certificate Template Security: Permissions of Authenticated User

Certificate Template Security: Permissions of Authenticated User

โดยทั่วไปแล้วสิทธิการใช้งานของ certificate template จะมีดังต่อไปนี้

  • Full Control : สิทธิการใช้งานที่เป็นเจ้าของ certificate template รวมถึงจะสามารถแก้ไขการตั้งค่าทุกอย่างได้
  • Read : ผู้ใช้งานที่มีสิทธิการใช้งานนี้ จะสามารถทำได้แค่เห็นว่ามี certificate template นี้อยู่ในระบบได้เพียงอย่างเดียว ไม่สามารถ enroll หรือแก้ไขการตั้งค่าใด ๆ ได้
  • Write : ผู้ใช้งานที่มีสิทธิการใช้งานนี้ จะสามารถแก้ไขการตั้งค่าต่าง ๆ ของ certificate template ได้
  • Enroll : ผู้ใช้งานที่มีสิทธิการใช้งานนี้ จะสามารถ enroll เพื่อขอใช้งาน certificate ได้
  • Autoenroll : ใช้สำหรับระบุให้ผู้ใช้หรือคอมพิวเตอร์สามารถขอ certificate นั้น ๆ ได้อย่างอัตโนมัติ ส่วนใหญ่มักจะเอาไว้ใช้งานในการต่ออายุของ certificate เองอัตโนมัติ

หากมีการตั้งค่าสิทธิการใช้งานที่ไม่เหมาะสม จะทำให้ผู้ใช้งานหรือ Domain Group นั้น ๆ สามารถควบคุม certificate template นั้น ๆ ได้เลย

Certificate Template Security: Excessive Permission of vault.tec\codsworth

Certificate Template Security: Excessive Permission of vault.tec\codsworth

Extended Key Usage (EKU)

Certificate templates แต่ละอันนั้นก็จะมีวัตถุประสงค์ในการใช้งานที่แตกต่างกันออกไป เช่น สามารถใช้ในการยืนยันตัวตน ใช้ใน document signing เป็นต้น

ตัวอย่างด้านล่างจะเป็น certificate template ที่ชื่อว่า User ซึ่งเป็น default certificate template ที่มาพร้อมกับ AD CS โดยวัตถุประสงค์ของ certificate นี้มีดังนี้

  • ใช้เข้ารหัสข้อมูลต่าง ๆ ที่อยู่ใน file system
  • ใช้ในการ signing และเข้ารหัสอีเมล
  • สามารถใช้ certificate นี้ในขั้นตอนการยืนยันตัวตนได้

Certificate Details

Certificate Details

เราสามารถเข้าไปกำหนด EKU ของแต่ละ certificate template ได้เองว่าอยากให้แต่ละอันนั้นมีวัตถุประสงค์ในการใช้งานเป็นอย่างไร โดยรัน certsrv.msc ****จากนั้นจึงคลิกขวาที่ "Certificate Templates > Manage" เพื่อทำการจัดการ certificate template ที่เรามีอยู่ทั้งหมด

💡 ในการการใช้งาน certsrv.msc จำเป็นที่จะต้องรันที่เครื่อง CA ด้วยสิทธิที่สามารถจัดการกับ CA เท่านั้น

CA Management

CA Management

เมื่อกดดู properties ของ certificate template ที่ต้องการแล้ว ให้เลือกไปที่ tab "Extensions > Application Policies" เราจะสามารถกำหนดได้ว่าจะให้ certificate template นี้ทำอะไรได้บ้าง หากเรามีการตั้งค่า EKU ที่ไม่เหมาะสม จะส่งผลให้ผู้ใช้งานที่มีสิทธิในการขอ certificate นั้น ๆ สามารถนำไปใช้ยกระดับสิทธิของตัวเองให้สูงขึ้นได้ โดยรายละเอียดเพิ่มเติมจะมีการกล่าวถึงในบทความถัด ๆ ไปอีกครั้ง

Certificate Template Properties: Application Policies

Certificate Template Properties: Application Policies

Subject Alternative Name (SAN)

SAN จะเป็นส่วนที่เราใช้ในการระบุถึง subdomain หรือ username เพิ่มเติมที่สามารถใช้งาน certificate นั้น ๆ ได้ ส่วนใหญ่มักจะเห็นใน SSL certificate ที่จะทำการระบุถึง subdomain ต่าง ๆ ของเราเอาไว้ ทำให้เราซื้อ certificate เพียงแค่ใบเดียวแต่ก็สามารถใช้ได้ในทุก subdomain ที่เราเป็นเจ้าของ แทนที่จะเป็นการซื้อ certificate ใหม่ให้กับทุก subdomain

SSL Certificate of Incognito Lab’s Website

SSL Certificate of Incognito Lab’s Website

การระบุค่า SAN ยังมีการใช้งานใน certificate ประเภทอื่น ๆ เช่นกัน ยกตัวอย่างเช่น web server certificate, RDS certificate (certificate ที่ใช้สำหรับ RDP) เป็นต้น ที่จะอนุญาตให้ผู้ใช้งานสามารถระบุ hostname ที่ต้องการได้

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

ตัวอย่างนี้จะสังเกตเห็นได้ certificate ในภาพด้านล่างจะใช้เพื่อยืนยันตัวตนและสร้างให้กับผู้ใช้งาน codsworth@vault.tec แต่ผู้ใช้งานคนดังกล่าวมีการระบุค่า SAN มาเป็น hank.mac@vault.tec ด้วย ทำให้ผู้ใช้งานดังกล่าวสามารถยืนยันตัวตนเป็น hank.mac@vault.tec ได้

The Certificate was issued to vault.tec\codsworth

The Certificate was issued to vault.tec\codsworth

Certificate Signing Request (CSR)

ผู้ใช้งานที่อยู่ภายใน Active Directory หรือภายในองค์กรนั้นสามารถที่สร้าง CSR ขึ้นมาเพื่อที่จะใช้ในการส่งคำร้องไปยัง Enterprise CA ได้ว่าเราต้องการ certificate อะไร โดยจะมีการอ้างอิงจาก certificate template ที่มีอยู่ภายใน AD CS

ในรูปตัวอย่างด้านล่างจะเป็นไฟล์ CSR ที่ได้มีการสร้างขึ้นมาอยู่ในรูปแบบ Base64 และพร้อมที่จะนำไป submit ที่ CA เพื่อขอ certificate ต่อไปนั่นเอง

Certificate Signing Request (CSR) file

Certificate Signing Request (CSR) file

Certificate Enrollment Process

Certificate Enrollment Process from SpecterOps’s "Certified Pre-Owned: Abusing Active Directory Certificate Services"

Certificate Enrollment Process from SpecterOps’s "Certified Pre-Owned: Abusing Active Directory Certificate Services"

Certificate Enrollment Process from SpecterOps's "Certified Pre-Owned: Abusing Active Directory Certificate Services"

ก่อนที่ผู้ใช้งานจะได้ certificate ที่ต้องการไปใช้งานนั้น จะต้องผ่านขั้นตอนกระบวนการในขอ certificate จาก CA เสียก่อน โดยขั้นตอนหลัก ๆ จะมีดังนี้

  1. ผู้ใช้งานจะต้องมีการสร้างคู่ของ public และ private key ขึ้นมาก่อน
  2. สร้าง CSR ขึ้นมา โดยระบุ certificate template ที่ต้องการใช้งาน จากนั้นจึงส่ง CSR ไปยัง CA สำหรับขั้นตอนจะเป็นดังต่อไปนี้
    1. เปิด certmgr.msc ด้วยผู้ใช้งานภายในระบบหรือ Active Directory จากนั้นจึงคลิกขวาที่ "Personal > Certificate" และเลือก "All Tasks > Advanced Operations > Create Custom Request"
      CSR Process: Create Custom Request

      CSR Process: Create Custom Request

    2. เราสามารถเลือกได้เลยว่าต้องการขอ certificate โดยอ้างอิงจาก template ที่มีภายในระบบ ในตัวอย่างด้านล่างจะเป็นการขอ certificate จาก template ที่ชื่อว่า Vault Visitor Authentication - ESC1
      CSR Process: Select Certificate Template

      CSR Process: Select Certificate Template

    3. เมื่อเลือก certificate template ที่ต้องการเรียบร้อยแล้ว เราสามารถระบุรายละเอียดเพิ่มเติมเกี่ยวกับ certificate ที่เราจะขอได้ด้วย เช่น ระบุชื่อ SAN ที่ต้องการจะใช้งาน (หาก certificate template มีการตั้งค่าให้เราสามารถใส่ชื่อ SAN ได้), ใส่ชื่อและคำอธิบายของ certificate ได้, ตั้งค่าให้ private key สามารถ export ได้ เป็นต้น
      CSR Process: Specify Details on Certificate

      CSR Process: Specify Details on Certificate

    4. เมื่อทุกอย่างเรียบร้อยแล้ว เราสามารถเลือกได้ว่าจะ save CSR ให้อยู่ในรูปแบบใด รวมถึงชื่อไฟล์ CSR ที่เราต้องการได้
      CSR Process: Save Certificate to Specific Path

      CSR Process: Save Certificate to Specific Path

    5. ในการส่ง CSR ไปยัง CA เราสามารถทำได้หลายรูปแบบ ไม่ว่าจะเป็นการส่ง CSR ไปให้ผู้ที่มีสิทธิในการจัดการกับ CA เพื่อออก certificate ที่เราต้องการได้, การใช้ส่ง request ผ่านทาง Web Enrollment หรือการใช้ Windows command line ก็ได้เช่นกัน
      1. ดำเนินการผ่าน CA โดยตรง
        CSR Submission via CA

        CSR Submission via CA

      2. ส่ง CSR ผ่าน Web Enrollment
        CSR Submission via ADCS Web Enrollment 1

        CSR Submission via ADCS Web Enrollment 1


        CSR Submission via ADCS Web Enrollment 2

        CSR Submission via ADCS Web Enrollment 2

      3. Windows Command Line
        certreq -submit <CSR_FILE> <CERTIFICATE>.cer
        

        CSR Submission via command line

        CSR Submission via command line

  3. CA จะทำการตรวจสอบ CSR ที่ผู้ใช้ส่งเข้ามาว่า
    1. Certificate template ที่ระบุมานั้นมีอยู่ภายในระบบหรือไม่
    2. ผู้ใช้งานดังกล่าวมีสิทธิที่จะทำการ enroll certificate template นั้น ๆ หรือไม่
  4. หลังจากที่มีการตรวจสอบ CSR เรียบร้อยแล้ว CA จะสร้างและ sign certificate ใบนั้นให้กับผู้ใช้งาน
  5. ผู้ใช้งานนำ certificate ที่ได้รับมานั้นไปใช้งานตามวัตถุประสงค์ของ certificate นั้น ๆ ได้เลย

💡 ในเครื่องขององค์กรที่ join domain เอาไว้ เราสามารถกดขอ certificate ที่เราต้องการได้ผ่าน certmgr.msc ได้เลย

Certificate Request from Join Domain Machine 1

Certificate Request from Join Domain Machine 1

Certificate Request from Join Domain Machine 2

Certificate Request from Join Domain Machine 2

Certificates in Windows Authentication

ขอเล่าย้อนคร่าว ๆ เกี่ยวกับ Kerberos กันสักหน่อย ปกติแล้วในการยืนยันตัวตนผ่าน Kerberos เราจะต้องผ่านกระบวนการ Pre-authentication ก่อนโดยการส่ง username + enc(timestamp, password_hash) ไปยัง KDC (Key Distribution Center) เพื่อใช้ในการยืนยันตัวตนและขอ TGT (Ticket Granting Ticket) ที่จะนำไปใช้ในการขอ TGS (Ticket-Granting Service) ต่อไป

Kerberos Pre-Authentication Flow: TGT Request from Kerberos in Windows Domain Environment

Kerberos Pre-Authentication Flow: TGT Request from Kerberos in Windows Domain Environment

แต่ภายใน Kerberos protocol เรายังสามารถใช้งาน Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) ในกระบวนการ Pre-authentication ได้ด้วยเหมือนกัน จะต่างกันกับการยืนยันตัวตนผ่าน Kerberos ปกติตรงที่จะใช้ certificate ในการยืนยันตัวตนแทนการใช้ username และ password ของผู้ใช้งาน ซึ่งตัว KDC ก็จะนำ certificate ที่ได้รับมาจาก client ไป validate ต่อ ถ้าทุกอย่างถูกต้องก็จะตอบกลับค่า session key และ TGT กลับไปยัง client เพื่อใช้ในขั้นตอนต่อ ๆ ไปของการขอ ticket ต่อไป

Kerberos PKINIT Pre-Authentication Flow

Kerberos PKINIT Pre-Authentication Flow

หากใครสนใจอ่านเรื่อง Kerberos เพิ่มเติม สามารถเข้าไปที่บทความด้านล่างที่ทางทีมงาน Incognito Lab เคยเขียนเอาไว้ได้เลย

Blog preview image

Kerberos in Windows Domain Environment

Kerberos in Windows Domain Environment

ภายในบทความนี้เราได้ทำความรู้จัก AD CS กันไปคร่าว ๆ บ้างแล้ว ในบทความถัด ๆ ไป ทางทีมงาน Incognito Lab จะพาทุกท่านไปรู้จักกับการโจมตี AD CS เพื่อยกระดับสิทธิการใช้งานให้สูงขึ้นโดยอาศัยช่องโหว่หรือการตั้งค่าที่ไม่ปลอดภัยของ certificate template และ CA server รวมถึงการฝังตัวของผู้โจมตีและการป้องตั้งค่าอย่างไรให้รัดกุม

สำหรับวันนี้ขอบคุณทุกท่านที่สละเวลามาอ่านบทความนี้กันนะครับ หากมีส่วนไหนที่จะเสริมก็สามารถแสดงความเห็นกันเข้ามาได้นะครับ ไว้พบกันใหม่ในบทความถัด ๆ ไปครับ

Joker Dance Parody with Bocchi

Joker Dance Parody with Bocchi


References:

Certified Pre-Owned by Will Schroeder & Lee Christensen

https://posts.specterops.io/adcs-attack-paths-in-bloodhound-part-1-799f3d3b03cf

https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/active-directory-certificate-services-overview

https://learn.microsoft.com/en-us/training/modules/implement-manage-active-directory-certificate-services/

ReCertifying Active Directory Certificate Services by Black Hat

https://cyberstoph.org/posts/2019/12/an-introduction-to-golden-certificates/

https://github.com/ly4k/Certipy

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786436(v=ws.11)

https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certification-authority-role

https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication#BKMK_CertificatesInWindowsAuthentication

https://www.encryptionconsulting.com/education-center/what-is-certificate-enrollment-and-how-is-it-used/

"Kerberos PKINIT: what, why, and how (to break it)" by Fraser Tweedale at Everything Open 2023

Up Next

Blog preview image

ARTICLES

Dec

26

2025

ฝึกซ้อม Cyber Drill ด้วย CYBER RANGES

CYBER RANGES แพลตฟอร์มที่ช่วยเพิ่มขีดความสามารถทางด้าน cybersecurity แบบ all-in-one แน่นอนว่ามีโมดูลมากมายที่ช่วยพัฒนาขีดความสามารถด้าน cybersecurity มากมาย

READ MORE

Blog preview image

ARTICLES

Dec

11

2025

รีวิว GMOB 2025: เจาะลึกเนื้อหา Mobile Security พร้อมทริคเตรียมตัวสอบแบบม้วนเดียวจบ

รีวิวสอบ GMOB 2025 เจาะลึกเนื้อหา Mobile Security ครอบคลุมทั้ง Android และ iOS พร้อมสรุปเทคนิคการใช้เครื่องมือ Pentest และวิธีการทำ Index สำหรับสอบ Open Book เพื่อแนวทางการเตรียมตัวที่ครบถ้วนและตรงจุด

READ MORE

Blog preview image

ARTICLES

Sep

03

2025

Invisible Threat ภัยเงียบที่มองไม่เห็น

การจัดการ Malware บน Unmanaged device ขององค์กรถือว่าเป็นเรื่องที่ท้าทายมาก โดยเฉพาะ Malware ที่ขโมยข้อมูลออก ทำให้เราเหมือนเลือดออกตลอดเวลา จะหยุดเลือดนี้ได้อย่างไร?

READ MORE

logologo

INCOGNITO LAB CO., LTD.

38 Soi Petchakasem 30, Pak Khlong Phasi Charoen, Phasi Charoen, Bangkok 10160

©2026 Incognito Lab Co., Ltd. All rights reserved

Terms & Conditions Privacy Policy