Last Updated: 2019-04-26 16:35:30 UTC
by Rob VandenBrink (Version: 1)
In our "pretend pentest" that we've been running these last few days, we've now got all the domain admins listed, all the service accounts found and listed, and the intersection of those two things - the service accounts that are either local admin or domain admin.
So what's the obvious next step? Let's recover the passwords for those target service accounts! Because once we have the full credentials, we have admin rights that no SEIM or systems admin will be tracking the use of - these accounts are almost universally ignored, since they login every time those services start (say during a system restart). So if this is for instance a service account with domain or local admin rights that's on every server and workstation, you are now "better than domain admin". You have all the rights, but no system controls are watching you!
Let's get on with the job at hand.
First of all, credentials for service accounts are stored in the local registry, as what's called "LSA Secrets" in the registry key HKEY_LOCAL_MACHINE/Security/Policy/Secrets. Because the service needs to read the actual password to login as the service account, that password is in the registry in clear-text. Yup, you read that right - this is why service accounts are such a great target. LSA Secrets are well protected however, you can't just fire up regedt32 and read them - only the SYSTEM account has rights. So you need ... yes, some powershell! Not only that, many of today's tools are based on some powershell posted way back in the day on microsoft.com!
(Thanks TrueSec!! In fact, thanks from all of us! )
Or if you're not in the mood for PowerShell, you could use some Python tools, or Metasploit or Mimikatz works too - choose your own adventure! Often you'll need to try a few different methods, and then maybe wrap one in some "AV evasion" code to make it work for you, but the results are worth it in the end!!
Those original scripts from microsoft don't work on modern hosts with any patches applied at all, but of course there's a toolkit that's improved on these scripts over time. I generally use Nishang for the PowerShell-centric "I'm on the box" approach to LSA Secret recovery
Nishang can run locally on the Windows host being targetted, or you can of course use PSRemoting. The problem with this tool is that if there's an AV product in play anywhere in the chain, it will very likely have a problem with you running Nishang. In fact, even downloading this on a Windows host with a default install (ie - with W10 Windows Defender in play) can be a problem.
Anyway, once it's installed, the execution if pretty straightforward:
> Import-Module .\nishang\Gather\Get-LSASecret.ps1
Name Account Secret ComputerName
Metasploit of course has a module for this. You can run it locally or (more likely) remotely. The module is post/windows/gather/lsa_secrets.
Because endpoint protection programs tend to focus so much on Metasploit (which of course tells us just how good this tool is), you need to be careful where and how you run it if the goal is to get this job done with any degree of stealth. You'll want to put some up-front work into evading whatever your client has for AV - this work pays off in all kinds of ways if the pentest you're running is longer than a few days. This method does a great job though, even though (depending on the module you're running) it'll tend to scream at the AV solutions "Look! Look at me! I'm running Metasploit!"
The MetaSploit method is a simple as "run post/windows/gather/lsa_secrets"
For me the most attractive thing about using Metasploit is that you can script the exploits. So if you need to, you can run 4-5-6 exploits against hundreds of machines in one go.
You can dump the LSASS process memory and recover service passwords (and a ton of other stuff too) from that, but that becomes less and less reliable over time as Microsoft puts more fences and protections around LSASS. I've never had to go this way on a real engagement. The easier method is to run the MimiKatz PowerShell Module and just watch the magic happen. That is if you put the work into evasion against your endpoint protection solution to allow MimiKatz to run.
Impacket makes a great little python based tool to accomplish the same thing. This is my first, go-to, it almost always works method - mainly because all you run on the target host is standard windows commands, then the rest of the attack is on the attacker's host. This makes it the least likely of these methods to trigger any AV alerts or other security measures.
First, from the local host we dump the 3 registry hives that are in play:
reg save hklm\sam sam.out
reg save hklm\security security.out
reg save hklm\system system.out
Now take those files and get thee to your Kali VM! If you don't have impacket installed yet (it's not in the default install), there's no time like the present. To install:
$ sudo apt-get install python-dev python-pip -y
$ pip install --upgrade pip
$ sudo pip install pycrypto pyasn1 pyOpenSSL ldapdomaindump
$ git clone https://github.com/CoreSecurity/impacket.git
$ cd impacket
$ sudo python setup.py install
(in most cases you don't need all of those pre-reqs, I put them all in just in case). Now you're good to go:
impacket-secretsdump -sam ./sam.out -security ./security.out -system ./system.out LOCAL
(you'll find a bunch of other interesting security stuff in this tool's output - all the local account password hashes for one thing!)
At the bottom of the output, you'll see what we're looking for, the locally stored password for that service account!! In this case I put a "fake" account on my SFTP server service (Solarwinds SFTP doesn't have a service account by default).
That's it - no fuss, no muss, and best of all, nothing to trigger AV or any similar "endpoint next-gen machine-learning AI user behavioural analysis security" product on the target host.
Other tools like CrackMapExec do a good job as well - I haven't used that one specifically yet, really the impacket method has done the job for me so far. While I tend to have a "try one or two new things" or "write one new tool" rule for each test, I haven't gotten around to using any other tools for this particular thing.
Do you use a different tool to dump service passwords? Does your tool collect more useful information than just that particular thing? Or maybe you've got a cool AV evasion that relates to this? Please, use our comment form and share your experiences on this!