Secure Your Active Directory and Windows Domains

Take Advantage of Kerberos Delegation

Users can use services in Active Directory. Occasionally, a service relies on another service to run. For example, if the company’s intranet provides a way of accessing files stored on a network share, this may indicate that the intranet’s web service is accessing a network share to display it to the user.

However, the web service doesn’t know what permissions the user has on the network share. This is where the Kerberos delegation comes in.

The idea is to allow a service account to impersonate a user of another service.

This enables the intranet to impersonate the user and be authenticated on the file server as the user. From the file server’s perspective, the user submits the request, and then the file server verifies the user’s permissions and sends back the information accessible to the account. This is how the web server can then display this information in a user-friendly interface.

There are three types of delegation, and each one can be exploited by an attacker:

• Unconstrained delegation

• Constrained delegation

• Resource-based constrained delegation

This is the most dangerous form of unconstrained delegation for a company, and that’s why we’re going to focus on it.

With unconstrained delegation, the service is responsible for it, and as indicated by its name, the service account has no constraints. As soon as a user submits a service ticket, it can impersonate that user with any other resource.

For this to work, when a user accesses a service in unconstrained delegation, they send their service ticket, as well as a copy of their TGT. As you know, the TGT is the user’s passport. Therefore, the service is in possession of the user’s TGT and can request service tickets for any resource by impersonating the user.

This is useful for you because, if you compromise a service in unconstrained delegation, you can easily impersonate someone! You simply wait until a user accesses the compromised service, because that’s when they will provide you with their TGT.

For this attack, the Rubeus tool can be used on a Windows machine. Remember that the machine account runs many services. So, if you compromise a machine in unconstrained delegation, you simply wait for users to access the service and then extract their TGTs.

Rubeus.exe monitor

When you collect TGTs, you can use them in your session by using the ptt (pass-the-ticket) option in Rubeus.

Rubeus.exe ptt /ticket:doIFmjCCBZagAwIBBaEDAgEWoo[...]

With constrained delegation, the service is also responsible for it. When a service is configured for constrained delegation, it will also be able to impersonate a user to other resources, but only for a well-defined list of resources.

If you compromise a server in constrained delegation, you can impersonate users of the resources authorized for delegation. Although the scope of attack is smaller, it’s still a possibility.

Finally, in resource-based constrained delegation (RBCD), the responsibility for delegation is removed. In unconstrained and constrained delegation, delegation is configured at the delegating service level. With RBCD however, it’s at the resource level that we indicate the list of services that can communicate with them through delegation.

For this to happen, a list of services authorized for delegation is specified at the resource level. Therefore, if you have permission to edit this list as an attacker, you’ll be able to add new services to it. 

For example, if you’ve compromised a service account with Kerberoasting or if you’re a workstation administrator, you can add them to the resource’s trusted list and then impersonate users of that resource.

To identify machines that are configured for Kerberos delegation, you can use findDelegation.py from the Impacket collection.

findDelegation.py medic.ex/pixis:P4ssw0rd

Retrieve Login Credentials From a Compromised Workstation

In this video, you learned that it’s possible to extract login credentials from the LSASSprocess to potentially find privileged domain accounts. One tool you can use for this is the lsassy tool, which automates this task on multiple remote workstations.

The search doesn’t have to stop there. There are many other places where login credentials are stored to make things easier for users.

DPAPI (Data Protection API) is a Windows feature that allows encrypted sensitive information to be stored on a computer. This feature is used by several Windows components and programs. These include scheduled tasks, Wi-Fi network passwords, and Chrome passwords. If Windows can use them to automatically connect to a Wi-Fi network, for example, that means the keys are available for you to extract.

DonPAPI was created for this exact reason. It is designed to extract DPAPI secrets (and much more) from a collection of remote machines. You must be the local administrator of the target workstations.

DonPAPI.py medic.ex/pixis:P4ssw0rd@10.10.10.2

The registry is another location where passwords are stored. This database contains configuration data for the operating system and any other installed software that wants to use it. In the SAM hive, you’ll find the login credentials for local accounts. This is where you can extract the NT hash of the machine’s local administrator. There are also LSA secrets in the SECURITY hive. These secrets are account passwords that can be used, for example, to run services.

