#10 AD CS Security Cheat Sheet: Audit Certificate Templates, Detection dan Hardening

Active Directory Certificate Services (AD CS) sering hidup tenang bertahun-tahun di jaringan enterprise. Ia menerbitkan certificate untuk user, computer, Wi-Fi, VPN, TLS, smart card, dan berbagai kebutuhan authentication. Karena jarang bikin suara, AD CS juga gampang luput dari review security.

Masalahnya: certificate adalah bagian dari trust. Kalau konfigurasi trust-nya terlalu longgar, dampaknya bisa jauh lebih serius daripada sekadar salah permission pada satu folder.

Artikel #10 Red Team Cheat Sheet Series ini membahas cara mengaudit posture AD CS secara defensif: memahami CA dan certificate template, mengenali keluarga misconfiguration ESC, mengumpulkan inventory, membaca evidence, membangun detection, dan melakukan hardening. Fokusnya bukan resep mengambil alih account, tetapi bagaimana security assessor menemukan jalur risiko sebelum adversary yang menemukannya.

Gunakan seluruh contoh hanya pada lab, sistem milik sendiri, atau environment yang secara eksplisit termasuk dalam scope security assessment.

Kenapa AD CS Penting?

AD CS adalah implementasi Public Key Infrastructure (PKI) Microsoft untuk environment Windows. Dalam deployment enterprise, certificate template disimpan di Active Directory Domain Services dan digunakan Enterprise CA untuk menentukan bagaimana certificate dapat diminta dan diterbitkan.

Secara sederhana:

User / Computer
      ↓
Certificate Template
      ↓
Enterprise CA
      ↓
Certificate
      ↓
Authentication / TLS / Signing / Encryption

Certificate template menentukan banyak hal penting: siapa yang boleh enroll, tujuan certificate melalui Extended Key Usage (EKU), apakah requester boleh menentukan subject, apakah approval diperlukan, dan permission siapa yang boleh mengubah template.

Kelihatannya administratif. Tetapi satu checkbox yang salah bisa mengubah trust model satu domain.

Istilah yang Harus Dikenal

Certification Authority (CA)

CA menerbitkan dan menandatangani certificate. Dalam enterprise PKI, CA menjadi salah satu akar kepercayaan yang sangat sensitif.

Certificate Template

Template adalah policy object yang menentukan bagaimana certificate diterbitkan. Template Enterprise CA disimpan di AD DS sehingga dapat digunakan secara konsisten dalam forest.

Enrollment

Enrollment adalah proses principal meminta certificate berdasarkan template tertentu.

Extended Key Usage (EKU)

EKU menentukan untuk apa certificate boleh digunakan. Contohnya client authentication, server authentication, code signing, dan lainnya.

Subject Alternative Name (SAN)

SAN mengizinkan identitas tambahan berada dalam certificate. Fitur ini sah dan sangat berguna, tetapi menjadi sensitif ketika requester dapat menentukan identitas secara terlalu bebas pada template yang juga dapat digunakan untuk authentication.

ACL

Certificate template dan CA memiliki access control. Jadi review AD CS bukan hanya melihat cryptography; kita juga harus melihat siapa boleh melakukan apa.

ESC Itu Apa?

Riset security AD CS mempopulerkan klasifikasi ESC (Escalation) untuk menjelaskan berbagai konfigurasi PKI yang dapat membentuk privilege-escalation path.

Jangan memperlakukan ESC sebagai daftar jurus untuk dihafalkan. Lebih berguna melihatnya sebagai taxonomy untuk audit.

Beberapa keluarga risiko yang penting:

template terlalu permisif;
EKU terlalu luas;
enrollment-agent configuration yang berisiko;
ACL template terlalu longgar;
ACL CA terlalu longgar;
CA setting yang memungkinkan requester mengontrol identity information;
web enrollment yang tidak memiliki perlindungan relay memadai;
RPC enrollment tanpa protection yang cukup;
certificate mapping yang lemah;
template/application policy yang membuka jalur impersonation.

Microsoft Defender for Identity kini memiliki security posture assessment khusus certificate yang mencakup beberapa kategori ini, termasuk ESC1, ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, ESC11, dan ESC15.

Artinya AD CS security sudah bukan niche research. Ia masuk ke pekerjaan identity-security sehari-hari.

Lab yang Aman

Untuk memahami AD CS, lab sederhana dapat terdiri dari:

DC01   - Domain Controller
CA01   - Enterprise Certification Authority
WIN11  - Domain workstation
AUDIT  - Administrative/security workstation

Gunakan domain lab seperti:

lab.example

Pisahkan lab dari production dan gunakan snapshot VM.

Tujuan kita adalah melihat konfigurasi PKI, bukan membuat production CA ikut eksperimen Jumat sore. Jumat sore sudah punya cukup masalah sendiri.

