Discussion on Domain Credential Extraction
It's been a while since I have posted anything, and today I ran across a Tweet and had a conversation that I thought would make a perfect subject. It begins with "A mini thread: I periodically see folks suggest that to prevent weak passwords you should dump AD and compare the hashes against known bad passwords. DO NOT DO THAT. Let me explain." - @SteveSyfuhs
https://twitter.com/SteveSyfuhs/status/1290673649070911488
Let me start by saying that I apologize if I seem to ramble a bit. This blog is very... organic. If I tried to properly format and organize every post, I would never get anything out. I would rather post imperfect content than nothing.
I do agree with some points Steve makes and I'll try to note those as I go along. This isn't meant to be some form of rebuttal, but as I stated in the conversation, I don't believe that dumping/testing passwords should be completely thrown out. I do believe there is value when used for the right reasons, and I also believe that planning and care need to be taken in this process.
Tool Concerns
Let's start unpacking all of this. The first four tweets and several other statements during the conversation call into question the tools being used, if you would be willing to run them as domain admin, and if you would be willing to risk a BSOD on a domain controller.
Questioning the tools being used for this is 100% correct. However, in several of my replies, I suggested a method that makes this very much a moot point. My short answer to several of these questions was "it doesn't matter". I wouldn't run any tools on a production DC, I wouldn't run them as domain admin, and I don't trust them.
Obtaining Necessary Files
In order to get the hashes associated with user accounts, you need two files, the SYSTEM hive, and NTDS.dit. I wrote a blog post about that here https://nullsec.us/extracting-domain-credentials/. Please keep in mind this is a 5-year-old post. While I trust FTK Imager, it is made by a legitimate forensics company and not a "hacker tool", there are better ways I have learned about since then.
You can use Volume Snapshot Service (VSS, aka Volume Shadow Copy) to extract these files on a live system (https://www.alttechnical.com/knowledge-base/windows/101-map-shadow-copy-as-drive). This is part of Windows, built in, and does not require any third-party tools. If your DC's are in a virtual environment, you could also clone one, disconnect all networking, and start it up and use FTK Imager (or another tool, such as KAPE) without worrying about bluescreening the system. In a physical environment, you could add a new domain controller, allow it to sync, and then remove it (physically and logically) from the environment and use this to grab the necessary files. The TL;DR here is that there are multiple ways to obtain these files without ever running third-party tools on a production system as a domain admin. I'm sure there are other creative answers as to how to obtain these, each with varying degrees of safety and security that may or may not be appropriate for any given environment. None of this is black or white, safe or unsafe, secure or insecure. As always, your threat risk model is not my threat risk model.
Moving These Files
Moving on, we have obtained these files in a way that I feel is secure enough for most environments, and at the very least it avoids the three largest concerns put forward. Now we have an encrypted file containing hashed passwords, and a file containing the key to decrypt these hashes. How do we move them to a more secure system? I would ask, how do you currently move very sensitive files? A fresh/trusted USB makes sense to me, because it can be physically destroyed (crushed) after being moved. Depending on your risk model, you may be willing to trust a TLS system, or move it directly to the other system via SMB. You can also consider separating the NTDS.dit and SYSTEM file from each other and moving each over a separate medium. Each is useless (in terms of obtaining hashes anyway) without the other.
Extracting Hashes
First, let’s address the tool trust issue I left behind in the first section. The system that you moved these hashes to should be physical and airgapped from the start. At this point, tool trust very much takes a backseat. I'm not worried about crashing the system, I'm not worried about a malicious tool exfiltrating the data, and I'm not worried about corrupting a live system.
My blog post above describes one way to extract these hashes, using libesedb and esedbxtract, but again, there are better ways now. Impacket's secretsdump.py would be my current go to https://github.com/SecureAuthCorp/impacket/blob/master/examples/secretsdump.py
"secretsdump.py -system <path_to_system_hive> -ntds <path_to_ntds.dit> LOCAL"
What Do We Do With These Hashes
"Whatcha gonna do with that? Upload it to some scanning site? Compare against a known bad list you've downloaded? Using what tools? Where? How?"
Let's be clear, there are many points I agree on, and the sensitivity of these files are certainly one of them. Under no circumstances should these hashes be uploaded anywhere; the air gap should solve this. As for what tools, hashcat is the obvious choice here. Usage goes outside the scope of this post (but here's a good guide from 13Cubed). I think we've also answered the where and how questions. This leaves the question “What we are going to do with this?” This will be the longest part.
Another thing I agree on here: this isn't a preventative measure, nor is it a mitigation. If we find weak passwords, they're already being used -there has been no prevention. You should have a clear goal going into this. As an example, you might go looking for service accounts with weak passwords. If you've inherited an environment with a large number of these and no documentation, there would be obvious benefits to knowing the password before making changes to the account. If the password can't be cracked, you may be able to assume it's safe (for now, prioritizing proper fixes later). If it can be cracked, it could be changed. Any change that breaks something could be reverted by changing back to the known password. You may also look for passwords below X length. For example, if you've changed your minimum length from 8 to 14 characters and allowed enough time to pass that all passwords -should- have been rotated. Now audit against that.
Part of my point is that just because you -could- crack all the passwords, does not mean you -have- to crack all passwords, nor do you have to go after actual users. What you are effectively doing is shining a flashlight in unknown corners. Does what you find there match what should be there? It often does, and this is the grey area that pen testers and attackers play in. These areas should be audited, not just on paper (this change should have occurred), but in actuality (this change DID occur. And here is the proof).
Lastly, there is also an option to discard current hashes and only crack historical hashes. The argument here is that these passwords are ones that cannot possibly be in use (assuming you have “Enforce Password History” set). Again, you should have a clear idea of what you are auditing. If your business has policies banning "password incrementation" (e.g. Spring2020, Summer2020 or Password1, Password2, etc.) you may look for these. These patterns are often hard to catch with rules and banned password lists (some users are creatively lazy).
We've accomplished our goal, now what?
I mentioned moving this to a physical air gapped system above, that's because we're going to physically destroy the drive of this system, along with any other raw data (e.g. the pin drive we used). In my example, three copies of the data exist . One on the DC in the shadow snapshot (which belongs there). One on a pin drive, and one on a physical hard drive, both of these are being physically destroyed. I saw this compared to storage and disposal of nuclear waste. I don't think this is an appropriate analogy, as nuclear waste cannot be smashed with a hammer.
I don't feel this is safe/I don't trust the process/I don't trust my people to properly destroy the data/I don't trust them not to move it to google drive just to make things easier.
As I said above, there are many shades of grey concerning security. If your definition of safe is 100% secure with the promise of nothing going wrong, then no, none of this is safe. That said, I believe I've presented reasonable methods that are safe enough. If you don't trust them, then don't move forward. If you don't trust your people... you have bigger problems, but don't move forward.
What about legal/philosophical concerns.
I believe these are beyond the scope of this post. These concerns must be addressed by management, HR, legal, and/or other appropriate entities. It must be done with your policies, company culture, and applicable legal regulations in mind. There may be very valid reasons to never proceed forward with this. That doesn't mean that there is no situation where it should never be considered.
What About Other Methods of password control? 2FA, technical controls, breach monitoring etc.
These are methods of preventing or mitigating poor passwords, not auditing for or discovering weak passwords. As was pointed out by others, MFA can't be used to protect every service, legacy accounts may have been set before controls went in place, and admins can set passwords that don't comply with policy. That said, all of these things should be examined and set as part of a defense-in-depth or comprehensive security program. I am by no means saying that these are not a good idea. I simply believe that they do not exclude or replace the benefit of this type of audit. I also believe that it would be wise to have a mature security program in place prior to skipping straight to “dump hashes, crack passwords”.
What about scalability?
It's probably not ¯\_(ツ)_/¯ at least not as I've described it here. Someone on twitter mentioned seen a rig dedicated to 24/7 cracking and automatic password rotation and email. I don't know how they accomplished this, and I'm scared to ask. I'm sure there is an enterprising solutions architect out there (you know who I’m talking to) that could design a way, but I think he's going to shun me for a month for even thinking about it. However, it also isn't a terribly painful or expensive process and could be repeated reasonably often if you for some reason had a decent case to do so.
Wrap-up
I said in the thread that I could not provide proper details in 280 character chunks. Right now, in draft form, this post is 9,947 characters, or a bit over 35.5 tweets. It will undoubtedly grow as I continue editing the draft, addressing things I missed, and getting feedback prior to publishing. If this gains any kind of attention, someone will point out flaws, produce new arguments, or have additional questions. My point is that even at over 10,000 characters (now), this isn't enough room for discussion. If you undertake this, the discussion on how to safely proceed and what the goals are will (and should) be much longer.
Looking back at this blog, I believe I had statements I was trying to make:
1) To propose a method of extracting and auditing these hashes that is considered safe (not 100% safe, but reasonably so).
2) To argue that there are valid reasons to do this. Not necessarily for everyone, but that the idea shouldn't be summarily tossed out, especially not for the reason it was unsafe.