volatilityfoundation
Unable to find lsa key
Describe the bug Whenever trying to use the cachedeump or LSAdump plugins - I am receiving the following error: Username Domain Domain name Hash WARNING volatility3.plugins.windows.cachedump: 'Unable to find lsa key'
Context Volatility Version: 2.0.2 Operating System: Windows 10 X64 Python Version: 3.10.4 Suspected Operating System: Windows 10 X64 Command: vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.cachedump
To Reproduce Steps to reproduce the behavior:
- Use command 'vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.cachedump'
- See error
Expected behavior Expected to get the information from the plugins extraction.
Screenshots If applicable, add screenshots to help explain your problem.
Additional information Other plugins do work - for example, Hashdump works perfectly.
I'm not sure this is really a bug. Volatility is informing you that it can't read the LSA key (which it finds from the registry in the memory, so you might want to investigate the registry plugins to try to determine why)? Specifically, it tries to open the PolEKList or PolSecretEncryptionKey keys under the security hive. If it can't find the security hive, or find those keys under it, then it will produce that error message. Without the LSA key it is unable to find the NLKM value needed to decrypt the cache, and it therefore can't continue:
https://github.com/volatilityfoundation/volatility3/blob/036698c739465afd0be0db011fbbe4a11c54865c/volatility3/framework/plugins/windows/lsadump.py#L58
Other plugins might work fine, including hashdump, which don't require the lsakey to operate. However, I would expect lsadump to fail with the same kind of error message, since it also uses the lsakey to operate.
As such, this doesn't appear to be a bug in the cachedump code, but more likely an issue with the acquired memory image. If you believe that the appropriate LSA key is present in the memory image, then we can investigate further but we'd likely need a copy of the memory image. If however you're not certain that the LSA key is present in the memory image you have then I'm afraid there's not a great deal more we can do and the recommendation would be to try to re-acquire the memory and hope thqt the LSA key is readable in the new image...
Please let us know, so we can either investigate further or close off this issue.
Wow, thanks for your prompt response.
The LSAdump plugin doesn't work as well and it prints the same error. Could it be that it's an issue of permissions when executing the memory dump from the windows machine (I am using the ftk imager for that)? are there any other tools that you worked with and it give you better results when doing the memory dump itself?
If you've got a full capture of the memory, then permissions shouldn't be enforced (I don't know of any function in windows that can explicitly filter certain chunks of physical memory, and as you said hashdump worked just fine. It's more likely either that the registry was (for some reason) not fully loaded in memory (unlikely) or that we have some issue in how we detect the registry hives, or that that particular image change mid acquisition and therefore the structures can't be rebuilt properly (not super likely, but possible).
It might be best to start by listing the hives (hivelist should do this for you) and then potentially using printkey to see if the key it should be finding is there or not. It might be the hive is missing, it might be that the key is missing, or it might be a bug in the way the lsadump plugin tries to find the key, but that's the first step to figuring out what's going on... 5:)
So, i ran both of them - registry hives command: vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.registry.hivelist
result: Offset FileFullPath File output
0xe10c7e80e000 Disabled 0xe10c7e848000 \REGISTRY\MACHINE\SYSTEM Disabled 0xe10c7e8a8000 \REGISTRY\MACHINE\HARDWARE Disabled 0xe10c81366000 \SystemRoot\System32\Config\SOFTWARE Disabled 0xe10c7e932000 \Device\HarddiskVolume2\EFI\Microsoft\Boot\BCD Disabled 0xe10c7ef47000 \SystemRoot\System32\Config\DEFAULT Disabled 0xe10c7e9ba000 \SystemRoot\System32\Config\SAM Disabled 0xe10c7e9bc000 \SystemRoot\System32\Config\SECURITY Disabled 0xe10c821c3000 ??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT Disabled 0xe10c824d9000 ??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT Disabled 0xe10c82598000 \SystemRoot\System32\Config\BBI Disabled 0xe10c82bcd000 ??\C:\Users\bill\ntuser.dat Disabled 0xe10c82bad000 ??\C:\Users\bill\AppData\Local\Microsoft\Windows\UsrClass.dat Disabled 0xe10c83cae000 ??\C:\Windows\AppCompat\Programs\Amcache.hve Disabled 0xe10c8407e000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.Windows.StartMenuExperienceHost_10.0.18362.387_neutral_neutral_cw5n1h2txyewy\ActivationStore.dat Disabled 0xe10c840e0000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\Settings\settings.dat Disabled 0xe10c84220000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.Windows.Cortana_1.13.0.18362_neutral_neutral_cw5n1h2txyewy\ActivationStore.dat Disabled 0xe10c842d2000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy\Settings\settings.dat Disabled 0xe10c84adc000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.SkypeApp_14.35.152.0_x64__kzf8qxf38zg5c\ActivationStore.dat Disabled 0xe10c84a74000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.SkypeApp_kzf8qxf38zg5c\Settings\settings.dat Disabled 0xe10c84c88000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\InputApp_1000.18362.387.0_neutral_neutral_cw5n1h2txyewy\ActivationStore.dat Disabled 0xe10c84c8a000 ??\C:\Users\bill\AppData\Local\Packages\InputApp_cw5n1h2txyewy\Settings\settings.dat Disabled 0xe10c8322a000 ??\C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\dosvcState.dat Disabled 0xe10c83349000 ??\C:\Windows\Appcompat\Programs\EncapsulationLogging.hve Disabled 0xe10c87af5000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.Windows.ShellExperienceHost_10.0.18362.387_neutral_neutral_cw5n1h2txyewy\ActivationStore.dat Disabled 0xe10c8426d000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.MicrosoftEdge_44.18362.387.0_neutral__8wekyb3d8bbwe\ActivationStore.dat Disabled 0xe10c87ad3000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\Settings\settings.dat Disabled 0xe10c90029000 ??\C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.LockApp_10.0.18362.387_neutral__cw5n1h2txyewy\ActivationStore.dat Disabled 0xe10c8aeac000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.LockApp_cw5n1h2txyewy\Settings\settings.dat Disabled 0xe10c90334000 ??\C:\Users\bill\AppData\Local\Packages\Microsoft.Windows.ShellExperienceHost_cw5n1h2txyewy\Settings\settings.dat Disabled
And the print key command: vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.registry.printkey
For the printkey command, you'll like want to supply the registry hive (in this case, the security one so -o 0xe10c7e9bc000) and that will list the top level, then you can try --key PolEKList and --key PolSecretEncryptionKey to see if they provide any results...
C:\Users\bill\Desktop\volatility3>vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.registry.printkey --key PolEKList | findstr /i 0xe10c7e9bc000
-
0xe10c7e9bc000 Key ?\PolEKList - -
C:\Users\bill\Desktop\volatility3>vol.py -f memdump_DESKTOP-GBG3PHC.mem windows.registry.printkey --key PolSecretEncryptionKey | findstr /i 0xe10c7e9bc000
-
0xe10c7e9bc000 Key ?\PolSecretEncryptionKey - -
So it means the memory capture didn't include that? if so i really need to do a re-acquisition of the memory dump?
By the way, I tried to use a memory dump from a CTF called OtterCTF and the plugin worked successfully - the memory dump was from a windows 7 machine) I couldn't reproduce that on windows 10 machines (different os builds). I know for sure that it works since I am using mimikatz to verify it on the workstation itself. any other ideas on how to understand what is the problem?
So it means the memory capture didn't include that? if so i really need to do a re-acquisition of the memory dump?
Yep, I'm afraid it does mean those keys are missing, and yes, it suggests that the memory image didn't include them. That may just mean that no LSA secrets were stored on the system, rather than that the memory image wasn't acquired correctly, or there could be something else entirely going on. You could try investigating more of the SECURITY hive to see if the rest of it seems present (you can use --offset 0xe10c7e9bc000 to limit it to just that hive). I'm not sure what else to suggest I'm afraid?
It's also possible that the plugin that was contributed only supports recovering the LSA secrets up to a particular version of windows and that Microsoft changed how it works for more recent versions? I have an image of windows 10 x64 17783 (so quite old) that works successfully though... 5:S
PS C:\volatility3> python.exe vol.py -f C:\volatility3\ram_dump\Ram_Capture_02\memdump.mem windows.hashdump Volatility 3 Framework 1.0.0
$$$"AFTER RUNNING THIS COMMAND ON THIS MEMORY DUMP I GOT THE FOLLOWING OUTPUT ALTHOUGH IT IS WORKING ON OTHER DUMPS BUT THOSE DO NOT HAVE ANY PASSWORDS"$$$
Progress: 100.00 PDB scanning finished
User rid lmhash nthash
Traceback (most recent call last):
File "C:\volatility3\vol.py", line 10, in
COULD YOU PLEASE HELP.
