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. And 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. Mimikatz created by Benjamin Delphy ‘gentilkiwi’ allows one to dump clear text credentials out of memory. Mimikatz 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 however is 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.

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 dudiligence and try this out to satisfy yourself. Windows 7 is slightly different and we can only go so far in stopping or slowing down this type of attack.

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

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

Windows Firewall Profile

Windows Firewall – Network Location Awareness (NLA)

Microsoft uses Network Location Awareness (NLA) with its Firewall this is not to be confused with RDP NLA (Network Level Authentication). This is used to determine if a network connection is on a public LAN, private LAN, or domain network. You can change the profile for each network connection by doing the following:

  1. Disable the network adapter.
  2. Open the registry at HKLM\Software\Microsoft\WindowsNT\CurrentVersion\NetworkList\Profiles – look for the ‘ProfileName’ and ‘Description’
  3. Delete the profile key.
  4. Re-enable the network adapter.

Hope this helps!

Facebooktwittergoogle_pluspinterestlinkedinmail

Insecure Service Permissions

How to check for them.

Just a quick post to show a way to check for insecure service permissions  in Windows using the following built in command line tools. This uses a combination of wmic to query for services and then icacls to check the permissions.

I found the below for loops as shown by travisaltman.com to quickly get the results we require.

The first line using wmi to query the services excluding ‘system32’ and then the the second line takes the output and runs icacls against each line.

Another way to view these is via Sysinternals with the accesschk tool like below:

accesschk.exe -uwcqv *

accesschk.exe -uwcqv “Authenticated Users” *
accesschk.exe -uwcqv “Everyone” *

Facebooktwittergoogle_pluspinterestlinkedinmail

Windows 7 Hardening Steps needed after updates.

Windows Updates… the bit you need to do after installing them!

Bit of an FYI post really. The below are some Windows 7 hardening steps that are needed after certain Microsoft updates are installed. I see these a lot in organizations, admins have installed all the patches however haven’t followed through with the extra steps that are needed. There are only a few updates that require some extra action. In most cases its a registry key that needs adding or modifying. The below list isn’t all of them just a couple I have recently come across.

MS KB2269637: Insecure Library Loading Could Allow Remote Code Execution

MS KB2719662: Vulnerabilities in Gadgets Could Allow Remote Code Execution

MS15-124: Cumulative Security Update for Internet Explorer (3116180)

Test and test again to ensure compatibility and that these work in your own environment, they worked for me though on Windows 7 Pro.

Facebooktwittergoogle_pluspinterestlinkedinmail

LLMNR and NBT-NS

Are LLMNR and NBT-NS really helping you?

In this post I’m going to be talking about LLMNR and NBT-NS. That’s Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS). They are backup name resolution processes that take place by default in windows networking to help your PC resolve names it requests. However are they really helping you or actually causing you more harm! I’l talk about why its bad, and why we should look to disable it.

Ok so what is LLMNR and NBT-NS, whats it all about?

Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are processes that take place by default in windows networking to help your PC resolve names it requests. When you PC needs to resolve the name or a server for example to an IP address it firstly uses the DNS server it has been assigned. If the DNS Server doesn’t have the record you requested, your PC will use LLMNR and then NBT-NS. With LLMNR your PC will broadcast across the local subnet and ask other machines if they have a record for the name you are trying to resolve. If no-one answers, your PC will then try NBT-NS in the same manner.

Lets see it in action, in the below wireshark we can see 10.0.2.2 (Windows 7 domain joined machine) querying 10.0.2.10 ( Windows Active Directory DNS Server) for the record of DC2. DC2 doesn’t exist, and as we can see the DNS server responds ‘No such name..’. The PC then proceeds to use LLMNR and broadcasts across the subnet. No response is given. The PC then tries NBT-NS and again broadcasts across the subnet, no response is given. No response is given as no-one on the subnet has that record, I just made it up to demonstrate LLMNR and NBT-NS.

DNS, LLMNR and NBT-NS

Ok so why is this bad, surely its a good thing right..?

Well yes and no, more no these days. Ordinary and back some 10 years ago LLMNR and NBT-NS were used in helping resolve names. If the DNS Server was unavailable local hosts on the same subnet would help resolve names. However lets face it if your PC can’t use DNS its pretty much not going to be doing alot in terms of network connectivity and services. LLMNR and NBT-NS are just not needed anymore (usually). Attackers can take advantage of the LLMNR and NBT-NS broadcasts by replying to them with poisoned responses. The poisoned response can essentially trick the PC into thinking that it knows where the resource is. The PC then attampts to setup an SMB challenge response, in doing so sends its credentials along to the attackers machine. An attacker is able to capture the username and LM, NTLMv1 or NTLMv2 hash of the user making the request. This can then be subject to an offline brute force attack using several different programs such as John the Ripper or OCLhashcat. Or be reused in a PassTheHash or SMB relay attack.

Lets see it in action from wireshark.

DNS, LLMNR and NBT-NS 2

We can see our usual DNS request, then an LLMNR broadcast goes out, as the DNS server has no record. Our attacker on 10.0.2.3 (a kali linux machine using Responder) sends a response back to our PC ‘Standard query response,  DC3 is at 10.0.2.3’ this is actually the attackers machine fooling the PC. NBT-NS request hasn’t gone out at this stage as a response is received to the LLMNR. The PC is fooled into thinking the resource is at 10.0.2.3 and starts to negotiate an SMB session, passing along its credentials to the attackers machine.

