Living On The Edge: Abuse Of Microsoft Edge For Persistence

Thank you very much everyone. Uh before we start I want to ask you guys a couple of questions. So please raise your hand if you use a Chromium browser. So that is Edge of course Chrome, Opera, Brave, anything like that. Yeah. So maybe the majority of people which um makes sense because 80% of internet traffic comes from a Chromium browser. And then again, hands up. Who uses their browser almost every time they turn on their computer? Yeah, maybe more hands this time. I see a couple of hands not up. Uh you guys kind of scare me because I'm not sure what you're doing with our browser. And then finally, who knows what a Java applet is. Oh, actually much more people

than I thought. But for those who didn't put your hand up, I get to teach you something new today. So, who am I? I'm Alex Brown. I'm a security consultant with Reverse. Um I have about three years of experience as a penetration tester first internally at the Met Office and now [snorts] with Reverse. I have some certificates and my uh my interests are Windows and reverse engineering. So obviously this talk is all about persistence. So we should probably quickly talk about what persistence is. Um it's very simple really. Persistence is anything you do to keep access to a system once you have initial access. So um there's loads of ways you can do this. You know, you could go uh for very

simple stuff which is just maintain maintaining persistence through uh shutdowns or log offs or all the way up to really complicated stuff where you're maintaining persistence like through full OS installs. Um today we're only looking at the simple end. So that's if the user logs off, the system restarts, that kind of thing. And the obvious first thing to look at is just built-in Windows functions. Um so these things like the startup folder or run keys. Um but the problem is these are going to be heavily heavily monitored. So people started pivoting and looking at other ways to get persistence and one common way that came up was applications that are used very often by the user. So this is things like

Microsoft Office or Microsoft Outlook, things that you just use every day and you don't even think about really. Uh and you can kind of abuse built-in functionality in this software to gain persistence. And that kind of sounds like Microsoft Edge, right? Like well maybe not for most people here, but kind of your average Windows user Edge is a default browser. They're probably going to be using that every day. And there are a couple of other things about Edge that make it seem like a really good candidate for persistence. Obviously, it's auto installed. It's the default browser. And if you're doing persistence, you're probably going to be making web requests. And web requests from a browser. Well, that's not

suspicious at all. But it was actually none of those things that first drew me to Edge as a potential persistence mechanism. It was IE mode. For those aren't familiar, IE mode let you run Internet Explorer inside of Edge. [snorts] And it's not just like you're, you know, kind of emulating Internet Explorer. You are literally running an Internet Explorer process inside of Edge, which kind of blew my brain when I first learned about it. I was like, you're telling me that Edge, you know, this modern brand new browser is just a rapper for Internet Explorer at times, this deprecated browser that no one should be using. Uh, and so that got me thinking and doing some kind of research and I came

up with three persistence mechanisms that we can use for Edge. But before I explain these, we're going to have to learn something about Chromium in um internals. So, we're all familiar with browser settings, right? We probably all um change them at some point in time. And [snorts] the way these settings are stored in the computer is in the preferences file. So, this is a file in the user's app data. And it's a clear text JSON file, and it has thousands and thousands of lines for the preferences and telemetry and and that kind of thing. But it turns out not all your preferences are saved here. There's actually a second file called the secure preferences file. And of course we know

it's secure cuz they're secure in the name. [snorts] Well, how is this any more secure? Well, you initially look at it, it doesn't seem like it is because well um the settings are still there in clear text, but you also have these weird hashes going on here. And these are what's called HMAX. Um, HMAC is just a way to ensure uh kind of authenticity and integrity of a message. And the way Edge is using them here is that for each setting it calculates a HMAC and then it calculates a super Mac of all the HMAXs it calculates and it stores those HMAXs along with the settings in the secure preferences file. [clears throat] So, uh, the typical way you use HMAX is

you're sending a message, right? You have a shared key between two parties. You have your message. You use your key to create a HMAC. Send the HMAC with the message. When the party gets the message, they can also calculate the HMAC. If the HMAC um match, then you know the message hasn't been um changed in transit and it's from the person who has the other key. And so like Edge is using it in a very similar way except uh or Chromium browsers are using it a very similar way except it's just the Chromium browser is the sender and the receiver. So the settings are the message and then the secure preferences file is the message and the HMAX. And

