The come back - Making a Pentester's "life" difficult (Part 2)

Summary

If you are bored to read the article and you only want to disable IPv6 (and/or LLMNR, mDNS and NBT-NS), jump directly to the following repository:

If you want to do it on your own, jump to the section "Video Part 2: Disabling IPv6 via a GPO and the affect on the attack." of this article.

If you want to understand what you are doing, read the article first and visit the repository at the end.

The come back of the Penetration Tester

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

"We have gained access as Domain/Enterprise Administrators"

A "déjà vu" ? A glitch in the matrix? No you are not reading again the "How To - Making a Pentester's "life" difficult (Part 1) ". Security is a "cat and mouse game" and now the "mouse" is back.

If you have not read the article "How To - Making a Pentester's "life" difficult (Part 1) " please read it, because I will try not to repeat my self. In any case, please read at least the "Important Notes" before blaming me that you broke something in your environment.

I remind you that 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. This is not a write-up or a highly technical article, which tries to describe the ins and outs of the attack.

Also remember that a Penetration Tester is on your side. If he can do it easily, you can imagine what a real threat with no "dead lines" and "scope" can cause. And the threat will not be on your side... If you intentionally apply these remediation actions only for the duration of the Penetration Testing in order to receive a "green report" and then you revert... well in that case let's hope you have a good cyber insurance.

Remediation Actions

Disable IPv6

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 requires that you have not explicitly disabled IPv6 .

Of course I assume that you don't have other security measures in place such as "DHCP Snooping", "DHCPv6 Guard (IPv6)", "DHCPv6-Shield (IPv6) ".

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.

Video Part 1: The victim, the attacker and the attack.

00:00 - 00:25: I assume you remember the "Responder" from the previous article. We observe that the victim in the Windows machine types the "\\secure\not", but this time the attacker does not receive the NetNTLM hashes. I remind that these hashes are printed in yellow letters in the attackers terminal. Just remember that the yellow letters in the attackers terminal is not good news for you :-) . Thankfully, in the previous article we disabled the "LLMNR", "mDNS" and "NBT-NS" and thus the attacker was not able to get these hashes, this time.

Please keep note of the following:

Victim's Workstation:
---------------------
DNS Server:              192.169.201.128
    
                          8.8.8.8

Link-Local IPv6 Address: fe80::7908::102f::96bc::26fa (One Address)

IPv4 Address:            192.168.201.129

+++++++++++++++

Attacker's PC:
--------------

IPv4:    192.168.201.1
IPv6:    fe80::250:56ff:fec0:8        

00:25 - 01:14: The attacker runs another publicly available tool, the "mitm6" . "mitm6" listens on the given interface, for any Windows machines which may request an IPv6 configuration via DHCPv6. By default, every Windows machine since Windows Vista will act as a DHCPv6 client and will request these parameters regularly (~2 minutes). The restart of the victim's computer (Windows machine) is not a prerequisite for a successful attack.

By default every Windows machine since Windows Vista, will search for a DHCPv6 server regularly. This gives the opportunity to an attacker to reply to these DHCPv6 requests and push their own IPv6 configurations, within the link-local range.        

As we observe in the attacker's machine, the "mitm6" outputs the following message:

"IPv6 address fe80::192:168:201:129 is now assigned to mac=00:0c:29:95:16:85 host=DESKTOP-OBUIGE5.zerospace.local ipv4=192.168.201.129"

That seems weird. This mac, this host and this IPv4 belong to our victim PC. The tools says that it has assigned the IPv6 address fe80::192:168:201:129 to our victim.

01:14 - 02:29: As we observe in the output of the "ipconfig" command in the victim's machine, indeed the attacker with the use of "mitm6" has pushed some IPv6 settings. Do note that the DNS server on the victim is the IPv6 address of the attacker and that indeed the victim has received a new IPv6 address.

