How To - Making a Pentester's "life" difficult (Part 1)

You are an IT Administrator. They just sent you again the same e-mail:

"We have gained access as Domain/Enterprise Administrators"

Did you know that many many times, gaining access as a Domain or Enterprise Administrator, is accomplished with ready available tools? Did you know that very often it's only a matter of minutes (or probably less) for someone to gain access as a Domain Administrator? Did you know that many times a non experienced pentester can gain that kind of access very easily?

In this series of articles, I will try to describe some of the most common and easy attacks which are being performed during an internal penetration testing exercise.

I will try to make these articles/videos easy to follow for the IT Administrators and for the people who have to apply the "remediation actions". These articles do not focus on the offensive part of the security, but on the remediation actions.

So let's see how (and if ??) you can make a pentester's "life" more difficult.

*don't forget: a Pentester is on your side. If he can do it easily, you can imagine what a real threat can do with no "dead lines" and "scope". And the threat will not be on your side...

Remediation Actions

Disable LLMR, mDNS, NBT-NS

You read the report and you end up to this line. Now you are wondering: WTF? How should I do that?

Let's watch the following video which demonstrates an attack. The attack can be performed when you have not disabled these protocols. The most important part of the video, is that it presents how you can apply the remediation actions by using GPOs in a Domain and how these changes affect the attack.

00:00 - 00:11: This terminal, as it is written in the terminal's title, is running in the "attacker's"/pentester's machine. The "Responder" is one of the most common tools which are being used in an Internal Penetration Test. Describing the internals of the "Responder" and how it works, is out of the scope of this article. What you have to keep in mind is this:

Link-Local Multicast Name Resolution (LLMNR), mDNS (multicast DNS) and NetBIOS Name Service (NBT-NS) are Microsoft Windows components that serve as alternate methods of host identification. 

Any of these protocols can be (ab)used by tools like the "Responder".

Disabling these protocols, is a very common remediation action you are going to read in a Penetration Testing report.        

00:11 - 00:33: As you can see, only the fact that the workstation powers on, is enough for the tool to receive some kind of information. In the video we observe the IP and the Name of the workstation which we powered on. This workstation, can be a user who just powered on his laptop, a server, etc.

00:33 - 01:44: I launch a cmd in the workstation/victim in order to present the IP of this machine. Please note that this is the machine to which the "poisoned answers" are being sent by the Responder, from the attacker's machine. In the attacker's terminal you observe the protocols which are being used for every poisoned answer: "LLMR", "mDNS and "NBT-NS"

01:44 - 02:17: The user/victim started to type the share \\test in his workstation. Back on the attackers machine, we notice that this action alone, is more than enough in order for the Responder to catch fire. . We observe that a poisoned answered is being sent for every single letter. Understanding the internals of the attack is out of scope of this article. For know, just keep this:

Only the fact that the user typed an SMB share, is enough for the attack to be successful. Of course this not the only way for the attack to be successful.        

In this article my main concern is not to explain the attack in depth, and present every possible case this vector could be abused by a malicious entity. For the needs of this article, I could only present you how to apply the remediation actions. However, I wanted to present how the attack will be affected by the remediation actions which we are going to be applied in the next minutes of the video.

In the video, the yellow letters are the NTLMv2-SSP hashes. These hashes (and not only) are being used by the "attackers"/pentesters, in order to crack the password of the user from which they grabbed it. In this example, cracking the hash will reveal the password of the user "gweeperxDC". Cracking the password is not the only way for an attacker to use these hashes. They can also use these hashes in order to gain access to machines which "do not enforce SMB signing".

Enabling SMB signing, is another very common remediation action which you are going to read in a report. I hope that we are going to discuss it in the next articles.        

02:17 - 03:22: We create a GPO which disables the "LLMNR" and "mDNS". But is this enough?

03:22 - 04:10: The victim types to his workstation another domain. As we can observe, the attacker receives again the hashes. However, this time we do not observe the "LLMNR" and "mDNS". This time, the only protocol which is being (ab)used, is the "NBT-NS".

----------------------------(Not so) #protip----------------------------

Pentesters, will usually ask you to put them in the users' VLAN, and not the servers' VLAN for example, in order to start their Penetration Test.

This is done for two reasons:

1. Because they know that in a VLAN which is being used by users, it will be easier for them to grab hashes by using tools like the Responder. Users are using shares and they are also doing misstypos when typing shares. The Domain Administrators are using this VLAN (either with the account of the DA, either as persons), etc. 

The chances for the Responder to grab hashes in a users' VLAN with many users are great. Moreover, it is very probable that these hashes will be from administrative users. Yes this evil I know...

2. When a real threat will attack your organisation, it's very probable that they will perform a phishing attack. The attacker's malware will run in the user's workstation. The user's workstation will be in the users' VLAN. Moreover, many organisations do not use a NAC, port security, etc, and any guest can plug a cable to an ethernet port and his laptop will connect to the network. The same applies for any malware that may "lives" in the guest's laptop.