it's kind of worth pointing out that the security of this is all based on the shared secret key. And uh you know, of course, you know, this [snorts] is a super popular browser, right? These are settings that they've decided need to be secure and protected. So this key is um you know, can be stored in a really um kind of annoying way if we want to get out as an attacker, right? You can imagine it might be obuscated. It might be split up into different parts. you know, it might not even be stored on the computer, right? It's a browser, has an internet connection. Maybe it's stored somewhere else. Uh, and that's what I thought until I

came across this paper. So, this is HMAC and secure preferences, revisiting Chromium based browser security. And, you know, it's not often when you're doing security research, you have to read an actual scientific paper. So, this kind of excited me just off the face. But what excited me more was the findings [snorts] they had. So two of their critical findings was they looked at all Chromium browsers and specifically at Chrome and they tried to calculate the seed of these browsers and what they came up for Chrome is wait this seed isn't randomly generated per user like it's claimed. In fact, it's not even changed with updates. This browser key is stationary. But it gets worse because Chrome isn't the only

Chromium browser. You have Brave, you have Microsoft Edge, you have Opera. And what they write here, which I think is very fitting, is they got an alarming result that the that the key for all those other browsers was just blank. It was just an empty string. And so, of course, they did the responsible thing. They reported this to the Chromium project. They said, "Hey, you know, your secure preferences are, you know, are not secure. Your your key your key is blank or it's not changing." And then Chrome said, "Oh, yeah, no. Yeah, that's that's kind of right. Uh but sorry, this is out of scope. Like, you know, this requires attackers to have local access and you know, check

[snorts] out the laws of security. If an attacker has access to your system, it's it's not your system anymore. Uh which is great for me cuz that means the secure preferences file that I kind of want to mess around with and the HMAX in it, they aren't really Hmax. Those are just hashes because there is no key. Um, okay. So, we can change stuff in the secure preferences file, but what does that actually mean, right? How are we going to get persistence with that? So, the attack path is obviously we have local access, we secure, we edit the secure preferences file, and then those preferences are loaded by Edge or any other Chromium browser. And we're able

to control the browser in some way. And the three ways we're going to control it are these three here. So, let's have a look at the first one, shall we? The startup URL. Startup URL does what it says on the tin. It's the first URL [snorts] that um that the user will see when they start up their browser. And uh you might be kind of thinking, well, like how are you going to use that for persistence? Um well, if we can control what the user sees, like maybe we can present them the page that they're going to, you know, enter their credentials in. And you might say, well, credentials isn't persistence, but you know, we're in [snorts] a the cloud age

now, you know, and the VPN age, you know, if you can get VPN credentials, well, you have persistence. If you can get maybe Microsoft credentials, you know, one drive, outlook, all these things allow you to persist in an environment. [snorts] That's enough theoretical talk though. Let's have a look at how we'll actually do this. So, here's the settings. You know, this is what we know. Here is the the settings, what it looks like for the startup URL. And here's what it looks like in the secure preferences file. So, we've already gone over this, right? The the values in clear text, but we've got these HMAXs. And we already know these HMAXs aren't Hmax, they're just hashes.

So an unfacker could come in, find this file, change that value, recalculate these hashes, put those hashes in, and when edge loads this back up, it will say, "Oh, yep, this is all correct." And show that URL to the user. How do we calculate these HMAX hashes? So this is how you would normally do it. You would have like [snorts] a seed or a key and you'd have your message. You put those into a function, you get your HMAC. But of course, we don't have a seed. It's empty. So all we have to do is figure out how Edge is uh creating its message. And thankfully for me, some smarter people than me have reverse engineered

um the Chromium project cuz it's open source. And this is how it's done. So the the free pieces of information you need are the JSON path, right? The secure preferences file is a just a massive JSON file. So you just need the JSON path where the preference is stored, the actual value of the preference, and [snorts] the SID of the user. If you can concatenate those all together, you put them into your HMAC function and you get your HMAC. But that's not the only one we have to calculate, right? We have the HMAC and then we also have the super Mac. So, we're going to have to recalculate the superm as well. How do we do that? It's

