adcs_enum lists Domain Users group as having WriteProperty when they don't have that access

[SoloDefend]

Tested this on multiple clients side by side with Certify and came up with conflicting results.

In multiple cases, adcs_enum lists the Domain Users group as having WriteProperty rights. A secondary check with Certify of the same template shows that is not the case (see below, a lot of data was redacted for obvious reasons). Additionally, we manually checked the ACLs on the templates with the clients and did not see WriteProperty being assigned to Domain Users.

// adcs_enum output
Template Name : User
Friendly Name : User

Extended Key Usage : Encrypting File System, Secure Email, Client Authentication
Permissions :
Owner : TEST\Enterprise Admins

Access Rights :
Principal : TEST\Domain Admins
Access mask : 00000100
Flags : 00000001
Enrollment Rights

Principal : TEST\Enterprise Admins
Access mask : 00000100
Flags : 00000001
Enrollment Rights

Principal : TEST\Domain Admins
Access mask : 00000130
Flags : 00000001
Enrollment Rights
WriteProperty Rights

Principal : TEST\Domain Users
Access mask : 00000130
Flags : 00000001
Enrollment Rights
WriteProperty Rights


// certify output
[*] Available Certificates Templates :
    CA Name                         : ADCS.TEST.local\TestRootCA
    Template Name                   : User
    pkiextendedkeyusage             : Client Authentication, Encrypting File System, Secure Email
    Permissions
      Enrollment Permissions
        Enrollment Rights           : TEST\Domain Admins       
                                      TEST\Domain Users        
                                      TEST\Enterprise Admins   
      Object Control Permissions
        Owner                       : TEST\Enterprise Admins   
        WriteOwner Principals       : TEST\Domain Admins       
                                      TEST\Enterprise Admins   
        WriteDacl Principals        : TEST\Domain Admins       
                                      TEST\Enterprise Admins   
        WriteProperty Principals    : TEST\Domain Admins       
                                      TEST\Enterprise Admins   

[freefirex]

Thank you for this report, we'll look into it.

One item to check, and we potentially are misdirecting here. See if domain users have generic write. currently our code is checking for either generic write or write property and printing them both as write property. Checking the certify code it doesn't do any check for generic write, but it may be that generic write doesn't allow effective exploitation, we didn't test that case at this point.

It will likely take us about 2 weeks, currently our research team is tasked up with other items

[SoloDefend]

Thanks for the quick response. I'll have to do some testing in my AD lab and see if GenericWrite allows you to modify the cert template properties.

[freefirex]

After looking into this more, yes this is for sure an issue.

I've spent a few hours working this now and I'm not able to replicate the results Certify presents, even when I copy there comparison logic. I don't know if we're pulling something wrong further up, or why our results has the bit set for write access when the user clearly is unable to overwrite various properties.

I'll pop back to this when I can, but for now this may be a standing issues unless someone else can figure out what we're doing wrong compared to certify.

[Xenov-X]

I think this is due to the GUID within the NTSecurityDescriptor not being evaluated correctly. [but this may be a separate issue]

Take the two following template ntsecuritydescriptors as a PoC:

(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU) (OA;;RPWPCR;;;DU)

Both will be evaluated as Domain Users having WriteProperty access, as the WP ace string is configured. However, the GUID of the former limits this to just the enrolment extended right.

      Principal           : DOMAIN\Domain Users
          Access mask       : 00000130
          Flags             : 00000001
                              Enrollment Rights
                              WriteProperty Rights

A simple middle ground fix to avoid having to be able to parse all of the possible GUIDs may be to print the GUID in the output next to the rights?

E.g. the above two GUIDs would result in the following differentiated output:

      Principal           : DOMAIN\Domain Users
          Access mask       : 00000130
          Flags             : 00000001
                              Enrollment Rights
                              WriteProperty Rights - 0e10c968-78fb-11d2-90d4-00c04f79dc55

      Principal           : DOMAIN\Domain Users
          Access mask       : 00000130
          Flags             : 00000001
                              Enrollment Rights
                              WriteProperty Rights