So to be honest, you have to know what will follow when someone lands to your users' VLAN.         

04:10 - 05:56: Disabling NBT-NS, requires to "Disable Netbios over TCP/IP". If you have only one workstation, this is easy to be done:

If you have 100 or 1000 workstations, you can't do that. You have to change some registry keys:

You have to change the default value of NetbiosOptions from 0 to 2, for every interface under the "Interfaces". The power-shell script "disableNetbios.ps1" which is being presented in the video, does exactly that:

disableNetbios.ps1:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces

Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}"        

We edit the GPO in order execute this ps1 during the startup of the workstations.

I am not a IT Administrator and probably you have better and more efficient ways to edit these registry keys. Probably what is being described in the following article, is a better way:

https://thesolving.com/server-room/how-to-deploy-a-registry-key-via-group-policy/

If you have more efficient ways to Disable Netbios with the use of a GPO, please let me know.        

05:56 - end: On the first reboot, the script will run and the registry keys will change. The problem while disabling NBT-NS, is that for this change to take effect, you have to enable/disable the network adapters or restart the computer.

In the first restart the script runs and the keys are changing. However, the NBT-NS will be disabled in the second restart. This is presented in this time frame.

After the first restart, the attacker is still able to grab the hashes with NBT-NS poisoning.

After the second restart, we observe that the attacker is not able to receive the hashes. No "LLMNR", no "mDNS", no "NBT-NS".

One of the problems when you disable the NBT-NS with a script which is being executed during the startup, is that the machines will have to be rebooted two times.


For the NBT-NS to be disabled, you have to:

1. Change the value of "NetbiosOptions" from 0 to 2 for every interface under the 

HKLM\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces

2. Enable/disable the network adapters.

The restart is not required, as long as you are able to enable and disable the adapters.

If you can find a more efficient way to do that with a GPO, please feel free to do it (and share it :-) )        

As you can understand, disabling the NBT-NS is complicated, because probably you don't want to enable/disable adapters to some servers, or if you use the PS script as presented in the video two restarts are needed and so on. It gets even more complicated, if you have very old versions of Windows such as Microsoft Windows 98, as you will read in the "Important Note" section.

And of course even if you do all these, are you done with these protocols and poisons and "black magic tricks"?

I don't think so... but let's keep the next "remediation action" for the next article.

Important Notes

Important Note 1

Before you turn off WINS/NetBT name resolution, verify that you don't need to use WINS or earlier NetBT-type applications for this network connection. For example, you can turn off WINS/NetBT name resolution if you communicate only with hosts that run a product in Windows Server 2003 (Microsoft Windows XP, or Microsoft Windows 2000) that use DNS and that register their names with DNS, or if you communicate with Internet computers using DNS-aware applications. Do not turn off WINS/NetBT name resolution if you communicate with computers that run a version of Windows that may use WINS or earlier NetBT-type applications (such as Microsoft Windows NT, Microsoft Windows Millennium Edition, Microsoft Windows 98, or Microsoft Windows 95).

Ref: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-tcpip-networking-netbios-turn-off

Important Note 2

Please note that I am not an IT Administrator. I am that guy who tries to grab those hashes and do all that "black magic tricks" and compromise your network. I do not know if the described GPO is going to create any issues in your own network, I do not know if there are better ways to defend your network and I do not know if the described GPO is the most efficient. You know your job better than me, thus make sure that you understand what the scripts and the GPO is doing and ensure that you are not going to break something in your infrastructure.

Important Note 3

This is not a writeup or highly technical article, which tries to describe the ins and outs of the attack. It is an article which I do hope to help some IT Administrators who try to disable the "LLMNR", "mDNS" and "NBT-NS" protocols and hopefully mark as "FIXED" this issue.

If you have better solutions, suggestions or ideas regarding the fixes, send me a PM or comment and I will be glad to update the article and the repo which is being mentioned in the "References" section.

Important Note 4

This is not a Pentester VS DA article. Let's don't waste 100 comments in order to investigate the deep meaning of the title, because it does not exist. I just used a title.

We all try to protect the company/client from threats. Some people by emulating threats, others by trying to identify vulnerabilities and others by trying to patch and defend and so on.

References

In the following repository you can find the script which is presented in the video and a Powershell script which automates the creation of the GPO:

https://github.com/DimopoulosElias/GPOs/tree/main/Disable_LLMNR_mDNS_NBTNS

Other references:

https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-tcpip-networking-netbios-turn-off

https://social.technet.microsoft.com/Forums/en-US/fbc13862-9946-4333-a195-deb863ce078e/programmatically-powershell-adding-startupshutdown-scripts-to-a-group-policy?forum=winserverGP

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wpo/f00add7f-a321-4a5f-a5d8-1748e748cd44