The Shadow Brokers dump – Eternalblue, DoublePulsar – Hello SYSTEM!

Well The Shadow Brokers dump certainly tied up a proportion of time of the Easter weekend for myself and I suspect many infosec bods. It turns out the exploit framework known as fuzzbunch which was released as part of the dump is tied to the ‘Equation Group’ threat actor,  the NSA’s Tailored Access Operations (TAO) according to Wikipedia. From my testing, this is the real deal and pretty effective at allow one to gain SYSTEM level access over an an unpatched supported operating system. It should be noted that many of the exploits have been patched by Microsoft in this months patch Tuesday, most notable MS17-010.  Interestingly there is no attribution from Microsoft in terms of who tipped MS off about the vulnerabilities, one would question whether this was the reason why MS skipped the previous months patch Tuesday.

Utilising the exploit module Eternalblue and doublepulsar from fuzzbunch coupled with Empire or Metasploit is a quick win for gaining SYSTEM level access on any unpatched systems.  If this is not patched in my view this is the next MS08-067 it terms of exploit-ability. The MS08-067 vulnerability was a classic RCE (remote code execution) and easy exploit for 9 times out 10 gaining SYSTEM level access in minutes on a pentest. In my view from my testing that I have completed in the lab with Windows 7 Professional 64bit this new vulnerability in SMB v1.0 is no different, requiring only a few extra steps. Ultimately allowing system level access in a reverse shell… yes those words should make your shudder at the thought. Ensure your systems are patched.

fuzzbunch exploit framework

What is also interesting is that these tools are from 2011-2013, as they require early python versions. One can’t help but think there are a whole raft of new tools being used in the wild potentially by the other nation state threat actor groups. This point simply emphasises the need for secure configuration in addition to mandatory patching. If indeed tools like this are out in the wild we need to ensure secure configuration in the enterprise, ie segmentation, tightening host based firewalls (yes removing access to 445 on your clients), effective monitoring, to name just a few.

How can we detect Double Pulsar?

There are a couple of ways we can detect if double pulsar has been used. Using a vulnerability scanner such as Nessus we can firstly detect whether the Critical patch MS17-010 is missing:

Nessus MS17-010

Nessus will also detect whether double pulsar has been used on a machine by sending an SMBv1 Trans2 request  .

Nessus Doublepulsar detection

In addition to this we can also use nmap’s scripting engine and invoke the smb-double-pulsar-backdoor to check if the target machine is running the Double Pulsar SMB backdoor:

smb-double-pulsar-backdoor

There are also some other specific detection scripts available on github by Luke Jennings available here and a auxiliary scanning module in Metasploit for detecting MS17-010 auxiliary/scanner/smb/smb_ms17_010.

How can we mitigate this threat?

  • Patch Patch and Patch some more, can’t emphasis this enough.
  • Stop using SMB1 as describing and advised by Microsoft in this blog post.
  • If you have SMB port 445 exposed on any systems review why and ensure only systems that need to access this port have access. Do your windows 7 clients really need this port?
  • Ensure your Firewalls are switched on and appropriate firewall configuration is in place. ie don’t just switch it on and allow everything through in any case.
  • Migrate your out of support systems XP and 2003 to new supported versions of MS Operating Systems.

Additional info from Microsoft on the Shadow Brokers was released here.

Facebooktwittergoogle_pluspinterestlinkedinmail

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):

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

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:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

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.

Facebooktwittergoogle_pluspinterestlinkedinmail

Linux Host Enumeration (Authenticated Post-Exploitation)

Linux Host Enumeration On a pentest once you have compromised a Linux host there stands a good chance you will want to go through further ‘Linux Host Enumeration’ from an authenticated position. If you have gained an unprivileged user shell such as a web user you are most likely also going to want to escalate your privileges to root or a higher privileged account and gather as much info as possible. The first stages of this are situational awareness and information gathering based on what you have right in front of you, ie starting with host enumeration. Now whether you have grown up with a Windows or a Linux background, you will probably be more au fait with one or the other. I tend to find as with myself people tend to fall into one camp or the other, probably simple due to the exposure and experience you have had with one or the other in the past. And the need to practice with the other, not so au fait side, is essential. For me I was more exposed to windows boxes.

This post will hopefully guide you through some of what I have learned with host enumeration for Linux operating systems, in this instance Debian Ubuntu. Commands will vary from distro to distro, however, this will give you a taste. Of course please feel free to comment on this particular post with what I have missed and I will be sure to update the post.

Starting on a Ubuntu 14.04 machine as root we would be looking to run the following, (some may seem obvious) however; this isn’t meant to be an exhaustive list more of a top commands:

System Information:

