Cookie Monsters in your Browsers: Cookie Exfiltration for Hungry Hackers

Welcome everyone. My name is Andrew Gomez. Uh if you're interested as a red teamer, a blue teamer, or just interested in cookies in general, you've reached the right talk. I'll be going over a variety of tools that I've made for cookie exfiltration uh here for Besides Augusta. So we'll continue on to the next slide. Maybe, maybe not. All right, there we go. Uh, with me today was supposed to be Entarog guy as well. Thank you. What's this? >> Okay, thank you. Uh, was supposed to be with me today was Entuy. He's also a consultant at Spectre Ops and his GitHub handle is Antro Guy. Um, we'll publish at the end a list of repos that we ended

up putting all our tools to, but that's one of the GitHub handles that you can reference uh for referencing some of the tools. Uh, he couldn't make it today. His flight unfortunately got cancelled from Colorado. um some sort of weather was going on up there, so that sucks for him. But I'm Andrew Gomez. I helped do some of the research behind this. Uh and my GitHub handle is King of the Knops. I work at Spectre Ops as a consultant, and prior to that, I did some DoD work with the Army uh while I was commissioned. Uh as far as what we're going to be covering today is just some background information about what cookies are, how

we can go about borrowing them, how they're being stored and encrypted uh back in the past versus what they're doing now. Uh and then how we do we ultimately get access to that cookie jar because it is a inuse file so it's locked. Uh and then we'll go into some demos and detections during each part of this presentation. I split it up into four parts so we don't just sit there and look at encryption schemes the entire time. We get some nice little mental breaks there. And then finally um some additional research that Antio had done was pivoting into Entra or into the cloud. Uh using specific cookies in a way to access things that might be

restricted via conditional access policies. uh he wrote a tool that helps you kind of finally select what client you want to interact with and receive a JSON web token for. And then we'll have room for some questions. As far as what triggered or what inspired all of this research, it came down to just doing daily ops. Um we would land on workstations and we established persistence, but then next thing you know, we're like, "All right, we need to do some reconnaissance, potentially even elevate our privileges. Where do we go from there?" Uh, and that vicious cycle kind of rinses and repeats it repeats itself over and over again until eventually you access whatever the objective is, that highv value target.

Let's say you're in a medical facility and you need to access PHI. Well, what we started to run into is sometimes that PHI isn't on a server they own and maintain. Sometimes it's on a website that they interact with, they log into, and just key logging and stealing a password wasn't enough because they had MFA locked up behind that. Uh, so then came the research behind cookies. Um, and a lot of previous research had already been done up up to that point. Uh, but Chrome started changing how things work. Um, and that's what I kind of want to highlight here is um, some of that research that we've done to kind of utilize cookies post authentication,

post ex uh, post initial access uh, and ways to utilize it not just to access your targets, but even potentially to use it for something like additional reconnaissance and lateral movement. A little bit of background primer on what cookies are. Uh essentially when you go to log in, you're not having to log in every single time you access a different page. It keeps track of your session. It makes that browser experience personalized to you. So it keeps that information. Um and then where does it store it on a Windows operating system? Well, stores it in two locations. That login data database as well as the cookies database. Login data is specifically related to the passwords. Has anyone ever logged into a

website and had a little popup that says like do you want to save your password? Yeah, it's a little bit annoying, but uh you can either accept or decline. And if you do accept it, it pops up in your login data database. And hopefully I can convince you to stop using that as a way to store your passwords by this talk and use a password manager instead. Um and then the other location is the cookies database. You can kind of see the structure of both those uh databases in the screenshots there. Um it's a little hard to see, but specifically in the login data as well as the cookies database, the encrypted value you see

starts with V20 or potentially even V10. And that's for the old encryption standard. Um, so we'll dive into what that means more here in a bit. I mentioned things are being encrypted and stored in all these weird ways. I promise we're not going to do a deep dive onto how the encryption is actually working. Just as a really basic highle overview, all this information is being stored and saved using DP API or the data protection API on Windows operating systems. Essentially, your password is derived and utilized to encrypt information with keys. And there's two pieces or two keys that are being utilized in the Chromium browser uh in order to uh save your encrypted key that is then

