I’m spending a lot of time with mimikatz lately. I’m fascinated by how much capability it has and I’m constantly asking myself, what’s the best way to use this during a red team engagement?

A hidden gem in mimikatz is its ability to create a trust relationship from a username and password hash. Here’s the mimikatz command to do this:

sekurlsa::pth /user:USERNAME /domain:DOMAIN /ntlm:HASH /run:COMMAND

The sekurlsa:pth command requires local administrator privileges. This command spawns the process you specify and modifies its access token. The local Windows system will still think the process was run by your current user. The parts of the token designed to support single sign-on will reference the username, domain, and password hash you provide.

If you use the above to spawn another payload (e.g., Meterpreter, Beacon); your actions that attempt to interact with a remote network resource will use the username, domain, and password hash you provide to authenticate.

In practice, spawning a new payload to pass-the-hash is a pain. It’s much easier to spawn a bogus process (e.g., calc.exe) and steal its token. Beacon’s steal_token command will impersonate a token from another process. The token stolen from our bogus process will continue to reference the username, domain, and password hash you provide. Any actions to interact with a remote resource, while Beacon holds this token, will pass the hash for us.

Let’s assume I have a foothold in a target environment and I’ve elevated my privileges. Here’s how I’d use this for lateral movement with Beacon:

1) Run hashdump to dump password hashes for the local users.

2) Run mimikatz sekurlsa::pth /user:Administrator /domain:. /ntlm:… /run:”powershell -w hidden”

We do powershell -w hidden to create a process without putting a Window on the desktop. Mimikatz doesn’t hide Windows for the processes it creates.

3) Use steal_token 1234 to steal the token from the PID created by mimikatz

4) Use shell dir \\TARGET\C$ to check for local admin rights

5) Try one of the lateral movement recipes (wmic, sc, schtasks, at) from this blog post to take control of the system.

To get a feel for how this works, I’ve put together a video:

This method of pass-the-hash has several advantages over traditional pen tester methods. Which advantage resonates with you will depend on the situations you face.

When I work with a mature network defense team, I try to avoid non-asynchronous communication. This means I can not speed up my Beacon to tunnel PsExec or another Metasploit module through my Beacon. This interactive communication will get caught right away. This plays well with an asynchronous post-exploitation workflow.

This method also gives me a great deal of flexibility. I’m relying on Windows to pass my credential material for me. What I do to interact with a remote network resource is up to me. If I’m only interested in data, I can list and copy files via a UNC path to the target. If I want to execute code, I have options beyond the service control manager to do so. When dealing with a mature target, this is important.

Finally, I prefer to use native tools over hacker tools to carry out my actions. I favor native tools because they blend in better and they’re more likely to work consistently. This method of pass-the-hash caters well to this preference.