Active Directory Delegation of Control

No you don’t all need ‘Domain Admin’ rights, that includes you Mr IT Manager!

Users in the IT Helpdesk don’t all need ‘Domain Admin’ rights to perform daily tasks like password resets, user group changes and logging into users workstations for fixes. In addition to this they should also elevate rights and authenticate with another account in order to perform Active Directory (AD) administrative tasks, I wrote about this here. We can delegate special permissions to a security group in order for that group of members to be able to reset passwords and perform other AD related tasks. We can delegate this level of control on specific Organisation Units (OU), so for example all users under that OU can be managed by different levels of IT Support and there corresponding AD security group, i.e. a group for 1st line IT Support called ‘IT Helpdesk ‘, ‘2nd line IT support’ and ‘3rd line IT support’ and so on, so we can have different levels of control. This means we give the permission to a group and in turn members of that group can perform special functions on the users that reside in that particular OU. Thankfully Microsoft have thought about this and there is a fairly straightforward way of achieving it by setting a set of stock permissions on the OU. To do this we can use the ‘Delegation of Control’ wizard in AD Users and Computers.

Delegation of Control Wizard

Ideally we want to split out our standard domain user accounts for standard non privilege duties like reading email and using Microsoft Word, then have a separate admin accounts ie ‘Adam-adm’ or ‘Adamadmin’ for the administrative privileges. These admin accounts can then be used to rdp directly to a separate management server which has the various tools installed. Tools like the Remote Server Administration tool set which has Active Directory Users and computers, DHCP and DNS etc.

Don’t use security groups you already have in your environment, create new groups. This might seem like it adds an extra complexity and more groups. However, if you botch your permissions on a group you are using for another function its not going to end well. If you later need to reverse changes or delete the group you can without fear of affecting other functionality.

Create a group for the help desk ie ‘IT Helpdesk’ for 1 st line staff. This should be used for password resets and group modifications etc.

Create a group for 2nd line support ie, ‘2nd line IT Support’. This should be used for all of the above including all other additional user account modification activities.

You may want to combine the first two groups into just one ‘IT Support’ group for smaller IT Teams. The point here really is to split out the duties so your helpdesk staff don’t have Domain Admin rights, and you’re not running elevated domain rights on your daily laptop/desktop, the principle of least privilege first should apply here. Only give the minimum required, no more.

Create a group for full Admins/3rd line support ie ‘3rd line IT Support’. This should effectively be used for all of the above tasks and any additional.

Keep the below points in mind when using the Delegation of Control wizard in Active Directory:

  • Always delegate permissions on a new AD group, not on one that is already in use.
  • Once applied to an OU there is no wizard to undo the changes. Changes will need to be manually undone.
  • You can re-run the delegation wizard again on the same OU to add additional permission, just not take away.
  • You can remove a newly added group from the security tab of an OU if needs be, (effectively reversing the changes).
  • Avoid setting permissions on individual user objects even if there is only one user, add the user to a group and make the changes on the group not the user. This is in case you need to revert changes. In addition to this you can always remove the user from the group.

Lets walk though an example.

As an example of how we can achieve this lets walk through the below lab. In this example we are going to delegate control in AD for password resets and user group changes for the ‘IT Helpdesk’ group, so that members of this group can carry out these tasks on domain users in the HR OU.

Right click on the HR OU and select the top option ‘Delegate Control…’ the wizard should pop up like below:

AD Delegation of Control Wizard

Select Next, and you will be prompted to add the group you want to grant the permissions too. In this case we will grant permissions to ‘IT Helpdesk’ as below:

AD Delegation of Control Wizard add group

Select Next. Now we will add the specific permissions that we want the ‘IT Helpdesk’ to have on users in the HR OU.

In this instance we are going to select the top five check boxes as these are a reasonable set of tasks that we would want our helpdesk staff to be able to perform. This obviously may be different from organisation to organisation depending on size and separation of duties. We will go with this as an example for now. Microsoft makes this very easy by grouping these tasks together in the form of the check boxes. We can go more granular than this if needs be,  however for now we will continue with the pre-defined options.