What can we do to fix it?

LLMNR and NBT-NS are old methods for name resolution. You may have legacy applications in your environment that may potentially still use LLMNR and NBT-NS for broadcast name resolution. Due to this thorough testing should be carried out first. If this is the case get onto the vendor for some answers as to why! Otherwise we can disable both via GPO and DHCP options. For LLMNR there is native GPO setting. For NBT-NS there is no native setting however it can be set in the registry. The registry key references an interface name which has its own unique GUID so can’t be changed in GPO via a registry key change (as the key will be different every time), however we can use powershell and do a ‘catch all’ on that key and thus script and then run via GPO. I’ll demonstrate below.

You can disable LLMNR via Group Policy in your domain or locally, go to:

Computer Policy -> Computer Configuration -> Administrative Templates -> Network -> DNS Client

In the DNS Client settings select “Turn Off Multicast Name Resolution” and set it to ‘Enable’ like below:

Disabling LLMNR

Disabling NBT-NS can be done in the windows networking as shown below:

On the ‘Advanced TCP/IP Settings’ screen select ‘Disable’ radio button for ‘NetBIOS over TCP/IP’.

Disabling NBT-NS

Changing the above will make the following change in the registry, value data 2 is for disable, 0 is the default setting:

NBT-NS disable via registry

Which in turn can be changed via powershell with the following line, this will change all interfaces (notice the tcpip* for the catch all):

This can then be scripted and set to run via GPO.

The process for disabling both are in the below video:

It obviously goes without saying the appropriate testing, change control and usual roll out procedures should apply especially with a change like this.

Facebooktwittergoogle_pluspinterestlinkedinmail

Unquoted Service Paths

Fixing Unquoted Service Paths in Windows.

This is just a short write up on unquoted service paths, what they are, why they are bad and how we can fix them. A vulnerabilty scanner will often find these on an ‘Authenticated’ type of scan. However we can search for them via WMI (Windows Managment Interface) query or by manually looking through the services one by one. So what is an unquoted service path? It is the path/file location of the service-exe for a given service that isn’t wrapped in quotes, like in the picture.

OK, so what? Why are these bad?

The problem with unquoted service paths is that as windows starts up or as the service is started Windows needs to locate the service-exe for that service. (I keep saying ‘service-exe’, well we’ll come on to that in a sec!). It looks for the service-exe in the path specified in the ‘Path to executable:’ field of the service. If the path is quoted and contains white space in the path windows knows to go directly to the location. If the path is unquoted and contains white space, Windows will essentially query the different locations in the path until the service-exe is found.

Where the service path contains white space and is unquoted, an attacker can use this to escalate privileges from a standard user account. For example if the service is running as SYSTEM, an attacker can create a service-exe to say create an account and drop it in the local administrators group. The attacker would also need to have ntfs permissions as the standard user in the location in the path so ‘C:\’ might not be viable however further down the path might be. The attacker then restarts the service and the new service-exe will be executed by the service running as SYSTEM.

The service-exe I keep refereing to is special type of executable file that is used by services, its not any old exe you can’t just drop cmd.exe in the path unfortunatly…

If I can’t do an Authenticated Vulnerability Scan how can I find them..?

We can use two methods, we can either use WMI query or manually open up each service and check each one, then check the ntfs permissions of each location. We can use the follwoing WMI command from Common Exploits; this will filter out the automatic service and also look for unquoted service paths:

Running the above wmi query will display something like the the following if present:

WMI Query of Unquoted Service Path

As we can see large mainstream manufactures still implment unquoted service paths!

I’ve found one, how do I fix it?

This is relatively straight forward however this should be tested before being rolled out into production (goes without saying). We need to add the quotes to our service path so windows know where to go for the service-exe directly immediatly, rather than searching each directory. We can do this through the registry.

Fire up the registry and navigate to the service as below:

Registry Unquoted Service Path imagepath

Open up the ImagePath string and simple add the quotes as below:

quotes

Restart the service and ensure the service starts properly. We can also open up the service and also re run the WMI query  to ensure our affected service now has quotes. This will ensure any attackers should they manage to compromise the machine as a standard user, stop them being able to escalte privileges in this manner!Unquoted Service Path Corrected

Hopefully this post will help you resolve the uquoted service path issue.

Facebooktwittergoogle_pluspinterestlinkedinmail

Active Directory Authentication for Cisco Devices

Cisco, AAA, Radius, Active Directory, Windows Server 2012 R2, NAP role, NPS its all going on!

Just a quick note to reference the following video on YouTube. This video demonstrates setting up Active Directory authentication for a Cisco router. This is using AAA on the router and RADIUS through the Network Access Policy (NAP) role in Windows Server 2012 R2, this in turn enables a Network Policy Server (NPS). The Windows server (the Radius Server) is registered in Active Directory which allows it to query the domain it is connected too for authenticating users in Active Directory to the Cisco IOS devices. You can control who has access to various network devices through rules created on the NPS. This can in turn be achieved in Active Directory via groups, binding those groups to privilege levels to pass through to deifferent devices.

For example you could have a group in AD called Network Admins which is tied to a prilivelge level 15 group rule in the NPS configuration. This rule would pass through the privilege level 15  setting through to the IOS configuration. Members of this AD group upon succesful authentication would then be granted privilege level 15 access on the router or switch.

 

Facebooktwittergoogle_pluspinterestlinkedinmail