Audit #1 — Inventory CA

Pertanyaan pertama sangat sederhana:

CA apa saja yang sebenarnya ada?

Dokumentasikan minimal:

hostname CA;
CA name;
Enterprise atau Standalone CA;
root/subordinate role;
certificate validity;
enrollment interface yang aktif;
published templates;
administrator/manager permission;
logging dan monitoring;
backup dan key protection.

Jangan berasumsi CMDB selalu lengkap. PKI lama sering bertahan lebih lama daripada orang yang dulu memasangnya.

Audit #2 — Inventory Certificate Templates

Microsoft menyediakan Certificate Templates MMC snap-in untuk mengelola template AD CS.

Dalam assessment, buat inventory:

Template Name
Purpose / EKU
Published?
Enroll Permission
Autoenroll Permission
Subject Name Configuration
Manager Approval
Authorized Signatures
Template ACL
Validity Period

Ini bukan pekerjaan paling glamor dalam Red Team Series, tetapi justru di sinilah misconfiguration biasanya terlihat.

Audit #3 — Siapa yang Boleh Enroll?

Cari template yang dapat dienroll oleh group luas seperti:

Authenticated Users
Domain Users
Everyone

Permission luas tidak otomatis berarti vulnerability.

Pertanyaannya harus digabungkan dengan:

certificate dapat digunakan untuk apa?
siapa menentukan subject/SAN?
apakah manager approval aktif?
apakah authorized signature dibutuhkan?
apakah template dipublish oleh CA?

Security assessment selalu soal kombinasi kondisi.

Satu checkbox jarang bercerita lengkap.

Audit #4 — Subject dan SAN

Salah satu konfigurasi paling sensitif adalah ketika requester dapat memasok subject information pada certificate yang dapat digunakan untuk authentication.

Dalam konteks ESC1, risiko meningkat ketika beberapa kondisi bertemu: enrollment tersedia bagi principal berprivilege rendah, requester dapat menentukan SAN, certificate mempunyai EKU yang memungkinkan client authentication, dan tidak ada approval/signature control yang cukup.

Jadi jangan sekadar mencari tulisan Supply in the request lalu panik.

Validasi seluruh chain kondisinya.

Audit #5 — Extended Key Usage

Review EKU pada template.

Pertanyaan yang berguna:

Apakah template benar-benar membutuhkan Client Authentication?
Apakah ada Any Purpose EKU?
Apakah template tanpa EKU memang dirancang seperti itu?
Apakah enrollment permission sesuai dengan kekuatan EKU?

Microsoft secara eksplisit menyoroti template dengan Any Purpose atau tanpa EKU sebagai posture risk ketika dapat dienroll secara terlalu luas.

Prinsipnya sederhana:

Semakin kuat kemampuan certificate, semakin ketat siapa yang boleh mendapatkannya.

Audit #6 — ACL Certificate Template

Template adalah object di Active Directory dan memiliki ACL.

Periksa siapa yang mempunyai permission seperti:

Full Control
Write
Write DACL
Write Owner

terhadap template sensitif.

Group berprivilege rendah seharusnya tidak dapat mengubah policy object yang menentukan bagaimana identity certificate diterbitkan.

Ini merupakan inti risiko yang sering dikelompokkan sebagai ESC4.

Audit #7 — CA Administrative Permission

Jangan hanya melihat template. Review ACL pada CA.

Role seperti Manage CA dan Manage Certificates sangat sensitif.

Tanyakan:

siapa anggotanya?
apakah permission diwariskan karena alasan historis?
apakah service account masih membutuhkan privilege tersebut?
apakah ada account lama yang tidak lagi digunakan?
apakah aktivitas administratif diaudit?

Least privilege juga berlaku untuk PKI. Bahkan mungkin lebih penting, karena kita sedang berbicara tentang mesin pembuat trust.

Audit #8 — Web Enrollment

AD CS dapat memiliki HTTP-based enrollment endpoint.

Dari perspektif defensive assessment, cari:

apakah endpoint masih dibutuhkan;
apakah masih menggunakan HTTP;
bagaimana authentication dikonfigurasi;
apakah HTTPS diwajibkan;
apakah Extended Protection for Authentication / channel binding diterapkan sesuai kebutuhan;
apakah NTLM masih diperlukan.

Microsoft menandai insecure AD CS enrollment IIS endpoints sebagai posture issue terkait ESC8.

Kalau sebuah interface legacy tidak lagi diperlukan, solusi paling aman kadang bukan menambah tiga lapis monitoring. Solusinya: matikan interface-nya.

Security engineering sesekali memang sesederhana itu.

Audit #9 — RPC Enrollment

