AD CS Workflows MetaModule

Active Directory Certificate Servies (AD CS) is Microsoft's system for managing Public Key Infrastructure (PKI) within Active Directory environments. The AD CS Workflows MetaModule enables you to assess the configuration of an AD CS deployment to identify and exploit common misconfigurations. It performs a multi-phase, configurable workflow that finds, exploits, uses, and reports on these misconfigurations. It can be used in a simulated breaching exercise to enable you to gain elevated privileges within the target environment. These privileges are accessible through the certificates it issues by leveraging the misconfigurations, which can then be used for authentication by standard modules.

To run the AD CS Workflows MetaModule, you must have the domain's Fully Qualified Domain Name (FQDN) (e.g. corp.target.lan) and a credential set. The credential set represents the attacker's access and does not need to be highly privileged. The exploitability of many of the misconfigurations that the AD CS MetaModule will search for depend on this account's privileges. It is recommended to use an account that has either been obtained as part of a penetration test or one with privileges obtainable by an inside threat. Running the MetaModule with different accounts with different privileges will likely yield different results.

Once started, the MetaModule will follow a five-step process.

1. The MetaModule will connect to a Domain Controller, validate its target information, and gather additional information necessary for later steps.
2. While still targeting the same Domain Controller, the MetaModule will find all AD CS certificate template objects and certificate authorities and analyze each one for exploitable misconfigurations.
3. For each misconfiguration found and enabled in the MetaModule's run configuration, the MetaModule will attempt to leverage the misconfiguration in an attack to issue a certificate with elevated privileges.
4. If a post-exploitation action was selected in the MetaModule's run configuration, the MetaModule will use each certificate it could issue in the previous step to perform the specified action.
5. The MetaModule will compile its findings into a report explaining what it found and how the misconfigurations can be remediated.

You can access the AD CS Workflows MetaModule from the MetaModules page. To access the MetaModules page, select Modules > MetaModules from the Project tab bar. Find the AD CS Workflows MetaModule and click the Launch button.

The AD CS Workflows MetaModule configuration window appears with the Scan Setting configuration form displayed. Each configuration step is divided into separate tabs, and you can click on any of the tabs to switch between the different configuration forms.

The first thing that needs to be configured is the target environment's information. Enter the target Active Directory Domain's FQDN (e.g. target.msf.local). This should be the domain's FQDN and not a specific server's. This domain name will be used to identify a Domain Controller by querying DNS. If Metasploit Pro's DNS server is not configured to the DNS server of the Active Directory domain, then a specific Domain Controller target can be specified by name or IP address by selecting the appropriate option next to Target Domain Controller.

By default, the MetaModule will find and target all available certificate authorities. However, you can specify a specific CA server by name by selecting "Target a specific certificate authority..." next to "Target Certificate Authority" and entering either the FQDN or CA name of the CA server.

The MetaModule must authenticate to the target Domain Controller to gather the necessary information and run the configured attacks. The account that is provided will be the perspective from which the analysis is performed to identify leverage misconfigurations. The misconfigurations that are present and can thus be attacked are dependent on the permissions to which this initial account has access. As such, running the MetaModule with different accounts that have different permissions will likely yield different results.

Either enter an explicit credential pair by setting the username and password yourself or select an existing pair from the project's storage. To perform a pass-the-hash attack, copy the NTLM hash into the "Password" field.

After the MetaModule has gathered the necessary information it needs and identified a set of misconfigurations, it will proceed to exploit each of the selected vulnerabilities. This page controls which vulnerabilities are to be exploited. By default, all vulnerabilities the MetaModule can exploit are enabled and will be attempted. The exploit process for each of the vulnerabilities is highly reliable and unlikely to affect the target adversely. However, each attempt will result in at least one certificate being issued, which will show up in the logs alongside any legitimate certificates. Turning off all misconfigurations will effectively cause the MetaModule to only search for misconfigurations. In this case, no post-exploitation action will occur because no exploit attempts will be made and no certificates will be issued.

For all misconfigurations except ESC13, a successful exploit attempt will result in a certificate being issued for the Domain Administrator account that was automatically identified in the first step of the workflow. In the case of ESC13, the permissions that are gained are dependent on the configuration of the certificate template. These may not be as highly privileged as those held by a traditional Domain Administrator account.

