I recently started the Attacking and Defending Active Directory course from Pentester Academy, and just finished up the last of the hands-on objectives. The material for the course is great for anyone looking to improve their skills for enumerating and abusing Active Directory on internal penetration tests or red team engagements. The course is designed for beginners and assumes students have zero knowledge going in, so the videos/lessons are thorough and detailed. I would recommend it to anyone who can afford it (or convince their employer to pay for it).
After completing the lessons, I wanted to created my own lab environment for testing against Active Directory (AD) and using some of the new C2 frameworks that have been released. @xorrior recently announced that Powershell Empire will no longer be maintained. I had used Empire extensively in previous engagements and testing. Fortunately, several new C2 frameworks have been released, such as Covenant, Faction, and Sliver. The update to Covenant looked great and I really wanted to give it a try, I just needed a lab environment to use it in…
Please note: The configuration used for the AD environment in this post is meant to allow for specific tests to be performed. It is NOT meant to be a recommendation on how to configure a real world, production AD environment. If you follow this guide in a real environment, you would be configuring a purposely vulnerable domain which is no good!
Choosing AWS
All of my personal “labs” I’ve created before were nothing more than a single Windows 7/10 VM that communicated with my host Windows box. After going through “Attacking and Defending Active Directory”, and Rastalabs on HackTheBox before that, I wanted to create a full AD environment to test in.
Initially, I was going to create the VMs on my desktop as I had done before. My desktop is pretty beefy, but I’m not sure how well it would handle multiple server and workstation VMs running at once, and then there is the issue of licenses for Windows Server and Windows 10… (cough)
So, I looked into “the cloud” to host my lab in. I have essentially zero experience using cloud providers beyond spinning up a Digital Ocean Droplet to use as a proxy. I hadn’t used AWS or Azure, and I think Google has a cloud service but I’m not 100% sure it exists.
After some quick looks at pricing, it seemed like AWS would be the cheapest and simplest option to host a Windows environment, though I am not confident in my ability to decipher the pricing between AWS and Azure. Oh well, AWS is what I went with.
UPDATE: I have been billed for my first month. After rebuilding my AD environment three times, and creating various additional servers for C2 and redirectors and other tests, my bill for a full month of usage was $13.71. To try and keep costs down I would stop my AWS instances when they weren’t in use. The one exception for this was I left the domain controller instance running for the whole month as I wasn’t sure what issues that may cause in the domain. It should be quite a bit cheaper if I only had the DC instance running on active days.
The bulk of the costs ($12.64 out of the $13.71) was for provisioning 126 GB of data during the month. I assume this will be much cheaper on months when I’m not constantly building and rebuilding instances.
Getting Started in AWS
Everything from here on out will be heavily based on posts from Jared Haight and SethSec on creating AD labs. You would probably be better off following their instructions than my own. Their posts can be found here:
https://sethsec.blogspot.com/2017/05/pentest-home-lab-0x1-building-your-ad.html
https://www.c2.lol/setting-up-an-active-directory-lab/part-1
To start, create an AWS account at https://aws.amazon.com/. This appears to be separate from a regular Amazon account. This caused some issues with my LastPass, since it overwrote my “amazon.com” password with the account password I created for aws. I had to create a separate entry in LastPass manually for the AWS password. Unfortunately, autofill keeps putting in my regular Amazon.com password into the aws.amazon.com login, so I have to copy it myself from my LastPass vault. Oh well, there are worse problems to have in life. I digress…
I setup my AWS account to use the “free tier.” As far as I am aware, this means that I won’t pay a monthly subscription, and that I will be very limited in the types of instances I can create for my VMs. This doesn’t mean it’s completely free, I will still need to pay for usage.
Once you are logged into AWS, you can start to create an instance by clicking on “Services” up at the top, and then “EC2” unter “Compute.”
Then, click on “Launch Instance.”
You will then be presented with a list of all the different types of instances you can create in EC2. I decided to have all my instances running Windows Server 2016. AWS does not provide any workstation Windows 7/10 instances, but running a bunch of Server 2016 instances should work fine for the purposes of this lab. I’ll just call some servers “workstations” and disable some of the web restrictions that are enabled on Server OSes (covered later).
The specific server instance I’ve used throughout my lab is “Microsoft Windows Server 2016 Base.”
AWS offers a Server 2019 instance, but Server 2019 appears to still be in “preview” from Microsoft and there haven’t been any updates since the fall of 2018. The 2016 base instance is running a version from 2017 and will need to be updated. AWS also offers a “Windows Server 2016 1903 Base”, which has been updated much more recently, but when I created instances of the 1903 base I was unable to boot to the desktop and explorer.exe and other executables were missing from the system. So, i went with the 2016 base and decided to update it (you may have to download and install the Windows updates manually instead of through the normal Windows Update functionality. I was having issues in my lab doing updates “normally” for some reason).
Click on “Select”, and then keep hitting next until you get to “Step 6: Configure Security Group.” Security Groups in AWS are similar to firewall rules you can apply to your instances. I’m sure there is a lot you can do with them in AWS that I am unaware of, but now you can add a rule to only allow RDP traffic to your instance from your IP address (or whatever IP or range you choose). You can select “My IP” from the drop down menu under “Source” to automatically fill in your IP address.
Click on “review and launch” and then “launch.” You will then be prompted to use a key pair to encrypt the password you will later use to log into the instance. If you haven’t created an instance before, you can create one. Save the generated .pem file. It will be used later. Once that is complete, you should see a button for “view instances.” Click this, and you’ll see your instance being initialized.
The name starts out blank, so I would recommend renaming it to help yourself keep track of what instance is what. This first system is going to be a domain controller, so I named mine “dc01.”
RDP will be used to connect to the system. To gain access, AWS will provide you an RDP file and a password. To get the RDP file and password, check the box next to the instance, and then click “Connect.”
Here you can download the RDP file if you want, or use the public IP address listed in the “description” of the instance. More importantly, this is where you will get the password for the Administrator account for the instance. Click on “Get Password”, select the .pem file you created before, and then decrypt the password.
This will provide you the plaintext password for the local Administrator account. Save this somewhere like a password manager.
Security Group Config for Domain
As more instances are added to the environment, they will need to be able to communicate to one another over the network. To facilitate this, a security group will need to be created in AWS. On the sidebar, you should see “Security Groups” listed under “Network & Security.” Once you click on that, click on “Create Security Group.”
You can now configure inbound and outbound rules to allow for the systems to communicate with other systems on the Domain. The instances you create will all be somewhere on the 172.31.16.0/20 subnet. To allow for communication between the instances, I created inbound and outbound rules so that All traffic on All protocols on All ports is allowed to the 172.31.16.0/20 subnet. I also included outbound rules to allow for HTTP, HTTPS, and DNS to any location.
Now click on “Instances” under “INSTANCES” on the sidebar and select your new instance. Click on “Actions” to open a drop down menu. Under “Networking”, you should see the option for “Change Security Groups.”
In the “Change Security Groups” menu, check the box next to the group that you just created, and make sure that the original group that allowed for RDP from your IP address is still checked as well. Then, click on “Assign Security Groups.”
This security group will need to be added to every new instance created that you want to be part of the domain.
Configure the Domain Controller
You should now be able to connect to your instance over RDP using the Administrator credentials provided by AWS. You should be aware that since this is using a fairly weak VM with only 1 gb of memory (as far as I can tell there is only one option if you are using AWS’s free tier), the instance will be slow to respond at times. Patience will be required. So far in my testing, everything still “works” on these weak VMs, but sometimes things get a little “stuck.” Oh well…
This first instance will be configured to be the Domain Controller (DC) in the AD environment. For now, I am only configuring one forest with one domain, so this will be the only DC running. My plan is to eventually have at least one child domain and an external forest, which would require more DCs, but for now, let’s configure just the one.
To start, configure the server to have a static IP address. As far as I can tell, AWS will not change the private IP you are provided, but to promote the system to a DC you need to configure the static IP on the system itself. Right click on the little computer screen with an Ethernet cable symbol (I think that’s what it is…) and select “Open Network and Sharing Center.”
Click on the link for “Ethernet” to configure the network interface.
Select “Internet Protocol Version 4 (TCP/IPv4)” and click on “Properties.”
Check the radio button for “Use the following IP address:.” You will then need to enter in the IP, subnet mask, and default gateway that were set by AWS. You can find this information with the “ipconfig” command in a command prompt. You will also need to provide a DNS server. This isn’t really important, because later the DC will be configured to act as a DNS server for the environment. For now, I put in Google’s 8.8.8.8 DNS servers. Click “OK” and then “close” for the rest of the windows and everything should be set.
Next, you want to change the name of the system. This isn’t required, but will make your life easier if systems are named for their function. I changed mine to “dc01” (very creative). To do this, click on the start menu and type in “This PC.” When this appears in the search results, right click and click “Properties.”
This will bring up a bunch of information about the system. Under “Computer name, domain, and workgroup settings”, click on “Change settings.”
This will bring up the “System Properties” window. Click on the “Change…” button.
Then, enter in the name you want for the DC. The “Member of” section can be left unchanged for now. When the system is “promoted” to a DC later, it will be made a member of the domain you specify.
With all this in place, the next steps are to actually configure the system as a DC. Open the start menu and select “Server Manager.”
In the top right, click “Manage” and then “Add Roles and Features.”
Click on “Next” until you get to the “Server Roles” section. Here, you will want to check the boxes for “Active Directory Domain Services” and “DNS Server” at a minimum. You can also include other features if you want, such as Windows Update (WSUS).
Click through “Next” until you get to the installation. The features you selected will now be installed. This can take a few minutes. When I included WSUS it took ~10 minutes for everything to install. Without WSUS it was only about one minute.
After the installation, you should see a little yellow warning sign next to the flag symbol in the upper right. If you click on the flag, you’ll see you now have the option to promote this system to a DC.
This will open the DC deployment configuration. Select “Add a new forest”, and then enter the root domain name, which should look something like “domain.com.”
After this, click on next until the end. Once everything is completed, you will be prompted to reboot the system. Once the system reboots, your AD forest/domain will be created.
Populating the Domain: Organizational Units
After the domain has been created, you can start to populate the domain with objects. “Objects” are things such as users, groups, computers, group policies, ACLs, etc. These objects can be organized into “Organizational Units” (OU) to make management easier and quicker. As an example, if you wanted to have all user workstations have a “Workstation Admins” group added to their local Administrators group, you could quickly do this by applying a group policy to the “Workstations” OU. We are going to create some simple OUs to help manage this AD environment.
In Server Manager, click on “Tools” in the top right and select “Active Directory Administrative Center.”
On the left hand side you should see a something that says “Active Directory…” Under that you should see to symbols that look like bulleted lists. If you click the one on the right, you’ll switch to the “Tree View”, which is what I prefer and you will see in my screenshots.
In the Tree View, you can click on the name of your domain to expand it. It will then show you all the “Containers” that come by default when a domain is created. This will include things like Computers, Users, and Domain Controllers. To keep things organized, we are going to create a new OU for the lab that will contain the user’s and computers that will be added.
Right click on the name of the domain you created and select “New -> Organizational Unit.”
Fill in the name of the OU. This will be used to store all objects in the lab AD, so I named mine “ad-lab.”
You should now see “ad-lab” (or whatever you named the OU) listed under your domain in the Tree View. Next, you can create three new OUs under the “ad-lab” OU called “Users”, “Workstations”, and “Servers.” Follow the same procedure as above to do this. Right click on “ad-lab”, then select “New -> Organizational Unit”, and fill in the names for each. When you are done, it will look like this:
With the OUs created, you can now start populating them with users and computers and applying group policy to them.
Populating the Domain: Users
With the OUs created, users can be added to the domain. This follows a similar process to creating a new OU. Right click on the “Users” OU that is under “ad-lab” in the tree view, then select “New -> User.”
The first user we’ll create will be a member of the Domain Admins group. A Domain Admin (DA) is a privileged user in a domain that can simplistically be thought of as an administrator to all things within the domain. In a typical environment, the DA has administrative privileges on all systems within the domain and has privileges to modify all objects, such as groups or access control lists, that are managed through Active Directory. It is a powerful user, and as such it is often the target for attackers and penetration testers as they escalate their privileges within an environment.
In the “Create User” window, enter in the “Full name” and “User UPN Logon” fields. This will automatically fill in the “User SamAccountName” field for you. Provide the user a password. To make it easier to use the users in this lab, under “Password Options” check the radio button for “Other password options” and “Password never expires.” (Note: this is not best practice for a real production environment.)
Now, the user will need to be added to the “Domain Admins” group to provide them DA privileges. Click “Member Of” on the sidebar. Then, click on “Add…” on the right hand side. This will allow you to select the group you want to add the user to. Type in “Domain Admins” and click “Check Names.” Finally, click “OK.”
Click “OK” on the “Create User” window and the domain admin user will be created.
Next, you can create a bunch of different users to add to the domain. For my environment, I created:
- 2 “regular” unprivileged users
- A server admin
- A workstation admin
- A service account
When you create these users, instead of adding them to the “Domain Admins” group, add them to the “Domain Users” group. When these users are first created, they will not have elevated privileges in the domain. They will all be “regular” users. Later, we will add them to groups, and provide those groups special privileges. After creating all my users, my “users” OU looked like this:
Populating the Domain: Groups
With the users created, you can now create custom groups and add users to them. Groups help manage privileges and access for users within a domain. For instance, if a bunch of users in your environment have to administer MSSQL servers, you can create a group called “MSSQL-server-admins”, add those users to the group, and then add that group to the local Administrators group on all MSSQL servers.
To start, we will create a “ServerAdmins” group for the serveradmin user. Right click on the “users” OU under “ad-lab”, then select “New -> Group.”
Enter the name for the group, which i made “ServerAdmins.” Set the “Group scope:” to “Global.”
You can add users to the group by clicking on “Members”, and then on “Add.” Type in the name of your server admin user and click “Check Names”, and then click “OK.” you should now see your server admin user added as a member of the group.
Click “OK” on the “Create Group” member and the ServerAdmins group will be created with the serveradmin user as its sole member.
For my environment, I also created a “WorkstationAdmins” group and added the workstation admin user. This can be done by following the same procedure for creating the ServerAdmins group.
Populating the Domain: Computers
Now, you can begin adding computers to the AD environment. To do this, you first need to have actual computers to add. In the AWS console, you can add new instances that same as you did for the initial system that is now the DC, or you can use the “Launch More Like This” feature of AWS. “Launch More Like This” will create a new instance that has the same AWS configuration as an already existing instance. It will not be a clone of the VM running on the instance. It will be a fresh from scratch VM, but importantly it will already be added to things such as the AWS security groups that you created to allow for the lab systems to communicate with each other. Basically, this quickly creates a new instance using the same OS and security groups as our DC.
Check the box next to your DC instance, click on “Actions”, and in the drop down menu select “Launch More Like This.”
This will immediately spin up a new instance running Windows Server 2016 and belonging to the correct AWS security groups. It will also have the same name as your DC, so make sure to rename it to something else to avoid confusion. The process to gain access to the system is the same as the DC. Use your .pem file to decrypt the Administrator’s password and connect to the system over RDP.
Once you have access to the system, you will need to configure it to be able to be added to the domain. First, modify the primary DNS of the system to be the private IP address of your DC. You can find the DC’s primary IP address in the “Description” of the DC instance of AWS.
Next, change the name of the system. This time, when you change the name of the system, select “Domain” instead of “Workgroup”, and enter the name you gave your domain/forest.
Now, when you click “OK”, you will be prompted for credentials of a domain user. This is required to join your new system to the domain. You can use the credentials of any user, including the unprivileged users.
If you enter in the user’s credentials correctly, you will be joined to the domain.
The system will require a restart. Once it is rebooted, you will need in the computer system properties that it has been added to your domain.
After adding the first computer to the domain, I added two more. The three systems I added were wkst01, srv01, and srv02. These will act as the servers and workstations within my environment.
When a computer is added to the domain, it is put into the “Computers” container by default. Open up the RDP window to your DC and open up the “Active Directory Administrative Center” again. Select the “Computers” contained under your domain, and you should see all the new systems that you have added to your domain.
Earlier we created OUs for “servers” and “workstations.” These new systems can be “moved” out of the Computers container and into the OUs to facilitate management through Active Directory. Right click on one of the systems and select “Move…”
In the “Move” window, select the “ad-lab” OU under your domain, and then either “servers” or “workstations” depending on the system you select.
Repeat this process for the remain systems in the Computers container to move them to their corresponding OU.
Group Policy: Restricted Groups
With the OUs, users, and groups created, you can now use group policy to effect change within the AD environment.
To demonstrate this, a “Restricted Groups” policy will be used to make the “ServerAdmins” domain group a member of the local Administrators group on all objects in the “Servers” OU.
Go back to “Server Manager”, click on Tools in the top right, and select “Group Policy Management.
In the Group Policy Management window, you will see a tree view of your domain on the left hand sidebar. Expand your domain, then expand the “ad-lab” OU, and then right click on the “servers” OU. Click on “Create a GPO in this domain, and Link it here…”
Provide a name for the new GPO such as “server-admins” and click “OK.” This will open the “Group Policy Management Editor” window. The group policy we want to apply is “Restricted Groups.” This can be found by expanding “Policies” under “Computer Configuration”, then expanding “Windows Settings”, and then finally expanding “Security Settings.”
Right click on “Restricted Groups” and then select “Add Group…”
This opens the “Add Group” window. Click on “Browse” to open the “Select Groups” window, type in “ServerAdmins” and click “Check Names.”
After you click “OK”, you will see something similar to “Server;DOMAIN\GroupName” in the Add Group window.
When you click “OK”, you will then be prompted to configure the membership for the ServerAdmins group. There will be two options, “Members of this group” and “This group is a member of.” To add the ServerAdmins domain group to the local Administrators group, you want to click “Add…” next to “This group is a member of” on the bottom half of the prompt. Search for the “Administrators” group, and then click “OK.”
When you click on “Apply” and “OK”, you should see that the ServerAdmins group has been added to the Restricted Groups.
You can repeat this process to add the “WorkstationAdmins” domain group to local Administrators group to all systems in the “Workstations” OU through Restricted Groups group policy.
When the group policy is pushed out to the affected systems, they should add the “ServerAdmins” group to their local administrator group. For whatever reason, when I ran “gpupdate” on one of my servers, the ServerAdmins group wasn’t showing up in the local Administrators group. I then restarted the system, and when it booted back up the group policy had been applied and I saw ServerAdmins in the local Administrators group.
Populating the Domain: Service Account
Earlier, we created an unprivileged user that was a “service account.” Right now, this user is just an unprivileged user without anything special about it. To make it a service account, we will need to provide it a Service Principal Name (SPN). SPNs display the name of the service, the system the service is for, and the port the service runs on. The SPN allows users to authenticate against the service account through kerberos to access the service. This will later be used to perform an attack called “Kerberoasting” when performing tests within the environment.
For the purposes of this test environment, I did not create an actual service on a system (yet), I simply added the SPN to an account. This should provide the minimal needed to later perform kerberoasting attacks against the service account.
Open a PowerShell prompt on the DC and use the “setspn” module to add a Service Principal Name to a specified account. The format of the command is:
setspn -A <account name>/<hostname>:<port number> <accountname>Which looked like this for me:
You can then query the user using “get-aduser” and view the applied SPN.
As part of an attack path I plan on covering in a later blog, I want to add the serviceaccount user as a local admin on the srv01.murph.coop system that it is supposed to be running a service on. This can be done by RDPing to the srv01 system, and then using the “net localgroup” command to add the user to the local Administrators group.
net localgroup Administrators murph\serviceaccount /add
Building in Weaknesses: Unconstrained Delegation
The following sections are going to be about building in weaknesses within the domain on purpose that will later be exploited during tests. The intent here is to have known attacks that can be performed, and later when I am testing C2 frameworks, figure out how to perform those attacks using the tool set.
Systems in an Active Directory environment can be configured to allow for kerberos delegation. This allows a system to impersonate a user to authenticate to another service using kerberos. This was meant to workaround the “two hop” problem where a user authenticates to serviceA, but through serviceA also needs to access data from serviceB. Kerberos delegation allows the system running serviceA to impersonate a user and authenticate to serviceB and access that service as the user.
One form of delegation is “Unconstrained Delegation.” The “unconstrained” portion means that a system can impersonate a user to any other service in the domain.
Unconstrained delegation can be exploited by attacker if they are able to gain local administrative privileges on a system configured for unconstrained delegation. As a local administrator, an attacker could extract other user’s kerberos tickets that are in lsass.exe’s memory space. The attacker can then reuse any kerberos tickets that haven’t expired to impersonate a user for any service in the domain. As an example, if a Domain Admin had recently authenticated to a web server configured for unconstrained delegation, and an attacker used a server admin account to gain local admin on the web server, the attacker could extract the Domain Admin’s kerberos ticket from the web server and then authenticate to the domain as the Domain Admin user, escalating their privileges to Domain Admin.
ADSecurity provides a much more thorough explanation of the issue and the attack here.
For the lab environment, I want to configure SRV02 for unconstrained delegation. In “Active Directory Administrative Center”, right click on the srv02 object and select “Properties.”
Then, click on “Delegation” on the left hand sidebar. Check the radio button for “Trust this computer for delegation to any service (Kerberos only).” Click “OK” and the server will be configured for unconstrained delegation.
Building in Weaknesses: Constrained Delegation
Another form of kerberos delegation is “Constrained Delegation.” Unlike Unconstrained delegation, constrained delegation “constrains” a system so that it can only impersonate users to services specific services. A system configured for constrained delegation can impersonate any user to the specified services.
For an attacker to exploit constrained delegation, they would again need to gain administrative privileges on the system. They can then create a kerberos ticket for any user to the services the system is configured for constrained delegation to. The user being impersonated does not need to have logged into the system first. The attacker can chose any user, including the DA or whatever. Both computers and users can be configured for constrained delegation. A more detailed explanation of the issue and how to exploit this can be found on harmj0y’s blog.
In my lab, I wanted to configure wkst01 to have constrained delegation to services on srv01. In “Active Directory Administrative Center”, right click on the wkst01 object and click “Properties.” Then, on the wkst01 page, select “Delegation.” Set the radio buttons for “Trust this computer for delegation to specified services only”, and then click “Add…”
On the “Add Services” window, click on “Add Users or Computers…”
Search for the system whose services you want to delegate to. I chose srv01. Once you choose the server, you will then be prompted to choose which services you want the delegation configured for. I chose CIFS. This should allow wkst01 to delegate to the file system on srv01. Click on “OK” to configure wkst01 for constrained delegation.
Building in Weaknesses: userPassword Attribute
The final weakness I want to add at the AD level is setting the “userPassword” attribute for a user. This is something that I’ve seen every now and then in real world environments. A user will have the “userAttribute” set to a value of a series of numbers. When the numbers are decoded, it provides the user’s password (or at least an old password). I’ve never been sure what caused this, and client’s always seem confused as to why it was configured, but I wanted to show here how to configure it manually.
Right click on any user in the “Active Directory Administrative Center” and select “Properties.” On the left hand sidebar, click on “Extensions.” Under Extensions, select the “Attribute Editor” and scroll down until you find “userPassword.”
Click on “Add”
You will then be prompted to add the value for userPassword in the value format of Hexadecimal. You can convert the ASCII value of the user’s password to hex and paste it here. My user’s password is “Password123”, which in hex is “50 61 73 73 77 6f 72 64 31 32 33”
Click “OK”, and you will see the “Values” listed as the password you entered.
Using the “get-aduser” command from the Active Directory module in powershell will show the value for the userPassword field.
get-aduser regularuser2 -Properties userpassword
As you can see, the value is displayed as a series of numbers. “80” is the decimal value for 50 in hexadecimal, which is the ASCII value for “P”. You can use powershell to query for the userPassword value and convert it to plaintext without having to lookup each ASCII value individually.
get-aduser regularuser2 -properties userpassword | select -exp userpassword | %{[System.Text.Encoding]::ASCII.GetString($_)}
This issue can also show up in other properties such as “UnixUserPassword.” A script created by @_nullbind at NetSPI called Get-AdDecodedPassword.psm1 that searches for these properties and decodes them.
You can also return all properties from all AD objects using get-aduser, and then look for any custom properties that might contain sensitive information and query for them further.
get-aduser -filter * -properties * | select -first 1 | get-member -membertype *Property | select -exp name
To allow for this user to be part of a potential attack path in the lab, I added regularuser2 to the WorkstationAdmins group.
Building in Weaknesses: Unattend.xml File
To add another potential attack path to the lab, I wanted to add an unattend.xml file to the wkst01 system. An unattend.xml is an “answer file” used by Windows Setup. Answer files allow admins to preconfigure settings that will be applied to systems when they are setup, including product keys to apply, how to partition disks, etc. These files can also sometimes contain passwords of the account used to apply these settings. More information on answer files can be found from Microsoft.
Unattend.xml files that contain local administrator passwords still (unfortunately) show up in client engagements I am on from time to time. Searching for these files is commonly done during local privilege escalation enumeration on a system. The unattend.xml file is often found at C:\Windows\Panther\unattend.xml.
For this lab, I found an example unattend.xml file to modify here. Under the <credentials> tag, I added the username and password for my workstationadmin account.
Privilege escalation scripts such as PowerUp should now be able to detect this unattend.xml file.
That’s it for now…
That concludes everything I have (so far) done to configure my AD lab in AWS. Next, I am to experiment using the new version of Covenant within the environment and try some of the attacks that I have mapped out in the lab. Hopefully everything works!