← All talks

Beginner's Guide To Malicious Browser Extensions

BSides London · 202513:16186 viewsPublished 2026-03Watch on YouTube ↗
Speakers
Tags
About this talk
Kush Pandya examines browser extensions as a high-risk attack vector, walking through real-world case studies including crypto-stealing tools, OAuth token interceptors, and affiliate-injection schemes. The talk covers how malicious extensions exploit user trust and broad permissions, and provides practical advice on treating extensions as supply-chain dependencies that require careful auditing and permission review.
Show transcript [en]

Good morning everyone. Uh, holy shoot that's a lot of people. Uh, yeah, my name is Kush Panda and uh, I'm a first-time speaker. So quite excited to be here. So today what we're going to be talking about is browser extensions as an ecosystem. uh what I've seen in the wild, a couple of case studies and uh yeah I'll open up to you guys at then for some questions a bit about myself. I did my uh undergrad in computer science back in India moved to US for my masters in cyber security. I'm currently a security researcher at socket. Uh besides that uh I do a lot of gaming. I binge watch anime and uh yeah I used to do standup comic but uh ended

up offending too many people so I had to switch careers there and uh thank god I can say this right finally I play football uh not soccer yeah that's that uh yeah let's get started so let's start with the basics what exactly are browser extensions think of it as a mini applications which kind of runs inside Your browsers has broader permissions than your normal website would have so that it could uh read and modify any kind of pages you are visiting or interacting with, intercept any kind of network requests which you are making across domains and u they also have the ability to run background scripts for a longer period of time without you knowing at all. um your ad blockers,

your password managers, your developer productivity aiding tools, all of these uh are broadly doing that. Fun fact, all of them are written in JavaScript and they run kind of as I mentioned with an extra privilege there. So this is why this is a interesting attack vector for uh all the malicious threat actors out there. when you think of it uh they can manipulate anything they want and also it when you install any kind of browser extension it doesn't just feel like uh you know installing an application it's a click and go thing you just install it and boom there it is it will run there and that is why installing or slipping in malicious code in there is uh quite

easy so we're just going to look at a couple of case studies I found while uh browsing and scanning this ecosystem The number one is uh a Chrome extension called Crypto Copilot. So when you look at the UI in a way looks totally harmless, right? It's a Solana trading tool. One click to go and the way it's being marketed, it's quite clean and all but what happens behind the scenes is quite devastating. uh whenever you perform a swap for any kind of transaction you are making there silently there is a hidden fee which is being siphoned uh which amounts to let's say if your Solana swap is more than 2.6 six Solana coins which are being

transferred 0.13 Solana will be just taken off siphoned as a hidden fee. Now that might not seem a big amount for an individual because it's so small. It's nearly about 0.05% but when you think of it at scale it could just be so devastating. And the worst part is that there is no UI which pops up in this case. So let's say there is on your typical platforms it's like it does show you a platform fee transaction fee no this just is so hidden and it just isn't the logic deeply offiscated inside the code this kind of bypasses all the audits and guideline rules of uh the Chrome marketplace in that case and uh yeah the

big takeaway is uh crypto extensions and crypto in general is a huge huge high value target for the start attackers when it comes to any kind of uh marketplace extensions. Uh the second one is a Firefox extension. It's called Cal Sync Master. Again, claims to be uh Google Calendar syncing tool. And honestly, it kind of looks convincing based on the readme and uh yeah, the way it's kind of designed. But here's kind of what I found when I dig into this particular code was uh whenever the user kind of connected to Google, it would definitely trigger a real oath login flow. In that case, it would just do the normal workflow. Nothing suspicious. uh but after the

user had kind of authenticated uh the extension would intercept the access token the o token in this case and it would uh just transfer it to a C2 which is not even known or like you can see it's clearly not advertised that we are going to take away our o token is nobody would I would assume nobody would install this then in that case uh but the worst part is this is not like stealing a password This is way worse than that because O tokens kind of bypass your MFAS or any kind of broad permissions you might have given to it. There was recently an attack based on this where the North Koreans kind of

took this oat tokens and they manipulated the Google calendar meets and etc everything which was in the scope permission of that particular token and delivered malware by just an invite. It was an interesting read here. Like the beauty of not beauty, the horror basically of this attack is that it didn't look malicious at all. There was like no popup, nothing, nothing shady. Just a normal login and boom, your whole account is compromised. And uh yeah, the last one is called Gimme Gimme. I don't even know why that name, but yeah, it it kind of presented itself as a shopping aiding helper. So what it did was it would track the wish list you would keep across multiple e-commerce

