We’ve all been there.
An end user has a problem with their computer or needs manual installation of some software. Either we elevate with an admin account logged on as the end user, or we switch user and are logging on with our admin account.
Far too often, the admin accounts used to help out end users, are very privileged accounts, 2/5 times I see this at my customers those accounts are Domain Admins.

Why is this a problem? Well, first of all, you should never expose very privileged credentials to “non trusted” computers. Secondly, at the time you log on, your credentials are exposed and can with Benjamin “gentilkiwi” Delpy’s tool mimikatz be extracted in clear text through the lsass process.

Ok, but the user is not local admin, so they will not be able to do it anyway? That is true, but far too many let end users be local admins, and of course there are ways to get around that if you’re a non admin user as well.

Example:
The end user Aaron that has been privileged enough to get local admin rights on his computer. He puts the powershell-script Invoke-Mimikatz.ps1 as a task to run at logon for all users.

In this example, I’ve just put in the row below in at the end of the script to dump the credentials to a file on the c-disk. This could of course be dumped anywhere if you wanted to.

Invoke-Mimikatz -dumpcreds | 
    Out-File -Append  c:\evilplace\$env:computername.txt

Effect:
Now, when his fellow administrator logs on to his computer to help him with some software installation, the admin credentials will be dumped to a file and Aaron is from now on Domain Admin!

Scary? Yes!
Lesson learned: Think both once and twice before logging on with privileged credentials to non trusted computers.

This is of course nothing new, it’s been out for quite a while. Look in to the following matrix that clarifies when this is an issue or not (in most cases it is…:( )

/Johan