MITM6 Strikes Again: The Dark Side of IPv6
Dale Hobbs //
As the world becomes increasingly connected through the internet, cyber attacks have become more sophisticated and prevalent. One type of attack that you may not have heard of is the Machine-in-the-Middle IPv6 (MITM6) attack. In this article, we’ll explore what MITM6 attacks are, how they work, and what you can do to protect yourself and your organization against them.
What is an MITM6 Attack?
MITM6 is a type of attack that involves intercepting and manipulating the communication between two parties. In this attack, the attacker positions themselves between the two parties and acts as a proxy, allowing them to intercept and alter the communication between the parties.
One common method for carrying out an MITM6 attack is through the use of a rogue IPv6 DHCP server. The attacker can set up a rogue DHCP server and advertise itself as the default DNS server to devices on the network. When a device sends a request to communicate with another device, the rogue router intercepts the request and establishes a connection with the target device on behalf of the original sender. The attacker can then use this position to intercept and alter the communication between the two devices.
DNS Takeover attacks via IPv6
Typically, people are running IPv4 on their networks. However, IPv6 is also enabled by default on your network. If you look at the network adapter properties on your system, you will likely find that IPv6 is turned on, even though you’re using IPv4.
To top it off, IPv6 is most likely set to obtain an IPv6 address automatically from a DHCP server, but in most cases, people are not actively managing IPv6 on the network. As such, DHCP is usually not configured to manage IPv6 on the network.
This brings up the question: who or what is providing DNS services for IPv6 on the network? A majority of the time, the answer to that is nobody and nothing!
This means that an attacker can set up a system to listen for IPv6 DNS requests and respond to them by telling the client to send all of its IPv6 traffic to the attacker’s system. Often, this can allow an attacker to get authentication to a Domain Controller via LDAP or SMB.
How, you ask? Well, when an attacker’s machine is intercepting IPv6 traffic, they can intercept authentication requests, intercept the NTLM credentials, and relay them using ntlmrelayx to a Domain Controller. If the relayed authentication request was from a Domain Administrator, the attacker can then use that NTLM credential to create a user account for themselves on the domain. The best part about this is that the mitm6 tool automagically does all of this for you.
Let’s walk through what this attack looks like. First things first, you need to download and install the mitm6 tool from https://github.com/dirkjanm/mitm6. Once that’s done, simply run the tool as seen below. In my case, the domain we’re testing with is called adlab.com; you should replace it with your own domain name.
As you can see, we pretty quickly started to see IPv6 requests on the network indicating that IPv6 addressing is not managed on the network.
Next, we’re going to set up ntlmrelayx to relay the requests to LDAPS on a domain controller, send the client a fake WPAD file, and automatically dump out any information we find to a folder called ‘loot’ on the local system. As you can see below, a connection request came in, our attacking system relayed the connection attempt to the Domain Controller at 192.168.190.200, and successfully authenticated.
impacket-ntlmrelayx -6 -t ldaps://192.168.190.200 -wh fakewpad.adlab.com -l loot 
Now, if we look in our ‘loot’ directory, we can see we’ve collected a lot of information such as the computers and users on the domain, as well as the domain password policy.
This in itself is incredibly useful, as we now have a list of domain users that we could launch password attacks against. But wait… there’s more! As luck would have it, an administrator logged in to a computer on the network, and we can see that the users’ credentials were relayed to LDAPS and created a user account on the domain for us.
So now we have a user account on the domain named ‘NbuCuQKhZW’ with a password of ‘v(Zt<)J_Snii$uo’. If we look in Active Directory, we can confirm that the user account was created.
Not only did it create an account for us, but it created the account with an ACL (Access Control List) providing the user account with the ‘Replication-Get-Changes-All’ privileges on the domain. The ‘Replication-Get-Changes-All’ right in Active Directory allows you to request everything out of Active Directory including password hashes. If we look at the ACL for domain, we can confirm that the user account has ‘Replication-Get-Changes-All’ privileges on the domain.
So now that we have a privileged user account on the domain, we can use a tool like secretsdump.py to perform a DCSync against the domain controller and download all of the password hashes from the domain. (mitm6 was even kind enough to suggest using secretsdump.py).
impacket-secretsdump -just-dc-ntlm adlabs.com/[email protected]Secretsdump will prompt for the password of the user account, in this case that user account was ‘NbuCuQKhZW’ with the password ‘v(Zt<)J_Snii$uo’.
As you can see in the image above, we have successfully dumped the users and password hashes from the domain. These can now be taken offline to a password cracking system where you can use a password cracker such as Hashcat to attempt to crack the passwords.
How Can You Protect Yourself Against MITM6 Attacks?
MITM6 attacks can be difficult to detect and prevent, as they often involve sophisticated techniques and tools. However, there are steps that organizations and individuals can take to protect against these types of attacks:
- Disabling IPv6 if it is not used on your internal network will prevent Windows clients from querying for a DHCPv6 server thereby making it impossible to take over the DNS server.
- Disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC URL instead of relying on WPAD to detect it automatically.
- In order to prevent NTLM relaying you should consider disabling it entirely and switch to Kerberos or, if that isn’t possible, you should:
- enable SMB signing to prevent relaying to SMB by requiring all traffic to be signed
- enable LDAP signing to prevent unsigned connections to LDAP
- Enable extended protection for authentication which will prevent some relaying attacks by ensuring that the TLS channel used for the connection to the server is the same that the client uses when authenticating.
In conclusion, MITM6 attacks are a serious threat to the security of your communication. By properly managing IPv6 on your network, you can help protect yourself and your organization against these types of attacks.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