used to encrypt your cookies or your passwords and that is your password as well as the computer's password. So just think about it as there's potentially two keys that are being utilized. And the way an adversary would interact with those uh keys um is through the crypt 32 uh DL specifically using crypt protect or crypt unprotect API calls. Uh and that'll be relevant later on when we get to the detection aspect. Uh I had mentioned they're being stored. Um there's a key used to encrypt additional cookies or even your passwords and all that's being located in a file in your local state. Um that's inside of your local app data directory. And two pieces of an information are being saved there.

An appbound encrypted key which is what we're now utilizing. Um or your encrypted key. Uh I guess technically both of them are still being utilized uh in some environments where you're using a roaming profile because your system is constantly changing. It resorts to using your encrypted key rather than the appbound key. And I'll explain that why in a little bit. And then if you've ever stored a password or hit save as on that login previous to your Chrome and Edge version one I believe 20 it'll have all that information stored using the version 10 uh encryption which will use your encrypted key rather than your appbound encrypted key. And so why did Chrome or Google implement all these

changes? Uh so starting back in chrome one uh chrome 80 uh several years ago at this point um everything was being stored uh prior to that in clear and then now we started storing stuff in an encrypted manner. Um and the only thing really protecting the key itself from other people or other adversaries was the fact that it was encrypted with essentially your password but because of the API calls you could utilize anyone could essentially decrypt it without having to necessarily know your password. They just need to be operating under the context of you. So imagine getting initial access through a fishing campaign. You land on someone's box as let's say beacon.exe. You could decrypt

that password. You didn't need to actually know. You could decrypt that key. You didn't actually need to know their password. Uh and so what Chrome decided to implement is an applicationbound key which now requires two forms of keys. um one is going to be your laptop or your hardware's um master key and then one's your password and all that information is being implemented and stored uh inside of an elevated service or the elevation service and they also restricted as far as who can interact with that elevation service. So now malware can't simply just perform a process dump of Chrome to retrieve the keys. uh and now malware can't just simply interact with that elevation service in order to decrypt a key. They

have to specifically be operating under the context of Chrome or in the application path of a Chromium based browser. So in the case of Edge that's also a chromium based browser. Uh same thing with Brave and a few other operating systems or not operating systems browsers. Uh one of the ones I mentioned that doesn't count would be Firefox. That's not a Chromium based browser. Um and so essentially they helped kind of move those goalpost farther along and moved the detection opportunities uh in the favor of defenders because now it's very specific. Only one specific either folder or application should be able to retrieve these keys. Um and so what that ended up leading into is some of this research where I

was like well how do you interact with this decrypt decrypt data com object? How does that work as a user? Can I recreate it as an admin? and we'll go into what that looks like. And then after a couple of uh months of banging my head on a keyboard and wondering like why the heck is this working, why is it not working? Realize there's also much more simpler ways to retrieve cookies. You don't have to um try to become system on a box. you could just launch Chrome with your own debugger port and then request via Chrome API calls uh the cookies or even load your own malicious extension manners that are a lot less um

difficult and sophisticated but also a lot easier to detect and we'll break down what that looks like. Um but first let's get into how the decryption works from the context of an application. So I mentioned Edge and Chrome are both Chromium based browsers. When the browser wants to decrypt that key used to encrypt passwords and cookies, it's going to go through the elevation service and it's going to send that key to the service where the first time it goes, it's going to decrypt it as system and then it's going to impersonate the user that called the comm object and then decrypt that key once again as the user. At that point, if you were a

malicious adversary, you would just want back the output. The output in this case would be the application path as well as the key used to save or in this case to encrypt cookies and passwords. But if you're the actual legitimate elevation service, uh you do something called an applicationbound validation, which essentially that elevation service is saying like all right, who requested this? Who's trying to decrypt this information? Um, and ultimately as long as you have the same path of the application folder, it returns the key. So you don't necessarily have to operate as Chrome or Edge, you just have to be in the same folder that Chrome and Edge lives in. Uh, which is important later

on. Um, as I went about finding all this information, how does the decryption work was simply just it wasn't any fancy reverse engineering. I was going to the Chromium uh source code and just reading through it uh and for any sections that I didn't understand, chat GPT helped out and helped kind of break it down and ultimately broke down to that red box and that yellow box. The red box is where the validation service is occurring and how I discovered that hey, it's just checking the path. It's not actually checking what process is performing the decryption um and then returning the key. Unless you happen to be Chrome, then it goes into this very specific post-process data. Um, where it