02:29 - 03:33: Well... shit happens. A "glitch" here, a bad connection there and no patience. You can ignore that part of the video. I have just restarted the "mitm6". Nothing changed. I thought I was running in the wrong interface, but everything was fine after-all .

During an exercise something may crash or break. Usually "glitches" or a mistypo of the attacker are not going to save your day :-) . As far as the penetration tester has the experience to recognize that something is wrong with their "toys", they will find a way to make your day miserable . I didn't "cut" this part, because shit happens in real exercises too. At some point, sooner or later, this victim or another victim in the network, will try again to access a share or reboot their machine and the attacker will have to wait again.

03:33 - 04:52: Like I said... sooner or later the victim will try to access something.

In Windows, the IPv6 DNS server will be preferred to the IPv4 DNS server and will be used to query both for A (IPv4) and AAAA (IPv6) records.        

As you can recall, the attackers IPv6 has been assigned as a the victim's IPv6 DNS. Thus, whenever the victim requests a domain, the attacker will present their own machine. The victim tries to connect to the attacker's machine and the attacker grabs the NetNTLM hashes. I will repeat this from the previous article:

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 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 they) 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.        

If you watched carefully the "Responder", probably you have observed that together with the first hashes it outputs:

"WPAD (auth) file sent to 192.168.201.129"

WPAD is another story and probably we will discuss it in another article. WPAD or not, we have received more NetNTLM hashes from non WPAD requests.

Video Part 2: Disabling IPv6 via a GPO and the affect on the attack.

04:52 - 06:43: We create a new GPO which executes a powershell script during the startup of the workstations. This powershell script will disable the IPv6 from the registry. The contents of the powershell script are the following:

$regkey = "HKLM:SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Set-ItemProperty -Path "$regkey" -Name DisabledComponents -Value 255 -Verbose"        

By default, the registry HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters has the following keys:

With the powershell script, we will add the new key "DisabledComponents", as presented below:

I am not a IT Administrator and probably you have better and more efficient ways to add these registry keys.

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

Note for the time-frame 05:30 - 05:43:

05:30 - 05:43: Ignore that part. I had created the GPO before the video in order to test it and I forgot to delete it, thus I could not create a new GPO with the same name. Just pretend you never saw that time-frame :-)        

For the IPv6 to be disabled, the machines will have to be restarted, because we opt to execute this script at startup. If you don't want to restart the machines then find another way to make the aforementioned changes to the registry. For example you could execute the following command in the machines which can't be restarted:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x000000FF        

As I said, if you have better and more efficient ways to disable IPv6 with a GPO, I will be glad to update the article.

Whats is the value 0x000000FF (255)?

References:
 
https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/configure-ipv6-in-windows        

06:43 - 08:20: Why can't we receive the new policy ??? This is a work for home ( ?? ) .

08:20 - 10:14: I restart the victim's machine. I present you with the current ipconfig, the registry key "DisabledComponents" which has been added and the fact that now I can perform the gpupdate.

10:14 - end: We repeat the attack. The attacker restarts the mitm6, because they receive nothing and that makes them wonder if there is a "glitch". The victim performs their tasks, they restart their computer whenever they want to and the attacker receives nothing. We also observe that the ipconfig has not changed at all.

At this point, in our lab we had disabled LLMNR, mDNS and NBT-NS protocols (Part 1) and we also disabled IPv6. The attacker at this point, does not receive the valuable NetNTLMs.

For sure we have started playing with their nerves.

But are we secure? Probably we will discuss it at Part 3... or not.

Important Notes

Read the important notes from the previous article. Every network is unique and you may require IPv6. Ensure that you are not going to break something, because you blindly followed these articles.

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/DisableIPv6

Other references:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dhcpe/c46e5602-4d6d-4fd7-b896-f3ab1e767318

https://www.ietf.org/rfc/rfc3315.txt (mostly the "5.5.??Transmission and Retransmission Parameters")

https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/configure-ipv6-in-windows

https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-077

" b3st"