actually very similar, right? You [snorts] get the JSON value of all the HMACs, you [snorts] concatenate it with the SID, put it into your hashing function, and you get your output. And this is all really good, right? As an attacker, it's going to be quite easy to calculate these hashes, the files in clear text. So, it's going to be very easy to read and write into it. It's all good, right? But there's one problem specifically with Edge, and that's if you ever used Edge, you might realize it starts up really quick. You know, browsers the first time you start, they norally take a little bit to load, and that's cuz Edge are being a little sneaky, right? What they've done

is they've um [snorts] set it up so that Edge runs on startup. Uh and this is a problem for us because once that browser is running, it's going to read those uh preferences from the two files and store that in memory. And if we write anything to those files, the browser is going to compare it with what it has in memory, see the difference, and go, "Oh, the user's updated preferences. Let's write this back to disk." So, how are we going to get around this? Right? It starts up, browser uh starts at startup, and the user's probably not going to close it until they shut down their computer. So, either we're going to have a very, very

tiny window that's probably not going to work most of the time. So pretty crap for persistence. Or we can kill Edge, just shut it down, which might sound like a bad idea, right? The user's probably going to be pretty upset if we just close out their browser. But because we're controlling the startup URL, we get to see what happens. We get to control what they see when the browser starts up again. So we could do something, you know, uh, like, hey, your VPN has been updated. Please re-enter your credentials, you know, something like that. So the user will be less suspicious. The only other thing to know because we are crashing Chrome, crashing Edge, uh

it will record that in its preferences file. Uh and the problem with that is if it thinks it's crashed, it won't follow its normal startup routine. So it won't show the user the startup URL. So all we have to do is uh once we've once we've killed Edge, we need to go into the preferences file. So this is the preferences one. There's no HMAX in here. This is just clear text. And change it from crashed to normal. And then Edge will start up just fine. So, uh, what will this attack actually look like to a user? So, here we've got a user and it looks like they may have fallen for some, uh, capture, uh, scam

where they've pasted, uh, pasted some PowerShell into the run menu, thinking it was a capture, but thankfully they've got Chat GBT to help them out. Uh, and of course, Chat GBT tells us that this is actually just a humorous and misleading capture, and there's nothing to worry about. Um, that's not fake, by the way. That's literally what chat GBT told me every time I pasted this image in. [snorts] So now we have local access to the machine. What we're going to do is we're going to shut down Edge. We're going to edit that secure preferences file, recalculate the HMAX, put them in, and they're just going to start up again to the URL we choose, which in this case

is a Microsoft fishing site. Um, and the user is going to enter in their credentials and boom, we have persistence. Now, you may be thinking, okay, like this is cool and all, but isn't this just worse fishing? I mean, it's fishing that requires local access. And I see your point, but I think there's a couple of things that make this better. Uh, first of all, we get to control when the user gets fished because we're just putting in a domain or a URL. We can just have that redirect to the user's normal startup URL most of the time. And then maybe in a week, a month's time, you know, we want to um we want to get

P, we want to get their credentials. Boom, they suddenly get a a a Microsoft login page and then they never see that again. Or, you know, maybe they get a Microsoft login page, they log in, you get flagged as the account getting taken over, re uh credentials get reset, and then maybe a week later you fish them again. That kind of thing. Uh, also from a defender side, this would be really hard to um to flag if you don't know what you're looking for, right? Because all that's happening is a program is editing a file in app data and then a web browser is going to a URL and if your opsec is good, that URL will

be like seen as a good URL. So, you know, I think it's I think it's a pretty good attack. And [snorts] the final thing that I think makes this especially good is that um users have kind of been trained to enter their credentials into a browser when it pops up. You know, if you've used Slack or any other application that has single sign on, you won't sign in in the app. The application will pop up in your browser and you sign in there. And because you know all fishing um all fishing training is based around hey don't click links in your emails you know um don't go to shady sites just a login popping up in

