Pillaging Password Managers with UI automation

in Pentesting on autoit, post-exploitation Last modified at:
Pillaging Password Managers with UI automation

Using UI automation & keystrokes to extract credentials from password manager vaults.

Background

I’ve already written about the reasons that made me pick up and start playing with AutoIt in a previous blog post. This post is about one of the sillier side projects I worked on while tinkering with UI automation.

Like a lot of people, I use password managers to secure and organize the credentials for the variety of online services I use. I also use multi-factor authentication (MFA) to add an extra layer of security to my password vaults.

As a pentester I’ve often been in situations where I’ve extracted login credentials from users, usually saved in their browsers (Chrome, Firefox, Edge etc). Some of these credentials have led to easy wins. But in some cases, they’ve led to me burning my access when I login to a site only for the user to receive an unexpected multi-factor code on their phone and change their password not long after.

These thoughts eventually led to me asking myself - if someone with remote access to my PC was somehow able to come across the master password I use for my password manager, how could they use it to pillage all the sweet credentials I store in my password vault without having to login and trigger the multi-factor mechanism I use?

UI automation

The simplest answer I could think of was “they could just click on stuff and dump all my vault creds”. I’m already logged into the password manager desktop app on my PC, so no MFA code would be required and if they had access to my master password then they’d have all they need to dump all the credentials in my vault. Since I was already learning the basics of UI automation with AutoIt for other reasons, I decided to spend some time on this little detour.

A brief definition of what UI automation is and why it exists from perfecto.io can be found below:

UI automation testing is a technique where these testing processes are performed using an automation tool. Instead of having testers click through the application to verify data and action flows visually, test scripts are written for each test case. A series of steps to follow when the verifying data is then added.

In a nutshell, UI automation is programmatically interacting (keystrokes, mouse clicks etc) with graphical user interfaces for any number of reasons; which is usually to automate software testing, but in this post is to extract creds from password managers.

Notepad automation demo AutoIt simplifies UI automation on Windows.

Probably not the best idea

Using a scripting language like AutoIt or AutoHotKey to interact with GUIs is the equivalent of walking up a user’s PC and using their keyboard and mouse to type into/click on windows on their desktop. Doing this remotely, say over a C2 channel, is bound to raise a couple of red flags.

There are also a bunch of gotchas, failure conditions and many unknowns that come up when automating UI interaction on a system with an active user on it. So this stuff should be right at the bottom of your “things to try on my next pentest” list.

Better alternatives

There are other publicly available alternatives offering more reliable techniques to pillage password managers that don’t rely on any form of UI interaction. I’ve listed some of the tools/research that I know about below:

Now that I’ve rambled enough about how terrible of an idea this entire journey was - let’s get into it, shall we?

Password managers

I had to pick a password manager to test my scripts on and eventually settled on 3 apps to use; KeePass2, Bitwarden and 1Password. I picked these 3 simply because they all have desktop apps for Windows and they’re all free (1Password requires a subscription, but offers a free 2 week trial period).

Password managers

I figured that using more than one app would create a diverse set of scenarios and conditions to experiment in.

Acquiring the master password

The techniques in this post assume we already have access to the user’s master password. There are countless collection techniques that could be used to get this data in the field; keylogging, clipboard monitoring, clipboard history, credential phishing, dumping logins saved in web browsers and more.

NOTE: The reason we need the user’s master password is because most password managers require it to be entered before authorizing the vault’s contents to be output to disk.

Credential Extraction

The general methodology I stuck to while scripting the password extraction was:

  1. Figure out the shortest possible route using a keyboard (and mouse where necessary) to successfully dump credentials from the password vaults to a cleartext file on disk (most password managers support this output format).
  2. Script the steps above in AutoIt.
  3. Print the extracted output file to console.
  4. Delete the extracted output file.
  5. Restore the password manager to its original state (minimized and/or locked).
  6. Troubleshoot issues and script workarounds for failure conditions.

After each attempt at credential export, I’ll list the issues that could lead to the script’s failure as well as the red flags that could alert a user to something fishy going on.

NOTE: None of these techniques will work while a system’s screen is locked since the program windows have to be active/in focus as the UI interaction occurs and screen lock prevents that.

1. KeePass2

I’ll start with KeePass2 because it was the easiest to dump credentials from. By default, KeePass2 doesn’t require the user’s master password to write the vault’s creds to disk - so all we need is to know the right keyboard shortcuts and keystrokes to input in KeePass2’s window to get our output file.

KeePass2 cred export 1 View in fullscreen.

Issues/red flags đŸš©

  • The script only works on an unlocked password database/workspace.
  • We can’t tell if the user is actively using their PC or idling. NOTE: Idle time would be the best time to execute because it reduces the chances of the script’s execution being broken by user activity.
  • The extraction process is completely visible to the user.
  • The extraction would fail if the user interrupted it by clicking on another window or pressing any key on their keyboard.