The secrets can be extracted using secretsdump.py, which is also from the Impacket collection.

secretsdump.py medic.ex/pixis:P4ssw0rd@10.10.10.2

If you have compromised a domain controller, this tool will also extract all of the secrets from every user and workstation in the domain. It uses the DRS (Directory Replication Service) protocol to impersonate a domain controller and request full replication from the target. This technique is known as DCSync.

Finally, since many programs store configurations details in the registry database, there is a strong possibility that the registry also contains user passwords.

Exploit GPOs to Compromise New Accounts

The asset management role is one of the various Active Directory roles. Active Directory allows you to manage all the machines and users on your information system, and Group Policy Objects (GPOs) are an invaluable tool for doing this.

In practical terms, GPOs are a set of rules/actions that apply to a well-defined collection of computers and users. A GPO can be used for many things, such as for changing the screensaver, setting up Wi-Fi networks, configuring the firewall, changing local administrators, running scripts when the workstation starts, and more.

You understand perfectly well that if you have permission to edit a GPO, you’ll be able to do a lot of things to the objects it applies to. BloodHound allows you to determine which users or groups have permission to edit a GPO. If you’re one of them, the best approach is to use your Windows Server virtual machine to edit the GPO.

There are many ways to compromise users or machines that GPOs are applied to, but one easy method is to add a local administrator. To do this, edit the GPO you have the permission to edit. Go to Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, and update the Administrators group by adding a new member that you control.

You should also be aware that sometimes sensitive information is stored in GPOs (e.g., local administrator passwords) or dangerous parameters are placed. Group3r was created to analyze the contents of all GPOs to extract potentially useful information for an attacker.

Group3r.exe -s -f group3r_output.log

Exploit a PKI (Public Key Infrastructure)

A public key management infrastructure allows you to manage all the public keys of users. In an Active Directory, this enables certificates to be provided to users for various purposes. It can be used for 802.1X authentication, VPN access, stream ciphers, signing PowerShell scripts, and enforcing authentication.

When a user requests a certificate from a certification authority, they are actually requesting a certificate signature by specifying the certificate template and the information needed to populate the template. Active Directory provides preregistered templates, so you don’t have to reinvent the wheel. It is also possible to add new templates for any type of application. With the information provided, the certification authority will then check if the user has permission to request this type of certificate, and if they do, it will send the signed certificate back to the client.

The problem is that there are often configuration errors in these certificate templates. If a user has permission to edit a template or if the template is too permissive and allows a user to change more information than intended, this can lead to a vulnerability. It could even compromise the domain.

For example, a user authentication certificate template may allow you to specify the name associated with the certificate. This means that you can request the certificate and specify that it is to be signed by an administrator. You can use this signed certificate to authenticate yourself as an administrator.

Another vulnerability is that, if you have permission to edit a certificate template, you can configure it as explained above and request it with a random user’s login name.

Certify was created to enumerate potential vulnerabilities in the implementation of an Active Directory PKI. It was written in C# and must therefore be run from an authenticated Windows session.

certify.exe find /vulnerable /ca:dc01.medic.ex /domain:medic.ex

If you’d like to find out more, there’s a 143-page paper called Certified Pre-Owned - Abusing Active Directory Certificate Services that focuses on this type of vulnerability.

There are many different forms of attacks. Some are more memorable than others. What if we asked Lionel which attack path is the most memorable?

Let’s Recap!

• When a machine is set up with unconstrained delegation, you can extract copies of users’ TGTs to impersonate them.

• Windows lets you store passwords in various locations, and knowing how to find or extract them will allow you to compromise privileged accounts.

• If you can edit a GPO, you’ll be able to take control of the computers or users it applies to.

• When a PKI is installed in an Active Directory, there’s a good chance that a certificate template is not correctly configured, allowing you to elevate your privileges.

When an attacker compromises machines—or even a domain—they move to the persistence phase to ensure that hard-earned access is not lost. A good understanding of persistence techniques will also help you to ensure that there are no persistence issues in your environment.