AD Delegation add permissions

Select Next, then Finish.

You can verify your permissions be selecting the OU right clicking on properties, selecting the ‘Security’ tab, the group in question should have ‘special permissions’, select advanced, your will then be able to view the permissions. The top four Access Control Entries (ACE) will have been added.

AD Delegation permissions

In addition to this, select the ‘Effective Access’ tab, add the group and verify that the four permissions Create/delete Group objects and Create/delete User objects have a green tick next to them. (they are spread out, so scroll down)

AD Delegation permissions

AD Delegation permissions

As opposed to an alternative OU such as our ‘Admin’ OU which doesn’t have any delegation on it. The default permissions are as below:

AD Delegation permissions

AD Delegation permissions


The next thing to do is test the effective permissions to ensure the new ‘adm’ users of the ‘IT Helpdesk’ group can for example change a password of a user under the HR OU. It also worth testing this on a user account that isn’t in that OU so you can see the difference and error message that you will receive if you don’t have permission.

Et voila. I hope this helps. Remember test test test.


MiTM Thick Client Web Services Testing.

This post walks through MiTM Thick Client Web Services Testing designed for testing thick client web applications for web services using burp and iptables on an internal engagement.


So you need to man in the middle web traffic for application testing on an internal test. This could be either a thick client application for web services that has no proxy settings. Or a client device that is using the system proxy settings (ie proxy settings controlled from Internet Explorer). Or proxying traffic from a client device through the browser as any other usual web application test.

In this scenario the thick client application is installed on a corporate device. So we look to setup some sort of MiTM (Man in The Middle) scenario to watch and alter the traffic as we see fit. The client device IP address must remain the same (ACLs are in place for example or you are unable to change the IP address on the client device). A simple solution to this is two use two virtual machines on your testing laptop to get around having two default gateways with the same IP on one device. With some clever iptables rules we can essentially do a double nat type affair and spoof the client device on the corporate network, at the same time spoofing the gateway for the client device. Bingo MiTM nobody is non the wiser. I talk a bit more about iptables in this post.

If DHCP is used on the client device this is significantly simpler. Rather than using the same ip address range as the corporate network you can set this to an alternative IP and thus removing the need for two virtual machines supporting the double NAT scenario.

They say a picture paints a thousand words… so to bring it all together it the scenario looks similar to this:

Example 1 Configurable proxy settings on client device:

In this example the application on the client system is using the proxy settings configured for IE or Firefox. You are able to modify these and so you can redirect traffic to the proxy of your choice on 8080 for example like so. Note Chrome uses IE system settings:

Network Configuration:

Caution: Don’t use network-manager for this. Dual homing interfaces does not play nice in network manager. Stop the network-manager service first, verify it is stopped then continue to work in the standard networking service with the interfaces file.

service network-manager status

service network-manager stop

service network-manager status

service networking status

Now continue to work using just the interfaces file with the standard networking services.

Set the mac address of the eth0 on VM2 the same as the PC mac address

Ifconfig eth0 down

macchanger –mac 08:00:27:8D:CD:53 eth0

ifconfig eth0 up

On both VM2 and VM1:

echo 1 > /proc/sys/net/ipv4/ip_forward

VM2 interfaces file:

**Gateway is always set on the forwarding interface.

VM2 iptables:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

VM1 interfaces file:

**Gateway is always set on the forwarding interface.

VM1 iptables configuration:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

Using burp set your proxy to the listening IP and port.

Example 2: No proxy Settings/Thick client App or Web Services etc..

In this example you have a thick client app that doesn’t allow you to set a proxy and doesn’t use the system proxy settings. You can use ‘prerouting’ in IP tables on VM1. This will route traffic destination port 443 and ‘redirect this to port 8081 with this command:

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 -j REDIRECT –to-port 8080

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 443 -j REDIRECT –to-port 8081

Then using burp configure your proxy to listen on all interfaces for 8080 and 8081 do this for as many destination ports as required. In addition to this ensure ‘Support for ‘invisible proxying’ is enabled.