AD CS juga mendukung certificate enrollment melalui RPC.

Microsoft merekomendasikan enforcement encryption untuk RPC certificate enrollment interface sebagai mitigasi risiko ESC11. Packet privacy memberikan authentication level tinggi sehingga traffic ditandatangani dan dienkripsi, membantu mencegah relay.

Audit apakah CA membutuhkan konfigurasi tambahan dan uji perubahan terlebih dahulu di controlled environment.

Jangan mengubah PKI production sambil berkata, "harusnya aman". Kalimat itu terkenal punya timing buruk.

Audit #10 — Strong Certificate Mapping

Certificate-based authentication pada Windows telah bergerak menuju strong certificate mapping. Microsoft memperketat mapping agar certificate terikat lebih kuat ke user/device identity, termasuk penggunaan SID extension pada skenario tertentu.

Dalam assessment modern, review:

patch level Domain Controller;
certificate mapping configuration;
legacy certificate yang masih digunakan;
template yang menghasilkan certificate authentication;
dependency aplikasi lama.

Hardening identity hampir selalu bertemu compatibility. Karena itu inventory lebih dulu, enforcement kemudian.

Cheat Sheet Audit AD CS

Berikut checklist ringkas yang aman digunakan sebagai worksheet assessment:

[ ] Inventory seluruh CA
[ ] Identifikasi Enterprise / Standalone CA
[ ] Inventory published certificate templates
[ ] Review EKU setiap template sensitif
[ ] Review Enroll dan Autoenroll permission
[ ] Cari broad enrollment groups
[ ] Review Subject Name / SAN configuration
[ ] Review Manager Approval
[ ] Review Authorized Signatures
[ ] Review template ACL
[ ] Review CA ACL
[ ] Review Manage CA / Manage Certificates delegation
[ ] Review Web Enrollment exposure
[ ] Review HTTPS dan Extended Protection
[ ] Review RPC enrollment protection
[ ] Review certificate mapping posture
[ ] Review CA auditing dan certificate issuance logs
[ ] Review revocation / CRL availability
[ ] Review backup dan CA private-key protection
[ ] Dokumentasikan owner dan business purpose template
[ ] Retest setelah remediation

Cheat sheet ini memang tidak membuat terminal penuh warna. Tetapi ia jauh lebih berguna ketika tujuan kita benar-benar memperbaiki environment.

Studi Kasus — Template VPN Lama

Bayangkan organisasi memiliki template:

Name              : Legacy-VPN-User
Purpose           : Client Authentication
Enrollment        : Domain Users
Subject handling  : Requester-supplied
Manager approval  : Disabled
Status            : Published

Template dibuat tujuh tahun lalu untuk VPN lama. VPN-nya sendiri sudah diganti, tetapi template masih dipublish.

Ini pola yang sering terjadi: teknologi pergi, permission tinggal.

Pertanyaan assessor

Kita tidak langsung menyimpulkan domain compromise.

Kita validasi:

Apakah template masih benar-benar dapat dienroll?
Apakah certificate valid untuk domain authentication?
Bagaimana subject/SAN diproses?
Apakah ada issuance requirement lain?
CA mana yang mempublish template?
Siapa business owner-nya?
Apakah certificate dari template tersebut masih aktif?

Remediation

Jika tidak lagi diperlukan:

unpublish template dari CA;
revoke certificate yang relevan berdasarkan impact analysis;
dokumentasikan retirement;
review template serupa.

Jika masih diperlukan:

batasi enrollment group;
perbaiki subject configuration;
review EKU;
pertimbangkan approval/signature requirement;
monitor issuance.

Temuan yang bagus bukan sekadar memberi label ESC1. Temuan yang bagus menjelaskan mengapa konfigurasi itu berisiko dan bagaimana memperbaikinya tanpa merusak business process.

Attack → Evidence → Detection → Hardening

Sekarang pola khas Red Team Series.

Attack / Risk

Adversary mencari CA, template, enrollment endpoint, dan permission yang dapat mengubah certificate menjadi jalur identity escalation.

Evidence

Evidence defensif dapat berasal dari:

konfigurasi template;
ACL template;
CA security settings;
certificate request/issuance records;
Windows Event Log;
IIS log untuk web enrollment;
authentication telemetry;
perubahan object PKI di Active Directory.

Detection

Blue Team sebaiknya memperhatikan:

certificate request yang tidak biasa;
issuance dari template sensitif;
perubahan ACL certificate template;
perubahan CA configuration;
template baru yang dipublish;
enrollment dari user/device yang tidak sesuai baseline;
authentication certificate yang tidak sesuai pola normal;
akses abnormal ke web enrollment endpoint.

Detection akan jauh lebih kuat jika organisasi sudah tahu certificate apa yang normal.