unfortunately the key that's being returned actually it does another layer of encryption and I'll kind of break that down later on. Um, but essentially only in instances of Chrome is there a third level of encryption being implemented, a third key per se. Um, and so I mentioned, hey, this information when you receive back the key looks like it's the application folder followed by the key. Uh, while I was creating the proof of concept, I just kind of wanted to see what did that blob kind of look like. And you can kind of tell it's a little blurry and hard to see. Um, but in the red box, that blob of information that's returned begins with that

application path. So as long as I run out of the context of program files Google Chrome or program files Microsoft Edge, I could decrypt those keys. Um, which then became the question of like how do I become Chromium? Well, in one instance, you could probably write to that folder, but you would need administrative access and that might not be likely. Uh, which marks out both the ability to write your payload to that folder as well as deal hijacking opportunities. Uh the next method we were looking into was process injection. Uh but nowadays that's become pretty noisy and being caught by EDRs fairly frequently. Uh so then came the third option of comm object hijacking which is

the preferred method uh for myself. Uh let's say you happen to socially engineer someone you land on their host and you want to maintain persistence as well as try to live inside of the Chrome or Edge process because you're trying to blend in a little bit into the environment with some of your C2 traffic. Well, one thing you could implement is COM object hijacking. Uh, essentially a COM object is like an API call within the Windows operating system in order to access or interact with other components inside of other executables or DLS. Um, and so all that information is being stored inside of the registry keyhive. And what happens is your operating system will actually check your current user keys

before it checks the local machine keys. Um, and so in that top uh screenshot that we have, and this stuff's really blurry, or it's my eyes, one of the two. Um, you'll see that there's the direct manipulation DL being used for this weird gooid. And that's the com object that's being called. Well, whenever that gooid's being called, instead of loading the direct manipulation DL, we can trick the operating system into loading our DL. In this case, I created the testing stub. DLL. uh and we can use it to perform additional actions and then proxy the real app or API requests to the real comm object in order to avoid breaking the actual application. And so

the process of going around and looking for these com object hijacking involves utilizing a tool called procmon uh or process monitor. Uh in this case I'm looking for registry key events where name is not found and I'm looking for instances of things in relation to chrome or edge. Uh, and if I set all those filters, I end up with events like this. So, for some reason, the browser is trying to when I, in this case, opened a new tab was trying to call this com object. And so, I saw that as a prime opportunity to essentially live inside of Chrome or Edge. Um, and we'll go on over to the next slide. Uh then came the problem of like well if it's

calling it let's say 10,000 times in a minute I don't want 10,000 beacons. I could potentially crash crash the operating system or even my C2 C2 platform if it can't handle that many callbacks. Uh so then came some requirements when I build that stub DLL. The first one being a mutex. Uh essentially we want to make sure that the first time our DL is called it only runs once. every other time just forward over the API calls to the real DLL or to the real COM object and then exit out of my current uh DL or unload from there. We also want to make sure that uh we only want to run or we only want to load

our shell code when it's the actual target browser application. Um and then uh yeah, the last part is really proxing the necessary DL exports to the right target. In regards to what that looks like in some C code, here's some little snippets. Essentially, we're looking, hey, what is that operating or what is that process that just loaded me? If it is Microsoft Edge or Chrome, then let's create a um mutex that says, hey, only load me once. And then eventually, let's load our actual payload, something like loading um our DL. Um, and so how do we go about creating those exports? You can utilize other tools uh like face dancer to create the exports and then copy and

paste the output to the top of your DLL stub in order to ensure that we're not breaking the actual functionality of your Windows operating system. Uh which I've done quite a bit during this research. Um so it's really important to implement that. Uh in regards to preventing it or even detecting it, we'll get into the detections after this. Um when Chrome version 127 came out, that's when applicationbound encryption was released. In addition to that, they added an additional Chrome Enterprise policy called dynamic code settings where essentially a DLL or process can't just allocate read, write, execute regions of memory. Um it's going to block it from doing it if it's unsigned. And so you can

actually implement these registries or these policies to kind of prevent stuff like com object hijacking. Or in addition to that, let's say you're unable to implement that policy for whatever reason. Um, one of the opportunities for looking for this activity, including process injection, would be looking at your sysmon event IDs. Um, in this case, event ID 12 and 13 will help you look for registry key creation and modification events. And you can fine-tune that to your environment as needed. Um, and so now we'll kind of jump into what all that looks like, tying it together. So at this point, we should We'll look at trying to become the Chrome process as well as implementing or using the sorry struggling over here

