How to Extract Passwords from the Browser?

Hands up if there’s someone here who has NEVER EVER stored a password in a browser… Honestly, I don’t think such human exists — we all did it at some point. So, how safe is it, really?

This episode of CQURE Hacks Weekly is about all the different ways that passwords can be extracted from different kinds of browsers (Internet Explorer/Edge, Firefox, or Chrome). If you are interested in how those passwords are stored, that’s a subject for you.

I would like to show you two types of browsers and how the password is stored. I would like to show you what the storage depends on. We will start with Edge. Since this a relatively new browser in Windows 10, it’s important to know whenever we are storing a password in Edge, where is it, and how this is happening.

Storing password from the Edge

In Edge:

  • we go to Settings,
  • we go to Advanced Settings,
  • here you’ve got an option which is called Offer to save passwords,
  • And then you can go to Manage my saved passwords,
  • here, you’ve got information about the certain type of passwords being stored.

How to extract password from the browser?

But obviously, we’ve got some little dots over here and that is actually quite interesting – it’s a P-@-s-s-w-0-r-d-#-1-2-3-!, so these dots correspond to the password. You can see basically what that is, more or less, by a number of letters but we are not able to guess at that moment. If you are wondering how to get those passwords, you can always go to Credential Manager and Web Credentials. Here you can see the password. Right now, I am authenticated but normally, you will be asked for providing the password over here.

How to extract the password from the browser? Go to Manage Web Credentials

Let’s get into Manage Web Credentials and as you see, I got this one and that’s what I’m talking about. I’m gonna specify here, the password, and that’s the moment I’m able to see the password.

This access is clearly dependent on the current user’s password and therefore it’s so important to take into consideration how this password is changed. For example, this machine that I’ve got right now, it is in a very, very special state because I have been playing with cached logon data and I’ve changed a user password illegally. Basically, I have changed the cached logon data (some people call it cached credentials), and then a user was able to logon with the password. In this case, Mimikatz for example, and previously my password was just P-@-S-S-W-0-R-D.

How to prove this to you that this kind of data is dependent on your password? Of course, underneath, there’s a big Data Protection API platform that is managing the access to your secrets, but since this is a very short tutorial, I think we can stop on that kind of explanation.

Using ChromePass

I also have here ChromePass. ChromePass, it’s a tool that you can get from Nirsoft, a very nice set of tools that you can download for free from the Nirsoft website.

I was mentioning previously that your passwords (like this in the browser) depend on your logon password. They may not always be. For example, you can have a root password or a master password. The same story is with Firefox. Firefox can do stuff like that too but if we are not using those, then our password is this point of entry on there.

Master Key Containers

Over here, we’ve got ChromePass and I have a password of the user stored like that. As you can see here, the password is not really displayed and the question is: why is that?

And the answer to that is quite simple.

It is because, in such a scenario, I have played with that password change illegally. So when we are thinking about the Data Protection API, technically If we get into C:/Users/Username/AppData/Roaming/Microsoft/Protect and then UserSID, then these little files (we should call them, Master Key Containers) contain the master keys, which more or less are used to decrypt our secrets, passwords, etc. Master keys that are in those Master Key Containers are encrypted by the user’s password hash.

Effectively, when I played with the password and it’s no longer my password P@ssw0rd but it’s Mimikatz, then I’m not able to decrypt those. I’m unable to read this particular password. Now what I’m going turn on the network connectivity and connect to the domain controller.

What’s going to happen? Well basically, that particular user will connect to the domain. Right now the network is on, so the only thing we can do is to logon with the password that is correct. Right now, I am logging on with the password that is Mimikatz, so I’m going, simply speaking, log out, and logon into the domain.

Credential Manager works a little differently for Edge than for Chrome

I’m going logon to the domain. Hopefully, this should all work out right now. We’ve got a password, P@ssw0rd. The next part I will do, is to get into ChromePass, for example, and as you see, without any problem, I am able to see the user’s password.

What about the other password that I was playing? So let’s get into Credential Manager for Web, and I got this stuff. Here, I will be providing the password. So we’ve got over here the P@ssw0rd#123! visible but this one wasn’t visible before and it’s visible right now, which proves one little thing, that Credential Manager works a little differently for Edge than for Chrome.


Chrome, in this case, purely relies on the Data Protection API, which isn’t bad by the way, it’s just that these types of credentials are a little bit different. Both depend on your password to the operating system. If your machine is not connected to the domain, that is also quite an interesting case in the case of Data Protection API, then your passwords stored like that, using Data Protection API, depending on your password hash as we already mentioned. We could be thinking, “A flaw in that, it’s not a good idea ’cause we all can grab MD4 from the SAM database.” Well, yes and no. You can always do that, but this particular, or these particular secrets are protected with SHA-1 of your password, especially for local accounts, so I mean the ones that are not connected to the domains. That is quite interesting over here.

For the accounts that are connected to the domain where we don’t store any hashes on the computer. Cached Credentials are not storing hashes, just for reference if you are wondering. Then, in the case of a domain, we use MD4 to protect this kind of secrets.

This is a little bit of a summary of how passwords are stored in the browser. If you are a geek, then please try the same stuff for Firefox and I’m waiting for your questions in the comments section below because it’s a very long subject and I’m pretty sure we’re gonna have a lot of different types of episodes about it.

So that’s about it. I hope you enjoyed it and don’t forget to leave your comments on our blog post and also on our Facebook page. If you want to learn more on how to extract users and system secrets, check out our new intensive training: User & System Secrets: Cybersecurity Data Extraction.