For each misconfiguration that is successfully exploited, a certificate will be issued to and stored by Metasploit Pro that facilitates authentication with additional privileges than those typically held by the configured user. An attacker typically uses this certificate to gain further access with their newly granted privileges. Metasploit Pro can be configured to take this step automatically by selecting one of the available post-exploitation actions. To skip the post-exploitation step, uncheck the box next to "Post-Exploitation" on the left side of the configuration window. If no post-exploitation action is taken, Metasploit Pro will not do anything with the certificates that have been issued. They will still be stored in the projects credentials data and be available for manual use in the future. Navigate to "Analysis > Credentials" to view these certificates.

Obtain a Kerberos Ticket Granting Ticket (TGT)

Metasploit Pro will use the issued certificate with PKINIT authentication to issue a Kerberos Ticket-Granting-Ticket. This ticket can then be used by various modules to authenticate to different services such as LDAP, SMB, MSSQL, etc. This does not establish a session or maintain a connection to the Domain Controller.

Select this option if you would like to authenticate to multiple services, including LDAP, SMB, MSSQL, and HTTP. Metasploit Pro will store the TGT and allow you to run modules as the elevated user.

Open an elevated LDAP session to the Domain Controller

Metasploit Pro will use the issued certificate with SCHANNEL authentication to establish an LDAP session with the Domain Controller. This session can be used by LDAP modules and by users to run LDAP queries in an elevated context.

Select this option if you only want to authenticate to LDAP and run queries as the elevated user.

Once completed, the MetaModule will generate a report detailing what was found and (depending on the configuration) able to be exploited. Individual sections can be omitted from the report by unchecking their respective names in the "Generate Report" tab of the configuration window. The entire report can be left out by unchecking the box next to "Generate Report" on the left side of the configuration window. By default, all sections will be added to the report, including various appendices which add informative context to the actions that were taken.

When you are ready to run the AD CS Workflows MetaModule, click the Launch button.

Once launched, the workflow run will begin gathering and logging information necessary to identify and exploit various misconfigurations. This view will show two tabs: "Statistics" and "Task Log."

Statistics

The statistics tab includes information about what was found in the target environment. It will start to be populated a few seconds after the MetaModule has begun. It consists of the following data points:

• Certificate authorities - This table includes each of the certificate authority servers identified in the target environment.
  • Certificate authority name - The internal name of the server as set within AD CS.
  • FQDN - The Fully Qualified Domain Name of the CA server which can be used to find it with DNS.
  • IP address - The IP address of the CA server that the MetaModule will use when connecting to it.
• Certificate templates - This table includes each certificate template that was analyzed for vulnerabilities.
  • Certificate template name—The name of the certificate template as used when issuing it. This value can differ from what is displayed in the AD CS UI provided by Microsoft.
  • Required signatures—The number of signatures the certificate template requires to be present in a request for it. Any non-zero value prevents the MetaModule from automatically issuing a certificate.
  • Requires certificate manager approval - This determines whether certificate requests using the template will be placed in a pending review state before being issued. When enabled, the MetaModule is unable to issue a certificate automatically.
  • Template schema version - The version of the certificate template object.
  • Misconfigurations - This lists any misconfigurations that were identified on the certificate template.
• Successful attempts - This table logs each successful exploit attempt, including what was targeted and what was obtained.
  • Technique - The name of the exploit technique for the misconfiguration that was leveraged.
  • Used in post-exploitation - What was able to be done with the issued certificate depending on the post-exploitation action that was configured.
  • Identity - The Active Directory user for whom the certificate was issued. This is always the name of the automatically targeted Domain Administrator, except in the case of ESC13, when it's the user configured in the MetaModule that ran the attack.
  • Subject - The subject field of the X.509 certificate issued as part of the attack.
• Failed attempts - This table logs each exploit attempt that failed, including what was targeted and why it didn't work.
  • Technique - The name of the exploit technique for the misconfiguration that was intended to be leveraged.
  • Reason - The short name of why the exploit failed.
  • Detail - Additional details about what went wrong.

Task Log

The console output from the MetaModule's running output can be viewed in the Task Log. This is useful for seeing what the MetaModule is currently doing and gathering information in case something went wrong. The top of this tab includes a status bar displaying the step on which the MetaModule run is on. The "Replay" button can be used to load the MetaModule's configuration window with the run's settings pre-loaded. This enables the user to adjust any settings as necessary to rerun the module.

