In this two-part blog post, Ill be taking a look into attacks password managers to improve my knowledge on techniques which can be used against them. To start with, I will take a look at local password managers by looking at the sort of techniques which can be used against KeePass. The second post covers some attacks against LastPass.
Ill start by covering some generic attacks against password managers (Both local and cloud-based), before moving onto KeePass-specific attacks.
Generic Password Manager Attacks
Monitoring/Grabbing the Clipboard contents
We can do this within Cobalt Strike using the
clipboard command. This is only a point-in-time grab of the data, and will not actively monitor it!
We can also use Mimikatz to do this with
misc::clip, but this is way overkill for most situations
If we are feeling patient (or want to coerce the target into opening their password manager), we can grab the master password by keylogging their system to capture the main password.
Now lets look into some KeePass-specific attacks. This was all performed against v2.52 which was the latest at the time! This was installed with all the default settings, and the
TopSecretStuff.kdbx file is using a password of ‘
And lets add a password or 2 to our KeePass database
KeeThief is another great tool from GhostPack. It was originally released 7 years ago and targets .NET 3.5, which meant I had to install the framework on my test system. For real-world usage, make sure you adapt this to your target environment!
I then had to combine the
Microsoft.Diagnostics.Runtime.dll DLL into the KeeThief executable and make the entry point public to avoid getting an “
Invoke_3 on EntryPoint failed” error in Cobalt Strike. To do this, I used
ILMerge which was downloaded as part of building KeeThief. Using the csproj file from KeeThief for guidance, the final command was:
PATH_TO_KEETHIEF\KeeTheft\packages\ILMerge.2.14.1208\tools>ILMerge.exe /target:winexe /targetplatform:"v2,C:\Windows\Microsoft.NET\Framework\v2.0.50727" /target:exe /out:test.exe "PATH_TO_KEETHIEF\bin\Release\KeeTheft.exe" "PATH_TO_KEETHIEF\bin\Release\Microsoft.Diagnostics.Runtime.dll"
I also did the same for the associated PowerShell file which this should produce, using the command:
PATH_TO_KEETHIEF\PowerShell>powershell -exec bypass -File Out-CompressedDll.ps1 KeeThief.exe KeeThief.ps1
The commands are covered in the README of KeeThief
Finding KeePass files
Using the pre-built
KeePassConfig.ps1 file, we can hunt in a system for KeePass XML files. These XML files contain the configuration data for KeePass which we will modify later on as part of an attack!
Stealing the master password from memory
We can now simply run the KeeThief tool against our system, and so long as KeePass is running, we can steal the plaintext master password. Notably KeePass just needs to be running on the system and be unlocked with the main password – a pretty typical arrangement for most users who use KeePass!
We can also do this using the
KeeThief.ps1 script if we want to throw it back to 2017, with the
From this point, we could steal the
TopSecretStuff.kdbx file, and interact with it away from the host.
Backdooring the trigger system
As mentioned in an older Mandiant report, KeePass includes a ‘trigger’ system which can be exploited. In short, this trigger system allows specific actions or commands to be run when specific criteria are met in KeePass. Mandiant’s example is to dump out the KeePass DB whenever KeePass is opened. On the 23rd January 2023, CVE-2023-24055 was released for this, but is disputed by KeePass.
As covered in the comments of
KeePassConfig.ps1, we need to pipe the output of
Get-KeePassConfigTrigger for it to work.
This didn’t work with me, after a bit of debugging I believe the structure of the KeePass config has likely changed since the tool was created, or the tool had revealed a false positive file. Below is an example of the error within the
After manually creating a Trigger on the target system, the
C:\Program Files\KeePass Password Safe 2\KeePass.config.xml file had not changed and was essentially an empty XML file
<?xml version="1.0" encoding="utf-8"?> <Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Meta> <PreferUserConfiguration>true</PreferUserConfiguration> </Meta> </Configuration>
This would explain why PowerShell was throwing an error, as there were no XML elements for it to add nodes onto! With a bit of hunting, I found the file at
We can now pipe this file path into
Find-KeePassConfig and then into
Add-KeePassConfigTrigger like so:
"C:\Users\vagrant\AppData\Roaming\KeePass\KeePass.config.xml" | Find-KeePassConfig | Add-KeePassConfigTrigger -Verbose
We can confirm this by looking at the
KeePass.config.xml file after running the command
Before we restart KeePass, note that there are no files in the
After signing into KeePass, a file named
TopSecretStuff.csv is dropped into the folder
Which we can open to reveal our passwords
We can then remove our configuration change by running
Cracking A KeePass file
The above attacks have relied on us compromising a system where the user is either actively using KeePass, or will routinely use it. What if we come across a user which only infrequently uses it, or find a
*.kdbx file on a share?
For this, we can use the
keepass2john executable from John The Ripper – which is built into Kali. If you are using a different OS, then Harmj0y has made a Python script to do this!
We now have our hash:
Looking at the example hashes from Hashcat (Mode 13400), we can see that we will need to remove the database name ‘
TopSecretStuff‘ from the beginning of this string
We can then run Hashcat using mode 13400 to try and crack this
hashcat.exe -a 0 pass.txt rockyou.txt -m 13400
Additional Persistence Methods
Something which I read about, but didn’t attempt was obtaining persistence via the KeePass plugins, which is covered by
@two06 on Medium, they also have another post which covers another way of abusing the trigger system to execute arbitrary code, in a similar way to KeeThief’s persistence method.
In my second post in this series, I will take a look at LastPass as an example of a cloud/browser-based password manager!