Tanpa baseline, semua terlihat seperti PKI sedang melakukan PKI things.

Hardening

Prioritas umum:

hapus/unpublish template yang tidak diperlukan;
minimalkan enrollment permission;
minimalkan EKU;
hindari requester-controlled identity pada authentication template kecuali benar-benar diperlukan dan dilindungi;
perketat template ACL;
perketat CA administrative ACL;
gunakan approval/signature control bila sesuai risiko;
harden web enrollment;
enforce RPC protection;
modernisasi certificate mapping;
patch CA dan Domain Controller;
monitor issuance dan perubahan konfigurasi.

Jangan Lupa Private Key

Security certificate bukan hanya soal template.

CA private key adalah crown jewel.

Review:

lokasi key;
siapa yang dapat mengaksesnya;
apakah HSM diperlukan;
backup protection;
offline root CA design bila digunakan;
key ceremony dan recovery procedure;
audit terhadap administrative access.

Kalau CA private key jatuh ke tangan yang salah, diskusi tentang permission satu template terasa seperti mengunci jendela sementara pintu depan dibawa pergi.

Best Practices untuk Red Team / Security Assessor

Inventory Sebelum Validation

Mulai dari arsitektur dan configuration review. Jangan mulai dengan tindakan agresif.

Validasi Kombinasi Kondisi

ESC biasanya membutuhkan beberapa kondisi. Hindari false positive karena hanya melihat satu setting.

Minimum Impact

Dalam banyak assessment, bukti konfigurasi dan controlled validation sudah cukup. Tidak perlu membuktikan risiko dengan mengambil alih account privileged.

Lindungi Evidence

Certificate, private key, dan authentication artifact harus diperlakukan sebagai sensitive material.

Libatkan PKI Owner

PKI sering memiliki dependency yang tidak terlihat dari sisi security. Perubahan template dapat memengaruhi Wi-Fi, VPN, MDM, smart card, device authentication, atau aplikasi internal.

Retest

Setelah remediation, verifikasi bahwa attack path benar-benar tertutup dan business process tetap berjalan.

Hubungkan dengan BloodHound

Pada artikel #06 kita membahas BloodHound dan attack path Active Directory.

AD CS memperluas graph tersebut.

Relationship dapat muncul antara:

Principal
   ↓
Template Permission
   ↓
Certificate Template
   ↓
Enterprise CA
   ↓
Authentication Trust
   ↓
Privileged Identity

Karena itu certificate security sebaiknya tidak diaudit sebagai pulau terpisah dari Active Directory.

PKI adalah bagian dari identity plane.

Hubungkan dengan Artikel Sebelumnya

Learning path kita sekarang mulai menyatu:

#06 BloodHound — memetakan relationship dan attack path;
#07 Windows Credential Exposure — memahami risiko credential material;
#08 Kerbrute — Kerberos enumeration dan detection;
#09 Kerberos Service Account Security — SPN, ticket telemetry, dan service-account hardening;
#10 AD CS Security — certificate trust, template, CA, detection, dan hardening.

Ini alasan seri dibuat berurutan. Satu tool atau teknologi jarang berdiri sendiri dalam enterprise attack path.

Penutup

AD CS adalah contoh sempurna bahwa security problem tidak selalu datang dari software bug.

Kadang semuanya bekerja persis sesuai desain—hanya saja desain permission-nya terlalu ramah.

Security assessment AD CS yang baik harus dapat menjawab:

CA apa yang kita punya?

Template apa yang dipublish?

Siapa yang boleh enroll dan mengubahnya?

Certificate tersebut dapat digunakan untuk apa?

Apakah issuance dan perubahan configuration terlihat oleh Blue Team?

Kalau ada template legacy, siapa yang berani mematikannya?

Kalau pertanyaan terakhir membuat ruangan mendadak sunyi, biasanya kita menemukan pekerjaan berikutnya.

Artikel selanjutnya akan melanjutkan Active Directory track dengan membahas #11 Responder: memahami risiko LLMNR/NBT-NS poisoning dari perspektif assessment, detection, dan hardening.

Sumber Resmi dan Referensi Teknis

Microsoft Learn — Active Directory Certificate Services documentation
Microsoft Learn — Certificate template concepts in Windows Server
Microsoft Learn — Manage certificate templates
Microsoft Defender for Identity — Certificates security posture assessment
Microsoft guidance — Certificate-based authentication / strong certificate mapping
SpecterOps — Certified Pre-Owned: Abusing Active Directory Certificate Services
SpecterOps BloodHound — AD CS attack-path documentation

Selalu verifikasi detail konfigurasi terhadap dokumentasi Microsoft yang sesuai dengan versi Windows Server dan architecture PKI organisasi Anda.