Detecting Mimikatz Use On Your Network

Published: 2015-02-10
Last Updated: 2015-02-10 20:01:56 UTC
by Mark Baggett (Version: 1)
8 comment(s)

I am an awesome hacker.  Perhaps the worlds greatest hacker.  Don't believe me? Check out this video where I prove I know the administrator password for some really important sites! 

(Watching it full screen is a little easier on the eyes.)

OK.  I lied.   I'm a fraud and I'll concede the title of greatest hacker to those listed at's charlatans page.  I didn't really hack those sites.  But I certainly did enter a username and password for those domains and my machine accepted it and launched a process with those credentials!  Is that just a cool party trick or perhaps something more useful?  What happened to those passwords I entered?

The /netonly option for the runas command is used to launch a program as a user that exists on a remote machine.   The system will accept the username and password for that remote user and create an authentication token in the memory of your LSASS process without any interaction with the remote host.   With this option I can run commands on my host as the administrator of the domain without having to actually know the password for that account.   Sounds dangerous?  Well, it is not really.   The command that you run doesn't really have any elevated access on your machine and with an invalid password it is not a threat to Microsoft.  Windows doesn't try to authenticate to the domain to launch the process.  It assumes that the credentials are correct, calculates the hashes and stores them in memory for future use.  At some point in the future, if you try to access a resource on that domain it will automatically use windows single sign on capabilities to "PASS THE HASH" to the remote system and log you in.  But until you try to access the remote network, the passwords just sit there in memory.

The result is a really cool party trick and an even cooler way we can detect stolen password hashes being used in our environment.   You see, those fake credentials are stored in the exact same location as the real credentials.  So, when an attacker uses mimikatz, windows credential editor, meterpreter, procdump.exe or some other system to steal those passwords from your system they will find your staged "Honey Hash Tokens" in memory.   It is worth noting that they will not see those hashes if they use "run hashdump", "hashdump" or any of the other commands that steal password hashes from disk rather than memory.  However, that is not uncommon unless the attacker is on the Domain Controller and it will not raise suspicion. 

Let's try it out and see how this deception might look to an attacker.   First, I ran the following command to create a fake administrator record:

runas /\administrator /netonly cmd.exe

Then, when prompted for the administrator I can provide any password that I want.  In this example I typed "superpass".   Now, let's create an account for root on the domain Yes, I know that is absurd.  The absurdity demonstrates that you can put anything in LSASS you want.  You can even use this to post snarky messages taunting the attackers if you want to live dangerously. (Not Recommended)  Here is what you type to create those credentials.

runas /\root /netonly cmd.exe

Once again, when prompted for the root user's password, I can enter anything I want.  For this example I choose "notreallythepassword".   You will need to leave those command prompts running on your system to keep the credentials in memory.  That is something a careful attacker might notice, but I'm betting they won't.  Next, I ran mimikatz to see what an attacker would see and this is what I found:

You can see both the hashes and clear text passwords sitting there just waiting for a hacker to find them.   But these hashes, unlike all the others, will not get them anywhere on my network.   This powerful deception can be exactly what you need to detect the use of stolen passwords on your network. 

Here is the idea.   You stage these fake credentials in the memory of computers you suspect might be the initial entry point on your network.   Perhaps all the computers sitting in your DMZ.    For a great deception my friend Rob Fuller (@mubix) is toying with the idea of putting this into the logon scripts to stage fake workstation administrator accounts on all the machines in your network.  Then you would setup alerts on your network that detect the use of the fake accounts.    Be sure to choose a username that an attacker will think is valid and will have high privileges on your domain.  So rather than\administrator you might try [yourdomain]\SuperAdmin. (unless, of course, you are Microsoft)

That's the idea.  I hope it is helpful.

UPDATE: The name "honeytokens" was originally coined by Augusto Barros way back in 2003.   Although I called them "honey hashes" there have been some other cool names suggested.  I like Rob VanderBrinks name of "Credential Canaries".   Other suggested names include "password phonies" ,"lockout logins" or  "Surreptitious SATs" but in the end they are just another type of honeytoken.

Mark Baggett      Follow me on Twitter:@markbaggett

Like this?  Interested in learning how to automate this and other common tasks with Python?  Join me in Orlando Florida April 13th   Attackers and Defender will learn the essentials of Python, networking, regular expressions, interacting with websites, threading and much more.   Sign up soon for discounted pricing.



8 comment(s)


I like the part when you said, "Lets hack the Bank of World".. That's awesome.
Are you honey hashing me? I think this guy is honey hashing me.
Mark you should register a trademark for "honey hash" immediately!
I am curious on how long these stay in memory. Until reboot or ...?
Since these are stored in memory, I'll assume they are flushed when the computer is restarted. I put the following line in a .bat file (ps1 would work as well) and deployed it as a login script via Group Policy:

echo "SuperSecretPasswordGoesHere" | runas /user:DOMAIN.COM\Super.Admin /netonly ipconfig

I choose ipconfig instead of cmd.exe just so the cmd.exe process isn't left running. Assuming a host is compromised by an attacker, the attacker could check the login scripts and see this is being run at login. He may or may not understand the purpose. If he understands the purpose, then he may be more cautious with post exploitation. If he doesn't understand the purpose, then he is likely going to try using the user name and password.

Event ID 4625 is logged in the Security event log when a login fails. You can specify a scheduled task to run a PowerShell script when this event is fired to check if the attempt was for the Super.Admin account. The script could then send an email notification (and/or syslog message) if the attempt was for the Super.Admin account. Both the script and the scheduled task can be deployed with Group Policy.

I can post an example script if anybody us interested.
So I take it nobody watched the video? He says the hash is dumped from memory as soon as the CMD process exits. You have to leave it running, an ephemeral process won't work.

[quote=comment#33435]Since these are stored in memory, I'll assume they are flushed when the computer is restarted. I put the following line in a .bat file (ps1 would work as well) and deployed it as a login script via Group Policy:

echo "SuperSecretPasswordGoesHere" | runas /user:DOMAIN.COM\Super.Admin /netonly ipconfig

Did you test this and confirm it works? If so, given that the credentials only stay as long as the process is running, can you explain how it works, since I'd think that the credentials would leave lsass as soon as ipconfig finished.

Also, in my testing, this doesn't work for getting the password in. If I run the runas manually, I can see the password with mimikatz as long as I have the cmd window open. But if I try to pipe the password in, mimikatz shows the user but with a blank password.
I changed my script to run cmd.exe instead of ipconfig.

Diary Archives