Things to Remember!:

After every reboot IP forwarding and iptables will reset so check both on a restart:

cat /proc/sys/net/ipv4/ip_forward

iptables -t nat -L -v -n

To make IP forwarding persistent you can do the following:

Edit /etc/sysctl.conf and uncomment the ‘net’ line:

# Uncomment the next line to enable packet forwarding for IPv4



DNS: hostnames will need to resolve on both the client and proxy machine.

Its is useful to create a bash script for your config for each machine. Then on a reboot there is no faffery looking for the right commands simply run the bash script. Note – the nameservers are pushed to the resolve.conf to save bringing down and back up the interfaces, and restarting the networking. A sample script might look like the below:


On the proxy VM:

This is definitely a labs worth! Hope this helps!


Disable Domain Users from Enumerating other Domain Users, Domain Admins and other objects!

In this post we will walk through how to disable domain user enumeration. Disabling Domain Users from Enumerating other Domain Users, Domain Admins and other objects in Active Directory. Why might I want to do this? Well, once a domain user account has been compromised through exploitation, sooner or later the attacker is going to want to enumerate the domain further and gather ‘intel’, commonly known as situational awareness. During this process an attacker is going to want enumerate the domain and all its users including high privilege groups such as Domain Admins. This is a gold mine for an attacker as they can launch password spray attacks on those enumerated users. The attacker doesn’t have to guess the usernames as he/she can just query the domain, that’s half the battle won. The attacker will then use a single password such as Password1 against all the accounts, inline with the domain password policy avoiding account lockouts. By default any authenticated domain user can enumerate the entire domain, this is standard out of the box configuration for a domain controller. For example our test user ‘bob’ in our lab is a domain user, he can freely pull up a command prompt and simply enumerate all the domain users, domain admins and other objects such as computers and servers in the domain, just wonderful…(not!!).

disable domain enumeration

Microsoft why on earth would we want our domain users to enumerate our ‘Domain Admins’ group by default??

This just won’t do, so how can we fix it? We can deny read permissions to certain objects in the domain through the use of the access control lists (ACL) in Active Directory. A word of caution here, this is likely to break certain applications so the way we will go about this is in stages. For starters we won’t be modifying any permissions of any users or built-in groups. We will create a new security group called ‘Disable domain read’. We will then add users to this group that we want to deny the read permission for, so when a user of this group tries to read the domain they will get either no results or an ‘access denied’ message. Then add this group at various OU’s in the forest, ticking the deny read permission for that group, this will take affect on all users under that OU. This has the added benefit of simply being able to remove users from the group and also removing the group from any ACLs on OUs, should anything need to be reversed.

An Example

As with the above screen shot we can see that bob is able to enumerate the domain. Lets fix this. First we will create our group:

create disable domain read group

Now as a simple test we will add this group to the ACL of the HR OU. You can see in the below screenshot there are a list of users in this OU already. By making this change we will be denying the read permission on the OU and its contents for members of the group ‘Disable Domain Read’. So right click on the OU and select properties. Select the ‘Security’ tab, then ‘Add’, add in the security group, then select ‘Deny’ on the ‘read’ permission as highlighted in the red box.

Add group to ACL OU HR

Add ‘bob’ to the group and then lets try and enumerate the domain again. Lets see what happens:

disable domain enumeration

Great… bob has now been denied access to reading the users in the HR OU. However, can still see the ‘Domain Admins’ group. I have purposefully done the the configuration this way to show you how granular we can set the permissions. As the Domain Admins group isn’t in the HR OU it has not applied to that object. Now lets go to the other extreme and set at the top level for the entire domain. Apply the same access control entry (ACE)  at the domain level, this will filter down to all objects including ‘Domain Admins’. In reality you would want to be more granular than this, applying the ACE in ACLs within the domain at specific OUs, this will give you more control. However as an example lets proceed:

Add group to ACL for the domain

Lets reboot our domain computer and test again:

disable domain enumeration