What to do after running the MetaModule depends on the operator's intentions. If you want to discover and remediate vulnerabilities, the report would be your next stop. In the report, each exploit technique that was successful will have accompanying details about how to remediate it. After following the remediation steps, use the "Replay" button to rerun the module with the same configuration and verify that the vulnerabilities are no longer present and exploitable. If the remediation strategy was to remove permissions, it is possible the certificate template may still be identified as vulnerable but it should not be exploitable if the permissions where sufficiently restricted. Look for "no-access" failures in the Statistics tab.

If you are attempting to simulate an active attack, you will most likely want to take further action after the post-exploitation phase. What is possible will depend on the configuration selected.

Using An Open LDAP Session

An interactive LDAP session can be used in a similar manner to other session types. Navigate to "Sessions" and select the LDAP session you would like to interact with. The account the session is authenticated as will be noted in the "Description column." From this point, you can select "Command Shell" to interact directly with the session. Interacting with LDAP sessions is primarily helpful for running specific LDAP queries using the query command.

In addition to running custom queries, LDAP sessions can also be used to run LDAP modules. From the session's page, select "Post-Exploitation Modules." The auxiliary/gather/ldap_query ("LDAP Query and Enumeration Module") has various built-in queries that can be run. The auxiliary/admin/ldap/change_password module can be used to change the password of a target account, allowing you to log in to any service the account has permission to that accepts a password.

Using a Kerberos Ticket Granting Ticket

Kerberos Ticket Granting Tickets can be used to authenticate to various services. They are issued by the Key Distribution Center (KDC), which is the Domain Controller in an Active Directory environment. The TGT itself is stored on disk as captured data and, as such, can be viewed from the "Analysis > Captured Data" page. TGTs will be listed with a "mit.kerberos.ccache" type with additional information in the "Info" column. The "realm" will be the Active Directory domain, while the "client" will be the name of the user for which the TGT is for.

Modules that authenticate with SMB, LDAP, MSSQL, and HTTP can use Kerberos authentication. Using Kerberos authentication involves making multiple configuration changes. Module option names depend on what protocol is in use. Using the exploit/windows/smb/psexec ("Microsoft Windows Authenticated User Code Execution") as an example, the following settings would need to be configured:

• SMBDomain - This is the Active Directory domain's FQDN (e.g. corp.target.lan)
• SMBUser - This is the TGT's username (the "client" field from the Info) (e.g. "Administrator")
• The following options are available under the "Advanced" section:
  • DomainControllerRhost - This must be the IP address of the Domain Controller
  • SMB::Auth - This must be kerberos to use the TGT
  • SMB::Rhostname - This must be the target host's hostname

Leave any password-related options blank. They will not be used when Kerberos authentication is active. The "DomainControllerRhost" option's name does not change. However, the others will be prefixed with their respective protocols instead of SMB.

Attempt Failed With "no-access"

Most of the misconfigurations that are capable of being exploited by the MetaModule require some degree of permission. For a user to issue a certificate using a particular certificate template, that user will need both enrollment rights to the certificate template and enrollment rights to a certificate authority that will issue it. Unless both permissions are available, the issuance request will fail with an authorization error, which Metasploit will report as "no-access". Another user account may have the necessary permissions to issue the certificate template. In this case, inspecting the permissions on the certificate template and certificate authority is advisable.

The AD_DS_DOMAIN Option Failed To Validate

The AD_DS_DOMAIN is the "Active Directory Domain" value from the "Scan Settings" in the MetaModule's configuration window. This is a domain name that is used to find a Domain Controller to target. This must be a domain name, not a NETBIOS name, "e.g., corp.target.lan", not "CORP". If Metasploit Pro can not resolve this domain name, then a Domain Controller's IP address must be specified by checking "Target a specific Domain Controller by name or IP address" in the "Scan Settings" of the MetaModule's configuration window. The domain name resolution can be tested using a tool such as dig or nslookup.

Every Certificate Template Is Vulnerable To ESC4

ESC4 is a misconfiguration resulting from permissions to edit the certificate template object. Highly privileged users, such as Domain Administrators, typically have this permission by default. Every certificate template will be flagged as vulnerable to ESC4 when the MetaModule is run as a highly privileged account. Running the MetaModule with a highly privileged account such as a Domain Administrator is not advisable.