with technology. Here we go. What does all that look like together in order to retrieve some cookies? So the first part of this demo is me I already set up my com object hijacking. I'm just going to show that the um browser is logged in as myself on mugglehackers.com. I'm logged in as a global admin inside of venture ID and I've set that uh com object hijacking DLL to something that I had compiled locally on the host and we see that Chrome's running as process 12,400. So the next time I opened a tab actually received a callback here in Cobalt Strike and I use a tool called cookie monster. um it's essentially a bot that

operates in memory to retrieve not only the cookie but also the key and the password um for whatever operating system I'm currently running under. Uh so once I download both that password and um cookies database uh inside of the project is a decryption script that takes the key then the database file and then you have a few different options. The first one being just passwords. In this case, it outputs all of the passwords uh to your console and you can try to use that to log in. Um or one of the things you can do is output the format to another tool called Cuttlefish um and utilize its NodeJS code to import or inject the cookies into your browser.

Um, it has additional functionality outside of that, but the nice part is you can just give it the JSON of the cookie information and then we can just load our own cookies that we just stole into our own browser session, proxy it through our target environment uh, in order to circumvent stuff like MFA or even conditional access policy. So, at this point, I'm just proven that I stole the cookies uh, for my target user, Andrew Gomez, and logging into the Entra ID portal. And so you'll see it's going through that revalidation of my cookie process here. That's what that little spinning bar was showing. And now I didn't have to enter a password. It still was using my cookies to access uh

Muggle Hackers as my uh user. And so um actually I'll go ahead and let the next one play. The same thing can be done from a system context. Uh the only difference is now we need to reimplement that decryption process as system. So since we're at the highest level possible, we can utilize the machine key as well as impersonating a user to retrieve um their key and then decrypt the credentials uh or in this case decrypt the key utilized for storing the password and the um cookies in an encrypted format. So uh all I'm showing at that point is that the passwords and cookies can be decrypted uh as an administrator in this case as system. So

um what's the biggest difference between using that comm object interface inside the elevation service and recreating the entire decryption process on your own? Um well I had mentioned there was that post-process data function that only Chrome implements. So, browsers like Edge or uh Brave, after it's done decryting it the second time, the only thing you're left with is the key used to decrypt those cookies and passwords. Chrome decided to implement some additional protection measures here uh in a sense where it first checks one of two things. Am I domain joined? If I am domain joined, I'm going to use a static key to um decrypt the appbound key once more. If I'm not domain joined, I'm

going to use a static key um for a different encryption format in order to decrypt that key. So, without having to really go into the nuances, just imagine if you're Chrome, there's the keys encrypted three times instead of two. If you're Edge or Brave or whatever the other uh browser is, you've only really encryptting it twice. Um, so we'll jump on over to the next slide. Uh, that leads to the last issue. If you're not operating as Chrome or as Edge, you don't have a handle to the file in use. So, if you've ever tried to copy a file that's currently open, you get this lovely popup that says file in use. Um, and so

what was implemented in that buff or in that tool that we demonstrated there was um, it numerates all current processes and looks for what has a handle to the name of the file you're interested in. In this case, the cookie or login data file and then it duplicates the handle to that file and downloads it. Uh, in the instance of something like Cobalt Strike, it's got a fileless download feature. So that way you don't have to worry about dropping or copying that file to another location. Um, but in other C2 instances, it has the ability to simply take a handle to that file and then copy the contents to another location. So, you can then download it.

Um, that's just a specific thing with Cobalt Strike versus other C2s that I haven't been able to implement the tool across all the others for fileless download. Um the other much more simpler option if uh you if uh the cookie file is in use but you for some reason just can't happen to get a handle to that file just terminate all other browser sessions and then that file is no longer in use. That method or that option tends to be a little bit noisier though. Um and then jumping into that um detection opportunity. So, by default on a Windows operating system, there's really not going to be any logging being done for DP API activity. It needs to be

um enabled in inside of your group policy. Uh essentially, you'll go down to Microsoft Windows Crypto and the DP API folder. And then there's a debug option for audit DPA API activity as well as audit process creation u activity. When those are enabled, you get your 4688s and your 16, uh 385 event codes or event IDs. But there's one giant issue with the with the uh DP API logs. It doesn't actually tell you who's doing the activity. It just tells you a key was decrypted, which is kind of useless. Um ultimately, what you can do is enable debug mode for that event ID. Uh there's a little screenshot of a PowerShell script um there that essentially enables the debug