in your browser is not really covered and users have been trained that this is kind of all right so I think it's a it's a pretty um pretty interesting attack but I know what you're all thinking you came here for persistence you came here for code execution but the problem is right Edge is a secure browser there's no way it would download and run code by visiting a website, right? That'd be crazy. [snorts] Java outlets. So, for those who don't know, um this is a Java applet. It's that little thing down in the the corner there, the little bottom left corner. Um [snorts] and Java applets are they do what they say on the tin. There are Java

application, but it's hosted on a web page. So your web browser goes there, it will download the the Java code, it will run it and it will display the output in the browser. And you know uh Java outlets uh this is quite a simple one but they they get quite complicated as well. So for anyone who's played the game Runescape especially if you played it uh back uh you know kind of 10 20 years ago uh you would have been using a Java outlet. Runescape is entirely done by Java outlets [snorts] and uh so much in fact you can still log in through a Java outlet today. So Java applets can be really really powerful.

Um and the because they're just hosted in a web page, we can use our startup URL to deliver a Java applet. Now this will require us to install Java on the system. But because Java is, you know, a trusted program, it's signed, it's kind of unlikely you you'll raise some red flags there. Um but the problem is right Java uh Java apps are an old technology there's going to be no browser modern browser that supports it right well we already know the answer to this IE mode and um so how are we going to make this work [snorts] uh what we're going to need is we're going to need edge to open in a page in IE mode we're going to need a

Java applet to have permissions beyond the Java sandbox so the Java sandbox is what normally applets are executed in and we're going to need the applet to be transparent to the user Right? If a pop-up comes up saying, "Hey, you know, um, allow this applet to run on your computer, you know, it's going to spook a user." So, how does Edge uh, control IE mode? Well, it's in the settings, of course, and you provide it URL, and it will let you access that URL in I mode for 30 days. But, you know, I know what you're all thinking. Of course, there's going to be some warning message like, hey, you know, you're using I mode, be

careful what you do. >> [snorts] >> Uh, but it turns out not so much. If you visit a page in IE mode, the only thing is that tiny banner at the top and it doesn't really give you anything a user would be concerned about. All it says is you're in an Internet Explorer mode. Most web pages work better in Microsoft Edge. So, um, funnily enough, even though this seems like quite a secure preference, it's not stored in the secure preferences file. So, we don't even have to worry about HMX for editing it. This is secured in the preferences file, and it looks like this. The only thing to to note is the date added. I mentioned

before that has a 30-day expiry. So, what we're going to want to do is when we add this to the preferences file, that date added, we're just going to want to put it way in the future, you know, 2029, so that when um Microsoft Edge calculates when it's going to expire, it's going to be, oh, this is going to expire for another 100red years. [snorts] Uh, and so, okay, we can get it running in E mode, but Java atlets, they execute in a in a Java sandbox, right? So, we're not actually going to be doing being doing anything interesting, right? Well, it turns out there's two kinds of applets. There's sandbox applets and there's privileged applets. And

privilege [snorts] applets run outside the sandbox. And they basically run like a normal Java program. So, you can literally with a Java applet, if it's privileged, have the browser go download Java code and execute it as if you were running Java locally. But how do we become a privileged applet? There's a couple of ways you can do that, but the easiest way is with the Java policy file. So what we can do here is we can define a um URL and we can say any app that running on this URL has all the privileges and this lets us do anything that a normal Java application can do on the computer. So this is read system files, this is launch

applications, this is download stuff, this is this is everything. Uh [snorts] so okay we can run our uh the browser in IE mode or we can give the outlet full permissions but what about these warnings right [snorts] you know the user is going to get a warning like this if you just try and run a Java outlet. Um okay but what if we sign the applet? Okay if you sign the applet with a self-signed signature you actually just get a very similar warning but this time it just says the the signature's been verified. [snorts] Um, and the only way to get around this if you use an official um, certificate authority code signing certificate. And of course, like me, you