hostname
uname -a
cat /etc/*-release
cat /proc/version
route
arp
ifconfig
netstat -antp
netstat -anup
iptables -L
mount
dpkg -l
apache2 -v
mysql –version
cat /etc/resolv.conf
cat /etc/network/interfaces

User Information:

id
who
last
cat /etc/passwd (you will need a privilege account for this one!)
cat /etc/sudoers
cat history

Sensitive Files:

cat /etc/passwd
cat /etc/group
cat /etc/shadow

Potential SSH information:

cat ~/.ssh/authorized_keys
cat ~/.ssh/identity.pub
cat ~/.ssh/identity
cat ~/.ssh/id_rsa.pub
cat ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
cat /etc/ssh/sshd_config
cat /etc/ssh/ssh_host_dsa_key.pub
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/ssh_host_rsa_key.pub
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/ssh_host_key.pub
cat /etc/ssh/ssh_host_key

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Stopping mimikatz from dumping clear text credentials.

This post aims to demystify how we can restrict mimikatz from running successfully in Windows. More specifically how we can stop clear text credentials from being dumped out of memory. My aim is to do this through demonstrating what can be done to the operating system configuration to prevent this from happening. In a follow up post perhaps we will look into how we might be able to identify if this has or is happening to a machine on the network.

Once a user logs on to a windows system the credentials are stored in the Local Security Authority Subsystem Service (LSASS). Once creds are cached, from here, with various tools, not just mimikatz, credentials in the form of clear text and hashed passwords can be extracted.

Mimikatz for a pen tester is a really great tool, like wise also unfortunately for hackers. Created by Benjamin Delphy ‘gentilkiwi’ allows one to dump clear text credentials out of memory. It can do all sorts of other pretty cool things like perform pass-the-hash, pass-the-ticket or build Golden tickets, among others. Some of which I may walk through in the future.

Mimikatz can be executed from different sources, directly from an executable and also from powershell, the later being the more desirable as no files are ever touching the hard disk drive. A typical screen shot of successful dumping would look like this, this is what we are trying to avoid:

Here you can see the local account ‘Adam’ and the clear text password being displayed. This is clearly bad news for organizations, and an IT teams worst nightmare. An adversary would have to initially compromise a workstation or server and gain admin or SYSTEM level privileges. This might be through a classic remote code execution vulnerability like MS08-069 or through some other weakness in the software, or mis-configuration in the operating system. An attacker from here on would move laterally from system to system dumping creds with the aim of snagging a Domain Admin, or capturing that key piece of business data.

This post isn’t necessarily concerned with showing you how to use mimikatz, rather it’s, to better inform IT teams how they can prevent clear text credentials being dumped. Any tester worth their weight will already know how to use it.

I’m going to test by running  mimikatz natively on a couple of Windows operating systems in my test environment, make changes to the system then re-run.

I’ll run through executing Mimikatz and the preventative measures we can use to stop the software interacting with LSASS and dumping creds. Lets start with Windows Server 2012 R2.

Windows Server 2012 R2

When we run Mimikatz on a fully up to date system we get the following results:

Restricting Mimikatz

Note where the ‘Password’ field is for wdigest and kerberos , this would normally reveal the clear text password however in this case a ‘(null)’ value is displayed. This is default behavior in Windows Server 2012 R2 and Windows 8.1 and above, sadly for older operating systems such as Windows 7 the credentials are in displayed here in clear text. The NTLM hashes are still present here which still isn’t great and so can potentially be used in ‘pass the hash’ type attacks (PTH on the rid 500 account) or cracked offline using large password lists. Lets see what we can do to harden our systems further.

With Windows Server 2012 R2 and 8.1 there is a new feature called LSA (Local Security Authority) Protection according to the following Microsoft page we are able to run LSASS as a protected process. This essentially prevents mimikatz from working correctly out of the box. Although with some tweaking you can get mimikatz to run however a driver would need to added into the mix for it to work properly. The following registry change can be made at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa adding a new DWORD entry of “RunAsPPL”  with a value of 1. This does require a reboot however. Lets see this in action on the same Windows Server 2012 R2 Server. First the registry key:

Restricting Mimikatz WDigest

Lets reboot, and now lets see what happens when Mimikatz is executed:

Restricting mimikatz WDigest

Thats more like it! Now we are getting somewhere. This is only going to slow attackers down. It is however also going to generate noise on the network when the attacker reboots the server.

Windows 7 Professional

A patch was released by Microsoft which allowed you to control the clear text credentials from the wdigest for earlier systems. This same functionality can be utilized by tweaking the registry for earlier versions of Windows. This is available for Windows 7,8,2008 and is kb2871997. Once this patch is installed it allows you control how WDigest credentials are stored in memory. According to the following Microsoft Security Advisor;  to prevent WDigest credentials from being stored in memory. A reg key can be set via Group policy and thus applied to your estate. The registry key is new DWord with the name UseLogonCredential under the following subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.

If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.

Lets see how this works in Windows 7, first we will run Mimikatz to verify default behavior then we will add the WDigest registry key, reboot, test, then add the RunAsPPL registry key, reboot one last time and test again, lets do this!:

As with the standard behavior below we get clear text creds and hashes:

Restricting Mimikatz WDigest

Now lets add the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential and set it 0:

Restricting Mimikatz WDigest

Lets reboot, and retry Mimikatz.

As we can see the password fields no longer contain our clear text password, and have the (null) value instead. This is a significantly better position to be in, this still does however, reveal the NTLM hash which is still not ideal.  Unfortunately the RunAsPPL registry key, cannot be utilized in Windows 7.

Windows Server 2008 R2

Lets try the same with Windows Server 2008 R2. When we run mimikatz natively this is the result:

As we can see the local administrators account password for the wdigest field is in displayed in clear text. Now lets see if we can apply the same  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential registry key and at least mitigate the clear text password. First the registry key then a reboot.

After a reboot we rerun mimikatz and as we can see from the below screenshot we have successfully mitigated from the at least the clear text password being displayed, although the hash is still available:

Conclusion:

So far we have tested using mimikatz natively from the windows server 2012 R2 and successfully stopped mimikatz from executing the same should apply here for Windows 8.1 and above, however you should carry out your own due diligence and try this out to satisfy yourself. Windows 7 and Windows Server 2008 are slightly different and we can only go so far in stopping or slowing down this type of attack, to not displaying the clear text password only the hash.

As you will agree though this is significantly better than allowing the default configuration to remain. I hope this helps slow down your adversaries!

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Searching for password files in PowerShell on a Penetration test!

Searching for password files in PowerShell

Searching for files in PowerShell, more specifically potential password files. During the course of a pentest once you have compromised a windows host there is a good chance that you will want to enumerate the box further and gather as much info as possible. If this is a low privilege user you are likely going to want to escalation your privileges to higher account. This being known as post-exploitation. This will most likely include searching the local system for passwords. Sure we can use the windows built-in gui however we can also use PowerShell. We can use the following syntax in PowerShell to search for files with the text ‘password’ in the filename, just like below. We use the wildcard ‘*’ either end of the ‘passwords’ so we can search for variations in the file name. Ace!

Searching for files in powershell

Simple and quick!

Facebooktwittergoogle_pluspinterestlinkedinmail

Pivoting with netsh in Windows!

Just a quick post to demonstrating pivoting with netsh in Windows! More specifically port forwarding with netsh in Windows (Windows 7 and above). This really is great as your not having to upload any tools to the target system. It is limited in its functionality however is a great option for say a single port such as 445 or 3389.

Now if you don’t have interactive logon rights but you have a PSEXEC, PTH or even a meterpreter session you can add a port forward on you target system and pivot to your next target with SMB/445. This is especially great when you think of tools like PSEXEC module in Metasploit or the main other remote CMD tools available. Now you could use the autoroute or route add function in Metasploit but its nice to have a backup plan if you didn’t have Metasploit!

You can use the below to display your port forwarding rules:

Just remember to clear down your port forwarding rules when your finished with:

Enjoy!

Facebooktwittergoogle_pluspinterestlinkedinmail

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!

Facebooktwittergoogle_pluspinterestlinkedinmail

Superceded Windows Updates

Is this update superseded or not?

I recently came across a need to check on whether a Windows update had been superseded or not. WSUS does give this information in the console view, it indicates whether an update has been superseded or not. However, in my opinion and experience people tend to find it not that great and bit confusing to read. A better and more solid view is to look up the official Microsoft Security Bulletin Data, which shows you what has been superseded and what has not.

If you search for ‘Microsoft Security Bulletin Data’ in google as below you find what we are after or the direct link is here. This is a link to the full Microsoft Security Bulletin Data.

Following the link will lead you to the download, this is in XLSX format. This is a list of all Security Bulletins that have been released. As you can see from the below you are able to navigate around the data with ease in Excel:

There really is a lot of useful information in here, such as whether a reboot is required, the severity rating and also the ‘supersedes’ column.

So when you need to check up on an update you can always refer to this useful data.

Facebooktwittergoogle_pluspinterestlinkedinmail

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 to demonstrates how to add an interactive logon banner legal notice to work/domain joined Windows 7 client machines 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.

Facebooktwittergoogle_pluspinterestlinkedinmail

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

Update-AdmPwdADSchema

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.

Facebooktwittergoogle_pluspinterestlinkedinmail