platforms out there and uh it would act as an extension to track those deals or your wish list whenever there is some kind of discount something popping up. Again on the surface completely harmless normal permissions nothing that would raise kind of any kind of suspicions there but again behind the scene scenes in this case it was uh monetizing the user. So what it did was u whenever user visited a shopping website the extension would kind of intercept the network request modify the URL without you guys knowing at all and it would uh kind of inject some kind of tracking codes which are affiliated to this particular user without the end user's knowledge as well. So let's say you make a purchase

every time the attacker has just under commission on that without you guys knowing at all. This might not be directly harmful to the users, but again, you are just a scapegoat in this for him making the money. So, yeah, like again, no pop-ups, no redirects, no broken functionality. It looks so legitimate, but uh from your guys, it from your guys perspective, it worked very fine, but uh yeah, it kind of abuses the trust there. It reaches the boundary which you explicitly put in here. And uh again, yeah, this is this is why that you need to make sure that malicious extensions won't always steal your data, but rather they would make you a medium to profit themselves in a

way. Uh yeah, so in terms of all the three case studies we see so far, what is something we can do about it? The most I would say the simplest and uh actionable advice here would be treat each of your browser extensions as software supply chain dependencies because that is what it is. It is an independent third party component in your workflow, your code, whatever it may look like. You need to audit it because these are open source. You could get this anywhere you want and you need to make sure you are correctly reviewing them, auditing them, uh you know, maintaining them regularly. you're not granting permissions which you don't understand or you're not okay with and

uh yeah the I would say the less you install the smaller your attack surface would become because trust is the primary thing in security and you should all be very careful what you are introducing there uh yeah that's that's all from my end and uh I would like to give a couple of thanks firstly to Liam for being an amazing mentor and uh socket for making this happen. So yeah, thanks a lot guys.

>> Does anyone have any questions at all? >> Yep. >> Yep. >> Hi. Uh thanks. Great great talk on uh extensions. Just a quick question. How how effective are EDR tools currently at picking up um like malicious modifications to browser extensions that we can because you can you can do we can do the allow list block list for extensions but then if these are existing extensions which are trusted and something gets compromised how effective are the current tools that you're seeing on the market at picking that up? Uh yeah I don't know don't want it to sound like a plugin for any companies but like there are some really cool companies out there uh I don't know

if I can name any but uh co security annex we at socket are kind of doing this to protect the ecosystem but yeah I would say there are a couple of good companies out there who are continuously monitoring this system like the ecosystem. Yeah >> cool thank you. >> Yeah. Here we go. A lot of popular extensions ask for just full permissions even though they are legitimate uh use cases. So uh what level of permissions do you think are asked for that are just completely unnecessary or what are dangerous permissions that maybe most people don't understand? >> That's a really good question. Uh on top of my head I would say anything which is kind of intercepting your URL, any kind

of network request. But again that's a Chrome extension thing where you need to intercept those requests but you need to see where they are being redirected redirected to in a way anything with access to your local storage uh which could steal like become an potential attack vector for stealing your cookies and etc. I think that is something you should definitely look out for. There are like multiple alerts there which you should either use some kind of tool or set it up yourself while reviewing the code. let's say cookies, any kind of redirectional network URLs. I think those are the top ones which makes sense because uh in terms of any kind of browser extensions, it doesn't run on

your system. So there are no system level access, these are the two main things which it would run on. So yeah, I would say look out for those. >> Uh probably got time for one more question. Oh, I'll run to the front. >> Okay. Um thank you for the uh you know great presentation. My question was around uh have you I mean of course you kind of discovered a few vulnerabilities right? Have you tried reporting this to you know Google? Um if so um you know what was their reaction because you know obviously I think if you have done this research this must be you know um you know causing a lot of harm to you know a

lot of people. So have you tried reporting this to them? Uh yes they are quite quick in responses of removing all of those extensions from the marketplace. So yeah, Google, Firefox, whatever think of it, they are quite uh quick to remove any of this malicious extensions once we report it to them. So yeah, they're kind of helping the community a lot. >> One more maybe. >> Yeah, one more. >> Let's go. >> Hi, thank you. Um you mentioned that these extensions are written in JavaScript. Is there is there how much now at this point in time how much WOM is there instead of JavaScript for extensions? >> So there's not much wom that I have seen

in there. It's mostly offiscated code which is again JavaScript but it it doesn't resemble much wom so I would say not that much of Wasom that I have come across personally but a lot of offiscation which kind of makes it difficult to audit that code and review it thoroughly. >> Right. when they're delivered by WOM, that'll make it um >> even more difficult. Yeah. Yeah. Yeah. >> Cool. Thanks. >> Thanks. Y >> huge thanks to Kush