probably don't want to spend £200 on a code signing certificate. But there is another way and that is with this button here. Always trust content from this publisher. Now when a normal user does this, clicks this button and clicks run. How Java keeps track of of whether this is a trusted publisher or not is it adds a certificate to the Java certificate store. Um that basically has a flag that says hey trust this certificate from now on. And what we can do is if we export that certificate and import it to a completely different computer, it will have the same effect. So you can have a uh so if we do this on our own computer and then import this

certificate to on our victim's computer uh Java will treat it as if the victim has seen this pop-up, clicked always trust the publisher and run. So they will get no warnings about it at all. And to make our life a little bit easier, we can actually edit the deployment properties file and point it to a uh to a certificate store uh that we create. So that's the bottom line there. The only other thing to flag about this deployment properties file is you're going to want to set caching to zero. So Java applets, what they'll do to save time to the user is they'll cache any applets it downloads. But our applet is malicious, right? So we don't

really want it hanging around on the computer for any um kind of antivirus or endpoint detection to to scan and look at. So saying caching to zero means that the applet will only be around for as long as it's running. All right, well that's enough talk. Let's have a look like what it looks like to the user. So here we go. The user started up their browser. We already know we can control the startup URL. So we point them towards our Java outlet. Here we get a loading bar. Looks like we're um compiling some shaders. And then we're redirected to Google. It doesn't seem that odd. I think most users would just uh move on from here

thinking nothing bad has happened. But if we go over to our C2, we can see we get an agent calling in. And not only does the agent call in, but even though the user's been redirected away from our URL, our agent is still running because Java is its own process. So even though the we're away from the URL, our Java uh applet that in this case runs an .exe is still working. So we only need about 5 seconds of the user looking at a web page to run our applet, execute our program, and get our agent call back, which I think is pretty neat. uh we can kind of use edge to download any file we

want. Uh and then finally our final uh persistence method extensions. Uh for those who aren't familiar, this is probably what most people thought about when they thought about persistence with Edge. This is a quite wellressearched topic and everyone knows extensions are dangerous. Uh but for those who aren't familiar with the anatomy of an extension, it really is just a website. You have an HTML page. You have a manifest.json file. This kind of defines metadata about the extension. [snorts] And then you have any JavaScript uh you want to run. And [snorts] we know extensions are dangerous and very powerful. And you know they can access things like cookies, histories, bookmarks, clipboard, uh debugger, proxies, right? All these things can be

very powerful for an attacker. But what you might not know um is that uh extensions can also run local binaries. So a colleague of mine did a talk at Wild Rest Hacking Fest about this exact thing. you know, exploiting browser extensions for preex and persistence. Um, and [snorts] using something called native messaging, you can actually whenever you're um whenever the browser starts and you have the correct extension installed, it will also start a companion local binary. And not only will it start the binary, it actually has a process for these two things to talk to each other, which means that you can have your kind of implant running uh started by your the browser and then any web requests go

through the browser as well. So this is quite a powerful attack. [snorts] Um but the problem is like silently installing extensions. There are a couple of ways that people have have done this before. So the most common two are force the force install key and the load extension command line. So the force install key is pretty good because um it force is installs the extension and the user can't uninstall it. But the problem is you're going to need abomin privileges to edit this registry key. And if you're familiar with this attack, you're probably going to be monitoring that registry as well. the load extensions command line uh was a good way to get around this, but it's

actually been deprecated in uh one of the recent versions of Chromium, so it no longer works. So, is there another way that we can um load extensions uh without the user knowing? Now, you might be guessing by now that yes, the secure preferences file uh holds extensions. So, we can edit the secure preferences file, put any extension we want in there, and the browser will load it. Not only can we put any extension we want in there, we can give it any permissions we want. Even those permissions that you, the user, would normally have to accept. Uh, which is really powerful. But again, I kind of think what I know what most of you are thinking. Uh, you know, I'm a

mature organization. We have extension allow list. You know, we know extensions are dangerous. We're not just letting users install anything. [snorts] So, let me show you how you can bypass extension allow lists. So uh credit to this goes to rehab from um St. Active. Uh they uh originally published this research. Um so I want to give them credit for for finding this. Now extension allow list if you aren't familiar is a uh registry entry. And what it is is just a list of um uh extension IDs. Uh and now this seems good, right? All extensions have their own unique ID and so if you and only extensions with IDs matching those on the allow list will be