mode and then that adds what process ID is doing the operation and what type of operation and including what kind of data. Um I believe here in the next slide I'll show that a little bit more clear. So when you have that debug log enabled, it's now showing, hey, crypt unprotect was performed by Google or on the Google Chrome key and the process ID for that happened to be 9108. And then when you go to reference that to system event ID 1 or your process creation event for 4688, you can go back and look at the image and you're like, wait a second, B.exe, that's not Chrome. That's a highly abnormal. That's potentially activity of someone trying to decrypt

the Chrome or Edge keys. Um, we've already done the demo for this, so we'll go ahead and skip on through. Um, but at this point, if your brain didn't already hurt from all of the different encryption, decryptions, and how to go about stealing stuff. Um, sometimes there's much more simpler ways to go about stuff. Uh so some of the research that we did ended up looking into the Chromium APIs that are built into your browser uh Edge, Brave, they all kind of use the same backend APIs and you can essentially when you enable something like the remote debugger port or load your own browser extension, you're able to interact with those Chrome specific API calls in order to

retrieve stuff like cookies. Um, and so we'll show what that looks like in the demo. But in order to enable the remote debugger port, uh, recently back in March, um, they discovered or Chrome/Google discovered, hey, people are just instead of dealing with all this encryption stuff, they're just enabling the remote debugger port. We're going to make it harder. Uh and so what they discover or what they implemented only in Chrome, it's specific to them is when you enable the remote debugger port, we're not going to allow you to also load the same uh user data directory where the cookies are located, where the extension settings are located. You have to because it's really abnormal for a regular user. Um you have

to specify an alternate user data directory, which is a great way to circumvent this. Um, so that way the next time someone launches Chrome, it's not going to have any of their information. It's gonna be highly abnormal. You could still potentially trick a user into launching Chrome in this manner by simply replacing their shortcut file on their desktop to do this action. Uh, so that way the next time they log in, they're like, "Oh, well that's weird. I'm not logged into anything anymore." And now they're logging back in. And now you've potentially got the opportunity to dump cookies via an alternate user data directory. It just requires the user not to be cognizant of why am I no longer

logged in or why are my extensions no longer loaded. Uh this doesn't happen to be the case in MS Edge or in Brave when I was doing my research. Um you just kill all instances of Edge, launch it again with the debug port and you're good to connect to it. Um which was highly interesting. So I mentioned there's those Chromium based API calls. They have all of this information completely open source and you can just kind of read through their documentation. It's got significantly more powerful API calls outside of the one I'm mentioning here, which is the get all cookies. Uh, in this case, you just need to ask or interact with that remote debug report. Uh, send it a

websocket connection and send it uh a JSON saying, hey, the specific network um, get all cookies API call, that's what I'm sending to you. What do you have for me back in response? And then from there, it returns a JSON of all of those cookies. and you can retrieve uh that response and then save it to a JSON to load later on into something like Cuttlefish. Um as far as detection opportunities, it's pretty straightforward. All you really need to do is look for those process creation events where remote debugging port is in the in the parameters. It's highly abnormal for a regular user to be doing this. maybe a developer if you're in a unique

environment where you're creating custom extensions, but it's not something that's normally implemented or utilized. We'll come back to the demo for this just because it's pretty short one. Um, and we'll jump into the malicious extensions. So, using those same Chromium API calls, instead of loading it and interacting it through the remote debugger report, we can call those inside of an extension that we load ourselves. Um, I believe roughly also in March, if not April, Chrome decided, well, we shouldn't let anyone via the CLI just load arbitrary extensions. But at the same exact time they implemented this change, they quietly or silently implemented an additional feature called the disabled feature flag. Um, so you're no longer able to with Chrome just load

arbitrary extensions via uh specifying a folder path. you actually um or so they wanted to say you can actually still load extensions. You just have to use an undocumented feature called the disable features uh specifically the disabled load extensions command line switch. Uh and in this case it doesn't apply to Edge or Brave. They said go ahead load whatever extensions you want whenever the um process is first created. Detection opportunities in this case are pretty similar as before. It's highly irregular for someone to be manually loading extensions. Typically extensions are loaded based off of the settings in a different file. You're not seeing that argument being used um whenever the Chrome or Edge process is first created.

