-1577058304 on PingPong . 0 on Westbridge, weeks later. Same attribute — msPKI-Certificate-Name-Flag — two answers, one negative, one blank, and Google had nothing useful for either: the same copied 5-row table everywhere, none of it able to decode a negative number or explain what the CA would do with it. At that point the white rabbit was already running, and the only option was to follow — into the spec, into the bitmask, into two live boxes. It started as an appendix to the Westbridge writeup. It was too big for an appendix, so it became this. The msPKI-Certificate-Name-Flag attribute is frequently explained using an oversimplified, inaccurate sequential bitmask in Active Directory Certificate Services (AD CS) write-ups. If you are relying on community cheat sheets to identify ESC1 or ESC4 vulnerabilities, you might be missing critical attack paths due to a fundamental misunderstanding of how this attribute is structured. This post uses the official Microsoft protocol specifications as the source of truth to decode the exact values, expose the common “5-row table” fallacy, and provide a definitive reference for offensive operators and detection engineers. The second half is a full end-to-end run of the ESC4➜ESC1 chain on the live HackTheBox machine PingPong — every command, every output, every failure. TL;DR msPKI-Certificate-Name-Flag is a bitmask — not a boolean. And yes: in a lab, bloodyAD set object ... -v 1 gives you the same forged cert. Everyone who says “just 0➜1, what’s the use” is right — until the baseline has bits you can’t afford to lose. On PingPong the baseline is 0xa2000000 : three require-bits encoding UPN, email, and directory-path requirements. A dirty write of 1 wipes all three — the template stops building identities from AD, someone’s smartcard auth changes shape, and the blue team gets a ticket. The correct move is an OR: read the existing value, compute existing | 1 , write back the combined result. 0xa2000000 ➜ 0xa2000001 is a one-bit delta and a clean exploit. 0xa2000000 ➜ 0x00000001 is a demolition. In a CTF lab, none of this matters. In a real engagement, it’s the difference between a clean op and getting caught because someone’s smartcard stopped working. Read the baseline. OR into it. Context — what this post is. The attack-class background for why a writable certificate template is ESC4 (SpecterOps’ Certified Pre-Owned by Will Schroeder and Lee Christensen, 2021), and the case study of one require-bit being abused in production — CVE-2022-26923 / Certifried — are linked from the relevant sections below. This post focuses on the bitmask itself — the value of each bit, the behaviour it triggers on the CA — and then weaponises it live. The Canonical Sources To understand how this flag actually works, we have to look past the Windows GUI and read the documentation that dictates the protocol. There are three sources of truth, in order of authority: [MS-CRTD] (Certificate Templates Structure): The Open Spec that defines every certificate-template attribute. Section 2.4 of MS-CRTD defines the bitmask. This is the only spec that defines the values. [MS-WCCE] (Windows Client Certificate Enrollment Protocol): The on-wire protocol. Section 3.2.2.6.2.1.4.5.9 of MS-WCCE describes what the CA MUST or SHOULD do on the wire when a bit is set. Use this for the behavior of a bit. The Microsoft Learn AD-schema page: Documentation only. It confirms the attribute is a 4-byte, single-valued field on PKI-Certificate-Template requiring Domain Admin to update, but it does not enumerate the bits. The 13 Defined Bits The attribute is a 4-byte sparse bitmask. Thirteen bits are defined in MS-CRTD; the remaining 19 bits are unused (or reserved) — some third-party CA products encode vendor-specific signals in those bits, but they have no Microsoft-defined meaning. The bits fall into two distinct operational groups: Supply bits: Who picks the identity inside the certificate. Require bits: What identity format the CA will accept; the CA MUST read that field from the requester’s AD object and bake it into the cert. Bit Hex value Dec value Flag name Group Behaviour 0 0x00000001 1 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT supply Requester supplies the Subject DN in the CSR. Without this bit, the CA builds the Subject per the template’s own subject-name policy. 3 0x00000008 8 CT_FLAG_OLD_CERT_SUPPLIES_SUBJECT_AND_ALT_NAME supply Renewal-only. Instructs the client to reuse the subject name and SAN from an existing valid certificate when building a renewal CSR — i.e. the client copies them from the prior cert instead of asking the requester to re-supply them. 16 0x00010000 65 536 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME supply Requester supplies the SAN in the CSR. This is the bit that turns the cert into a forgeable identity token. 22 0x00400000 4 194 304 CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS require CA SHOULD retrieve the domain DNS information policy and use it to populate the SAN. (This is SHOULD , not MUST ). 2...