Perfect, now our domain user is not able to enumerate other domain user accounts and more importantly the ‘domain admins’ group. This is the other extreme and will likely break things so you should apply at specific OU’s however hopefully this should give you a good idea of how powerful the permissions can be and granularity in which we can apply them.

Using this method you should take into consideration that an implicit deny takes precedent over another ACE with the same permission. For example, if there were another ACE that explicitly was allowing the same action the deny would win and take precedent. This means that delegating rights to an OU after you have used this method to allow reading of permissions (ie the reverse) would not work.

Windows Security

This is why we have used a new separate security group just for domain users. If you were in a position where you needed a specific user or service account to be able to enumerate all domain users due to the way an application worked you could remove the user from the group and set alternative permissions on a new group with just that user in it.

Hope this helps. Remember test out your configuration before moving into production!


Creating realistic test user accounts in Active Directory test lab.

How to create realistic test user accounts in Active Directory test lab. Often when I’m working through certain lab scenarios I will want multiple realistic test users in Active Directory to work with. Yeah sad I know. However, for example if searching through users in PowerShell, modifying permissions or pentesting techniques like RID cycling etc you would ideally want realistic users with pre-populated data to search through. Sure you can create a quick script to create a bunch of accounts like user1 user2 user3, with Address1 Address2 and Address3 however I prefer to have a realistic environment to work in. After all, by working in a lab ultimately we are trying to mimicking an Enterprise environment or order to test something your working on. I wanted a quick simple was to do this. I came across this website by Helge Klein which does the trick. A PowerShell script to create realistic users with proper account names, first name, surname, address etc. In order to create realistic accounts you do require the information such as names and addresses which Helge supply’s in the form of a few text files.

You need to set a few variables at the beginning of the script:

Creating realistic test user accounts in Active Directory

Note you can set the user count variable $userCount to the amount of users you want in your lab.

Running the script results in the following:

Creating realistic test user accounts in Active Directory 2

And as we can see in ‘Active Directory Users and Computers’ we have our test users:

Creating realistic test user accounts in Active Directory 3

As always familiarise your self with the script be comfortable with what its doing! enjoy!


Pivoting through SSH with dynamic port forwarding.

snmp-check UDP over SSH

Pivoting through SSH with dynamic port forwarding. Just a quick post about how we can pivot to an internal/dmz network through a host via SSH. This is a classic example of how we might want to pivot through one host to get to an internal or dmz network using SSH as a tunnel. We can essentially tunnel our traffic of this SSH tunnel via the compromised host to an inside network.

The scenario… A picture paints a thousand words… Essential our ‘Hkali’ machine is on the outside. Our Ubuntu Server is in the internal/dmz, this is going to be our pivot point.

So in this scenario the firewall is only allowing inbound access to our Ubuntu server, on port 22  from our attack box running Kali2.0 ‘HKali’. So from Hkali all we can see is port 22 open on We suspect from our initial enumeration that other servers might be in this network. However, we want to check out the rest of the subnet ie ‘WS2K32’ and ‘meta’ to see whats actually there. Imagine we have compromised the ubuntu server already and have gained login details.

Starting at our attacking machine we will SSH into ‘Ubuntu’. In order to be able to forward traffic for any TCP port on through our SSH tunnel we will want to take advantage of Dynamic port forwarding and specify the ‘-D <port>’ command. This uses ‘Dynamic’ port forwarding feature of SSH. This will allow us to send other tools with Kali to localhost:1234 and thus onward onto any route able networks the ‘Ubuntu’ server can see.

Our command would look similar to the below:

ssh root@ -D 1234

Before we go any further there are some useful additional options we can pass on the ubuntu server in the SSH command, these being below. However the minimum we need to specify is just the -D for dynamic forwarding:

-f: Sends the process to the background. If you do this you will have to kill the process ID rather than just closing the terminal window as it will already be closed. This is easy enough use ‘ps aux | grep ssh’ to get the process ID then ‘kill <ID number>’.
-C: Compresses the data before sending it through the tunnel, mixed success with this, so experiment.
-q: Uses quiet mode.
-N: Tells SSH that no command will be sent through once the tunnel is up.

