WSUS clients not reporting in? No problem check this out.

Are you having difficulty with your WSUS clients not reporting in? I recently posted about running Microsoft Baseline Security Analyser to check your systems are getting the right patches in this post. If your haveing issues with clients not checking in this may help. If you have gone through the basic troubleshooting steps and believe you have everything in place continue on. In this instance we have recognised that our Automatic update agent store is corrupt or that your clients may have a matched susclient ID in WSUS. More info on troubleshooting the basics first can be read about in this article by Microsoft.

This script will help your clients check back in to WSUS. If the agent store is corrupt or the client agent susclient id is botched. In my experience that a few other issues this tends to be the most common issue that crops up. Issues with Clients having the Same SUSclient ID usually happens as a result of an imaging process.

Save the below txt into a batch file, then run with elevated privileges in an Administrative command prompt on your target machine.

REM stop the Windows Updates service
net stop wuauserv
REM Delete SusClientID and AccountDomainSid registry keys
SET WU_KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
reg delete %WU_KEY% /v SusClientID /f
reg delete %WU_KEY% /v  AccountDomainSid /f
REM Delete registry keys may contain old SUS info
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update” /f
REM Start the Windows Updates service
net start wuauserv
REM Initiate the WU Client…
wuauclt /resetauthorization /detectnow

Hope this helps as this can be frustrating waiting for clients to check back in.

17th April 201728th April 2017

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:

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

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.

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)

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:

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:

This is where our channel access string comes into play.

Our GPO should look like this:

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:

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:

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.

18th March 201717th March 2018

Stopping mimikatz from dumping clear text credentials.

This post aims to demystify what can be done to restrict mimikatz from running successfully in Windows. Specifically how we can mitigate clear text credentials being dumped out of memory. My aim is to demonstrate what can be done to the operating system configuration to help reduce 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. Either 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. Ultimately 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:

However… this wouldn’t stop an attacker from changing the reg key back logging off and waiting for credentials to be cached.

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.

Unfortunately with different versions of Windows there are different fixes and varying degrees of success in reducing the impact of mimikatz being run on a system.

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

29th January 201730th April 2017

Superseded Windows Updates

Is this update superseded or not?

I recently came across a need to check for Superseded Windows Updates. Basically checking 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.

21st January 201730th April 2017

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.

20th January 201721st January 2017

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.

4th December 201630th April 2017

Windows Firewall profile – Network Location Awareness (NLA)

How to reset the windows firewall profile.

In Windows operating systems Microsoft uses Network Location Awareness (NLA) for its Windows Firewall profile. 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. Essentially NLA collects information for each network adapter. The windows firewall then makes a decision as to which profile to assign based on this information. It first checks If the Connection Specific DNS Name matches a specific key. If it does it will apply the ‘Domain’ profile. If it doesn’t match this, it will move on and look at other characteristics such as gateway etc.

You can change the profile for each network connection by doing the following:

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

More in depth informaiton on the Windows Firewall Profile and NLA can be found in the following Microsoft Blog on NLA . However I hope this quick tip helps!

1st December 201630th April 2017

Checking for Insecure Service Permissions in Windows

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.

for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> c:\users\adam\permissions.txt

for /f eol^=^"^ delims^=^" %a in (c:\users\adam\permissions.txt) do cmd.exe /c icacls "%a"

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” *

28th November 201630th April 2017

Windows 7 Hardening Steps – the things you need to do after installing updates KB2269637 KB2719662 MS15-124.

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

Bit of an FYI post really for the following updates KB2269637 KB2719662 MS15-124. The below are some Windows 7 hardening steps that are needed after installing Microsoft updates KB2269637 KB2719662 MS15-124. 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. In mosat cases these can be achieved through Group Policy. 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

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /f /v CWDIllegalInDllSearch  /t REG_DWORD /d 0x1

MS KB2719662: Vulnerabilities in Gadgets Could Allow Remote Code Execution

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Windows\Sidebar" /f /v TurnOffSidebar /t REG_DWORD /d 0x1

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

REG ADD "HKLM\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_ALLOW_USER32_EXCEPTION_HANDLER_HARDENING" /f /v iexplore.exe /t REG_DWORD /d 0x1

REG ADD "HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_ALLOW_USER32_EXCEPTION_HANDLER_HARDENING" /f /v iexplore.exe /t REG_DWORD /d 0x1

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

15th July 20165th January 2017

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

set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2

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.