So let's jump on in and look at some of these in a demo. Oops.

So we'll go ahead and show the first one which is the remote debugger. In this case, I'm killing all instances of Edge where they were already killed and I'm launching Edge for the first time. You'll see I'm still logged in because I didn't have to specify an alternate user data directory. And through my C2 platform, I'm setting up a sock session. So that way I can proxy those requests to the remote debugger report and interacting with that websocket to retrieve all of the cookies. I save all that information to a JSON file and use my personal preferred tool for um cookie exfiltration or not cookie exfiltration but for cookie um relaying. And in this case I'm using cuttlefish and the

steerjs script and loading that JSON file to log back into enter ID. Um and you'll see just as before no password required because I still have those valid cookies in that valid session. Um, and there's no MFA being requested in this case due to conditional access policies. I just left it where the user can log in without having to perform MFA. So, one of the ways you could prevent someone from relaying cookies would be for something like the Azure portal, implement a conditional access policy that forces users to log in with MFA each time they reauthenticate for the first time. Um, in this case here is the Chrome extension. It's pretty similar as before. We're calling that Chrome get

all cookies. We're retrieving all the information. Um, and then we're saving it to a JSON. Um, in order to do that, we have to kill all instances of Edge. The same extensions be used for Chrome. Um, and when we load the extension, have a small little popup saying, "Hey, you're in developer mode now. Are you sure you wanted to do that?" But you saw it doesn't really matter. The cookies, or in this case, the JSON file was already saved. In this case, I saved it to the downloads folder. the script or the extension can be modified to exfiltrate cookies, let's say via an HTTP post request or via some other covert channel. You don't have to

necessarily save it to disk. I just did it to show that there will be a popup if you happen to do that specific implementation. Um, from there, the JSON format needs to be converted a little bit in order to be used with Cuttlefish. So, I convert the JSON format to mirror what Cuttlefish requires in order to later on import those cookies and perform a cookie replay attack. And then, yeah, once again, just kind of showing there Coish is loading it the wrong date because demos are hard. And then once again, we're loading um Entra ID. Um not picking on Intra. I just that was what I was logged into that day and it was the easiest one to

demonstrate showing like hey I am who I am on both ends. Sweet. And then the last little bit is what if I don't necessarily want to load all of um oops let's go back. What if I don't necessarily want to log in to uh enter ID or what if I can't because of conditional access policies? Um well in this case uh one of the things we can implement or utilize is uh recreating the OOTH um authorization code flow in order to obtain a um JSON web token and the refresh tokens. Um but this specific attack is really only effective in environments that aren't cloud joined or hybrid joined devices and that's because of the PRT that's utilized. Uh

essentially whenever you log in it's using this token that's signed by your um hardware or by your laptop and when it whenever you sign in it's using that session key to also tie it to your device. So those cookies every single time it ends up going to a certain website um in this case for Entra it's actually saying like hold on when you sign this key are you still that device? Um, and so it does something called proof of possession where it's validating that, hey, you are who you say you are. You are still that device that you say you are. Um, and that's something that you can circumvent using um different trade craft. We're not

going to go into it, but if you're interested in some of that trade craft where um you either steal the PRT or or log in via Kerros authentication, uh, Durkan has a really great uh, repo for road recon and road tools that I've linked in the presentation. And all these uh slides will eventually be on GitHub on uh myself and Interero's um GitHub. But let's say you are on just a regular workstation. They're not hybrid joined or intrajoined. Um what does that login process look like? Well, first endpoint we have to hit is the OOTH version two authorized endpoint. And what we're doing is we're providing that ESTS off persist cookie to the endpoint. when it replies, it's going to

give us an authorization code that we we can utilize to interact with the token endpoint and then eventually returns back to us not only a refresh token, but also the JSON web token for the specific client ID that we're trying to access. So, it can be it can be a client ID for something like Azure Power Session, something like Teams, Outlook. You don't necessarily have to go into the browser and access those websites. uh you can just specifically request uh those specific JSON web tokens and then pass them into additional tools. Um and so what did that process look like in regards to figuring it out? It really just involves reading some of the documentation and then looking at some