If we take a look at our local network connections we can in fact see our ssh connections and also our localhost listening on port 1234.

netstat -antp ssh dynamic ports

We can now use a socks proxy or equivalent to proxify our traffic through the SSH tunnel and onward to the inside network. For this we will use proxychains. Lets look at how we could do this using a socks4 proxy. First a look at our proxychains configuration. Lets open up /etc/proxychains.conf and ensure the the following line is set in the last line. (note the port should be whatever you used in the SSH command after the ‘-D’.

dynamic port forwarding SSH proxychains

Now we can proxify something like nmap through to the internal network. Bear in mind we can only proxify full TCP connect commands. So UDP traffic/tools such as snmp-check won’t work – however, we can proxify udp in an alternative way, I describe this here. Some tools won’t play nice with proxychains, so play around in your lab and experiment.




Tunnel snmp-check and other UDP traffic over SSH

Today I will be walking you through how to tunnel snmp-check and other UDP traffic over SSH.

In this example we are tunnelling UDP over SSH to circumvent firewall rules on the outside. Our firewall rules are only allowing access into the other side of the firewall to TCP port 22 on a Ubuntu server. We don’t have access to any other TCP or UDP ports. The only method of communication into the environment is via SSH to our Ubuntu server. We will use this server as jump/pivot point for other traffic. Imagine we have earlier identified through cdpsnarf using SSH dynamic port forwarding and proxychains another router, we want to enumerate this further. Our next goal in this case is to try and enumerate SNMP UDP port 161 on target router with a public community string. This example could also be applied to all sorts of UDP traffic such as DNS for example were we want to tunnel our local DNS requests to a server behind a firewall. Zone transfer maybe?tunnel snmp-check and other UDP over SSH

Attack machine: Kali Linux
Pivot Server: Ubuntu
Target: GNS3 Cisco Router

We are going to do this by sending our local UDP traffic through netcat (handling UDP) into a fifo process back into netcat (handling TCP), through the ssh tunnel then in reverse the other end. Yes I know bit of a brain teaser! You can read more about fifo files here, they are similar to pipe in linux. In essence we are sort of writing the output to a file (without actually writing anything) then sending it on its merry way through netcat via TCP then down the tunnel. Its best we see this in the flesh with an example.

We begin on the Attack machine by running up the ssh connection, here we are forwarding TCP port 6666 on localhost to TCP 6666 on the remote pivot server:

Then on the Pivot Server we create a fifo file for netcat to talk too:

On the Attack machine we do similar:

In second terminal on the attack machine:

Run up ‘netstat -au’ to verify snmp is listening on the local machine.

UDP netstat connections

We can then simple run snmp-check to localhost.

snmp-check over SSH


Looking further down the information we discover the following:
snmp-check over SSH another netowrk


Another network interface, is this possibly the internal network and route to DA..? Maybe in the next post…

Bingo UDP and snmp-check over an SSH tunnel, awesome!


Windows Event Forwarding – Free Tools!

Windows Event Forwarding is a powerful tool and is also free unlike most SIEM options. Being able to log certain events back to a logging server is important, getting the right events logged is also equally important, and not being swamped with the wrong events. You really do need to know if someone is messing with your Domain Admins group or an LSSAS proccess on a member server.

In this post we will walk through setting up WEF (Windows Event Forwarding) in a lab environment to demonstrate how we can have better visibility over important security events in the domain. All without having expensive SIEM products, ie using what we already have.

For a bit of background, WEF has been part of Microsoft Operating systems for a while, being supported in Windows 7 right up to 2012 R2. Events can be either source initiated, ie sent from a client, DC or member server to a collector. Alternatively be collected by the event collector server itself. The idea here being that when an important event gets written to the Windows event log (Client or Member Server) it also gets forwarded to a certal logging server and thus the IT admins or security team get alerted to the event in some manner such as email. I posted a while back about doing this for Cisco kit with a Ubuntu 14.04 server utilising rsyslog for event collection posted here. 

So our lab will utilise GNS3 as it gives us a good visual representation as to what we are working with:

WEF LAB Network Diagram

As you can see, a pretty simple lab setup a Domain Controller (DC1) a couple of member servers (NPS and WEF-Collector) and client machines (W71, W72 and W73). We won’t worry too much about ESW1 or R1 at the moment these were just left over from an 802.1x lab I had been working on, the topology is just a flat 10.0.x.x network. The events will be written to our WEF-Collector Windows Server 2012 R2 machine.

First we will setup our Event collector server WEF-Collector. We will want to ensure WinRM the Windows Remote Managment service is started and Event forwarding is setup. Open an administrative prompt and type ‘winrm qc’ (you may find it is already configured as below):

WEF WinRM qc

Now to enable event forwarding on WEF-Collector our event collector. Go to the event viewer, select ‘subscriptions’ you will get a pop up – select ‘yes’ as we do want to enable event forwarding to start automatically if the server is restarted.

WEF Event Forwarding 'Subscriptions'

Now lets look how we can forward events to the collector ‘WEF-Collector’.

First we need to give the local Network Service principal rights to read the security log, we run the following ‘wevtutil gl security’ on machine in the lab to grab the channel access string (this will be used in our GPO):


WEF Event log enable

Thanks to Jessica Payne with this article for discribing this section.

We will then append the string with (A;;0x1;;;NS) so it reads:


This line is essentially where the permissions on the log are stored.

Now we will create a GPO so we can apply the settings to our clients and servers that we want to push events from, this will tell the clients and severs where to check for subscriptions and where to send events to ie ‘WEF-Collector’. We will initially want ot set two policies:

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Forwarding>Configure target subscription manager:

WEF GPO Subscription Manager

Note: Instructions are in the text of the GPO iteslf however in summary we want the FQDN, URL path, port and refresh time. Clearly checking every 10 seconds is overkill however for the lab its ideal.

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Log Service>Security> Configure log access:

WEF GPO Log Access

This is where our channel access string comes into play.

Our GPO should look like this:

WEF GPO Summary

Now link the GPO to our AD structure to enable it.

Now our clients and servers are configured, lets configure some example subscriptions:

Logging Domain Admin changes sounds like a good idea, this is event ID 4728 and 4729. Start in the Event View, under Subscriptions select create subscription and fill in details like so:

WEF creating subscription to monitor domain admin group changes

Next select ‘Source computer initiated’, and in this case we are going to add DC1. Next we are going to go into the Select Events option and configure like so:

At the moment we can see that DC1 hasn’t yet checked in as the ‘Source Computers’ column is still ‘0’.

Once DC1 has checked in to see if there are any subscriptiosn for it we can see that the ‘Source Computers’ column is now 1, we can check the status by clicking on ‘Runtime status’. Here we can see DC1 is ready and waiting to send events:

WEF Runtime Status

If we now generate some events on our DC by removing and adding the user ‘Bob’ to the ‘Domain Admins’ group we can see the following two events have been logged in the ‘Forward Events’ section under the ‘Windows Logs’:

Clearly this is only based on two event ID’s however hopefully demonstrates what can be done takeing this example and expanding it, creating multiple subscriptions based on certain filters and IDs.

I hope this helps demonstrate WEF and how we can get much better visualisation into whats happening on the network for security events.


VLAN tagging in Kali Linux 2.0

Connecting to Trunked Ports!

Just a quick post on how to configure VLAN tagging in Kali Linux 2.0. If we have a trunk port presented to us, how do we utilise it?

To setup vlan tagging in Kali Linux 2.0 is pretty straight forward, to set the scene and demonstrate this further we need a lab. The below lab is our ‘test.local’ environment set up in GNS3. There are 3 vlans, 10 20 and 30. 10 and 20 are routable, vlan 30 is isolated from 10 and 20. In the lab we have a ‘router on stick’ configured  at R4, fa0/1 is sub interfaced with vlans 10 and 20. utilising DHCP, vlan 10 for servers and vlan 20 for clients. All devices in vlan 30 are statically assigned IP addresses and not routable to the 10 and 20 vlan networks.  In all switches there are a variety of 802.1q trunked and access ports.

The idea of the lab is that vlan 30 can’t talk to vlan 10 or 20. However as a trunked port is presented to the Kali vm, it will be able to communicate to all vlans.

This is how it looks:

VLAN tagging in Kali Linux 2.0 - switch configuration

Lets look at how we would configure Kali to test all hosts in the different vlans, first via CLI and then via GUI in Network Manager:

As you can see with the current trunk connection we can’t access any of the networks, however a quick Wireshark does reveal we can see traffic and the different vlans…

First lets open up ‘/etc/network/interfaces’ in nano and add our interfaces. The idea is very similar to a cisco router we are essentially sub interfacing our network connection in the interfaces file:

Save our file and then simply bring up the sub-interfaces with ‘ifconfig XXX up’ where XXX is our subinterface:

We can now access all of our vlans in question.

Further to this, if we set off a ping to each network and Wireshark the trunk connection we can see our tagged packets. Hooray.

The Gui is even easier, lets configure it via the Network Manager. We will do this via opening up our network connections/Network Manager, simple click on the ‘+’ sign, select ‘VLAN’ fill in the details on the vlan tab as well as the ‘IPv4Settings’ tab:

And there you have it.

I hope this helps someone!


Creating a Windows 7 Logon Banner Legal Notice message at Logon via GPO

Windows 7 Logon Banner

This is just a super quick post to reference an earlier video which I created which demonstrates how to add an interactive Windows 7 logon banner legal notice to work/domain joined client machines. This can be achieved via group policy object. A user would need to click ‘OK’ to accept the message before logging onto the machine.

This is a CIS (Center for Internet Security) benchmark for Windows 7 machines the rationale is that it is important to notify and warn unauthorized users attempting to gain access to carry out an attack on the computer by notifying them of the consequences of what they are about to do and any legal ramifications.


Microsoft LAPS (Local Administrator Password Solution) Deployment

Password re-use… ah such a bad idea.

During a penetration test one of the most common vulnerabilities I see is the local administrators account having the same password used across all client machines in the estate, usually one for servers and one for clients. So a classic scenario I see a lot goes something like this; a vulnerability is identified in an environment lets say a nasty remote code execution, it gets exploited giving SYSTEM level privileges, you then dump creds from the box and boom you have the local administrators password, even if you don’t get the clear text password you might get the hash. You use the creds/hash with something like hydra or medusa to try a few more workstations in the environment, and hey presto your screen lights up with successful smb authentications. You now have the ability to move laterally across the network logging into workstation after workstation either dumping more creds with mimikatz or stealing tokens with incognito until you reach a domain admin account.

There are in fact a few ways in which we can contain or should I say slow down lateral movement by an attacker, one being to use a different local administrators password on every device, I’m going to walk through how we can achieve this using Microsoft LAPS (Local Administrator Password Solution). This essentially allows you set a unique local administrators password on every workstation in the domain. Thus stopping password reuse and pass the hash type attacks. Granted this is only half the problem solved however does shutdown this avenue of attack.

OK, how do we set this up?

A quick search on google for LAPS and you will find the free download from Microsoft.

Go ahead and download the 32 & 64 bit downloads as well as the ops guide for reference.

For this demo I’m going to be using the trusty Blue Team Security lab in GNS3, you can see from the below diagram we have our Domain Controller and a few windows 7 clients to play with, great:

LAPS works by having what Microsoft refers to as clients and management computers within your domain. Passwords are stored in Active Directory as a computer object attribute this does mean that the password is stored in clear text. However transmission is encrypted. Management computers and its user will have the ability to fetch the password of any given client, so its important to delegate this responsibility carefully i.e to a specific security group. The msi we downloaded is the same for both client and management computers, the install has different options selected for each type. The default options being for clients. For the management computers I’m going to use ‘W71’ this is a standard Windows 7 Pro domain joined client.  For the client computers we are going to use W74 and W72, again just standard domain joined Windows 7 Pro builds.

When we talk about management machines we are talking about user admin machines so where your helpdesk or second line staff can access.

There are a couple of pre-requisites; the first is a schema update which adds two new attributes to AD these are to store the password and timestamp for password expiry. The second are some permissions that need to be setup for our clients and the users that can see these attributes.

Let’s first install the management software and tackle the schema update.

On our management computer lets go ahead and double click on the msi in my case 64 bit so ‘LAPS.x64’

Click Next.

Accept the End-User License Agreement and click next.

Select the ‘Managment Tools’ and select to install to all the computer and click next.

That it management install complete.

Onto our scheme update, open up an elevated PowerShell prompt with an appropriate scheme admin account, import the module and then update the schema like below:

Import-module AdmPwd.PS


Onto our permissions. Basically, the client machines need to be able to update the password and timestamp expiry attributes. Using the module that we have previously imported, or in the same window as before run:

Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>

In the Blue Team Security lab this would be on the ‘PCs’ OU:

So the command would be:

Set-AdmPwdComputerSelfPermission -OrgUnit PCs

Next we will create a User Group that we can assign read permissions for the new attributes. This will essentially allow the new group and its users the ability to read the password field of the computer objects. In this case I have created a group called ‘LAPS Admins.’ The comand is:

Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

In the Blue Team Security Lab our command would be:

Set-AdmPwdReadPasswordPermission -OrgUnit PCs -AllowedPrincipals ‘LAPS Admins’

The same again for the expiry field:

Set-AdmPwdResetPasswordPermission -OrgUnit PCs -AllowedPrincipals ‘LAPS Admins’

Managing clients; telling them we want to control their local administrator password is done through group policy. The policy we want to configure is a computer policy under administrative templates called LAPS, this will have been imported when the management computer software was installed. Using our management machine, in our group policy management console we want to create a new GPO under the container where our client machines are, just like below:

The settings we want to configure are to initial switch on the password management this is called ‘Enable local admin password management’ funnily enough and we want to enable it. Next is the ‘password settings’ this looks like, and has the below configuration options, as you can see we have a fair amount of control over the password to configure it securely. What you see below is the default settings:

Its probably worth noting if you have changed the local administrators account name via policy (and you should!), then you will need to specify the new account name in the policy ‘Name of administrator account to manage’, enable the policy and specify the new name. This policy is only needed if you have renamed the account.

Next up is installing the client side software. I’m going to manually install this however in the enterprise you will probably use SCCM or GPO to deploy to your client machines. I will perhaps demonstrate this in my next post.

Over on our client the install takes all the default values from the same msi that we used for the management computers. I won’t bore you with additional screenshots, just know that it is a next, next, next, finish situation and installed successfully on my client machine W72.

Once the above GPO has had time to take effect on our client machine we can verify the password in AD and through the fat client installed on the management computer. First in Active directory users and computers you can view the password by navigating to the computer object in question (W72 in this case) selecting the attribute editor and scrolling down to the value ‘ms-Mcs-Adm-Pwd’ this value is our new password the one below it is the expiry time (you will need to have selected ‘Advanced Features’ to view the attribute editor on the computer object) and be viewing with the appropriate rights (ie be part of in our case the LAPS Admins group):

On the management machine with the account ‘Adam’ which is a member of the ‘LAPS Admins’ group through the fat client UI (which does require DotNet4).

Just to demonstrate if we log in with ‘Bob’s account on the same management computer and try to use the same LAPS UI tool the following expected results are shown, not the bob is not a member of the ‘LAPS Admins’ group and so the password is blank, ace!

And for the die hard CLI users you can of course use powershell to retrieve the password with the appropriate account of course:

You can now try out your new unique local administrators password. Now even if the box has been compromised an attacker will struggle to crack the likes of the above password and secondly won’t be able to reuse the hash to authenticate to another machine. Remember to test out in your lab before in production. I hope this has been informative.