Intro Welcome to another post from the research group! As usual, we'll be talking about a new attack vector that we found and, better yet, one that can be reproduced in the real world. This time, we're exploring how to abuse installed browser extensions to extend our access on a compromised machine. It's post-compromise because initial access is lame :D. Motivation The true motivation for this research was the new (now not so new) Changes to remote debugging switches to improve security . Nowadays, most attackers aim for the identity of the user instead of the machine itself, and for that, they need to compromise the user's session. One of the most common ways to do that was simply retrieving cookies from the browser. But then App Bound Encryption came along, and attackers shifted to abusing the remote debugging protocol. Ngl, it's kinda funny that Google closed the gate but forgot to install the fence... But alas, the remote debugging protocol was then restricted to non-default profiles only. If you wanted to use it, you had to create a new profile, which would for sure raise some eyebrows, and you wouldn't be able to retrieve those tasty cookies from the user's actual session. And that, folks, is where we started our research to find a way to retrieve those sessions >:). The bad workaround After reading the new changes to the remote debugging protocol, we took a full 0.25μs to try to abuse Microslop's Directory Junctions in order to trick Chrome into thinking the default profile was actually a non-default one. We know we could have just read the source code and seen how the check was being made, but first, nobody has time for that, and second, our hands were already typing the command to create the junction. So we balled. The bypass that wasn't (but kinda was) What came out of that was that the check won, BUT we found something interesting tho. We gotta be honest: at first we thought the bypass worked, but that was only due to the weird behaviour attached to the junction creation. When you create a junction, you make a softlink to another folder. The original folder still exists, and if you try to access it, it just redirects you to the new one. However, when used with Chrome, the browser won't present you with your previous session. Instead, it creates a new session but with your previous preferences (bookmarks, extensions, etc.). The most interesting part came when we tried to log in to a website with the new profile. We were able to log in successfully and retrieve the cookies from it (nothing new here, yet). But when the junction was later removed, the original profile remained logged in with the sessions created through the junction. HMMMMMMMMMMM... The attack chain So we had a way: Create a junction to the default profile Fool the user into using this profile by changing the taskbar shortcut Remove the junction and flee with our tasty cookies The scuffed part of this attack is that when the shortcut was launched, Chrome wouldn't stack the icons and would just create a new one... but hey, it was a start. The weird behaviour can be seen in the video below, and a small tool was created to automate the process. You can find it here . The good strategy After the junction adventure, we started probing other ways to get the same access as the user but without relying on cookies (we are on a diet now). For this, we took a step back, not on the viewpoint, but literally on the session creation. From cookie theft to credential theft Users tend to log in to their machines with the usual bad passwords, and for years passwords.txt or creds.xls have been a fun way to get credentials out of compromised users. But nowadays, with the rise of password managers, users tend to store their credentials in there. Some password managers even allow users to store MFA codes, which is pretty neat but also kinda removes the M in MFA. Oh well, we're not here to judge. So we thought: what if we could just steal the password manager data? Enter the extensions And that is where extensions come into play (we know we took 700ish words to get here... but ʕ •ᴥ•ʔ with us). Most password managers have a browser extension for easier access to credentials. Users don't want the hassle of opening the password manager app, searching for the credentials, and then copying and pasting them, they just want to click the extension, search, and auto-fill. Pretty neat, but it also opens a new attack vector. When you open the UI of an extension, it's rendered in a separate process from the browser, running with the same privileges as the user. That UI may contain structured data, such as the credentials the password manager is displaying, and that data can be exfiltrated if an attacker manages to access it, this is due to the fact that extensions weren't really designed to handle sensitive data. We can go on and on about how the browser in itself is just patchwork to make something that wasn't designed with security in mind a lil bit more secure, but ...