able to load right foolproof right there's not much that can go wrong here except it's how kind of Chromium calculates these extension IDs. Now for a packed extension that's pretty simple because it would have to be signed by the private key. But for unpacked extensions it's a little bit more complicated. And so what it does is it does a SHA 52 50 256 hash of the public key uh and it does some translation to that as well. But you might see the problem here. This is the public key. This is the key that everyone has access to. So if we know what the uh extensions that are allowed on the allow list, we can go find one of

those extensions, download it, unpack it. The uh the public key is stored in the manifest JSON file that every extension has. grab that key and put it in our own manifest.json file. Uh, and this way when we load our extension by adding it in the secure preferences file, uh, Edge will look at our key, we'll calculate the extension ID and it'll be like, oh, this is on the allow list. Come on in. So, let me show you what that looks like. So, here we have our user again. Uh, we know kind of by now they're an AI fanatic. So, here they are trying to install uh, AI browser extensions. And you can see they're getting a little popup there saying that

this extension ID is not allowed. [snorts] Um, but what we're going to do as attackers is in a second we're going to shut down that browser, right? We're going to edit the secure preferences file. We're going to put in our own extension and we're going to make sure that the public key of an allowed extension is in our manifest file. So there we go. The browser's been shut down. We've edited the file. We pop back up again. Obviously, they go back to our startup URL. uh and our agent gets launched again. But uh now it doesn't look any different to the user, right? The only thing the user knows is that in the uh the only thing

the user could notice is that in the top right there's a little tiny extension icon that shows extensions are being installed. Now, we know our user likes AI, so I thought I'd install for them an extension that that kind of helps with AI. So, here they are going and unfortunately they're not getting the answers they're hoping for. [snorts] Uh, but there's more. Okay, what what happens if uh, you know, there's an extension on the allow list, but the user has that extension installed already, right? Surely uh, we can't add any extensions then. Well, it turns out that even if the extension is installed by the user, so in this case, we're using Ublock Origin. [snorts]

Um, we can still uh add our extension, it's actually going to overwrite that extension. And so, instead of Ublock Origin, now they have uh my extension installed instead. Uh there is one thing to note about this technique. Um because we're installing an unpacked extension, uh Chromium will give the user a warning uh that uh this is an extension in developer mode and that you know it could be dangerous to their browser. Uh but the problem with this is that it has a remind me in two weeks option. Uh and so what [snorts] what Chromium does is it will store you know uh when to notify the user again about this. And uh by now you're

probably guessing yes, we can go in there and we can change that value, set it 100 years in the future and the user is never going to know uh that they have a developer mode extension installed. So uh those are all the attacks that uh that I have to talk about today. Uh but [snorts] how can we defend against them? So the startup URL, I kind of mentioned at the start that this is really hard to defend against and I think there's only really one viable way and that's to uh add an alert onto the secure preferences file of the browser that if anything tries to um modify it that isn't the browser to alert on that. Um

and then Java outlets. So this one's a little bit easier to defend against cuz it's quite again quite a lot louder. The most obvious one is to disable IE mode. Um, you should definitely do that if you're an organization and you don't need IE mode. Some of you do will need IE mode. Um, so probably the best thing you can do in that case would be kind of application allow listing. Don't let your users just install uh random stuff. So then as an attacker, you wouldn't be able to install uh Java. Uh, and you can also kind of do vulnerability and patch management um flagging for old versions of Java, that kind of thing. Um, if you are kind of in

a snowflake or that is running an old version of Java, I would love to hear from you. Um, because I'm not really sure what you would do in that case. I don't know how you could defend against this. Um, and then finally, our final attack. We talked about extensions. Um, obviously the easiest way to deal with this is just to fully disable extensions, but I'm going to imagine most orgs here don't want to do that. Users kind of like extensions and it can be really useful for their job. [snorts] Uh, the second thing you might think about is force install instinctions. So that's the the uh kind of attack we talked about earlier for silently

