[Bug]: ADCS ESC1/ESC2 detectors emit edges for disabled and unpublished certificate templates → false-positive T0 attack paths

[FLX-0x00]

ADscan version

ADscan launcher: v11.2.0, adscan/adscan-lite:latest

Host OS

Arch linux-lts

Docker version

Docker version 29.7.2, build a7dcaa6fdb

Command and sanitized output

start_auth

Expected behavior

Summary

adscan reports attack paths of the form Authenticated Users@WELLKNOWN → ADCSESC1 → Domain Admins → ... → DCSync (Direct, T0/Domain Breaker) that are not exploitable. Tracing the edge back through the inventory data and the detector source shows that the ESC1 (and ESC2) edges are emitted against certificate templates that are not enabled and - in the worst case - not published on any CA. Enrollment against such templates is rejected server-side, so the entire attack path is a false positive.

Environment

• adscan 11.2.0 (adscan-lite container)
• Single-forest AD lab, one enterprise CA (IssuingCA), 51 templates, 15 enabled
• Cross-checked with certipy find -enabled -json (v5.1.0)

Evidence

1. The reported edge targets a disabled, unpublished template

The flagged template in inventory/adcs_attack_steps.json (sanitized):

{
 "relation": "ADCSESC1",
 "source_object_id": "S-1-5-11",
 "source_name": "Authenticated Users@WELLKNOWN",
 "target_kind": "CertTemplate",
 "target_name": "LEGACYAPP@CORP.LOCAL"
}

The same template in inventory/adcs_templates.json:

"enabled": null,
"properties": {
  "mspki_certificate_name_flag": 1,
  "mspki_enrollment_flag": 8,
  "mspki_ra_signature": 0,
  "pki_extended_key_usage": ["1.3.6.1.5.5.7.3.2"]
}

Note "enabled": null - the collector does not record publish/enabled state at all.

2. Ground truth from Certipy

Template Name   : LegacyApp
Enabled         : False
Certificate Authorities : []          <-- published on NO CA
Enrollee Supplies Subject : True
Client Authentication     : True
Requires Manager Approval : False
Enrollment Rights         : ... Domain Admins, Authenticated Users

Enrollment attempts against it fail (template not published on the enterprise CA), so no certificate can ever be minted → no PKINIT → no DA.

3. Code tracing

Collector (adscan_internal/services/collector/adcs_collector.py / adcs_templates.json output): template objects are created without evaluating the template↔CA publication relationship; enabled is left null.

Detector (adscan_internal/services/collector/adcs_detectors/esc1.py, detect_esc1()):

def detect_esc1(*, template_node, template_acl_edges, domain) -> list[CollectorEdge]:
    if template_node.kind != "CertTemplate":
        return []

    name_flag = template_int_property(template_node, "mspki_certificate_name_flag", ...)
    if not (name_flag & ENROLLEE_SUPPLIES_SUBJECT):
        return []

    enrollment_flag = template_int_property(template_node, "mspki_enrollment_flag", ...)
    if enrollment_flag & PEND_ALL_REQUESTS:
        return []
    ...
    return [make_adcs_edge(principal_sid=sid, template_node=template_node, esc="1")
            for sid in get_enroll_principal_sids(template_acl_edges)]

There is no check for:

1. enabled / CA publication state of the template, or
2. whether the CA referenced by the template exists/is reachable.

The same applies to esc2.py (identical shape, also flagged the disabled template for Authenticated Users).

Consequence in the attack graph: Authenticated Users@WELLKNOWN (SID S-1-5-11) gains an ADCSESC1 transition against a T0 template, the path engine then expands it to → Domain Admins → Administrators → DCSync and surfaces it as a ready-to-execute T0/Domain-Breaker path with "Execution Readiness: 1 ready".

Expected behavior

ESC detectors (esc1.py … at minimum the enrollment-based family: ESC1/ESC2/ESC4/ESC5) should be gated on template publication state:

• Skip templates with no entry in the CA↔template publish relationship (Certificate Authorities: None), or
• emit the edge but mark it as disabled / not_published so the attack-path engine (and the "Execute this attack path now?" prompt) filters it out.

At minimum the collector should persist the enabled/published flag instead of null.

Impact

False-positive T0 paths directly erode trust in the "Ready" attack-path ranking and the interactive execution prompt - the highest-severity finding in this particular engagement was unexploitable on manual verification, while the genuinely real ADCS issue (ESC8 web enrollment over HTTP) ranked lower.

Workaround (pentester-side)

Cross-check every ADCSESC* finding against certipy find -enabled -json before executing, and discard edges whose target template shows Enabled: false or an empty Certificate Authorities list.

Lab or environment context

No response

[ADScanPro]

Hi Paul,

This is a genuinely useful report. Cross-checking the emitted edge against certipy find -enabled -json, following it back through adcs_templates.json, and pinning it to detect_esc1()/detect_esc2() did most of our triage for us.

It's fixed in 11.3.0, which we're cutting this week. Your diagnosis was right: the collector wasn't evaluating the template↔CA publication relationship, so an unpublished template flowed straight into the issuance detectors with enabled: null.

The fix gates the issuance ESC family on real CA publication, keyed on the same signal your is_enabled cross-check used:

• The collector computes, per template, whether its cn appears in any Enterprise CA's certificateTemplates list (_template_is_published in adcs_collector.py) and passes that as a published flag into the detectors.
• When a template is published on no CA, the issuance-bound detectors (ESC1, ESC2, ESC3, ESC6, ESC9, ESC10, ESC13, ESC14, ESC15) are skipped, so no edge is emitted. That template can't be requested from any CA (the request fails with CERTSRV_E_UNSUPPORTED_CERT_TYPE), so the edge you hit was a false positive under our exposure-validation rule: a "Ready" path has to be one ADscan can actually walk end to end.
• ESC4 is intentionally excluded from the gate. It's a write-ACL weakness on the template object, so a principal who can rewrite an unpublished template into an ESC1 config and then publish it is a real finding regardless of current publication state. Certipy takes the same position.

We also tightened a related ADCS false positive in the same release: ESC13 now fires only when a template's issuance-policy OID resolves to a group link (msDS-OIDToGroupLink), so a domain without that link no longer produces a phantom ESC13.

Your point underneath the bug is the one that made this worth prioritizing: a false-positive T0 path erodes trust in the "Ready" ranking, and here it outranked your genuinely exploitable ESC8. That inversion is exactly what the tool exists to prevent, so a template no CA issues shouldn't be sitting at the top of that list.

One caveat so you can verify precisely. The gate keys on CA publication (CN present in a CA's certificateTemplates), which is what made your LegacyApp template unexploitable: Certificate Authorities: []. If you have a template that is published by a CA but disabled through some other mechanism, send it over with the same detail and we'll treat it as a separate case.

We'll leave this open until 11.3.0 ships so you can confirm it clears in your lab before we close it. Point ADscan at the same environment on 11.3.0: if the Authenticated Users → ADCSESC1 → LegacyApp path is gone and your real ESC8 finding stays, that's the confirmation we're after.

Thanks again.

[ADScanPro]

11.3.0 is out: https://github.com/ADScanPro/adscan/releases/tag/v11.3.0

The publication gate described above ships in it, so the Authenticated Users → ADCSESC1 → LegacyApp path should be gone while your real ESC8 finding stays. If you get a chance to point ADscan at the same environment, let us know how it looks and we'll close this out. And if you hit the published-but-disabled edge case, send it over and we'll take it as its own issue.