INTRODUCTION
This paper will cover techniques a pen-testers can use in order to accomplish
initial foothold on target networks and achieve full domain compromise without
executing third party apps or reusing clear text credentisla. We will utilize how a
default Windows environment acts when IPv6 is enabled (which is enabled by
default) in order to perform a DNS takeover (using MITM6) and relay credentials
to LDAPs (LDAP Over TLS) with Impackets Ntlmrelayx tool to create a new
machine accounts. Using the newly created machine account we will be able
authenticate to LDAP and modify some of its properties which will allow us to
access the target machine impersonating almost any user we want (even
Domain Admins). The utilized technique is resource-based constrained
delegation and we will show a full walkthrough on it.
To achieve a full compromise of the network, we will then utilize SpoolService
bug (PrinterBug) to force an authentication from the Domain Controller to a host
under our control with Unconstrained Delegation enabled on it. Using this
technique we will be able to extract krbtgt ticket and use it to dump Domain
Controller database.
WHAT IS RESOURCE-BASED AND UNCONSTRAINED DELEGATIONS?
To simplify the concept of Kerberos delegation we can say: “it is a feature that
allows an application to reuse the end-user credentials to access recourses
hosted on a different server”.
RESOURCE-BASED CONSTRAINED DELEGATION
As described in Microsoft documentation: “Kerberos constrained delegation can
be used to provide constrained delegation when the front-end service and the
resource services are not in the same domain. Service administrators are able
to configure the new delegation by specifying the domain accounts of the frontend services which can impersonate users on the account objects of the
resource services” which means resource-based constrained delegation can be
configured on the resource or a machine account and controlled by (msDSAllowedToActOnBehalfOfOtherIdentity) attribute.
UNCONSTRAINED DELEGATION
As described by Oleg Alexandrov: “A server that is trusted for unconstrained
delegation is actually allowed to impersonate (almost) any user to any service
within the network. When a user requests a Service Ticket (ST) from a DC to a
service, which is enabled for delegation, the DC will copy the client’s Ticket
Granting Ticket (TGT) and attach it to the ST, which will later be presented to the
service. When the user accesses the service with the ST, the user’s TGT will be
extracted and saved in the server’s LSASS for later use” which means if we
control a host that has Unconstrained Delegation enabled, we will be able to
extract the TGT and reuse on any service from LSASS process.
For more details regards Kerberos delegation:
❖ Wagging the Dog
WHAT IS SPN?
A service principal name (SPN) is a unique identifier of a service instance. SPNs
are used by Kerberos authentication to associate a service instance with a
service logon account. This allows a client application to request that the service
authenticate an account even if the client does not have the account name.
For more details:
❖ Service Principal Names
❖ resource based constrained delegation abuse
❖ kerberos constrained delegation overview
WINDOWS IPV6 AND WPAD
IPv6 is enabled by default in all Windows versions from Vista and above, and
when windows boot up it started to look for DHCP configuration and then for
WPAD configuration. To apply the attack we will do a DNS takeover using MITM6
in order to redirect all the traffic to our malicious DNS server and then when
hosts start to look for WPAD configurations over DNS we will make targets
connect to our rouge proxy server and prompt targets for authentication which
we will force target machines to authenticate to our ntlmrelax server and relay
credentials to LDAPS to create new machine accounts.
FULL ATTACK ILLUSTRATION
In order to apply the abovementioned techniques and concepts, I have prepared
a virtualized environment which consist of a Windows Server 2012R2 (Domain
Controller), a client host running Windows 10 (Mark-pc), an AppServer running
windows 10 and our kali box (Attacker). We will assume that the attacker
machine is the same subnet.
ATTACK DEMO
As we mentioned above, we will assume that our attacking machine (kali) is in
the same subnet with our targets. We started the attack by simply doing an SMB
signing check using CrackMapExec since it is required that SMB signing is
disabled to successfully apply the attack.
CrackMapExec can be downloaded from the official repository here:CrackMapExec
or using pip to install it by executing this command:
apt-get install crackmapexecwe started the attack by checking our machine IP configuration:
Then executing CrackMapExec to check for SMB signing and detect live hosts:
So now we know that the internal domain name is “contoso” and we have
detected three live hosts which two of them has SMB signing off (Domain
Controller has SMB signing enabled by default). What we will check as last
peace of the puzzle is if the LLMNR and NBT-NS name resolution is disabled or
not, to do so I will run responder for just a minuet and check if we catch any
requests.
As we can see in above screenshot that responder started to catch and
response to LLMNR and NBT-NS name resolution which means that it is not
disabled.
7 | P a g e
Also since we are creating new machine account we need to check if the LDAP
over TLS (LDAPS) is configure, to do so we will use Nmap to scan the DC for port
(636):
Now since all the requirements for the attack are satisfied, we will execute the
attack using both MITM6 framework and Impacket ntlmrelayx to relay captured
credentials to LDAPS and create a new machine account from the captured
credentials. In order to successfully apply the attack, you need to whitelist
specified targets that you think their machines will be rebooted (client machines)
while our MITM6 server is running in order to redirect traffic from targets to our
rouge DNS server.
To facilitate the attack, I have whitelisted Mark-pc and I will initiate the reboot
from that machine in my environment.
And execute ntlmrelayx targeting LDAPS on the DC as follow:
Once Mark-pc has rebooted, we will see that it has been assigned an Ip from our
rouge DNS server and as you can see in the screenshot below that the IPv6 DNS
server is preferred over IPv4 DNS .
If everything went as expected we will see ntlmrelayx start picking up the
credentials and try to attack LDAPS on the Domain Controller.
Once ntlmrelayx successfully authenticate to LDAPS using relayed credentials, it
will try to create a new machine account using those credentials and modify the
“msDS-AllowedToActOnBehalfOfOtherIdentity” on Mark-pc to allow the newly
created machine to impersonate any user on it.
So how is it possible to create a new machine account in the domain using the
relayed credentials? It appears that any user in active directory can create up to
10 machine account.
And by browsing the domain controller users and computers, we can see that
the attack has been successfully executed and ntlmrelayx added a new machine
Also ntlmrelayx will dump domain information if we connected to LDAPS using
the relayed credentials (ldapdomaindump).
Now since we have the machine account credentials and we modified the
“msDS-AllowedToActOnBehalfOfOtherIdentity” propriety, we will use Impacket
getST.py script to request a service ticket to access Mark-pc impersonating
domain admin privileges (contoso\Administrator).
As we can see above that we successfully requested a service ticket using the
machine account credentials with impersonation of “Administrator” and it is
saved as CCACHE file.
Bear in mind that we can use previously dumped domain information to
understand which users belongs to which group.
Now we will add the CCACHE Kerberos ticket to “KRB5CCNAME” environment
varialble using “export” command as follow.
export KRB5CCNAME=/root/Desktop/Administrator.ccacheand we use Impacket Wmiexec to achieve command execution with Domain
Admin privileges. Note that the CIFS SPN is only valid to access file shares (ex.
using Smbclient) but Wmiexec will attempt to automatically changes the SPN to
one that we can use to execute WMI quieres and commands which is HOST SPN
Once everything is ok, a semi-interactive shell will be opened with the privileges
of “contoso\Administrator”
We can use the Kerberos service ticket with Impackt SecretsDump to dump local
hashes
And for example we can use lsassy to remotely dump cleartext credentials using
the local admin hashes
After we gained our initial foothold on the network, we will try to fully
compromise the target network we will look into the dumped information from
ntlmrelayx to find any interesting things.
13 | P a g e
We can see here that AppServer is configured with unconstrained delegation
which means that if we compromised it we can export the tickets stored in
memory and reuse it or we can use the SpoolService bug to enforce the DC to
connect to AppServer then use its TGT to dump the DC database.
We tried to reuse the local admin credentials over AppServer but with no luck
since each machine in the environment is configured with different local admin
password.
So back to our domain information dump we found an interesting domain group
“Servers Admins”.
In order to find the members of this group we used bloodhound.py (find it here)
with mark credentials and imported the data to Bloodhound
Using Bloodhound queries we found that Mark-pc$ machine account is part of
“Servers Admins” group
So we will try to pass Mark-pc$ machine account we obtained from
Secretsdump and using CrackMapExec we will check if we will got any access
on AppServer.
As we see in above screenshot, we have successfully authenticated to
AppServer using Mark-pc$ machine account, so now using Impacket Wmiexec
we will pass the machine account hashes to obtain command execution on
AppServer
Since we are running with local admin privileges we will use Secretsdump to
dump local hashes because we need machine account Kerberos keys for the
SpoolService bug
Now we will add a new SPN to AppServer using krbrelayx addspn (project can
be found here) tool, we added the new SPN in order to make our victim (in this
case it is the DC) to look for that SPN and redirect its traffic to our rouge
krbrelayx server.
Using AppServer machine account to add new SPN (HOST/attacker1.contoso.local)
to AppServer$
Then using krbrelayx dnstool.py, we will add a new DNS record for the newly
created SPN (attacker1.contoso.local) on DC DNS that will point to our kali
machine
So after waiting for a while until the DNS is updated, we issue an Nslookup on
attacker1.contoso.local to make sure that it resolves to our kali box ip
Now we wil setup the krbrelayx servers with AppServer machine AES265 key in
order to capture the krbtgt TGT as follow
Then using printerbug.py (can be found within krbrelayx project) we will enforce
the DC to lookup for SPN HOST/Attacker1.contoso.local which will trigger a
callback to our kali box since the DNS record points to it. We used AppServer$
machine account for authentication.
upon a successful execution we will receive and capture the krbtgt TGT on our
krbrelayx server which will be decrypted using the AppServer$ machine account
AES256 keys then it will be saved as CCACHE format.
Now we will add the CCACHE file to our environment variables using export, and
use Impackets secretsdump to dump domain controller database.
So now we have all the NTLM hashes for the contoso domain accounts, we could
use Impacket wmiexec utility to pass the hash and obtain a shell on contoso DC.
MITIGATION
As demonstrated with abovementioned techniques, we have exploited the default
configurations that ships with fresh installation of a windows environment in
term of relaying credentials and DNS takeover. The mitigation for such attacks
we need to disable LLMNR and NBT-NS name resolution also enforcing LDAP
signing and LDAP channel binding for LDAP over TLS. As for the part were we
used the printerbug, try to avoid using unconstrained delegation whenever is
possible and to disable printer Spooler Service or blocking outbound 445 port
connection on critical systems.
Source:
Stay connected