installing them, but this time you're using it legitimately to install extensions for users. Now, this will work in preventing an attacker from installing an extension. Um but you shouldn't um just assume that because it's force installed, it's always going to be installed. Um, if you edit the secure preferences file to try and install an extension uh over a forced install extension, uh, when the browser loads up for the first time, it will actually have no no extension installed. So, that's a kind of neat little attack if you're trying to get rid of a uh maybe an extension that's protecting the user. Um, things that will make a difference, you can manage allowed uh permissions for extensions. Um, this is

probably the best way to do it or maybe the second best. um aside from fully disabling them all. But yeah, managing allowed permissions, there's tons of permissions um that uh extensions can have. And if you just go through all the extensions that your kind of org needs, you're going to get a list of all the permissions you need and just to staple anything else. Um you can also prevent uh uh extensions having access to certain sites. And this can be really useful especially if you have uh sites that you know your users are going to be putting kind of sensitive information into or doing sensitive work on because extensions can get full access to a

site. So just disabling access to that is going to uh significantly reduce your risk. [snorts] Uh the final thing if you're very risk averse organization uh it might be worth just doing a review of your installed extensions before you kind of manage allowed permissions. Uh we have done this for um uh clients in the past. Uh and I think it's been quite useful. Uh the the final thing that you should be on the lookout for is uh if you're loading extension for the secure preferences file, that extension does have to be on disk. So just setting up alert looking for kind of the manifest JSON file or any other extension indicator installed in a weird place on

the computer. Uh, and finally, Microsoft does have a guide on on how to do all these things. Uh, final thing I want to talk to you about is disclosure timeline. So, a few days ago, Microsoft did reach out to me just to make sure I wasn't going to release kind of any unreported vulnerabilities. I let them know I wasn't. Uh, they asked if they could still see my slides, and I I gave them a PDF of my slides. Thank you. That's my talk.

AWESOME. [applause] I think uh we've got plenty of time for questions. So, if anyone has any questions, I'd be delighted to answer them.

[snorts] >> Hello. Um so the secure preferences file um if you're already uh if an attacker has already got in and has persistence [snorts] how can you how could you troubleshoot that? How could you find out please? Yeah. Um it's going to be quite difficult because obviously the whole the whole way we're establishing persistence is by making it look like we're legitimately editing the file. So I think the only way would be to look back um if you have logs of processes that have been accessing this file and look at those processes. Um obviously you could look at you could start up the browser and see if it does anything weird that would be like the

only the other way to troubleshoot it. Probably the most effective. Uh but if you're looking at from like a pure like kind of technical point of view. Um yeah you just have to look at the logs and hope that you've been logging access to that file. Otherwise there's no real way to know. Yeah. [snorts] >> Um, yes. So, thanks for the tour. Really enjoyed it. Um, I I just wanted to revisit one bit. So, you mentioned with the Chromium based browsers where for Edge basically you didn't need to supply the key for the HMAC. Is that the same for all Chromium based browsers or do the other ones have like just a hardcoded key that you don't need to

figure out? So, um, from [clears throat] from the paper, so I haven't tested this myself. I've only tested Chrome and Edge. Um, so yes, Chrome is the only browser that has a key, but that key is static. For all other browsers, the paper tested. So that was Microsoft Edge, Brave, and Opera. I believe they didn't have a key. It was just an empty string.

Thanks. Assuming a user's got local access in order to edit secure preferences file, would it not be easier for him to go straight in via the guey um edit it there um and then allow process to run or is the output on the guey unchanged if you edit the secure preferences file so it gives a a different output. So, uh, if yeah, if you have desktop access, it might be easier just to go in the browser and change those settings. Uh, there are a few settings to note. For example, IE mode, right? You'd still have to go in and edit the preferences file so that the uh it didn't expire. Um, uh, and as well, if um, uh, there was a as well as

the, uh, extensions as well. Um I if you're loading uh if you're loading an unpacked extension and there is an allow list or a block list uh you won't actually be able to do that in the browser. You will only be able to do that for the secure preferences file. So the first two attacks, yes, you could do those in the GUI. The last one you would have to do it for the secure preferences file.

