Creating a Simple Windows Domain for Offensive Testing: Part 4

By: Justin Palk, Security Consultant

This is part four of my series of blog posts on creating a windows domain for offensive security testing. In part 1, I stood up a domain controller (DC) for the rslabs.lan domain. In part 2, I added users, groups and Organizational Units (OU), and in part 3, I added workstations and a server to the domain. This part will focus on using Group Policy Objects (GPO) to enable services and manage access to machines based on user group memberships and computer OU.

Creating GPOs

Making the domain more functional requires enabling services and granting users access to resources. This is a small enough domain that I could do this on a machine-by-machine basis, but if the domain grows at all, and also to keep things consistent, it’s better to do it using Group Policy Objects. I’m going to create three GPOs. One to make it easier to use the domain (allowing RDP), one to add management functionality (enabling WMI) and a third to allow for different levels of user privilege (local admins).

Allowing RDP Access

As noted before, access to machines previously has been through the VMWare console window, which is fine. But in an actual domain, at least some machines are going to be accessible by Remote Desktop, whether that’s for management of headless and virtual servers, some sort of virtual desktop infrastructure (VDI), or to allow helpdesk techs to provide end-user support. What I need to do is:

1. Enable RDP on each computer

2. Ensure RDP is permitted through the firewall

3. Authorize users to access machines via RDP

I’m going to do this with a set of GPOs, applied to the Workstation, Server and Domain Controller OUs, so that I can control who has access to what kinds of devices in the domain. I’ll start with Workstations, and then repeat the process for the other OUs. Going to the Server Manager on my DC, from the Tools menu in the upper-right corner, I select Group Policy Management.

This opens the group policy manager. In the navigation pane, I navigate through Forest: rslabs.lan -> Domains -> rslabs.lan until I see my Workstations OU. Right clicking that, I select Create a GPO in this domain, and Link it here.

When prompted, I name my new GPO Workstation RDP Access, and leave my Source Starter GPO as (none).

The GPO now appears, linked, under the Workstations OU. When I click on it, I’m notified it’s a link, not the GPO itself, but I’m also told any changes I make here will apply to the GPO, so I just click Don't show this message again, hit OK and move on.

To edit the GPO, I right click on it and hit Edit, which opens the Group Policy Management Editor.

The first thing I’m going to do is enable RDP. In the navigation pane I navigate through Computer Configuration -> Policies -> Windows Settings -> Administrative Templates: Policy definitions... -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host - > Connections. Once there, In the right-hand pane, I right-click Allow users to connect remotely by using Remote Desktop Services, and hit Edit, then select the Enabled radio button, and hit OK.

 

With RDP now enabled, I need to permit it through the host firewall. Back in the navigation pane, I go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security... -> Inbound Rules (yes, WDFwAS is in there twice). Right-clicking on Inbound Rules, I select New Rule.

I set my rule type to Predefined -> Remote Desktop, hit Next twice, then Finish. The firewall is now configured to permit RDP connections.

The last step is to authorize users to connect to workstations over RDP. Earlier, I created a group Workstation RDP Users to authorize users to make RDP connections to workstations. Now I’ll add that group to the local Remote Desktop Users group on computers in the Workstations OU. In the group policy management editor’s navigation pane, I go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups. I right-click Restricted Groups and choose Add Group.

When prompted to add a group, I hit Browse, then enter Remote Desktop Users into the Enter the object names to select field, and hit Check Names. If Remote Desktop Users gets underlined, it’s good to go, and I hit OK.

I’m now prompted to add users to the group. Next to Members of this group I hit Add, then Browse in the Add Member window, and then enter Workstation RDP Users and hit Check Names in the Select Users, Service Accounts, or Groups window. Again, if Workstation RDP Users gets underlined, it’s good, and I OK back up through the windows.

The GPO is now configured to do everything it needs. However, if I were to try and RDP to my workstation now, I still wouldn’t be able to do it. The GPO hasn’t refreshed on the computer yet. GPOs update:

1. Upon a reboot

2. Upon a domain user login

3. Every 60-120 minutes (90 min with a randomized +/- <30 minute offset)

4. When manually pulled with gpupdate

I reboot rsl-wks-1, and try again to RDP to the machine. The first sign of success is that I’m prompted for credentials.

I’m greeted a moment later with a desktop login process.

I can now repeat this process for Servers and Domain Controllers.

Allowing WMI

After allowing RDP, allowing WMI is much simpler, as it’s basically adding a firewall rule. I’m going to create the rule under Group Policy Objects in the Group Policy Management tool, because I’m going to apply it to both Workstations and Servers.

I create the new GPO the same way I did for the RDP GPO, naming it Allow WMI, and go to add a new firewall rule, also as I did above. I set my rule type to Predefined -> Windows Management Instrumentation (WMI), hit Next twice, then Finish.

That’s it for the GPO, so I close out of the editor. Back in the Group Policy Management window, I then drag the GPO to the Workstations OU and Servers OU to link it to those organizational units. Remember to update the GPO on the endpoints before trying to connect to them with WMI.

Allowing Local Administrator Access

Again allowing local administrator access is just like adding RDP users in the RDP GPOs I created earlier. In the Group Policy Management screen, I right-click on the Workstations OU, and select Create a GPO in this domain, and Link it here..., and name it Workstation Admins.

I then go to edit the GPO and navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups. I right-click Restricted Groups and choose Add Group.

When prompted to add a group, I hit Browse, then enter Administrators into the Enter the object names to select field, and hit Check Names. If Administrators gets underlined, it’s good to go, and I hit OK.

I’m now prompted to add users to the group. Next to Members of this group I hit Add, then Browse in the Add Member window, and then in the Select Users, Service Accounts, or Groups window, I enter Workstation Admins and hit Check Names. Again, if Workstation Admins gets underlined, it’s good, and I OK back up through the windows.

That’s it for the GPO. I close out the editor, update the GPOs on the endpoints (or wait for them to update), and I’m good to go. I repeat the process for Server Admins.

Conclusion

That’s it. I now have a simple windows domain, with a couple of key services enabled, and with users whose access to systems is dependent on their group membership and the OU of the computer they’re using. This would be suitable for practicing with BloodHound, Impacket, a C2 framework or any other number of tools. I hope you find this as useful as I do. Now go forth and develop those offensive skills!

About Justin Palk, Security Consultant:

Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.

Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA

Connect on Twitter & LinkedIn