Cached credentials in windows - what remains after logoff?

Hi experts.

While testing countermeasures against the famous hacking tool mimikatz, I stumbled upon something I cannot explain: following https://github.com/thomhastings/mimikatz-en
Mimikatz uses admin rights on Windows to display passwords of currently logged in users in plaintext
It says "currently logged in" - not more. However, I noticed, it could even display the passwords of all users that logged on today! OS: win7x64 SP1

Please let me assure you that caching of credentials is turned off (cachedlogonscount=0, verified at HKEY_LOCAL_MACHINE\SECURITY\Cache) and all password safes (credential manager) are empty!

Where does mimikatz get the passwords from? In other words: what part of the credential cache windows uses survives a logoff?
I noticed, that only after restarting the computer, these caches are emptied and can no longer be attacked.
LVL 61
McKnifeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nick RhodeIT DirectorCommented:
I think what it is refering to is the domain cached credentials.  This can be disabled but this is what you will take a hit from.

If you disabled the caching, if lets say a mobile user takes his laptop home, he will not be able to sign into his system and will recieve this error "The system cannot log you on now because the domain *domainname* is not available.

The only way the user can log is locally or if the server is present.  This feature allows for users to login to their workstation (as long as they have at least logged into the domain one time while on the domain) to be able to sign into the machine wether the domain is available or not.
0
Rich RumbleSecurity SamuraiCommented:
WCE too http://www.ampliasecurity.com/research/wcefaq.html
Nonetheless, this is how windows does single-sign-on, the creds are not plain-text in memory (again in the lsass.exe process), but are protected in a reversible way.
I blame IE first: http://technet.microsoft.com/en-us/library/cc778402%28v=ws.10%29.aspx

This will "explain it" more than i can...
http://www.slideshare.net/gentilkiwi/mimikatz-phdays

Also, if you can make a minidump of the lsass.exe process, and copy it off the box, you can then use mimikatz (alpha) to get the same data you're looking at now.
Why it's not expunged I don't know, it might be after the kerb-ticket expires, I don't know how "garbage cleanup" works for windows cred's.
-rich (I initially translated mimi to en)
0
Rich RumbleSecurity SamuraiCommented:
It's all part of a process, if you use new creds on that box, I'm sure the old ones are updated, but how long those stay on I've never bothered to see. I know of exactly what you speak, we had a user long gone, and her machine had a great up time, and I found her credentials weeks later. The cached cred's has to do with the SAM db not so much with the SSO "back alley" M$ made.
-rich
0
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

McKnifeAuthor Commented:
Hi Nrhode.
You did not  read the italics, did you?
Hi Rich.
please convince me that we really talk about the same thing: did you reboot her machine before you found those or not?
0
Rich RumbleSecurity SamuraiCommented:
No it was not rebooted, hend the good uptime :) They do not survive a reboot, I know that for a fact, and it's interactive logon's only, where the windows GINA is used.
-rich
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
McKnifeAuthor Commented:
Ok, so passwords stay in the RAM after logoff. That's really bad news for me.
Very likely I will soon open a new thread about 2-factor-authentication and/or one-time-pw.

Just wanted to make sure the author I quoted used wrong wording writing "currently logged in" and it's not our fault.
0
Rich RumbleSecurity SamuraiCommented:
Just remember that 2-factor applies almost exclusively to interactive logons. not \\ip.ip.ip.ip or wmi, powershell, and other network level authenticators (psexec). "Pass the Pass" works very well there, and I believe I read on a thread somewhere that the RSA token is in lsass too. Pass the hash and pass-the-pass work even in 2 factor env's provided it's the network level.
-rich
0
McKnifeAuthor Commented:
Thanks for confirming.
0
McKnifeAuthor Commented:
0
Rich RumbleSecurity SamuraiCommented:
But supposedly 8.1 is worse? It's a tragic "hole" to begin with, and M$ refuses to break backward compatibility or to stop supporting RFC's they've always supported since back in the day, 16 years this has been available. While mimikatz doesn't inject into the process, it could potentially do so and get the keys. I refuse to use windows 8 because I'm an old fogie, and that new fangled goodness looks horrid to me :)
-rich
0
Rich RumbleSecurity SamuraiCommented:
http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx Is supposed to address the issues you were asking about, however the mimikatz author has stated that this fix might not work against US target OS's as intended. https://twitter.com/gentilkiwi/media I've seen that the PT hash is not available even when you are not fully logged off, meaning if you have a RDP session, and you end the session but don't log out, the PT pass is not present, but the hashes and tickets are. The PT pass comes back once you have reconnected to the same RDP session.
-rich
0
McKnifeAuthor Commented:
Thanks, but it will never restore my belief in computer security again (and that was gone before mimikatz already). I'd have t get in too deep to understand all that findings of the kiwi guy. Hopeless :)
0
Rich RumbleSecurity SamuraiCommented:
Yeah the golden ticket is really bad... and I don't know that it can be fixed. I'm trying to understand it's magic, but so far it works better than P-the-H.
-rich
0
McKnifeAuthor Commented:
Did you see this tut. on golden tickets? http://blog.cobaltstrike.com/2014/05/14/meterpreter-kiwi-extension-golden-ticket-howto/ - it holds no fix, but of course tells you that changing the pw for the account (and service) krbtgt will break golden tickets.
0
Rich RumbleSecurity SamuraiCommented:
Yep I have, and we've adapted to use IPSEC connections in production and critical systems that use pre-shared keys that have cut lateral movement down. We could use FW rules, but having the connections encrypted was an added bonus and no 3rd party pentester we've hired even knew you could use those filters. Seems people forgot about them.
-rich
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.