Um, so my question was, what do you think the odds are of like an out of the box team detecting this if it wasn't configured with this attack in mind? >> Uh, I think very low. Um, as long as you're like not doing like for example, if you're doing the applet one, uh, [snorts] but you're doing it with like a a a well fingerprinted payload, you're going to get flagged there. But as long as your ops is good, um, yeah, it's it's not going to get flagged because again, you're just a program that's editing a file and app data. Like there's, you know, that that happens so frequently, I don't think it's ever going to get

flagged.

>> Hi. Um, thanks thanks again for the talk. Um, I'm also thinking about this whole hate the initial sort of HMAC thing. Um, I guess if Chromium sort of turned around tomorrow and said, "No, we do consider um someone with local access part of our threat model." Now, I guess would the would the patch be that they generate a shared key with a random from a random seed like on install? Would that [clears throat] fix the problem? >> Yeah. So, it's quite a hard problem to fix obviously because at some point that key is going to have to be on the system. So, if it's on the system and you have local access, an attacker is

going to get access to it. Um, I believe the the solution that was proposed in the paper is you could use something like Windows um TPM to store the key in. So, that would add an extra level for the attacker to break into to get that key. Um, but I don't see I don't see Chrome doing that.

Um I just wanted to revisit that one about uh native messaging you mentioned. Um is there anything uh beyond the secure preferences or regular preferences fold that needs to be done for that to trigger the application to launch and start up? >> Yeah. So [snorts] there is one other thing that would would have to be done for native messaging. Again I encourage you to go watch my colleagues talk at worldfest. He covers all of this. Um but you would have to add a registry key that points to the local application uh for for the browser to know what to run. So there would be another step. Yes. >> Thank you.

>> Oh [snorts] questions today. Love it. >> Thank you very much for the talk. Um, so we tried to lock down IE mode uh with group policy. We found that broke uh some native Windows tooling um off the back of it. This still uses IE mode. So bit of Microsoft saying do one thing but our tooling still uses it. Um is is your is your research pre or post the changes that Microsoft made? >> Uh sorry, say that I get lost again. is your is is all your research pre the uh changes that Microsoft made to edge IE mode with the restrict the native restrictions. So for consumer devices now it's not visible at all in the in

the preferences. I don't I haven't looked further if it's to actually restricted in the preferences file. So the only thing I'm familiar that they recently did to IE mode was they changed the the guey. So before you used to have a button that you could press. Is that what you're talking about where you could toggle into IE mode? Um yeah. So, they got rid of that button recently, which kind of upset a few people. Yeah. No, that doesn't affect my attack at all. Um because you can still go if you if you want an um a URL to run in I mode, you can still go into the gooey into the settings and and change it

there. They've just got rid of the button so you can't toggle it on on or off. I don't know why they've done that, but yeah, it doesn't affect uh affect the attack at all.

>> [snorts] >> Cheers. So if the original callback is running as a user, can you edit the secure preferences file or do you need to be a privileged user? >> No. Yeah, because the secure preferences file is an app data uh just any uh well the user that the app d of that owns the app data can edit it. So yeah, you don't need any admin privileges or anything higher than just a normal user to edit the file. >> Right. Okay. Thank you. >> We have time for maybe one more.

>> Hello. Um my question is have you seen these techniques being used in the Y for example by threat actors before? >> Uh I haven't seen it used in the wild. The one thing that is actually probably I probably should have mentioned this in my talk. A couple of days ago, it was uh brought to my attention there's a GitHub project called Chrome alone that exploits the secure preferences file. Um and they claim to be able to install an extension that has um basically uh full C2 capabilities. So, uh be able to run uh programs uh as the user and stuff like that. I haven't been able to verify it for myself, but yes, there there are

I think this is about 4 months old now. So there are projects out there that would allow someone to use uh this technique to uh as a C2 like as a prophecy too. Thank you. >> Thank you very much everyone. That's uh all the time we have for questions but let's hear it again for Alex.