of that Burp traffic and seeing like oh these are the endpoints we're interacting with. This is the information that's being returned. Let's recreate all of that inside of a Python script so we can automate that process instead of using something like Burp. Um, and so that's one of the tools that Entro created, which is the Git access token with single signon cookie. Um, that's currently live on his GitHub repo. And so we can, um, utilize that to pivot into different portions of the Entra suite. Um, but you'll see it's not going to go completely unnoticed. Um, in this case, Entra is logging signin events. And even though I'm using that cookie for authentication via those

APIs, it's still being logged and monitored in your sign-in events inside of the Entra admin center. Um, and in this case, you'll see it even says for what application. So the detection logic in this case is for specific users. Let's say you've got a group of users in HR. It would be highly regular or abnormal for them to log into an application like the Microsoft Azure CLI. you probably only see them logging into something like Outlook, Teams, etc. Uh so you can start building some detection logic around abnormal login requests from for different or weird locations. Um and so yeah, the final demo is showing off uh Entara's tool. Uh we love it when people always when

every website you go to, they're like, "Oh, do you want my cookies?" And like, "Here you go. Take my data." And so here's that final tool being utilized. Uh essentially at this point we've already accessed uh those cookies. We have the ESTS off cookie. We're pasting it on in to the Python script and it's going to automate going through that login process to receive back the JSON web token uh that you can then utilize in additional or other tools. Um, not really highlighting. I didn't expect to have the time to really highlight what you can do with that token, but just wanted to highlight there's other use cases outside of just importing it into Cuttlefish or to your

browser via cookie editor. Um, in regards to, if I can get to the next slide, in regards to cookie protections in the future, don't expect your browsers to become all of a sudden magically hardened. Uh, really what I expect to see is what you see in Entra. you're starting to see proof of possession being utilized and that's specifically something that was called out by Google uh when they implemented appbound encryption. Um by implementing proof of possession by signing your cookies via a key generated by your device, it's going to make it a lot harder for thread actors to essentially just steal cookies. At this point, it would raise the barrier to be even higher. Now you have to go onto the

device itself and try to steal something like that PRT that was being utilized to sign the cookies. Um, in regards to what all this research came from or even some of the locations, um, give a shout out to like the original idea I got this from or the inspiration I got this from is from Mr. Unicoder. Um, he had a great, uh, what's called example of how to steal cookies to begin with. But as Chrome started to change things, uh, different authors out there started to help reverse engineer and discover what that decryption process is, like Snow Crash. Um, and then I've mentioned over and over again, Cuttlefish. Um, that's b done by another co-orker of mine here at

Spectre Ops. Uh, you can find his tool on GitHub, uh, uh, under his, uh, repo, Cuttlefish. Um, and then, yeah, there's bunch of other links there. not bothering to go through them all, but if you're interested in this information and want to revisit it, uh the cookie blog QR code brings you back to essentially all of this information on the Spectre Ops website explaining the information once again showing it off in demos or in this case in screenshots. Or if you want to know more about the com object hijacking, there's inter blog in the other QR code. Or if you just want links to the tools themselves, there's my QR code for my GitHub and the QR code

for Interero's GitHub there. Um, I'll take room for any questions or actually I have to give away uh three prizes or three uh gifts. I guess the first question would be name a browser that falls into the Chromiumbi based family. >> All right, I don't know who answered first. Um, we'll give it to the guy in the back. Um, what's a method of stealing cookies that doesn't involve uh using like a beacon object file and calling the decrypt data com interface? >> Go ahead. >> What's that? >> Yep. We'll give that to him. Um, and then we got to do one last question. I didn't come up with questions beforehand. I'm sorry. Um, oh yeah, I guess. What tool did I

utilize on almost every demo to import the cookies? >> Shoot. I don't even know who answered that. You want to give it to someone? >> Uh, we on the left. I think I saw his hand first. All right. Um, sweet. Uh, I've got room for questions. If not, that was my talk. What's up?

I did not. Uh the client or in this case the agent running on the uh Windows operating system is setting up the socks proxy to allow me to tunnel into the same exact host. So there's no firewall restrictions since the endpoint that I'm reaching is the same one that the agent is on. Uh the question was did I run into any hurdles or technical blockers when running the socks proxy on the um agent? In this case, the answer is no because any sort of firewall implementations or restrictions are on that host itself that I'm already on. Um, any other questions from the audience? All right, that's all I got. Thank you for your time.