The first issue I was able to figure out was the user idle time detection. I found this post on the AutoIt forums and added the example provided into the KeePass script. The script will now pause execution until no keyboard and/or mouse activity has been detected for a specific number of seconds (3 seconds in the screen recording below).

KeePass2 cred export 2 View in fullscreen.

Let’s take a look at our issues & red flags again; 1 down, 3 to go:

  • The script only works on an unlocked password database/workspace.
  • We can’t tell if the user is actively using their PC or idling.
  • The extraction process is completely visible to the user.
  • The extraction would fail if the user interrupted it by clicking on another window or pressing any key on their keyboard.

2. Bitwarden

Bitwarden took a few extra steps since it requires the user’s master password to authorize credential export to disk. I also intentionally locked Bitwarden’s workspace before attempting execution; creating the need to deal with password prompts in the script.

Bitwarden cred export View in fullscreen.

For some reason, bringing Bitwarden into active focus with WinSetState or WinActivate wasn’t working reliably. So I had to modify this piece of code to send a mouse click event to Bitwarden’s tray icon on the Windows task bar and force its window into the foreground.

Bitwarden tray icon Send mouse click event to Bitwarden’s tray icon.

Issues/red flags đŸš©

Now we can deal with password prompts. 2 down:

  • The script only works on an unlocked password database/workspace.
  • We can’t tell if the user is actively using their PC or idling.
  • The extraction process is completely visible to the user.
  • The extraction would fail if the user interrupted it by clicking on another window or pressing any key on their keyboard.

3. 1Password

1Password’s credential export was pretty similar to Bitwarden’s. Click on the app’s tray icon and use the appropriate keystrokes to write the vault’s contents to disk.

1Password cred export 1 View in fullscreen.

But we still have the 2 biggest issues to deal with; our user can see everything that’s happening on screen, and even if they weren’t paying attention, they can still intentionally/unintentionally interrupt the extraction process by typing or clicking on anything else while the script is executing - leading to a failed cred dump.

The solution?

The idea for this “fix” came to me when I accidentally came across AutoIt’s BlockInput function.

BlockInput function

If we have local admin rights on a system, we can effectively block all keyboard and mouse events aside from the ones being sent by our script. So
say we:

  • Take a screenshot of the user’s active desktop.
  • Display this screenshot as a fullscreen image in the foreground.
  • Block all keyboard and mouse input.
  • Initiate the credential export process behind the on-screen screenshot.
  • Restore the user’s desktop as well as keyboard and mouse input once execution is complete.

If these steps go according to plan, all our user would be able to tell is that their PC inexplicably froze for a couple of seconds. While in the background, our script is busy raiding their password manager app for loot. If it’s stupid but it works?

Let’s take a look at how this actually plays out in practice. I opened a bouncing red ball GIF on the left side of the screen just so it’s possible to notice when we’re displaying our makeshift “smokescreen” desktop to blind the user.

1Password cred export 2 View in fullscreen.

Nice - it worked. There is some slight flickering on-screen, but nothing that screams “your password vault is being raided!”. Since the password export doesn’t take too long (around 10 seconds), the system freeze shouldn’t overstay its welcome. So hopefully our user won’t think anything too sus is going on.

Some caveats

  • This workaround comes at the cost of requiring local admin rights on the target system.
  • There’s also a very high chance of the extraction failing and the system freeze lasting until it’s manually killed. So use this with caution. Or preferably not at all :)
  • It’s possible to break out of the forced input block with [CTRL+ALT+DELETE]. Remember that if you’re testing this in your lab and lock yourself out of your own box 😉

Issues/red flags đŸš©

If we combined all the fixes so far into a single script, we should take care of all the major issues that I could think of. There are bound to be others that I didn’t think of or didn’t have to deal with in my limited testing.

  • The script only works on an unlocked password database/workspace.
  • We can’t tell if the user is actively using their PC or idling.
  • The extraction process is completely visible to the user.
  • The extraction would fail if the user interrupted it by clicking on another window or pressing any key on their keyboard.

Conclusion

Even though I had a blast messing around with the UI automation shenanigans in this post, I still don’t think they’re viable techniques to apply in real world assessments. There are just too many unknown variables and unforeseen failure conditions to deal with when automating Windows UIs outside of a controlled environment.

I should also mention that none of this was a dig at any of the password managers I was testing these scripts against; they’re all great and if you aren’t already using a password manager, then now’s a great time to start.

If you’d like to try and of this out, I’ve uploaded all the scripts demonstrated in this post to the OffensiveAutoIt repo on GitHub.

References

© 2022. VIVI.